This is a draft of multiple top-level windows (requested in issue #45).
The windows are created outside of the regular tree of Gtk widgets by wrapping a widget with a special "window host" widget that maintains a new top-level window in addition to the original widget. The handle to the window widget is put into the custom state field of the StateTreeNode (the original custom state of the widget is also kept).
This seems to work okay, although I am not sure the design is that elegant. Some things are worth mentioning in particular:
In order to remove the windows when the wrapped widget is removed, I added a destroy method to the Patchable class. An alternative option here would be to attach a "destroy" signal handler to the wrapped widget (that then destroys the window), but I thought keeping the control within gi-gtk-declarative (rather than involving Gtk event handlers) would be more predictable. Does this design make sense?
There is some code in Patch.hs that presents a problem for the destroy method design - I'll add an in-line comment to elaborate on this.
I vaguely wonder if the "extra state in the widget tree" idea could be generalised to something more useful. There could be "custom attributes" that would allow hanging bits of state (with their own patching behaviour) from widgets in the tree. This could be used to easily implement new top-level windows, but also other patching behaviour that could call arbitrary methods on widgets. This would provide something similar to custom widgets, but less flexible and more re-usable - since a CustomAttribute Button Event could be attached to any Button, along with any combination of other custom or regular attributes. Does this make any sense?
This is a draft of multiple top-level windows (requested in issue #45).
The windows are created outside of the regular tree of Gtk widgets by wrapping a widget with a special "window host" widget that maintains a new top-level window in addition to the original widget. The handle to the window widget is put into the custom state field of the
StateTreeNode
(the original custom state of the widget is also kept).This seems to work okay, although I am not sure the design is that elegant. Some things are worth mentioning in particular:
In order to remove the windows when the wrapped widget is removed, I added a
destroy
method to thePatchable
class. An alternative option here would be to attach a "destroy" signal handler to the wrapped widget (that then destroys the window), but I thought keeping the control withingi-gtk-declarative
(rather than involving Gtk event handlers) would be more predictable. Does this design make sense?There is some code in
Patch.hs
that presents a problem for thedestroy
method design - I'll add an in-line comment to elaborate on this.I vaguely wonder if the "extra state in the widget tree" idea could be generalised to something more useful. There could be "custom attributes" that would allow hanging bits of state (with their own patching behaviour) from widgets in the tree. This could be used to easily implement new top-level windows, but also other patching behaviour that could call arbitrary methods on widgets. This would provide something similar to custom widgets, but less flexible and more re-usable - since a
CustomAttribute Button Event
could be attached to anyButton
, along with any combination of other custom or regular attributes. Does this make any sense?Cheers!