Alt+Tab improvements

As I mentioned in another message, I've been distracted this
week with some 
TabBox improvements.  Nothing terribly drastic, it still
works pretty much 
the same way, but:
  - I've changed the desktop mode to work more like windows
mode
  - the CDE vs. KDE features have been split out
    - static order vs. MRU order
    - whether to show a list, or just switch
    - whether to raise selected window
  - mouse wheel support
  - (very) slightly improved effect interface

Attached is what I've done so far.  It works well enough,
but I still have 
some things I'd like to do:

First, there's a bug I'm not sure how to solve.  Ever since
Lubos made the 
QFrame OverrideRedirect, mouse input over the TabBox doesn't
work; that is, 
clicking an item in the list or scrolling the wheel.  I
don't know why this 
is, especially as OverrideRedirect windows used for input by
effects work 
just fine.  Calling XSelectInput does help, but only if it's
called late 
enough; the earliest point I can put it where it makes a
difference is either 
after a KeyPress (waaay too late), or in show() after 
qt_x11_wait_for_window_manager (causes ugly ugly painting
delay).  I can 
create an InputOnly child window of the TabBox, and this
makes it all work 
fine, but I feel like I'm missing a better solution.

Second, my Shift key isn't working wrt Alt+Tab, either to
call the box with 
Alt+Shift+Tab, or to go backwards a step once the box has
been called.  Is 
anyone else seeing this, or is this my problem?

Third, hooking up the new options into the configuration
dialog.  My question 
here is whether it's worth preserving
[Windows]AltTabStyle=KDE|CDE, since now 
that simply sets defaults for
[TabBox]WindowOrder,ShowList,RaiseSelected.

Fourth, I'd like to draw the tabbox with Plasma::SVG.  This
way, we can have a 
nice-looking tabbox even for those who can't/won't be using
compositing.

Fifth, search-as-you-type.  I haven't started on this
because I don't know 
what to do about Unicode.  By the time we reach
Workspace::tabBoxKeyPress(), 
the incoming XEvent has been converted to a Qt key mask; but
from there, how 
do I get the character, if the character is going to need a
combination of 
keypresses?

-- 
Philip Falkner

_______________________________________________
Kwin mailing list
Kwinkde.org
https://ma
il.kde.org/mailman/listinfo/kwin

On Monday 19 of March 2007, Philip Falkner wrote:
> As I mentioned in another message, I've been distracted
this week with some
> TabBox improvements.  Nothing terribly drastic, it
still works pretty much
> the same way, but:
>   - I've changed the desktop mode to work more like
windows mode
>   - the CDE vs. KDE features have been split out
>     - static order vs. MRU order
>     - whether to show a list, or just switch
>     - whether to raise selected window
>   - mouse wheel support
>   - (very) slightly improved effect interface

 The patch looks ok to me, although I'm not that fond of all
the foo->mFoo 
changes.

> Attached is what I've done so far.  It works well
enough, but I still have
> some things I'd like to do:
>
> First, there's a bug I'm not sure how to solve.  Ever
since Lubos made the
> QFrame OverrideRedirect, mouse input over the TabBox
doesn't work; that is,

 For KWin's own windows it shouldn't matter at all if
they're 
override-redirect or not, since that'd be overriding itself.
I made the 
window override-redirect because such windows are not
managed by KWin's 
window code, only tracked, and that's how the tabbox should
be handled.

> clicking an item in the list or scrolling the wheel.  I
don't know why this
> is, especially as OverrideRedirect windows used for
input by effects work
> just fine.  Calling XSelectInput does help, but only if
it's called late
> enough; the earliest point I can put it where it makes
a difference is
> either after a KeyPress (waaay too late), or in show()
after
> qt_x11_wait_for_window_manager (causes ugly ugly
painting delay).  I can
> create an InputOnly child window of the TabBox, and
this makes it all work
> fine, but I feel like I'm missing a better solution.

 It works fine for me, with your patch applied. Debug output
added to 
TabBox::handleMouseEvent() shows there are events.

> Second, my Shift key isn't working wrt Alt+Tab, either
to call the box with
> Alt+Shift+Tab, or to go backwards a step once the box
has been called.  Is
> anyone else seeing this, or is this my problem?

 Same here.

