| 11 Jul 2026 | |||
| wayland | tbrowder: Good question. I think they look like individual user instructions, but I'd advise asking on #raku or maybe #raku-dev, since these will get it in front of more of the relevant people :) . | 01:55 | |
| patrickb | tbrowder: I wrote that readme. Thanks for your suggestions. | 14:01 | |
| tbrowder | yw, thanks for all you do for raku! | 16:12 | |
| patrickb | Let me explain why I wrote it the way I did. The precompiled packages where the readme is deployed in, is built to allow a typical "download, extract, use" workflow. They are self-contained. One could in principle try to deploy them system wise, but that's not a use case I tried to target. | 18:45 | |
| For system wide installation, a distro package (e.g. rakudo-pkg, or the ones of the distros the self) or "make install" are better suited. | 18:46 | ||
| That's why I didn't add instructions of how to install them system wide. I could add a sentence stating the alternatives though. | 18:47 | ||
| 13 Jul 2026 | |||
| tbrowder | got it, that explains it better. perhaps a lead-in comment would help explain it to us old ppl. ref rakudo-pkg, that has always been my choice, but i'm having trouble getting it on my new debian trixie install. i put two gists on irc #raku showing the errors i'm getting. | 13:26 | |
| in the meantime i'm using trixie's rakudo-pkg which is raku 2024.09 | 13:30 | ||
| 16 Jul 2026 | |||
| SmokeMachine | Hi all! wayland76 suggested me to talk about this here too: fco.github.io/Raku-Playground/ | 23:42 | |
| 17 Jul 2026 | |||
| japhb | Very cool, SmokeMachine++ ! :-) | 00:18 | |
| 18 Jul 2026 | |||
| ab5tract | Not strictly mugs related, but I've been vibing with Claude to create a PostScript-driven display server (Rust) and a UI framework called Pang (Raku). | 10:56 | |
| The eventual idea is to enable a sort of "live-code-able" UI design environment. The actual rendering happens on the GPU so per-object shaders are possible. | 11:01 | ||
| Another main goal (probably the closest connection to #mugs is to have the display server running via the framebuffer (eg, you don't need wayland or x to use this Pang thingy) | 11:03 | ||
| tbrowder | i just found the trixie rakudo-pkg install problem is caused by another package: softmaker by a German company. | 12:48 | |
| rakudo-pkg installed fine on another upgraded deb trixie host without softwaker installed. | 12:50 | ||
| japhb | ab5tract: Sounds like a fun project. But also a really hard one. :-) | 20:38 | |
| 19 Jul 2026 | |||
| ab5tract | The idea is that any programming language that can emit text and read from a handle can create a UI (or UI framework). Right now that goal is a bit obscured because everything happens through mmap'd "files." But the plan is to also provide a slower, text-only path that even bash could just cat into | 10:57 | |
| wayland | Just got tagged by the reference to wayland! :p . It's been a constant problem ever since they started using my name. Well, not constant, but I probably get tagged in some random github issue once a year. | 22:52 | |
| ab5tract: Sounds interesting! | 22:53 | ||
| japhb | There was an entire generation of CPUs sharing my name. I found it absolutely hilarious that I would get bug and incident reports. Thankfully I was not flooded with them -- people had to be pretty darned confused to end up at my doorstep -- but nonetheless I would happily celebrate a crash bug by taking a nap. | 23:38 | |
| 1 Sep 2026 | |||
| patrickb | Quick question: How would I add a border around a dialog? Setting border width on e.g. a label works, but it seems to not have any effect on a node or center element. | 15:23 | |
| japhb | Make the surrounding .node a .widget instead, which gives it a drawing surface. Most of the layout methods that don't name a particular widget just create simplified layout/placement nodes that do not actually directly provide a drawing surface. | 18:17 | |
| But if you use the .widget layout method, it creates a generic Widget to scribble on. This will also give you a central point to filter events destined into your dialog, since events travel through the real widget hierarchy, not the layout tree. | 18:18 | ||
| I can't believe those lines ended up the same length purely by chance. | 18:19 | ||
| patrickb | Did that last message end up in the wrong window? | 19:05 | |
| Thanks for the quick reply! I'll try that! | |||
| japhb | Nope, it was referring to the two lines right above it (which are exactly the same length in my maximized irssi window). | 19:07 | |
| You're welcome, and good luck! | |||
| patrickb | Ah! No chance I would have noticed that on this smartphone with a non mono space font. :-P | 20:45 | |
| japhb | Heh | 20:58 | |
| 2 Sep 2026 | |||
| patrickb | I just realized that I still have three open PRs in T-W. Can we get those in soon-ish? | 12:46 | |
| japhb | Nod. Remind me over the weekend if you haven't heard by then. | 15:44 | |
| 3 Sep 2026 | |||
| patrickb | Architectural question: I need a static rich text widget. I.e. non-focusable, non-scrollable. Pretty much what PlainText does, but with RichText support. | 13:08 | |
| I tried stripping down Viewer::RichText, but that gets ugly when trying to disable scrolling and focusing. | 13:09 | ||
| I tried adding rich text support to the PlainText widget (or create a copy named "RichText"). But PlainText does have support for wrapping, replicating that would duplicate the better part of WrappableBuffer. | 13:11 | ||
| I then tried to have PlainText inherit from WrappableBuffer. That is difficult, as WrappableBuffer not only provides Wrapping, but also the concept of a cursor. I'm unsure how difficult it would be to pull the concepts of "put wrapped rich text on the screen" and "maintain a cursor including highlighting on some text" apart. | 13:15 | ||
| My feeling is that ideally we should have rich text support everywhere. If so, then having the ability to easily wrap a piece of rich text is valuable to have. Thus we should indeed separate RichText processing and cursor management. | 13:18 | ||
| But ugh, that will be a chunk of work... | |||
| Geth | Terminal-Widgets: patrickbkr++ created pull request #58: Input::Text: Implement &process-change to allow reacting to text changes |
14:14 | |
| Terminal-Widgets: patrickbkr++ created pull request #59: Implement TW::RichText |
14:17 | ||
| 4 Sep 2026 | |||
| japhb | patrickb: Yeah, that will be a chunk of work, but ultimately I wanted to have rich text everywhere (fast pathed for when the full generality isn't needed, like I do with mono/duo text). | 01:35 | |
| It looks like you created a PR for it though, that was fast | 01:36 | ||
| patrickb | nah, that PR just adds a RichText widget without wrapping, pretty much sidestepping the task of generalizing the wrapping logic. | 06:27 | |
| japhb | Ah. | 15:10 | |
| patrickb | Not intending to poke, just ensuring it's seen: Are you aware of the two layouting bugs I reported? | 15:28 | |
| github.com/japhb/Terminal-Widgets/issues/56 | |||
| github.com/japhb/Terminal-Widgets/issues/57 | 15:29 | ||
| japhb | Just haven't had brain space for them. Your poking is completely fair, FWIW. | 15:36 | |
| patrickb | ♥️ | 15:48 | |
| 5 Sep 2026 | |||
| Friendly "it's weekend" poke. | 17:22 | ||
| japhb | :-D | 18:33 | |