[Geany-Devel] Focus lost when last document closed

Pallai Roland pallair at xxxxx
Mon May 27 15:03:54 UTC 2013

2013/5/27 Colomban Wendling <lists.ban at herbesfolles.org>:
> Le 27/05/2013 13:22, Pallai Roland a écrit :
>> 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.
Maybe I was very abstract here: I just want consistent widget focus
when I close the very last document.

> 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?
Me too. (The "edit documents" activity does not finish when a document
closed of many -I did not talk about changing this behaviour-,
finished when the _very last_ document closed. Anyway, forget this
activity thing, I'll talk about "closing the very last document" from

> 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).
Maybe enough in practice, this is what NetBeans does for example. I
use Geany this way in practice currently (by patched plugins), but I
see the shortcomings of this method, surfing over results of 'find in
files' could be much convenient for example.

I'll propose this simple method if other solutions are coming down to
an overcomplicated implementation.

>> 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.
Thanks for the hint!

> ...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.
Agreed, depends on habit and workflow, hard to tell how many
(potential) users are affected. Anyway, great IDEs and text editors I
have used has consistent focus strategy so the need is out there.

>> 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.

More information about the Devel mailing list