On Fri, Nov 11, 2011 at 2:47 PM, Michael Natterer <mi...@gimp.org> wrote: > Hi Benjamin, > > [snip typical German ecouragement talk] > > please give a small example. > (disclaimer: just to illustrate the idea, might change a lot)
So, a GtkButton is kinda complex from the input perspective, but simple for drawing. It would have these "Views": - Background - Child It would inherit those from GtkBin, so it wouldn't have any drawing code at all. And it'd have those "Controllers": (- Hover) - Click - Activate (- Focus) - KeyPress/Release Not sure if hover and focus should be default or separate controllers. What they'd do is toggle the :focus and :hover state on the widget and nothing else. The click controller would capture mouse presses, take a grab, and on release it'd make the button emit "clicked". Same as the KeyPress/Release controller (which would only capture space, return and whatever else activates a button). And the Activate controller would respond to gtk_widget_activate(). A GtkLabel would have these "Views": - Background (or not - it'd have it in GTK4, maybe not in GTK3, where labels have no background) - Text and it'd have probably these "Controllers": - "Rubberband" - Click - DoubleClick - Drag - KeyPress/Release I wanted to call "Rubberband" "Drag", but that'd confuse people with DND. What I mean is pressing the mouse, holding it and releasing it elsewhere. Consider the name a work in process. All of them would only be active if the label was selectable. Rubberband would be used to do a selection, drag would allow DND'ing the selected text. The KeyPress/Release controller(s) would be used for the general selection handling in text, as would the Click and DoubleClick ones. (I suppose we would have one that'd be shared between all the text-handling widgets that ensured all our keybindings were identical and the selection behavior consistent - try double-clicking between words in different widgets for some fun.) Now for some fun widget, the notebook. We'd have these views: - Background - Child (for the active widget) - per action and arrow button: - Background - Icon per tab: - Background - Child And these actions: - Drop (for tabs maybe?) - per action and arrow button: - Click - Focus - Hover - KeyPress/Release - per tab: - Click - Focus - Hover - KeyPress/Release - Drag (to drag tabs elsewhere) - Drop (for tabs) - Activate (for keybindings) - per close button on the tab: - Click - Focus - Hover - KeyPress/Release You would probably be able to limit actions to certain areas/views of the widget, so the hover/focus actions would be setup to only apply to the ones they are about. It'd at least solve all our bugs with focus, hover and whatnot not working properly on notebooks that get filed and fixed regularly. Or we would make the notebook have real buttons, at which point the actions would be setup by the button. Then we'd just have to solve attaching the DND actions to the button. But with such an approach, the notebook code would look less scary (apart from the setup code...). We'd just move some views around in size_allocate and connect some signals and that'd be that. I'm not even going to try to imagine the setup for the treeview here... That said, you can see that the number of different views and controllers is quite small. It's just that we duplicate their functionality over and over and over again. And you can maybe start to imagine what would happen when people started adding gestures etc to the notebook code... Benjamin _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list