Re: [Libreoffice-ux-advise] keyboard focus/ raise window to top behaviour

Hi Lionel,

        Wow you're a brave man heading into this rats nest to disinfect
it ! :-) but bravo - it badly needs doing (as you see).

On Sun, 2011-11-13 at 23:06 +0100, Lionel Elie Mamane wrote:
> My experience with X11 is that unless I went specifically and disabled
> that in my window manager, new windows get the focus by default.

        Seems reasonable.

> well, I'll be pissed off if an application circumvents that !

        And this is a big problem with LibreOffice, it tries to be too clever
for it's own good - and in large part it does it to try to deal with
things like TWM / CDE and other lost-cause window managers ;-) [ I mean
selecting to manually position all newly created windows is a
nightmare ;-]. I'd love to start ripping some of the WMAdaptor nastiness
if at all possible.

>  Recycled windows pose a particular problem: we cannot guess what the
> user wants, so doing what most of them want (raise window) seems
> sensible. The situation would be simpler if we did not recycle windows
> at all :-| If I were designing LO from scratch, I'd be tempted to never
> recycle windows, so that the "on top" decision is truly delegated to
> the window manager.

        Sure; out of interest - where is the window recycling most rampant ? it
is not as if our X backend is that efficient anyway, with it's ~30ms
fixed-time delay before rendering, and it's love of rendering some 200x
square version of the window before re-sizing and re-rendering it as it
starts so ... ;-)

> Frankly, my feeling is that a user-settable setting (a "solution"
> which gets proposed again and again) is not the right thing.

        Agreed as well; if we can detect & do the right thing we should in
every case [ perhaps with some hyper-power-user hidden tweak-able
somewhere if it can't be avoided ].

> Note also that the past discussions where about *document* windows,
> but I find LO's raising of *dialog* windows *repeatedly* excessive,
> too.

        I -assume- that dialog windows should be tagged as 'transient' and thus
be forced above their parent windows anyway (?). At least git grep -10
transient_for in vcl shows several hits which hopefully are useful.

> > > I intend to hunt down every place where LibreOffice raises its
> > > window to the top, and inactivate it on X11, and leave it active on
> > > Windows.
>
> I started doing that, and I noticed that - at least when using GTK,
> the only platform I tested today - more than half of the calls to
> GtkSalFrame::ToTop will actually do nothing anyway... Don't know if
> that's the case for other platforms, too.

        Heh :-) perhaps they are falling into:

        if( isChild( false, true ) )
            gtk_widget_grab_focus( m_pWindow );
        else if( IS_WIDGET_MAPPED( m_pWindow ) )

        ie. not the top-level.

        Personally I think scattering the code with if (unix) style stuff is a
bit annoying; it'd be better to separate out the semantic we want [ if
indeed we really want to force someone to raise ever on Unix ], into
another method. SuggestOnTop(); vs. ForceToTop(); or somesuch - that we
can annotate the code with and see easily via a git grep in future.

        Anyhow - from my perspective, my only real concern here is that we
don't break the toolbar / dock stuff: un-docking and dragging toolbars
around; and ensuring that these are always 'above' the document. We have
a number of nasties there - the popup/pop-down that happens as you move
through a table eg. That doesn't want to loose focus from the document,
and of course wants to be above the window.

        But I'm sure we can find the right use-cases there. Then again, the
toolbar / dock stuff involves really quite a lot of heavy-lifting around
manual positioning of windows etc. that is quite a pain - but good to
cleanup of course.

        So - go for it ! :-) and I look forward to seeing your work.

        All the best,

                Michael.

-- 
michael.meeks@suse.com  <><, Pseudo Engineer, itinerant idiot