|
Welcome to MUGS ⚄♠♞🏹 (Multi-User Gaming Services)! | github.com/Raku-MUGS | v0.1.4 has been released! (github.com/Raku-MUGS/MUGS/blob/mai...v0.1.4.md) | This channel is logged for historical purposes; logs at irclogs.raku.org/mugs/index.html Set by japhb on 3 March 2024. |
|||
| patrickb | Quick question: In TW, is it possible / sensible to dynamically remove widgets from their containers? a %.by-id<some-widget>.parent.remove-child(%.by-id<some-widget>); Followed by a relayout doesn't seem to do the trick. | 09:26 | |
| Well, I'm just as interested in adding it back again later. ;-) | |||
| [Coke] | japhb: do you have a sample somewhere (I'll need it to work on mac & windows) that I can have a progress bar on the last line of the terminal, and then dump screens of output (in chunks) that scroll by above that last line? | 15:05 | |
| (and ideally,if you pipe through this program, it would just emit the text and ignore the progress bar) | |||
| Right now I'm using Terminal::Spinners and it's just redrawing the progress bar occasionally (so snapshots of it scroll up with the text) | 15:06 | ||
| japhb | patrickb: You can add and remove widgets from containers, but that' | 19:39 | |
| s generally done for temporary floating widgets (which I don't have canonical examples of yet ... that's on The Big List, of course) | 19:40 | ||
| For widgets that are part of the main layout, the problem you're facing is probably that the widget tree and the layout tree both exist (with links between them). Generally the widget tree is simpler than the layout tree because many layout nodes do nothing but constrain their childrens' placement, rather than actually create another layer of widgets that do nothing but pass compose requests around. | 19:42 | ||
| So when you do the relayout, it probably notices that the matching widget doesn't exist for a given layout node and goes "OK, guess I need to create that!" | |||
| It sounds like it would be useful to have some more DOM-ish functionality there. Would you mind posting a feature request issue for it? | 19:43 | ||
| [Coke]: Do you want the scrollback buffer to work normally, despite the transient progress bar? (If so, that's not T-P or T-W, both of which depend on using the "alternate display" VT mode, which in most terminal emulators does not store content that scrolled offscreen.) It can be done though, even using capabilities that are *more* portable than T-P and T-W. | 19:46 | ||
| If you post a gist somewhere of an example of your *current* technique (so that I can see how you're integrating the output streams), I can probably come up with something. :-) | 19:47 | ||
| [Coke] | I'd have to strip it down to an example, it's currently under work licensing. | 20:42 | |
| It's really just running a bunch of async proc like P::A.new(['git', 'clone'...]) with a react that whenever $proc.stdout.lines { ... ; .say } | 20:44 | ||
| Which itself is just: a bunch of `say` calls that are interrupted by occasional calls to the progress bar's .show | 20:45 | ||
| japhb | Ah, OK. Can I assume at least Unicode 1.1 UTF-8 support, or do I need to do ASCII? (Windows Terminal needs to be set to UTF-8 manually -- it's not default apparently -- so some people want to go ASCII-only for Windows stuff to be distributed to non-experts.) | 22:49 | |
| Recent versions of MacOS seem to have pretty decent Terminal defaults. | 22:50 | ||
| The only difference FWIW is that with Unicode 1.1 you can have smooth progress bar updates even if the number of actions is quite large; in ASCII it's not as smooth but still works fine. | 22:51 | ||