> Third, hooking up the new options into the
configuration dialog.  My
> question here is whether it's worth preserving
> [Windows]AltTabStyle=KDE|CDE, since now that simply
sets defaults for
> [TabBox]WindowOrder,ShowList,RaiseSelected.

 I think I've already mentioned that here, but before you
get even deeper into 
this, are you aware of http://bug
s.kde.org/show_bug.cgi?id=118184 ? I think 
that, ideally, it should be first designed with the help of
the usability 
people how the tabbox should actually work. Right now I
consider it to be 
somewhat useless with more than 2 windows open and it's
already a bit messed 
up with all these CDE vs KDE etc. options and
"randomly" adding more options 
would probably just make it worse. Would you be willing to
do all that work?

> Fourth, I'd like to draw the tabbox with Plasma::SVG. 
This way, we can
> have a nice-looking tabbox even for those who
can't/won't be using
> compositing.

 I have no idea about Plasma::SVG, but assuming it'd work I
don't see a 
problem with that.

> Fifth, search-as-you-type.  I haven't started on this
because I don't know
> what to do about Unicode.  By the time we reach
> Workspace::tabBoxKeyPress(), the incoming XEvent has
been converted to a Qt
> key mask; but from there, how do I get the character,
if the character is
> going to need a combination of keypresses?

 I think that in order to support composed characters the
XEvent would have to 
be left to be passed to Qt and Qt would do the necessary
conversions.

-- 
Lubos Lunak
KDE developer
------------------------------------------------------------
--
SUSE LINUX, s.r.o.   e-mail: l.lunaksuse.cz , l.lunakkde.org
Lihovarska 1060/12   tel: +420 284 028 972
190 00 Prague 9      fax: +420 284 028 951
Czech Republic       http//www.suse.cz
_______________________________________________
Kwin mailing list
Kwinkde.org
https://ma
il.kde.org/mailman/listinfo/kwin

On Wednesday 21 March 2007 12:23, Lubos Lunak wrote:
> On Monday 19 of March 2007, Philip Falkner wrote:

>  The patch looks ok to me, although I'm not that fond
of all the foo->mFoo
> changes.

I'll avoid them in future, then. 

> > First, there's a bug I'm not sure how to solve. 
Ever since Lubos made
> > the QFrame OverrideRedirect, mouse input over the
TabBox doesn't work;
> > that is,
>
>  For KWin's own windows it shouldn't matter at all if
they're
> override-redirect or not, since that'd be overriding
itself. I made the
> window override-redirect because such windows are not
managed by KWin's
> window code, only tracked, and that's how the tabbox
should be handled.

Curious, because removing that flag makes mouse input work
again here, so 
obviously it's having some effect.

> > Calling XSelectInput does help, but only if it's
called
> > late enough; the earliest point I can put it where
it makes a difference
> > is either after a KeyPress (waaay too late), or in
show() after
> > qt_x11_wait_for_window_manager (causes ugly ugly
painting delay).  I can
> > create an InputOnly child window of the TabBox,
and this makes it all
> > work fine, but I feel like I'm missing a better
solution.
>
>  It works fine for me, with your patch applied. Debug
output added to
> TabBox::handleMouseEvent() shows there are events.

Interesting.  Here, not even Workspace::workspaceEvent()
gets mouse events 
when the pointer is over the tabbox, unless I use one of
those hacks.

> > Second, my Shift key isn't working wrt Alt+Tab,
either to call the box
> > with Alt+Shift+Tab, or to go backwards a step once
the box has been
> > called.  Is anyone else seeing this, or is this my
problem?
>
>  Same here.

I'll look into this, then.

>  I think I've already mentioned that here, but before
you get even deeper
> into this, are you aware of http://bug
s.kde.org/show_bug.cgi?id=118184 ? I
> think that, ideally, it should be first designed with
the help of the
> usability people how the tabbox should actually work.
Right now I consider
> it to be somewhat useless with more than 2 windows open
and it's already a
> bit messed up with all these CDE vs KDE etc. options
and "randomly" adding
> more options would probably just make it worse. Would
you be willing to do
> all that work?

