[Geany-Devel] Focus lost when last document closed

[Colomban Wendling]

Hi,

Le 27/05/2013 13:22, Pallai Roland a écrit :
> 2013/5/27 Lex Trotman <elextr at gmail.com>
>> On 27 May 2013 18:24, Pallai Roland <pallair at magex.hu> wrote: I
>> see several problems with the proposal:
>> 
>> 1) What is the "correct" behaviour? As you say there are several 
>> open methods, do I return to the method used for the particular 
>> file that was closed last, even though I had opened many other 
>> files using a different widget since that file was opened.  I
>> would have said that the most recently used method might be more
>> likely to be the one I want.  And some I probably don't want to
>> return to, eg if the file was opened from a compiler error message
>> and as you say having a dialog open automatically is wrong too.
> 
> No correct behaviour, just ordinary what you had described: return to
> the most recent activity if an activity finished. This is a common UI
> behaviour and expected by users, no one will complain about it.

Hum, it's probably either so well done or not done at all I never saw it
anywhere.

Generally what applications do is that e.g. when closing a document in a
tabbed document view, it switches to another document (either left or
right tab, or MRU one) -- and that's what we do, which I find consistent.

In my personal usage, I would find it *very* annoying to get the focus
out of the documents when I close one:  why would you expect me to
return to opening a file and not edit another open one?

And if it's only when closing the very last open document, I'd think
it's much ado about nothing.  If it's a problem the focus is nowhere, I
would think we could chose an arbitrary thing to focus that would maybe
make you or 1% of people happier without messing up with an
overcomplicated solution to a non-existent problem (IMHO).

> Yes, there are cases when return of activity a., is not possible: 
> skip this activity and see next. b., is not sane: the default widget 
> behaviour would be "do not return the focus here" and we have to 
> agree on the exceptions (eg. filesystem browsers, search results - 
> widgets that contains file lists and typically used to open files - 
> IMHO it's pretty trivial.)
> 
>> 2) Methods of opening files are provided by plugins, filebrowser 
>> being the initial example, but treebrowser and the project plugins 
>> being other options.  Geany does not know about what plugins can
>> do for opening files, and passing a widget pointer to Geany is
>> risky since the plugin may have been closed in the meantime and
>> the widget deleted.  Trying to use that is a likely crash.
> 
> Agreed, passing a widget pointer to Geany is risky, I have no good 
> solution now. Now I thinking about a signal-based solution (based on
>  Qt experiences) but I have to dig into GTK for the details.

This is a false technical problem, we could very well listen to the
:destroy signal of the widget and pop it out of a queue.

>> In general this is a situation where Geany can't assume what the 
>> user wants to do, it is better to let the user focus something via 
>> the mouse or keybinding.
> 
> I do not agree on this: we can guess right based on common UI 
> traditions. If we guess badly, the user have to focus manually just 
> as before - worth to try.

...so IIUC what you try to fix is the focus when the last document tab
is closed?  So I really think it's much ado about (almost) nothing, because

1) many (I would have said "most") users have many tabs open and even
sometime don't ever close them all (so don't encounter the issue);

2) we have a setting to make sure there is always a document open (so
users don't encounter the issue);

3) many users use mostly the mouse, so they don't even care about focus
location in this case.

> Do you agree that the problem exists

Somewhat, yes.  I mean, the focus indeed gets nowhere when closing the
last open document if the setting `new_document_after_close` is off.

> and should be solved?

Honestly, I don't care.

> Will you commit my patch if I find a good solution?

Maybe, if it's small and simple.  But I probably won't accept a huge
queue-based focus history for this, because the waste of resources and
code complexity wouldn't be worth what they fix.


Regards,
Colomban