Re: Proposal for a smarter behavior for raising windows on mouse click (#2)

[Olivier Chapuis <olivier chapuis free fr>]

On Wed, May 05, 2004 at 08:40:11PM +0200, Lubos Lunak wrote:
> On Tuesday 04 of May 2004 22:00, Olivier Chapuis wrote:
> > On Tue, May 04, 2004 at 06:58:11PM +0200, Lubos Lunak wrote:
> > > > _NET_WM_MOUSEMOTION_RAISE (not in the list and the application think
> > > > that the application should be raised)
> > > > _NET_WM_MOUSEMOTION_NORAISE (not in the list and the application think
> > > > that the application should not be raised)
> > >
> > >  And I don't like that much this part. But even with good list of actions
> > > such fallback will possibly be needed. On the other hand, I can't think
> > > of any more actions than those above. DRAWING (when renamed to something
> > > more generic) can mean any kind of working inside the window, and maybe
> > > even TEXTSELECTION and SCROLLING could be merged.
> >
> > I think it is preferable to do not merge this two types. I've no
> > strong arguments, but the fact that I want different behavior for this
> > two types (so maybe others users too). I can give some details if you
> > want.
> 
>  Yes, please.
>

Say I start a click raise motion, the window is raised. At button
release with text selection the window is put back at its original
stacking position, with scrolling the window is put back at its
original stacking position only if you leave the window quickly after
the button release.  I think that SCROLLING is in between TEXTSELECTION
and WORKING. Any way I think we are agree that SCROLLING != TEXTSELECTION
regarding the click raise semantic.

> > Some window manager can consider it equivalent some others 
> > no. I do not think that this can cause big problems at the toolkits
> > implementation level?
> 
>  Well, I just said 'maybe', now that I think of it they are different. What I 
> rather meant by that paragraph is that there should be a good list of 
> possibilities so that those two RAISE/NORAISE fallbacks are rarely used 
> (preferably never), as otherwise we can simply have only RAISE/NORAISE a do 
> the apps do the deciding (which I consider the worse solution).
> 
>  I cannot think of any more actions that you listed though - DND, SELECTING, 
> SCROLLING, DRAWING (which I'd rather call WORKING with the meaning that it's 
> when you press the mouse inside the window and do something inside the app 
> with the button kept pressed). Some more ideas?
>

I am totally agree with these last two paragraphs. WORKING is really
better than DRAWING. I think some think like DUMMY (a not useful
motion, as a motion on a simple button) can be useful. I've added
RAISE/NORAISE because it was a solution to do not forget a type;
bad. It will be good to have some advice from toolkit developers.

Regards, Olivier