Yes, I took a look at that bug, and it seemed like several
people were looking 
for some way to combine certain features of what is now KDE
mode with CDE 
mode, e.g. MostRecentlyUsedOrder, but with windows raising
on select.  Right 
now, KDE vs. CDE is a coarse control, which is why I split
up the differences 
into more and smaller options.

For others' requests, like the one for a ring instead of a
list, I was 
thinking they'd be best served by effects.

As for the work, I'm willing but should I be doing it now? 
If there's any 
plan of having kwin_composite in KDE 4.0, should I be
focusing on other areas 
like turning effects into proper plugins, and leave most of
this tabbox stuff 
for 4.1?

In either case, I'd still like to commit
TabBox::setCurrentClient/Desktop(), 
as well as the TabBox::createDesktopList() and associated
QList< int > 
desktops; the first allows effects to highlight a selection
without 
activating it, and the second insulates effects from having
to know what the 
sorting order of desktops is.

> > Fourth, I'd like to draw the tabbox with
Plasma::SVG.  This way, we can
> > have a nice-looking tabbox even for those who
can't/won't be using
> > compositing.
>
>  I have no idea about Plasma::SVG, but assuming it'd
work I don't see a
> problem with that.

The basic idea would be to have a Plasma::SVG object which
loads an svg off 
disk (probably on first tabbox use), and then paint it
instead of 
QFrame::paintEvent().  Also, more svgs could be used for the
highlighted item 
and hover effects.  ksmserver shows a simple use of this.

The only problem I see would be my lack of artistic skill,
so obviously this 
would be in coordination with artists (again, should this be
saved for 4.1?).  
Also, kwin would require plasma, but I don't see that as a
huge problem.

> > Fifth, search-as-you-type.  I haven't started on
this because I don't
> > know what to do about Unicode.  By the time we
reach
> > Workspace::tabBoxKeyPress(), the incoming XEvent
has been converted to a
> > Qt key mask; but from there, how do I get the
character, if the character
> > is going to need a combination of keypresses?
>
>  I think that in order to support composed characters
the XEvent would have
> to be left to be passed to Qt and Qt would do the
necessary conversions.

Hm.  Using QKeyEvents instead of XEvents would seem to do
the trick, if I'm 
reading the docs right.

-- 
Philip Falkner
_______________________________________________
Kwin mailing list
Kwinkde.org
https://ma
il.kde.org/mailman/listinfo/kwin

On Monday 26 of March 2007, Lubos Lunak wrote:
> On Friday 23 of March 2007, Philip Falkner wrote:
> > As for the work, I'm willing but should I be doing
it now?  If there's
> > any plan of having kwin_composite in KDE 4.0,
should I be focusing on
> > other areas like turning effects into proper
plugins, and leave most of
> > this tabbox stuff for 4.1?
>
>  The plan is to have kwin_composite for 4.0, and one of
the things I'd like
> to have there is a good tabbox (expose, switcher,
whatever you call it,
> simply something that's useful for switching between
windows). We can
> hardly beat Compiz/Beryl on the useless eyecandy front,
but it'd be nice to
> score some points for having useful things. So, in
short, having
> kwin_composite there at all is of course primary, but
tabbox should be a
> high priority.
>
>  As for how to actually proceed, I'm not quite sure
honestly. I think there
> should be an actual proposal first and after that it
should be discussed
> (here and with usability people) and finally
implemented. There's
> kde-usability list but AFAIK it's ridden with clueless
usability wanabees
> and not that useful - I'll try to find out how to
handle this part.

 Ok, so this part should be just mailing the proposal to the
kde-usability 
list for getting feedback on it. Apparently the list has
gotten better 
recently.

-- 
Lubos Lunak
KDE developer
------------------------------------------------------------
--
SUSE LINUX, s.r.o.   e-mail: l.lunaksuse.cz , l.lunakkde.org
Lihovarska 1060/12   tel: +420 284 028 972
190 00 Prague 9      fax: +420 284 028 951
Czech Republic       http//www.suse.cz
_______________________________________________
Kwin mailing list
Kwinkde.org
https://ma
il.kde.org/mailman/listinfo/kwin

