Summary: | ALT-TAB switch box too large | ||
---|---|---|---|
Product: | [Plasma] kwin | Reporter: | Joseph Wenninger <jowenn> |
Component: | general | Assignee: | KWin default assignee <kwin-bugs-null> |
Status: | RESOLVED DUPLICATE | ||
Severity: | normal | CC: | ewilhelm |
Priority: | NOR | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | Compiled Sources | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: |
Description
Joseph Wenninger
2002-04-28 13:59:21 UTC
That bug is still here. We should really wrap the lines if they are maybe > than 50% of the screen width. Please don't change the priority, it's only for developers working on the app. I count 75 open windows right now on desktop 1. While not having the icons wrap is a problem, I'd really like to see the alt-tab task list interface turn into something more than a simple stack. Maybe something similar to the window-list button on the taskbar (which lets you select an item with the mouse). If you setup the task list to wrap at about 60% of the screen, but had it accessible as a matrix so that as long as you kept the ALT key depressed, you could use the keyboard arrows to jump to the next row or you could select an item with the mouse. I think the dialog should preserve the current ALT-TAB cycling behavior, but adding the option of a "random access" feature once you have the list box would be great. Possibly even allow the 1,2,3,etc keys to jump to the respective app (so you would hold alt, and hit tab,4 to jump to the fourth item in the list.) In 3.2 (at least) it was already possible to select an item from the Alt/Tab box directly with the mouse. For 3.3 I have changed the Alt/Tab box so that it's more like the window list from kicker. That means, the window titles are shown in a list with the icons on the left. Still this does not solve the very first request, because now on a 1024x768 resolution you will see at a maximum about 42 windows. The list will neither scroll nor wrap to a second column (all the other window titles are not shown). But I really doubt, that you can easily navigate at all in such a long list (My suggestion is to use more virtual desktops instead) I don't like virtual desktops, because switching between them has always been too slow and it is too much trouble to try to sort applications into one desktop or another. Please fix the tabbox so that it can handle an unlimited (or at least reasonable large (~400)) number of applications. My desktop is more of a set of layers. If I'm doing a lot of varied work, the top layer of about 5-10 apps is always off the left of the tabbox. So, I don't need to be able to navigate between 400 apps, but it would be nice to be able to see the few that I'm dealing with (everything around the stack pointer.) Different users have different habits and preferences. If you impose an arbitrary limit, you hinder those that need to go beyond it. Ok, now I'm running 3.3.2 and I see your new tabbox not only doesn't implement the wrapping behavior which was the original source of the bug. It also truncates the stack order to what can be displayed on the screen. This means that I can't alt+shift+tab to the window which was last minimized. *** This bug has been marked as a duplicate of 98190 *** >http://bugs.kde.org/show_bug.cgi?id=41822 >l.lunak kde org changed: > >*** This bug has been marked as a duplicate of 98190 *** Please don't mark new bugs as duplicates of old bugs. 98190 is a report of a bug in the attempted fix for 41822. The vertical tabbox that was implemented for 3.3.2 is the wrong approach. The previous tabbox was more functional, and simply needed to check the width of the current *screen* and then wrap the icons onto multiple rows. Note that I say *screen* because checking the width of the display gives the wrong answer on xinerama desktops. Fixing the bug as reported in 98190 would mean changing the behavior of the wrong code. Please go back to the 3.2.2 tabbox code and implement wrapping. Please mark 98190 as a duplicate of 41822 (or maybe as "should never have been able to be a bug", since it is a bug in a workaround.) Thanks, Eric |