3 ms·

Reading the examples given and trying to generalize, I wonder if anyone else has some thoughts on the ideas of more explicitly tracking state and objects in GUI

Reading the examples given and trying to generalize, I wonder if anyone else has some thoughts on the ideas of more explicitly tracking state and objects in GUI applications. It's common in GUI frameworks to have a backing class for each complex GUI element (it could be a screen, or a panel/frame, or a complex widget). In some frameworks, we control invoking the backing classes (as in, we call the initializer/constructor), and in other frameworks, we tell the framework which class to build an instance of for us. In nearly all cases, when we're "done" with a GUI object, we just let go of it, and let the framework or language runtime handle it. If the framework is good, it'll give you some sort of "on_gui_element_undraw" event or something you can handle to trigger your "destructor". This results in some weirdness. For example, if you have a long living socket that is only suppose to be active for say... 3 of 5 screens of an application, now you're counting "on_gui_element_undraw" events to track GUI state to control backend state. I've sometimes played around with the idea of wrapping these frameworks with -something- (I don't know what...) that somehow gives you like... the "history vector" of the GUI... I don't really have fully developed thoughts on this (notably, I really only write native GUIs, and only for smallish internal tooling), but has anyone played with frameworks with more powerful state management?

wwright 8y ago
I imagine that this would be related to separating your GUI code from your “business logic”/“effects”. You can make a rule that code should only ever invoke widget code if it “owns” that widget. Then, have the code “owning” your widget be responsible for both showing and hiding the widget. That code then always knows when to invoke cleanup for related resources.

wwright 8y ago

I imagine that this would be related to separating your GUI code from your “business logic”/“effects”. You can make a rule that code should only ever invoke widget code if it “owns” that widget. Then, have the code “owning” your widget be responsible for both showing and hiding the widget. That code then always knows when to invoke cleanup for related resources.