2013/5/27 Colomban Wendling lists.ban@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 now.)
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?
Yes.
So I really think it's much ado about (almost) nothing, because
- 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);
- we have a setting to make sure there is always a document open (so
users don't encounter the issue);
- 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.
OK