Jump to content
Posted 08 August 2012 - 05:05 PM
Posted 08 August 2012 - 05:55 PM
Posted 08 August 2012 - 06:27 PM
If anything, I think a central location would actually reduce overhead. If you don't want a manager or globals, you could go for a static members.
As for keeping the information in a centralized location, I want as little overhead as possible. I don't want to wrap my widgets in a "gui manager" class. The application just needs to keep a reference to one or more root widgets, where a widget can be anything from a single button to a large control panel.
Posted 09 August 2012 - 03:24 PM
How is focus normally represented in GUIs then? And how are dragging scrollbars normally handled?
I'm not clear on what you gain by complicating your focused event dispatch in this manner?
Posted 09 August 2012 - 08:04 PM
Posted 10 August 2012 - 04:43 PM
Edited by AaronWizardstar, 10 August 2012 - 04:44 PM.
Posted 10 August 2012 - 05:35 PM
on_gui_event(event) pass_event_to_widget(current_focus_widget, event) pass_event_to_widget(widget, event) if(widget.parent) if(pass_event_to_widget(widget.parent, event)) return true if(widget.wants_event(event)) widget.handle_event(event) return true return false
Posted 11 August 2012 - 06:38 AM
I'd still like the ancestors of the focused widget to see the event before the widget itself sees it though.
One example I had in mind for my project is a panel with a draggable row of pictures. I can either click on a picture to "select" it and have some data show up somewhere, or I can grab and drag anywhere in the whole row panel to scroll it.
Posted 11 August 2012 - 05:22 PM
So rather than pass events to the root widget, where a widget first processes the event then decides which child to pass the event to, I'd pass events to the focused widget, where a widget first sends the even to its parent then processes the event.
That's easy enough, just use something like this pseudocode:on_gui_event(event) pass_event_to_widget(current_focus_widget, event) pass_event_to_widget(widget, event) if(widget.parent) if(pass_event_to_widget(widget.parent, event)) return true if(widget.wants_event(event)) widget.handle_event(event) return true return false
Hm. My example of the scrollable row of pictures would have been implemented with a panel that contains a row layout widget, with the row layout widget containing a bunch of image widgets, If the panel becomes a single widget without focusable sub-widgets then would it still be possible for me to reuse the image and row layout widgets? I want to leverage composition as much as possible throughout my GUI system, e.g. buttons contain text labels.
Regarding your picture panel, the functionality of scrolling when the user clicks and drags and selecting when the user clicks but does not drag can be implemented using the single focus widget approach in a number of ways. The first obvious way is to not use widgets for the pictures in the panel and instead have the panel draw the pictures itself, as well as perform the required mouse hit-testing. This approach is used a lot. For example, tabs in a tab control are not individual widgets. There is no set criteria, but in general, if it's "a component in a list" kind of thing and doesn't require complex internal user interactions, it's not a widget, but an internal component of the parent widget.
Posted 12 August 2012 - 02:43 AM