On Monday 26 March 2007 11:36:42 Lubos Lunak wrote:
> On Saturday 24 of March 2007, Philip Falkner wrote:
> > On Friday 23 March 2007 11:25, Philip Falkner
wrote:
> > > On Wednesday 21 March 2007 12:23, Lubos Lunak
wrote:
> > > > On Monday 19 of March 2007, Philip
Falkner wrote:
> > > > > Second, my Shift key isn't working
wrt Alt+Tab, either to call the
> > > > > box with Alt+Shift+Tab, or to go
backwards a step once the box has
> > > > > been called.  Is anyone else seeing
this, or is this my problem?
> > > >
> > > >  Same here.
> >
> > The problem is Shift+Tab.  The X server interprets
that as
> > XK_ISO_Left_Tab, which becomes Qt::Key_Backtab. 
The result is that the
> > Qt keycode we get is Qt::ALT + Qt::SHIFT +
Qt::Key_Backtab, which of
> > course is not what we're looking for, and so
nothing happens.
>
>  *sigh*
>
> > This used to be dealt with by KKey::simplify(),
which in turn was called
> > only from KShortcut::contains(), but now that KKey
is dead and KShortcut
> > is little more than a QList, this doesn't happen.
> >
> > I've looked at the KKeyServer code, but I don't
understand it well enough
> > to suggest where decomposing XK_ISO_Left_Tab into
Shift and XK_Tab (like
> > before) would go best.
>
>  That'd mean one would have to call this additional
function manually which
> would often get forgotten I guess. This can apply to
all of KDE, not just
> KWin. On the other hand, others than KWin are not very
likely, so it can be
> a hack at worst.
>
> > The other option is to add secondary shortcuts so
> > that Tab or Backtab both work.
>
>  Shift+Tab being some unknown key called Backtab would
quite likely confuse
> me if I were a normal Joe User. I think a proper fix
might be filling a
> bugreport to X.Org saying that Shift+Tab should not be
ISO_Left_Tab and
> that they should fix their XKB maps. Which means there
should be a
> temporary solution needed and so this probably should
be also fixed in Qt.

Apparently it already is confusing: http://bug
s.kde.org/show_bug.cgi?id=125812

As far as I can tell it's been Left_Tab for a long time, and
changing it on 
the xkb level might well break a number of other programs. 
And 
Qt::Key_Backtab is used in various places in KDE.

On the other hand, there's already some special handling of
Backtab in 
QShortcutMap::nextState() which seems to do what we want.  I
haven't had much 
time the past couple of days, but I'll dig into this
further.

-- 
Philip Falkner
_______________________________________________
Kwin mailing list
Kwinkde.org
https://ma
il.kde.org/mailman/listinfo/kwin

