| 19 Apr 2024 | |||
| japhb | (The one exception that I can see for the above is offering a plugin that runs in the server context and does online translation (via e.g. Google Translate API) for messages sent between players ... but that's not actually translating anything in the Server or Client Game, just offering a plugin to massage human messages sent *through* the Server.) | 04:54 | |
| All of which is to say: My biggest suggestion would be to focus on the game's *semantics* so that I can have time to take the translation system that I designed for MUGS-UI-TUI/Terminal-Widgets and port it to MUGS-UI-CLI. I expect it will save you lots of mess in the long run. | 04:56 | ||
| And as for testing, I think the main trick will be to test the Server Game's behavior in isolation, the Client Game's behavior in isolation, and then do your first integration test with: Test Suite <-> Client Game <-> Server Game | 04:58 | ||
| That way you can test the semantics of the game completely separately from any UI. | 04:59 | ||
| Once those are trustworthy, *then* you can start testing one (or more) of the UIs. :-) | |||
| greenfork | It's a good point that translation should happen on the UI layer | 05:45 | |
| I think I intend to use the Pop game engine as a UI layer. I want to ship games to Windows, so any terminal interaction is not going to be easily digestible | 05:47 | ||
| I saw some work on the Pop UI layer, I will probably try to start there once I get Pop installed, so far I can't gitlab.com/jjatria/pop/-/issues/1 | 05:48 | ||
| About testing: I think I will need a barebones example of how to do integration testing. I can unit test specific parts of my Client or Server implementation | 05:50 | ||
| but I don't fully understand what the entry points are to the whole program | 05:51 | ||
| If you could provie an example, it would be very appreciated, I can start from there | |||
| patrickb | that pop error seems to be a rakudo or even MoarVM bug. | 07:16 | |
| greenfork | patrickb: Okay, I will ask in the main channel, thanks for looking into it | 12:11 | |
| 26 Apr 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 | ||
| 27 Apr 2024 | |||
| [Coke] | unicode is fine. I have a very limited audience that I can tell to do things. | 00:32 | |
| 15 May 2024 | |||
| japhb | Apologies for disappearing for a couple weeks! Life happened. :-/ | 04:49 | |
| Let's see, first [Coke] . | |||
| Here's a (synchronous) program that does work in a pile of Git trees. I use it personally just to see if I've forgotten to finish work, or make sure I've fetched all my upstreams. | 04:50 | ||
| gist.github.com/japhb/8dc8046b5718...1d1fe3279b | |||
| Generally speaking, you should be able to see the most useful bits in the show-progress-bar() and hide-progress-bar() routines. | 04:52 | ||
| I've provided commented-out alternate implementations if you' | |||
| re having any compatibility problems with any of the Unicode or VT100 escape sequences. | 04:53 | ||
| You can see them get used liberally in the big for loop at the end | 04:54 | ||
| For async work, as long as you can serialize the actual output such that hide-progress-bar gets called before printing a regular line (e.g. something captured by Proc::Async) and show-progress-bar after, you're good. | 04:56 | ||
| One simple way would be to create a Channel or Supply that actually manages that, and any other `whenever` blocks that want to print just send to that common Channel/Supply as needed. | 04:57 | ||
| (Normally I license all Raku I write publicly under Artistic 2, but in case your $day-job is allergic to that license, I hereby grant you a license to incorporate/use any of the code there in your work code.) | 05:01 | ||
| (royalty-free, non-exclusive, worldwide, blah blah blah) | 05:02 | ||
| Oh, and let me know if anything isn't clear; I tried to comment liberally for your benefit. | 05:05 | ||
| [Coke] | japhb++ I will have to digest that, thank you | 12:12 | |
| 16 May 2024 | |||
| patrickb | Just to prevent duplicate work: I'm currently implementing a RichText widget (basically a glorified SpanBuffer, including optional wrapping, click events that resolve to the clicked line, optional highlighting of the selected line). | 21:55 | |
| After that I'll tackle a TreeView widget. | |||
| japhb | Oh excellent, those were on my lists anyway. | 23:45 | |
| Thank you for letting me know you're working on them patrickb ! | |||
| 18 May 2024 | |||
| patrickb | Current progress on my RichText widget: github.com/patrickbkr/Terminal-Wid...-rich-text | 22:46 | |
| Implemented so far: Optional wrapping (with working duospace text), selecting lines by click | 22:47 | ||
| Missing: Click event that correctly extracts x/y of cursor in line, Keyboard events | 22:49 | ||