Re: events for no-window widgets
On Wed, Sep 22, 2010 at 11:43 AM, Havoc Pennington h...@pobox.com wrote:
A couple other ideas, just to put more options in the pile.
Minor concern. gdk_event_set_coords() and set_source() could be
problematic in that GdkEvent would become a mutable non-GObject. This
is normally considered Bad language-binding-wise. Though in this case,
the implications are perhaps limited since events don't stick around
and multiple proxies for one event would probably be OK.
Another API for getting events to no-window widgets, would drop
GdkEvent for this, and add something like:
/* pretend these are opaque objects with accessors but that's too much
typing in this email ;-) */
typedef struct {
gdouble x, y; /* widget relative */
GtkWidget *source;
GdkDevice *device;
/* rest of any useful fields here */
GdkEvent *event; /* original event in case you need window or root
relative, or whatever */
} GtkButtonPress;
struct GtkEventReceiverClass {
void (* button_press) (GtkEventReceiver*, GtkButtonPress*); /* this
bubbles the button press. */
}
There could or could not be a base class for GtkButtonPress,
KeyPress, etc. and a base signal ::bubble that was emitted for all
of them. It could be that each button_press, button_release, etc.
bubbles separately with its own vfunc directly. Without the base
class, you never actually have to name this GtkEvent or use the word
event, which avoids some of the namespace collision.
This sounds like a nice approach. In order to get something going,
I've started to experiment with implementing pick(). First attempt is
here:
https://bugzilla.gnome.org/show_bug.cgi?id=633209
It seems to work mostly ok, according to the included testcase.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: events for no-window widgets
On Tue, Oct 26, 2010 at 1:49 PM, Matthias Clasen matthias.cla...@gmail.com wrote: This sounds like a nice approach. In order to get something going, I've started to experiment with implementing pick(). First attempt is here: https://bugzilla.gnome.org/show_bug.cgi?id=633209 It seems to work mostly ok, according to the included testcase. as the slow convergence on a canvas-like model continues, i'd just note in passing that it turns out to be quite useful in GnomeCanvas for an item to be able to avoid ever being picked. this is possible by inverting the logic of your patch, and asking each item (widget) whether a given (x,y) coordinate is within it. by returning false, items can avoid ever being considered the target for an event. their geometric bounds remain unaffected, of course. --p ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: events for no-window widgets
On Tue, Oct 26, 2010 at 2:20 PM, Paul Davis p...@linuxaudiosystems.com wrote: On Tue, Oct 26, 2010 at 1:49 PM, Matthias Clasen matthias.cla...@gmail.com wrote: This sounds like a nice approach. In order to get something going, I've started to experiment with implementing pick(). First attempt is here: https://bugzilla.gnome.org/show_bug.cgi?id=633209 It seems to work mostly ok, according to the included testcase. as the slow convergence on a canvas-like model continues, i'd just note in passing that it turns out to be quite useful in GnomeCanvas for an item to be able to avoid ever being picked. this is possible by inverting the logic of your patch, and asking each item (widget) whether a given (x,y) coordinate is within it. by returning false, items can avoid ever being considered the target for an event. their geometric bounds remain unaffected, of course. I guess that depends on what you are picking for ? this picking was discussed for finding the chain of items to generate enter/leave for, or update a ::contains-pointer property. I think you probably want that to be accurate, even if you don't want the user to click you. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: events for no-window widgets
On Tue, Oct 26, 2010 at 2:46 PM, Matthias Clasen matthias.cla...@gmail.com wrote: I guess that depends on what you are picking for ? this picking was discussed for finding the chain of items to generate enter/leave for, or update a ::contains-pointer property. I think you probably want that to be accurate, even if you don't want the user to click you. actually, it was specifically to avoid enter/leave events that this turned out to be useful. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: events for no-window widgets
And here is a very sketchy patch to experiment with a ::contains-pointer property on GtkWidget: https://bugzilla.gnome.org/show_bug.cgi?id=633222 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
events for no-window widgets
Hi, I've been exploring how widgets with no GdkWindow could receive events. Here are some notes so far in case people have thoughts. Event Types === Events separate very cleanly into weird lowlevel stuff only matters for GdkWindow and things widgets in general including no-window widgets care about A. Events all widgets care about have two subdivisions: A1. events that bubble: GDK_MOTION_NOTIFY, GDK_BUTTON_PRESS, GDK_2BUTTON_PRESS, GDK_3BUTTON_PRESS, GDK_BUTTON_RELEASE, GDK_SCROLL, GDK_KEY_PRESS, GDK_KEY_RELEASE A2. events that are glorified property notifies: GDK_ENTER_NOTIFY, GDK_LEAVE_NOTIFY, GDK_FOCUS_CHANGE B. Freaky events of interest only in context of GdkWindow or GdkDisplay: GDK_DELETE, GDK_DESTROY, GDK_EXPOSE, GDK_CONFIGURE, GDK_MAP, GDK_UNMAP, GDK_PROPERTY_NOTIFY, GDK_SELECTION_CLEAR, GDK_SELECTION_REQUEST, GDK_SELECTION_NOTIFY, GDK_PROXIMITY_IN, GDK_PROXIMITY_OUT, GDK_DRAG_ENTER, GDK_DRAG_LEAVE, GDK_DRAG_MOTION, GDK_DRAG_STATUS, GDK_DROP_START, GDK_DROP_FINISHED, GDK_CLIENT_EVENT, GDK_VISIBILITY_NOTIFY, GDK_NO_EXPOSE, GDK_WINDOW_STATE, GDK_SETTING, GDK_OWNER_CHANGE, GDK_GRAB_BROKEN, GDK_DAMAGE Unfortunately, the current ::event signal (and per-event-type sub-signals) dump all this together. These are logically very distinct and ideally if we were starting from scratch, I would probably want to see: A1. a GtkEvent with some of the obscure lowlevel fields removed, no -window field, add -widget field, coords are widget-relative A2. just use property notifies on contains-pointer and has-focus properties B. GdkEvent as it is now (well, cleaned up, but similar idea) Splitting out B (Window Owners) === A challenge is to think about all code related to B as conceptually a new type, GtkWindowOwner or something. The only instances of this type would be GtkWindow, GtkPlug, GtkSocket, and maybe a couple other weird widgets like GL area. Unfortunately this type is sort of a mixin; if it were an abstract base class, then widgets could not be both a GtkWindowOwner and a GtkContainer. This probably means that the WindowOwner functionality has to remain in GtkWidget. Stuff that belongs to the conceptual window owner type could include: the signals for all the B events; event mask; set_window; set_double_buffered; GdkVisual; style_attach(); shape mask. I don't think this stuff can easily be actually split out of GtkWidget. However, I do think it's helpful to think of it as distinct. _Possibly_ it would be clearer to add an interface that explicitly had all this, and make GtkWidget implement that interface, and deprecate the old gtk_widget_ names someday. Or maybe there's a nice solution involving delegation, where window widgets have a helper object and there's a base class for that. Enter/Leave Notify === Here is how I think enter/leave should work: http://bugzilla.clutter-project.org/show_bug.cgi?id=1576 Though I'm not sure events are required at all. Currently, something like GtkButton needs the input-only window just to prelight. I think a simple boolean property button or any child of button contains pointer would be sufficient for this, however. Multiple GdkDevice pointers complicates that a bit, though it doesn't look like GtkButton handles that right now. The boolean could be defined to mean that greater-than-zero devices are inside the widget and that would probably work fine for prelighting, better than the current enter/leave events in fact. My current thought here is to have a boolean prop which is set on the leaf widget containing each device and all ancestors of that widget. For convenience, maybe a vfunc or vfunc pair which is invoked whenever this property changes. notify::contains-pointer would already be a signal for it but that's sort of annoying in subclasses. I guess this flag would simply mean prelight and that might be handy for the new theme stuff. Given the property, the event would be only on conceptual GtkWindowOwner. No-window widgets would use the property not the event. Implementing contains-pointer for no-window widgets would require some kind of pick() virtual method for identifying the widget under the pointer, GtkWidget default implementation just looks at widget allocations, GtkContainer default recurses into its children. Picking would start at the window widget receiving a GdkWindow native motion notify or enter/leave and then generate synthetic events for no-window widgets inside that GdkWindow. Focus Change === I believe the existing has-focus pretty much handles this; similar to the above-proposed notify::contains-pointer, it might be handy to have a virtual function to go with it, or virtual function pair. The fields in the focus change event are only of interest for GtkWindowOwner not for widgets in general, it looks like. Given the property, the event would be only on conceptual GtkWindowOwner. No-window widgets would use the property not the event. Bubble Events === If we solve A2 enter/leave/focus events with properties, A1 remains. I've
Re: events for no-window widgets
On Wed, 2010-09-22 at 02:11 -0400, Havoc Pennington wrote: During capture, a signal like ::event-captured seems logical. During bubble, a signal like ::event seems logical. Unfortunately that signal already exists but its GdkEvent is window-relative to the original event window, rather than widget-relative to the widget currently getting bubbled through. Possible solutions include: - add a new signal ::event-bubbled with the widget-relative events. - break ::event to be widget-relative, but in my initial experimentation this looked like it'd be pretty disruptive even within GTK - gtk_widget_class_set_widget_relative_events() toggles what kind of coords each subclass receives to ::event - leave event-x, event-y window-relative and add new GdkEvent fields for the widget-relative another possible solution is to detail the ::event-bubbled and ::event-captured with the event type, e.g.: ::event-bubbled:button-press ::event-captured:key-release ... callbacks interested in all events just use ::event-bubbled. con: it's slightly longer to use, but it makes conceptually sense to detail the signal name, since something like ::button-press-event is currently just emitted prior to ::event. con: the overriding of the default handler gets harder - you get to override a single signal. ciao, Emmanuele. -- W: http://www.emmanuelebassi.name B: http://blogs.gnome.org/ebassi ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: events for no-window widgets
On Wed, Sep 22, 2010 at 2:11 AM, Havoc Pennington h...@pobox.com wrote: Hi, I've been exploring how widgets with no GdkWindow could receive events. Here are some notes so far in case people have thoughts. Event Types === Events separate very cleanly into weird lowlevel stuff only matters for GdkWindow and things widgets in general including no-window widgets care about A. Events all widgets care about have two subdivisions: A1. events that bubble: GDK_MOTION_NOTIFY, GDK_BUTTON_PRESS, GDK_2BUTTON_PRESS, GDK_3BUTTON_PRESS, GDK_BUTTON_RELEASE, GDK_SCROLL, GDK_KEY_PRESS, GDK_KEY_RELEASE A2. events that are glorified property notifies: GDK_ENTER_NOTIFY, GDK_LEAVE_NOTIFY, GDK_FOCUS_CHANGE B. Freaky events of interest only in context of GdkWindow or GdkDisplay: GDK_DELETE, GDK_DESTROY, GDK_EXPOSE, GDK_CONFIGURE, GDK_MAP, GDK_UNMAP, GDK_PROPERTY_NOTIFY, GDK_SELECTION_CLEAR, GDK_SELECTION_REQUEST, GDK_SELECTION_NOTIFY, GDK_PROXIMITY_IN, GDK_PROXIMITY_OUT, GDK_DRAG_ENTER, GDK_DRAG_LEAVE, GDK_DRAG_MOTION, GDK_DRAG_STATUS, GDK_DROP_START, GDK_DROP_FINISHED, GDK_CLIENT_EVENT, GDK_VISIBILITY_NOTIFY, GDK_NO_EXPOSE, GDK_WINDOW_STATE, GDK_SETTING, GDK_OWNER_CHANGE, GDK_GRAB_BROKEN, GDK_DAMAGE i think you might want to consider MAP and UNMAP (and possibly VISIBILITY_NOTIFY too) as being in section A2. i know that as they stand, these refer to GdkWindows, but by implication they also apply to widgets within the window. in addition, is it really true that drag events are of interest only in the context of GdkWindow or GdkDisplay? ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: events for no-window widgets
Hi, On Wed, Sep 22, 2010 at 8:55 AM, Paul Davis p...@linuxaudiosystems.com wrote: i think you might want to consider MAP and UNMAP I was thinking the vfuncs (already called on no-window) and map/unmap signals would be fine. i.e. I agree map is interesting for no-window, but I don't think ::map-event adds anything over just ::map, does it? (and possibly VISIBILITY_NOTIFY too) as being in section A2. i know that as they stand, these refer to GdkWindows, but by implication they also apply to widgets within the window. Some kind of are we covered up and do we need to paint flag could be interesting in addition, is it really true that drag events are of interest only in the context of GdkWindow or GdkDisplay? It looks to me like drag events are all handled globally in gtkmain.c, gtkdnd.c and end up converted to signals on GtkWidget (events are not sent to GtkWidget right now). I didn't look super closely though. Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: events for no-window widgets
On Wed, Sep 22, 2010 at 9:14 AM, Havoc Pennington h...@pobox.com wrote: Hi, (and possibly VISIBILITY_NOTIFY too) as being in section A2. i know that as they stand, these refer to GdkWindows, but by implication they also apply to widgets within the window. Some kind of are we covered up and do we need to paint flag could be interesting Isn't that handled by containers simply not calling draw on covered up or hidden children ? ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: events for no-window widgets
Hi, On Wed, Sep 22, 2010 at 10:28 AM, Matthias Clasen matthias.cla...@gmail.com wrote: Isn't that handled by containers simply not calling draw on covered up or hidden children ? yeah, quite possibly. Especially if we move animations into a magic master clock that would also be stopped. Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
