Re: Focus applications with trigger
- From: Ulrik Sverdrup <ulrik sverdrup gmail com>
- To: David Martin <david martin mailbox googlemail com>
- Cc: kupfer-list gnome org
- Subject: Re: Focus applications with trigger
- Date: Sun, 10 Apr 2011 00:37:21 +0200
2011/4/9 David Martin <david martin mailbox googlemail com>:
> Hi,
>
>>> The multiple focusing is intentional to raise
>>> all windows. Now I changed this on a whim.. hm the window cycle was
>>> easy to ditch because it worked in the wrong order (least used window
>>> first). I wonder how we can put all these behaviors into one action.
>
> what is the intention behind raising all windows? I think it's weird
> because you only want to access the last one and the others should be
> left how they were unless you cycle to them.
>
>> how do you like the current development version. Now it does,
>> confusingly, both of these. If the app is only on one workspace, it
>> will cycle the windows. If it is on multiple, it will only cycle the
>> workspaces the app is on. What do you think? Is there anythingthat
>> should be configurable.
>
> I don't have a strong opinion on that one as I don't spread my windows
> across too many workspaces. Wouldn't it make more sense to cycle
> through all windows and not just the workspaces? I mean that is what
> it is supposed to do IMO.
>
> Wish you a nice weekend,
> David
>
In my understanding, it is not possible to perfectly combine both
a window cycle and to jump to the latest window.
The reason is that "Go To" is just one action, and it keeps no state.
The state is in the window manager itself, and this state is mutated
each time we use Go To, so for example "cycle windows from most recent
to least recent" is not possible with this implementation, because we
change the sort order while we're iterating it, simply.
Ok, so "Go To" was broken in Kupfer v204, because it would not focus
the most recently used window. To fix that is simple, but then we
lose the old "reverse-cycle". The reason it cycled windows in reverse
should be obvious now -- that way, you can be sure to visit all
windows.
So by now I think it's impossible to wish everything from just one,
dumb, action.. The primary behavior is finally there "Just find the
most recent window" and we have to choose what we want together with
that. I'm ok with bringing up all the app's windows, because the the
secondary inter-application cycle is really quick to reach on Alt-Tab
(because the windows are all at the front). I'm much happier with that
than the old "Pick Some Window" experience.
So the first implemented cycle, "Bring all to front, cycle
workspaces", was basically the one I saw as working inside this
framework.
We can have a "Next Window" action in addition, and it would somehow
do the correct window-cycling thing for that application. (Reverse
again?)
The wider window-application integration is still open, it has never
been properly implemented (and this is maybe the whole problem).
Ulrik
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]