[compiz] Re: [PATCH]Application-window switcher,
and comments for switcher.c
Christopher Halse Rogers
chalserogers at gmail.com
Mon Feb 26 16:18:09 PST 2007
On 2/27/07, David Reveman <davidr at novell.com> wrote:
> (I assume that you didn't actually want to take this off the list)
Quite true. It seems I need to check what gmail is doing more closely, sorry.
> On Thu, 2007-02-22 at 11:09 +1100, Christopher Halse Rogers wrote:
> > On 2/21/07, David Reveman <davidr at novell.com> wrote:
> > > On Thu, 2007-02-15 at 22:23 +1100, Christopher Halse Rogers wrote:
> > > > Sorry, this time with the actual patches attached!
> > >
> > > Great work!
> > Thanks :).
> > >
> > > Wouldn't it make sense to have an enum for the switch type currently
> > > used instead of two boolean values (allWindows and appWindows)? It seems
> > > that allWindows is currently always FALSE when appWindows is TRUE, which
> > > btw is different from the scale plugin where scaling a group will always
> > > include group windows from all viewports.
> > I considered using an enum, but decided against it. First, because
> > they're not really mutually exclusive - the reason there's not an
> > allWindows + appWindows mode is that I'm not quite sure the best way
> > to display the windows not on the current viewport (it would probably
> > need to use the popup-switcher or change the viewport).
> Isn't how allWindows currently work good enough? Why should allWindows +
> appWindows be different then allWindows?
> The scale plugin is doing "allWindows + appWindows" for initiate_group
> and it seems more useful to me than just doing allWindows.
I think there's a use-case for appWindows on the current viewport
only. Someone who uses workspaces/viewports to organise their work
will probably want the ability to only switch to windows on the
For application-window-switching, I think switcher's pop-up window is
not very useful - in many cases the windows from the same application
will look very much the same, and be pretty much indistinguishable in
thumbnail form. So, for "this viewport only" switching, I think the
pop-up window shouldn't be used (the behaviour of my patch).
However, if you include windows on all viewports, this gives the
somewhat unintuitive behaviour of being able to switch to windows you
can't see at all. I think "allWindow + appWindows" either needs to
use the popup, or switch viewports when windows are selected, or some
other way of making sure you can always see the currently selected
> > Secondly, I
> > wanted my first patch to be minimally invasive, and this seemed the
> > best way.
> OK, we can put this in first.
> > I do hope to extend this a bit further: I'd like to add an appWindows
> > + allWindows mode, and also add some extra animation stuff to the
> > app-switcher, so it's easy to distinguish the possible switch-targets
> > from the windows from all other applications (I'd be interested in
> > hearing feedback as to what the best way to do this would be). It
> > might be worthwhile changing the appWindows/allWindows to a set of
> > flags, though.
> Do you mean some other animations then the current zoom animation?
Well, what I wanted was some way of visibly distinguishing the windows
that you can switch to. A simple example would be having 3 levels of
fade/transparency while switching, rather than the current two. For
appWindows, that would mean:
1) The current window is fully opaque, and zoomed
2) Windows in the same group (ie: windows you can possibly switch to)
have transparency x
3) All other windows (ie: windows that aren't possible switch targets)
have transparency y
Or some similar effect.
It seems that Feisty's Xorg 7.2 migration is now done, so now that
Compiz works again I'll now be able to work on this again. I'm not
very fast, so don't expect anything too soon, though :).
- Chris Halse Rogers
More information about the compiz