On Monday 26 March 2007 10:54:34 Lubos Lunak wrote:
> On Friday 23 of March 2007, Philip Falkner wrote:
> > On Wednesday 21 March 2007 12:23, Lubos Lunak
wrote:
> > >  It works fine for me, with your patch
applied. Debug output added to
> > > TabBox::handleMouseEvent() shows there are
events.
> >
> > Interesting.  Here, not even
Workspace::workspaceEvent() gets mouse
> > events when the pointer is over the tabbox, unless
I use one of those
> > hacks.
>
>  Although, thinking of it, this is probably not related
to cursorPos(). No
> idea though :(.

The bit I find most odd is that using XSelectInput late
enough can make it 
work, which suggests some kind of race...  Worst case, I
know the child 
InputOnly window works, so we can always put that in later.

>  The plan is to have kwin_composite for 4.0, and one of
the things I'd like
> to have there is a good tabbox (expose, switcher,
whatever you call it,
> simply something that's useful for switching between
windows). We can
> hardly beat Compiz/Beryl on the useless eyecandy front,
but it'd be nice to
> score some points for having useful things. So, in
short, having
> kwin_composite there at all is of course primary, but
tabbox should be a
> high priority.

Ok.

>  As for how to actually proceed, I'm not quite sure
honestly. I think there
> should be an actual proposal first and after that it
should be discussed
> (here and with usability people) and finally
implemented. There's
> kde-usability list but AFAIK it's ridden with clueless
usability wanabees
> and not that useful - I'll try to find out how to
handle this part.
>
>  Ok, so this part should be just mailing the proposal
to the kde-usability
> list for getting feedback on it. Apparently the list
has gotten better
> recently.

Thanks for finding that out. 

As for a proposal...

There are several ways to switch tasks in KDE, and on other
systems.  A 
traditional one has involved pressing Alt+Tab (Cmd+Tab on OS
X), which would 
pop up a list of applications or windows.  Repeated presses
would cycle 
through the list, and on releasing Alt, the current
selection would be 
activated.  Pressing Escape often cancels the whole thing,
leaving the window 
order as-is.

Differences among Alt+Tab implementations include whether it
lists windows or 
applications, and in what order.  Also, sometimes a list is
not popped up, 
but rather the next window/app is activated immediately
(CDE, Cmd+` on OS X 
switches windows within the current application).

In KDE, we offer a list of windows in most-recently-used
order by default.  As 
an option, CDE-style can be chosen wherein no list is popped
up, activation 
is immediate, the ordering of windows is static based on
creation, and 
minimized windows are skipped.
We also re-use the Alt+Tab mechanism to cycle through
desktops (Ctrl+Tab), 
either in numerical order or most-recently-used order.

It seems to me that Alt+Tab has two different uses;
switching to the 
most-recently-used window (or, with Alt+Shift+Tab the most
recently minimized 
window), and cycling through all windows.  Current
"KDE-style" behaviour is 
great for the first option, but kinda sucks for the second. 
"CDE-style" 
behaviour is ok for the second, but sucks for the first.

When switching to the "previous" window, one
generally presses Alt+Tab or 
Alt+Shift+Tab once and that's it, with no need for popping
up any sort of 
list.  But when cycling through windows, it helps to have an
organised list 
displayed.  I would think that the most helpful organisation
would be by 
application (all konqueror windows together, all kopete
windows together, 
etc.), perhaps with some visual indicator separating the
application groups.

So, here's an idea.  If the user presses Alt+Tab, then the
most-recently-used 
window is activated.  If the user presses Alt+Shift+Tab,
then the 
least-recently-used (most recently minimized) window is
activated.  But, if 
Alt is held, a list of windows grouped by application pops
up.  The initially 
highlighted window is the most-recently-used window, so that
if Alt+Tab is 
held long enough to trigger the window, but not pressed
again, the behaviour 
is the same as pressing it quickly.  Further presses of
Alt+Tab cycle through 
the window list.  Any window can be selected by clicking on
it.

Outstanding questions:
   What should the order of applications be?  In the order
they were opened?  
Most recently used?  ...?
   What should the order of windows within each application
group be?  I'm 
leaning towards most-recently-used, but would another order
make more sense?


Does anyone here think this outrageously stupid?   If not,
I'll post to 
kde-usability soon.

-- 
Philip Falkner
_______________________________________________
Kwin mailing list
Kwinkde.org
https://ma
il.kde.org/mailman/listinfo/kwin

On Wednesday 28 of March 2007, Philip Falkner wrote:
> As for a proposal...
>
> There are several ways to switch tasks in KDE, and on
other systems.  A
> traditional one has involved pressing Alt+Tab (Cmd+Tab
on OS X), which
> would pop up a list of applications or windows. 
Repeated presses would
> cycle through the list, and on releasing Alt, the
current selection would
> be activated.  Pressing Escape often cancels the whole
thing, leaving the
> window order as-is.
>
> Differences among Alt+Tab implementations include
whether it lists windows
> or applications, and in what order.  Also, sometimes a
list is not popped
> up, but rather the next window/app is activated
immediately (CDE, Cmd+` on
> OS X switches windows within the current application).
>
> In KDE, we offer a list of windows in
most-recently-used order by default. 
> As an option, CDE-style can be chosen wherein no list
is popped up,
> activation is immediate, the ordering of windows is
static based on
> creation, and minimized windows are skipped.
> We also re-use the Alt+Tab mechanism to cycle through
desktops (Ctrl+Tab),
> either in numerical order or most-recently-used order.
>
> It seems to me that Alt+Tab has two different uses;
switching to the
> most-recently-used window (or, with Alt+Shift+Tab the
most recently
> minimized window), and cycling through all windows.

 It has three uses, the third one being activating a
specific window that one 
wants to work with. Cycling through all windows until one
hits the right one 
could be possibly seen as a solution for this, but that's
awfully cumbersome.

> Current "KDE-style" 
> behaviour is great for the first option, but kinda
sucks for the second. 
> "CDE-style" behaviour is ok for the second,
but sucks for the first.
>
> When switching to the "previous" window, one
generally presses Alt+Tab or
> Alt+Shift+Tab once and that's it, with no need for
popping up any sort of
> list.  But when cycling through windows, it helps to
have an organised list
> displayed.  I would think that the most helpful
organisation would be by
> application (all konqueror windows together, all kopete
windows together,
> etc.), perhaps with some visual indicator separating
the application
> groups.
>
> So, here's an idea.  If the user presses Alt+Tab, then
the
> most-recently-used window is activated.  If the user
presses Alt+Shift+Tab,
> then the
> least-recently-used (most recently minimized) window is
activated.  But, if
> Alt is held, a list of windows grouped by application
pops up.

 Do you mean Alt alone? Modifier-only shortcuts doesn't
really work :( , as 
can be seen e.g. with Ctrl in KHTML.

> The 
> initially highlighted window is the most-recently-used
window, so that if
> Alt+Tab is held long enough to trigger the window, but
not pressed again,
> the behaviour is the same as pressing it quickly. 
Further presses of
> Alt+Tab cycle through the window list.  Any window can
be selected by
> clicking on it.
>
> Outstanding questions:
>    What should the order of applications be?  In the
order they were
> opened? Most recently used?  ...?
>    What should the order of windows within each
application group be?  I'm
> leaning towards most-recently-used, but would another
order make more
> sense?
>
>
> Does anyone here think this outrageously stupid?   If not,
I'll post to
> kde-usability soon.

 I think I've not expressed myself clearly. There are two
ways (intentions) to 
switch windows, #1 switching between recently used windows,
#2 switching to a 
specific window  (and #3 cycling, if somebody actually
thinks cycling is 
useful on its own rather than being a poor solution for #2
). The current 
tabbox is good (at least somewhat) for #1, but it's pretty
bad for #2, 
especially with many windows.

 What I'd like to have would be a system that'd work well
for #2 and would be 
also good for #1 (this would be simply a default, effects
could try their own 
ways). Let's say, without thinking that much about details,
that one would 
press Ctrl+Alt+Tab and in some Expose-like way all windows
in some good 
arrangement. Then I could use arrows to select a window or 
filter-them-as-I-type and hit Enter to activate the one I
want. The same 
would be also displayed for normal Alt+Tab go-to-most-recent
if one holds Alt 
for longer, again with some suitable arrangement. Things
like whether to show 
windows from all desktops or only current one, KDE-style or
CDE-style walking 
and similar would be selected either by options or possibly
some of them 
could also have separate shortcuts (e.g. all desktops vs
current desktop can 
be both useful).

 Of course, this description uses vague descriptions
"some Expose-like 
way", "some good arrangement" etc. that'd
need some thinking about. That's 
what I meant with improving the tabbox. Sorry if that wasn't
clear.

-- 
Lubos Lunak
KDE developer
------------------------------------------------------------
--
SUSE LINUX, s.r.o.   e-mail: l.lunaksuse.cz , l.lunakkde.org
Lihovarska 1060/12   tel: +420 284 028 972
190 00 Prague 9      fax: +420 284 028 951
Czech Republic       http//www.suse.cz
_______________________________________________
Kwin mailing list
Kwinkde.org
https://ma
il.kde.org/mailman/listinfo/kwin

On Thursday 29 March 2007 08:16:07 Lubos Lunak wrote:
> On Wednesday 28 of March 2007, Philip Falkner wrote:
> > It seems to me that Alt+Tab has two different
uses; switching to the
> > most-recently-used window (or, with Alt+Shift+Tab
the most recently
> > minimized window), and cycling through all
windows.
>
>  It has three uses, the third one being activating a
specific window that
> one wants to work with. Cycling through all windows
until one hits the
> right one could be possibly seen as a solution for
this, but that's awfully
> cumbersome.

You're right.  Cycling through the windows is really just a
means to an end: 
activating a specific window.  Of course, that's exactly
what 
PresentWindowsEffect is so good at, with its (in essence)
maximally sized 
thumbnails.

> > So, here's an idea.  If the user presses Alt+Tab,
then the
> > most-recently-used window is activated.  If the
user presses
> > Alt+Shift+Tab, then the
> > least-recently-used (most recently minimized)
window is activated.  But,
> > if Alt is held, a list of windows grouped by
application pops up.
>
>  Do you mean Alt alone? Modifier-only shortcuts doesn't
really work :( , as
> can be seen e.g. with Ctrl in KHTML.

No, I meant as in how it works now: press Alt+Tab, but only
release the Tab, 
and the window list stays open so long as Alt continues to
be held, no matter 
what other Tab or Shift+Tab gets pressed.  But, this could
be a problem 
(below).

>  I think I've not expressed myself clearly. There are
two ways (intentions)
> to switch windows, #1 switching between recently used
windows, #2 switching
> to a specific window  (and #3 cycling, if somebody
actually thinks cycling
> is useful on its own rather than being a poor solution
for #2 ). The
> current tabbox is good (at least somewhat) for #1, but
it's pretty bad for
> #2, especially with many windows.

Yes.

>  What I'd like to have would be a system that'd work
well for #2 and would
> be also good for #1 (this would be simply a default,
effects could try
> their own ways). Let's say, without thinking that much
about details, that
> one would press Ctrl+Alt+Tab and in some Expose-like
way all windows in
> some good arrangement. Then I could use arrows to
select a window or
> filter-them-as-I-type and hit Enter to activate the one
I want. The same
> would be also displayed for normal Alt+Tab
go-to-most-recent if one holds
> Alt for longer, again with some suitable arrangement.
Things like whether
> to show windows from all desktops or only current one,
KDE-style or
> CDE-style walking and similar would be selected either
by options or
> possibly some of them could also have separate
shortcuts (e.g. all desktops
> vs current desktop can be both useful).

Hmm.  I'm assuming that the default non-effect tabbox is not
going to be able 
to use window thumbnails.  I know kompose can do it, but
it's also (as I 
remember) quite slow at it.  And if we are compositing, then
surely having an 
effect handle the thumbnails would be better, especially
with OpenGL being 
able to accelerate it.

Without thumbnails, how useful is an expose-like layout?  At
this point, all I 
can think of that we have to distinguish windows are icon,
title, 
application "group", and location on screen. 
Taking up more (all?) of the 
screen to have a big tile view instead of a list is visually
disruptive, 
which may be bad for immediate most-recent switching, but
for more general 
task-switching is ok.  It does win us bigger icons, possibly
longer window 
titles, and better use of dead space to separate windows. 
So, for example, 
we could have the konqueror windows clustered together,
while konsole is 
further away from them.

The addition of arrow-key navigation is good, and
complementary to mouse-wheel 
selection; perhaps even changing mouse-click to activating
instead of 
selecting, and mouse-hover to selecting (maybe).  But as for
as-I-type 
filtering/searching, does the holding of Alt interfere?  Is
there any 
keyboard layout or input method that uses Alt to make
characters?  If there 
isn't, great, but even then typing isn't as easy with one
finger holding Alt 
down.  So either this would need an activator after the
initial Alt+Tab, 
change the behaviour of Alt+Tab to not require the held Alt
(which would be 
different from how it works elsewhere), or have another
activation mechanism 
(like the Ctrl+Alt+Tab) that allows filtering.  I dislike
that third option, 
but the other two don't really appeal either...

>  Of course, this description uses vague descriptions
"some Expose-like
> way", "some good arrangement" etc.
that'd need some thinking about. That's
> what I meant with improving the tabbox. Sorry if that
wasn't clear.

Not at all; it just seems you're more ambitious about this
than I am. 

Just as a general comment, I think we shouldn't forget that
Alt+Tab is not the 
only task-switching method, and given its non-discoverable
nature, it's 
probably not the primary method for most people either.  I
think two of the 
main attractions of Alt+Tab are speed of use and its
previous window 
activation, i.e. "go back to where I was just
now".  Anything else should 
probably be subordinate to those two.

-- 
Philip Falkner
_______________________________________________
Kwin mailing list
Kwinkde.org
https://ma
il.kde.org/mailman/listinfo/kwin

On čt 29. března 2007, Philip Falkner wrote:
> On Thursday 29 March 2007 08:16:07 Lubos Lunak wrote:
> >  What I'd like to have would be a system that'd
work well for #2 and
> > would be also good for #1 (this would be simply a
default, effects could
> > try their own ways). Let's say, without thinking
that much about details,
> > that one would press Ctrl+Alt+Tab and in some
Expose-like way all windows
> > in some good arrangement. Then I could use arrows
to select a window or
> > filter-them-as-I-type and hit Enter to activate
the one I want. The same
> > would be also displayed for normal Alt+Tab
go-to-most-recent if one holds
> > Alt for longer, again with some suitable
arrangement. Things like whether
> > to show windows from all desktops or only current
one, KDE-style or
> > CDE-style walking and similar would be selected
either by options or
> > possibly some of them could also have separate
shortcuts (e.g. all
> > desktops vs current desktop can be both useful).
>
> Hmm.  I'm assuming that the default non-effect tabbox
is not going to be
> able to use window thumbnails.  I know kompose can do
it, but it's also (as
> I remember) quite slow at it.  And if we are
compositing, then surely
> having an effect handle the thumbnails would be better,
especially with
> OpenGL being able to accelerate it.

 Right, no thumbnails without compositing, it's either doing
