31–40 of 63 posts
I’ll have to give this a look! I’ve been looking for a simple way to use Go to write an internal development tool which is basically just a form with some buttons and text fields. I tried Gio, but had a hard time with wrapping my head around it. Right now I’m using wails and like it much better. This looks interesting and worth a look!
I'm curious to hear your take on this: what's the advantage of following the virtual control tree approach compared to instead updating directly the controls that are displayed to the user?
For complex scenarios (i.e. the user interacting with the UI while there are some long-running processes in the backround doing this, too), managing the state quickly gets unwiedly: You need to write callback code everywhere that carefully has to inspect the current status of all other activities and might then updates 10s of widgets accordingly. With the reactive approach you are able to write a single rendering fun…
TextBox { Text: app.currentUser.name }
Instead of having to call setText on that TextBox.
What I'm still missing is why it has to involve a virtual tree being maintained and synchronized with the real GUI tree. The UI engine could implement the above binding by instantiating for the user a callback trigerred when the bound property changes and changing precisely the value currently shown on the screen. Hence, the UI engine is in charge of the callbacks, which keeps the user unburdened by callbacks.
I'm curious to hear your take on this: what's the advantage of following the virtual control tree approach compared to instead updating directly the controls that are displayed to the user?
For complex scenarios (i.e. the user interacting with the UI while there are some long-running processes in the backround doing this, too), managing the state quickly gets unwiedly: You need to write callback code everywhere that carefully has to inspect the current status of all other activities and might then updates 10s of widgets accordingly. With the reactive approach you are able to write a single rendering fun…
The web had a lack of options for state management and hence React coupled the two.
Earlier quoted context omitted.
For complex scenarios (i.e. the user interacting with the UI while there are some long-running processes in the backround doing this, too), managing the state quickly gets unwiedly: You need to write callback code everywhere that carefully has to inspect the current status of all other activities and might then updates 10s of widgets accordingly. With the reactive approach you are able to write a single rendering fun…
I'm already convinced of the benefit of declarative GUIs over imperative ones. To be clearer, what I mean by declarative GUIs is ones where I can specify that UI elements should be bound to certain values in the memory of my program, so that they don't have to be changed explicitly by imperative code. Ex.: TextBox { Text: app.currentUser.name } Instead of having to call setText on that TextBox. What I'm still missing…
Using the virtual tree, you are able to build components which dynamically change the rendered subtree based on the current state.
Was looking for something like this some years back. Though I wanted Windows support too. Ended up switching to C++ to use wxWidgets, giving me small self contained binaries.
Big fan of WxWindows, I'm just too invested into Go these days. :) Self-contained Spot "Hello World" is 2.3MiB on my Mac. Not pretty, but works for me.
Earlier quoted context omitted.
Big fan of WxWindows, I'm just too invested into Go these days. :) Self-contained Spot "Hello World" is 2.3MiB on my Mac. Not pretty, but works for me.
So you didn't like to continue on that? https://github.com/dontpanic92/wxGo
Was looking for something like this some years back. Though I wanted Windows support too. Ended up switching to C++ to use wxWidgets, giving me small self contained binaries.
Earlier quoted context omitted.
For complex scenarios (i.e. the user interacting with the UI while there are some long-running processes in the backround doing this, too), managing the state quickly gets unwiedly: You need to write callback code everywhere that carefully has to inspect the current status of all other activities and might then updates 10s of widgets accordingly. With the reactive approach you are able to write a single rendering fun…
I'm already convinced of the benefit of declarative GUIs over imperative ones. To be clearer, what I mean by declarative GUIs is ones where I can specify that UI elements should be bound to certain values in the memory of my program, so that they don't have to be changed explicitly by imperative code. Ex.: TextBox { Text: app.currentUser.name } Instead of having to call setText on that TextBox. What I'm still missing…
(Or at least, to paraphrase Joseph Heller, “it’s intuitive once you get your head around it”)
Earlier quoted context omitted.
For complex scenarios (i.e. the user interacting with the UI while there are some long-running processes in the backround doing this, too), managing the state quickly gets unwiedly: You need to write callback code everywhere that carefully has to inspect the current status of all other activities and might then updates 10s of widgets accordingly. With the reactive approach you are able to write a single rendering fun…
I'm already convinced of the benefit of declarative GUIs over imperative ones. To be clearer, what I mean by declarative GUIs is ones where I can specify that UI elements should be bound to certain values in the memory of my program, so that they don't have to be changed explicitly by imperative code. Ex.: TextBox { Text: app.currentUser.name } Instead of having to call setText on that TextBox. What I'm still missing…