Re: TAKE_ACTIVITY patch
- From: Lubos Lunak <l lunak suse cz>
- To: wm-spec-list gnome org
- Cc: Olivier Chapuis <olivier chapuis free fr>
- Subject: Re: TAKE_ACTIVITY patch
- Date: Mon, 11 Oct 2004 17:00:13 +0200
On Monday 11 of October 2004 07:01, Elijah Newren wrote:
> On Fri, 8 Oct 2004 17:03:26 +0200, Lubos Lunak <l lunak suse cz> wrote:
> > > Question: does the spec really need to spell out waiting for button
> > > release, DND, etc. or can we leave this more policy-free?
> > I think it'd be nice to have. There's a difference between DND and
> > selecting a text, and it'd be nice to have no raise on DND and temporary
> > raise while the text selection is done.
> > On the other hand, that could be a pain to (fully) implement. All places
> > handling press->move->release mouse would need to specify the kind, which
> > could be many places, including application code. The Qt patch which
> > doesn't make any difference between the actions is awfully simple. Maybe
> > having a generic action handled in the toolkit as a fallback and the
> > possibility for other code to specify exact action would do?
> I'm trying it out (see below). While it is definitely more work, I
> don't think it's so bad (it definitely feels like far less work than
Of course. It's rather difficult to have a single seemingly simple feature
that'd be more work than that :-/.
> In widgets where base class behavior isn't good
> enough (or where you are dealing with the base class), it appears to
> require merely three short functions calls -- one each for the
> ButtonPress handler, the ButtonRelease handler, and the MotionNotify
> > Does perhaps somebody have at least kind of working implementation of
> > this BTW?
> I'm getting pretty close. Because of this and a few other things,
> I've been thinking a fair amount about the _NET_WM_TAKE_ACTIVITY stuff
> and been trying a few things out. It appears there are a number of
> A) We (at least Rob and I) would like to have windows raise upon
> ButtonPress if the click is upon a widget that doesn't have any
> meaningful drag operation; and to raise upon ButtonRelease in other
> cases (it turns out that Windows XP does this, and it seems
> sensible). TAKE_ACTIVITY only allows raising to happen upon
> B) Rob would like windows to raise upon ButtonPress when a slider is
> clicked. I want the window raised for a slider click only on
> ButtonRelease and only if the slider hasn't moved. The more I've
> thought about it, the more I believe Rob's argument may have merit
> and that he may be right for Metacity. But I really doubt we could
> get everyone to agree. Unfortunately, TAKE_ACTIVITY places the
> decision making into the toolkit (possibly resulting in
> inconsistencies among toolkits if toolkit developers disagree on
> the appropriate action)
> C) Olivier wants to be able to raise upon ButtonPress at the beginning
> of text selection and then lower upon ButtonRelease of text
> selection if the mouse has moved. I don't think I'd like that.
> TAKE_ACTIVITY can't enable this currently, and further, it places
> the decision making into the toolkits instead of the window
I think you misunderstand Olivier's proposal at
or I have misunderstood it the same way). As I read it, the app sends one
message back to WM right after it finds out which operation is triggered by
the press, and sends a second after release. That should make it both
policy-free and allow what you want.
> So, it'd be nice to modify TAKE_ACTIVITY so that:
> 1) It is policy free (the window managers have total control over
> whether and when to raise/lower/focus, etc.)
> 2) It allows actions upon ButtonPress as well.
> 3) It can handle all these cases.
> 4) It is extendible to further cases (button reordering for tabbed
> browsers or the tasklist maybe?) that we haven't thought of yet.
> Here's my shot in the dark proposal to try to handle all those things.
> It is heavily adopted from Lubos' proposal and Olivier and Lubos'
> extended discussion. I renamed it too, for kicks. It isn't as cool
The name is fine. I didn't like the name much anyway.
> as TAKE_ACTIVITY in that it's not quite as simple to implement, but I
> think it's still pretty reasonable (despite the lengthy explanation);
> it appears to be much less work than, say, _NET_WM_USER_TIME.
> I believe I am close to a working basic implementation (handling a few
> different widgets and cases); I do have at least part of it working
> for sliders and text selection but I'm tracking down some segfaults
> and infinite loops (bugs suck). I thought I'd throw the idea out to
> see if I'm anywhere close to the right track so that I don't spend all
> my time going down the wrong path--especially since the gtk+ API slush
> freeze is /very/ soon and it'd be wonderful if I could get at least
> one of these proposals incorporated (or at least know enough to be
> able to state which function APIs I want so I can at least provide
> blank functions). I'm not counting on it, but it'd be nice.
> Basic idea:
> 1) Window manager receives ButtonPress, and, if window supports
> _NET_WM_MOUSE_ACTION, it queues basic information (timestamp,
> window) about the event but doesn't take further action.
> (Unlike TAKE_ACTIVITY, here the WM doesn't send any message to
> the client. It seemed too much of a pain to worry about the
> order of ButtonPress and ClientMessage events when I sometimes
> want to take action upon ButtonPress.)
Good idea. I'm not sure why I wanted the message from WM to the app on press.
We just should take care the timestamp in the WM matches the timestamp in the
app, but I think SyncPointer in XAllowEvents() uses the same for replays, so
that should be fine.
> 2) Whenever the client receives a ButtonPress event, it must send a
> _NET_WM_MOUSE_ACTION message to the root window. The message
> contains timestamp & window (so the WM can uniquely identify the
> queued info), and the type of mouse action that could be
> 3) Whenever the client receives a ButtonRelease event, it must send
> a _NET_WM_MOUSE_ACTION message to the root window. The message
> contains the timestamp of the ButtonPress & window (again, so the
> WM can uniquely identify the queued info), the timestamp of the
> ButtonRelease, the type of mouse action, and whether there was
> "threshold" mouse motion between ButtonPress and ButtonRelease.
Why should the threshold be necessary? If there wasn't any such motion, then
there wasn't any action -> say the mouse action was none.
> There's a few things I need to specify in more detail. One is how I'm
> going to handle all the things being passed in the message (I have 6
> for ButtonRelease and only 5 are allowed in ClientMessages), another
> is that the "type of event" needs to be specified, and finally I have
> to specify how distinguish between ButtonPress and ButtonRelease in
> the _NET_WM_MOUSE_ACTION messages above. More details about how to
> handle all this (but not in order--sorry):
> Specify EVENT_TYPE:
> ButtonPress = 0
> ButtonRelease, without intervening "threshold" mouse motion = 1
> ButtonRelease, with intervening "threshold" mouse motion = 2
> Specify ACTION_TYPE:
> MOUSE_ACTION_NONE = 0,
> MOUSE_ACTION_MISC = 1,
> MOUSE_ACTION_DND = 2,
> MOUSE_ACTION_SELECTION = 3,
> MOUSE_ACTION_SLIDING = 4,
> MOUSE_ACTION_WORKING = 5
> Explanation of ACTION_TYPEs:
> NONE: No relevant mouse click-and-drag action (used, for example,
> on buttons (no relevant drag action), or when no action
> exists for a click at the given location)
> MISC: A mouse click-and-drag action not listed below (use of this
> should be avoided; it is preferred to add an extra type
> after gaining consensus on the wm-spec-list for extending
> the _NET_WM_MOUSE_ACTION section of the EWMH. It is
> suggested that this type only be used while waiting for
> consensus and an extension)
This probably shouldn't have so strong wording. Getting every single widget
which can handle mouse press+move+release to report correct type can be a lot
of work. My Qt patch doing only the old way (i.e. only MISC) is a couple of
lines, supporting all this won't be. Maybe only supporting MISC should be
called a simple support or so? After all, I don't know about others, but I'd
only rarely need this feature, so I wonder if developers would consider this
to be worth the trouble.
> DND: Mouse action is or may be part of drag and drop
> SELECTION: Mouse action is or may be part of selection (usually text
> selection, but could include graphics or even be exclusively
> graphics (think of office suites with mixtures of graphics
> and text, for example))
> SLIDING: Mouse action is or may be part of moving a slider
> WORKING: Mouse action is or may be part of general working (drawing
> in a photo editor, moving objects in a diagram editor,
> Since I was short on fields by 1 (I needed 6; ClientMessages only have
> slots for 5), I combined ACTION_TYPE and EVENT_TYPE as follows:
> Define STATUS
> STATUS = 3*ACTION_TYPE + EVENT_TYPE
I'd like to see this at least split to bitfields, instead of such strange
maths. But I think this is not necessary, one more field could be saved by
having different message types in the X11 ClientMessage for every event type.
IMHO that's a bit cleaner.
> Okay, just one more thing. The proposal above handles policy free
> (clients merely say what happened, not "should raise" or "shouldn't
> raise"), it allows actions upon button presses, and it handles all the
> cases that have been presented so far. To handle extensibility:
> If a WM receives a STATUS greater than the values in the range it
> knows how to handle, it MUST treat it as an ACTION_TYPE of
> MOUSE_ACTION_MISC. (EVENT_TYPE is still handled via the rule:
> EVENT_TYPE = STATUS mod 3)
> This will allow us to add other ACTION_TYPEs later, and even older
> window managers can handle them with at least some sane default
> So, does this sound reasonable? Would it be useful with some
> modifications (and with what modifications)?
Besides what I already commented above, this looks fine to me.
SuSE CR, s.r.o. e-mail: l lunak suse cz , l lunak kde org
Drahobejlova 27 tel: +420 2 9654 2373
190 00 Praha 9 fax: +420 2 9654 2374
Czech Republic http://www.suse.cz/
] [Thread Prev