them properly or 
not at all, no ugly hacks needed here.

> Without thumbnails, how useful is an expose-like
layout?  At this point,
> all I can think of that we have to distinguish windows
are icon, title,
> application "group", and location on screen. 
Taking up more (all?) of the
> screen to have a big tile view instead of a list is
visually disruptive,
> which may be bad for immediate most-recent switching,
but for more general
> task-switching is ok.  It does win us bigger icons,
possibly longer window
> titles, and better use of dead space to separate
windows.  So, for example,
> we could have the konqueror windows clustered together,
while konsole is
> further away from them.

 Well, non-composited switcher is part of the problem I
guess . I think
all 
switchers could share the underlying mechanism of the Tabbox
class if 
possible, but visual representations will need to be
separate.

> The addition of arrow-key navigation is good, and
complementary to
> mouse-wheel selection; perhaps even changing
mouse-click to activating
> instead of selecting, and mouse-hover to selecting
(maybe).  But as for
> as-I-type filtering/searching, does the holding of Alt
interfere?  Is there
> any keyboard layout or input method that uses Alt to
make characters?  If
> there isn't, great, but even then typing isn't as easy
with one finger
> holding Alt down.  So either this would need an
activator after the initial
> Alt+Tab, change the behaviour of Alt+Tab to not require
the held Alt (which
> would be different from how it works elsewhere), or
have another activation
> mechanism (like the Ctrl+Alt+Tab) that allows
filtering.  I dislike that
> third option, but the other two don't really appeal
either...

 That's why I used in the example Ctrl+Alt+Tab for #2 and
