Mailinglist: http://foo-projects.org/pipermail/xfce4-dev/2006-December/021967.html Flash Demo: http://users.tpg.com.au/adsltimu/task-system-launcher.html Images: http://users.tpg.com.au/adsltimu/task-system-launcher.html http://www.robin.com.au/image/mywinlist.png Forum threads: http://ubuntuforums.org/showthread.php?t=320315
OK I'm looking for a Linux desktop environment that can do this, good to see at least something has been opened already even though it was 5 years ago. :) For implementation examples, I think Windows 7 is quite a good example of how it can be done. I don't think system tray needs to be included in the equation as some of the background providing thread links seemed to discuss. Just combined launcher + window buttons = win for me. Half of this functionality/design is actually achievable already, see next attachment. Integrated Launcher part is missing.
Created attachment 3603 implementation example for combined launcher+windowbuttons
I sorta got back fron this idea. I'm using windows 7 on my work laptop, and I think the design (merge running and launching apps) is horrible.
Okay. I think it works well precisely with laptop's limited screen estate. Can you tell me your thoughts on what sense does the current approach make, demonstrated in the next attachment.
Created attachment 3604 demonstration of useless duplication between launcher and window buttons
Note about duplication: there is only one app icon shown in the demo, but on my regular laptop workflow the whole taskbar vertical height is regularly full of icons (switched to small size!) and there is no good solution to paging them. As a matter of fact when the taskbar pages them, that's my cue to start closing some idling apps. Anyway, that particular estate is quite valuable IMHO. Can you perhaps elaborate on "horrible"?
Yes the somewhat closer packing is an advantage, however a lot of people like to know which app is actually running, this is not always exposed with this approach (look at osx). Another downside is that it becomes less efficient (as in less relative space "gain") when you open more windows of the same app which is something you frequently do when the tasklist becomes "full". So in my experience it works good (as in saving space) when not a lot of applications are running (and you don't really need it) and it becomes less effective when things got crowded. Instead I tend to focus on making the tasklist more effective when it has limited space: predictive sorting, mouse-over wireframe (since you often remember the screen position of the window), overflow menu and, although not completely finished yet, good grouping of windows. I also like the windows 7 powerful right-click menu, if possible to implement properly (so it probably needs a fd.o-spec first), which also improves launching new instances of the same application (and for all applications, not only the ones that also have a launcher). There are some technical difficulties that got better with gnome-shell; wm-names are more consistent so easier to match windows with launchers/menus/etc. But still some cases it won't work, something that can be very confusing for end-uses. This whole merge thing can still exist along with the current code, best in a separate plugin since tasklists are already quite complicated, but for now I focus on optimizing what-we-have before throwing something else in the ring, building on top of other half-backed code (ok it's not that bad, but you get the point ;-).
(In reply to comment #7) > Yes the somewhat closer packing is an advantage, however a lot of people like > to know which app is actually running, this is not always exposed with this > approach (look at osx). I am not sure how to agree here. OS X is my daily workstation and "running dot" in the Dock is more than enough to know what is running. As implemented on Windows 7, there is absolutely no misunderstanding of what is running and what is not, since the icon becomes framed, highlighted, blinkityblinking and all that. > Another downside is that it becomes less efficient (as in less relative space "gain") when you open more windows of the same app which > is something you frequently do when the tasklist becomes "full". Am I missing something here? Windows of a single app will be listed underneath the single app's launcher icon as shown in my demo screenshot. When you open more windows of the same app, doesn't efficiency increase instead - since you put more window entries hidden underneath a single launcher icon. > So in my experience it works good (as in saving space) when not a lot of > applications are running (and you don't really need it) and it becomes less > effective when things got crowded. Things get crowded with launched apps count, which usually is still much less than total window counts across all apps. As a wrap-up, I think the only issue is paging to which i really don't have a good solution. I don't like Microsoft's way of hiding the previous icon page completely though, something like up-down scroll arrows + scrollwheel recognition would work a lot better IMHO. > I also like the windows 7 powerful right-click menu, if possible to implement > properly (so it probably needs a fd.o-spec first), which also improves > launching new instances of the same application (and for all applications, not > only the ones that also have a launcher). +1 here, it took a bit to get used to, but then it does work alright. > This whole merge thing can still exist along with the current code, best in a > separate plugin since tasklists are already quite complicated, but for now I > focus on optimizing what-we-have before throwing something else in the ring, > building on top of other half-backed code (ok it's not that bad, but you get > the point ;-). ACK on this. Just wondering, if I were to look for one co-dev interested in doing some co-hacking on this, where should I look?
Greetings, I'm the guy who made the demo, but older. > a lot of people like to know which app is actually running A solvable problem with many room for creativity, eg. make not-running icons monochrome/transparent, make running icon glow like jesus, etc. > less relative space "gain") when you open more windows of the same app Should be space gain cos you don't need to render the icon for every Firefox window, just once will do. Assuming panel is in top/bottom. If panel is to the side, then maybe no gain at all. > Instead I tend to focus on making the tasklist more effective when it has > limited space: predictive sorting, I prefer my tasklist to not do any fancy sorting. Just simply open new tasks to the right (now that's predictable) or in the demo's case, to the right of the correct app group, and can be rearranged manually after but only within the app group. So this brings up a possible disadvantage, Firefox window tasks MUST always be within the Firefox group of tasks. > mouse-over wireframe (since you often > remember the screen position of the window) My windows are always maximized :( > This whole merge thing can still exist along with the current code, best in a > separate plugin since tasklists are already quite complicated, but for now I > focus on optimizing what-we-have before throwing something else in the ring, > building on top of other half-backed code (ok it's not that bad, but you get > the point ;-). Come on! Take a chance! Just look at Gnome Shell! To go to my Firefox window on page 2, I move my mouse to the top left then all the way to the right edge, select page 2, then to the middle to select Firefox window.
Not easy to fix this, and anyway, no nice way to fix this in a panel-internal plugin.