Alt+Tab for #1. I 
think the best option is having one shortcut for Alt+Tab
switching the way 
it's now and another shortcut which activates the mode and
in which another 
action needs to be taken to leave the mode.

> >  Of course, this description uses vague
descriptions "some Expose-like
> > way", "some good arrangement" etc.
that'd need some thinking about.
> > That's what I meant with improving the tabbox.
Sorry if that wasn't
> > clear.
>
> Not at all; it just seems you're more ambitious about
this than I am. 
>
> Just as a general comment, I think we shouldn't forget
that Alt+Tab is not
> the only task-switching method, and given its
non-discoverable nature, it's
> probably not the primary method for most people either.
 I think two of the
> main attractions of Alt+Tab are speed of use and its
previous window
> activation, i.e. "go back to where I was just
now".  Anything else should
> probably be subordinate to those two.

 This is not only about the keyboard shortcuts. The mode for
#2 could be also 
activated in other ways, like throwing the mouse into some
screen corner or a 
button on the panel. When having The Ultimate Window
Selector(TM) it'd be 
just logical and e.g. for users mostly using mouse this
could be pretty fast 
and convenient.

-- 
Lubos Lunak
KDE developer
------------------------------------------------------------
--
SUSE LINUX, s.r.o.   e-mail: l.lunaksuse.cz , l.lunakkde.org
Lihovarska 1060/12   tel: +420 284 028 972
190 00 Prague 9      fax: +420 284 028 951
Czech Republic       http//www.suse.cz
_______________________________________________
Kwin mailing list
Kwinkde.org
https://ma
il.kde.org/mailman/listinfo/kwin