Hi Martijn, Since I am very busy with university stuff (learning for some kind of exams), I did not answer earlier / lengthier, sorry. :-/ I will also send this to kde-look together with the quoted parts, sorry for forcing you scrolling... There are nice ideas in all those texts so I did not dare snipping too much. ;-) Martijn Klingens writes: > On Sunday 18 March 2001 19:53, Hans Meine wrote: > > Matt Newell writes: > > > > Your remark made me wonder though ... Would it be a good idea to have a > > > > taskbar button for _ANY_ document, whether it's inside an MDI view or a > > > > real SDI window? Then the stacking of similar views is up to to > > > > taskbar/kasbar/whateverbar and the user can directly activate any > > > > document, wherever it is located. It would make KDE even more > > > > document-centric (which is better than app-centric IMNSHO) > > > > > > I don't like this idea. I always have at least 10-30 "documents" open at > > > one time. 3-4 konsole views, 5-20 Kant docs, 3-6 Konq wins, 1 email win, > > > 1 xmms win, 1 knode win. This is too many documents to have listed on > > > the taskbar. > > > > Yet I think Martijn is right; it would be cool to have all documents > > accessible and if you read his words carefully, he mentions an > > often-talked-about idea: > > > > Let the taskbar/kasbar/whateverbar manage the "stacking of similar views", > > It would btw be a 'document bar' then and not a 'task > bar' anymore, but that's rather unimportant ;-) > > > that is: show i.e. only one kant doc (the last accessed/current for > > example, that would be quite how it is currently) but make all other kant > > docs accessible by a button-menu (like konq's navigation toolbar buttons, > > with a small menu- indicating arrow) for example. > > > > There might come up more/better ideas for such "stacking", > > If I remember the articles on Windows XP correctly, > they have a scheme that roughly translates to: > > "Just add buttons to the taskbar until some threshold > is hit and the user enabled stacking. Beyond the > treshold, start grouping open documents on the taskbar > per app." > > I'm not sure if the group button itself only pops up > the grouped windows or also activates the most recent > doc. Both have their own merits and problems. Either > you have to keep the button pressed for a while to > access the other documents, or there is no quick way > to access the most recent one, and both of those > problems aren't great imho. > > The obvious solution is the way e.g. Mozilla treats > the popping up of submenus: the drop-down arrow reacts > different from the rest of the button, so _BOTH_ can > be accessed using single-click and no need to keep > buttons pressed. The visual clue on mouse-over makes > it immediately clear what (will) happen. But AFAIK Qt > does not support such behaviour in QToolButton :-( Hmm, did not try that yet. Seems reasonable for an experienced user; maybe QToolButton should be enhanced to behave like before, but react instantly if you press on the small arrow. Sound cool. > Buttons on other desktops should IMHO honour the > settings like they are now: either they are all shown > like all other buttons, or they are not shown at all. > > Related, but not entirely similar is another idea that > I have to make the taskbar even more doc-centric. It > is the way I interpreted articles on MacOS X, so > either it's a complete rip-off or a misinterpretation > that might still be a good idea. > > Anyway, I would really like an API that allows apps to > provide thumbnail previous of documents in a way > similar to the way icons are provided. That API > performs pretty well, whereas the thumbs from Kasbar > TNG are nice, but also way too slow for generic use. > > It allows for a completely new kind of task bar, split > into two parts. The first part shows all apps that > don't maintain documents (kcontrol for example) and > all legacy apps that don't have this new API the same > way current taskbar/kasbar implementations do. > > The apps that do support the API however, register > this capability to the taskbar and the taskbar does > _NOT_ draw a normal button for it. Instead, _ONLY_ a > thumbnail is drawn, without the text label, or with > the label superimposed on it somehow. > The thumb should use the entire height of the panel in > which the task/kas/etc-bar resides, i.e. no stacking > of buttons like the normal taskbar does in the larger > panel sizes. That is not a problem since leaving out > the labels actually results in more rather than less > space on the task bar. Sounds OK, but I am not convinced it's worth it. Somehow I believe the doc's name is more descriptive than a thumbnail in many cases. I wouldn't recognise most .txt, .wrd, .doc, .ps, .dvi or other files I have opened by a thumb I guess. > When performance allows it a zoom feature like > kicker's icon zooming should be available that shows > the document's thumb in sizes up to 64x64 or more. The > tooltip should show the normal text the way it's done > now too. Seems like a reasonable extension to the upper idea, _it that's done_. > Most of this is somehow already available in Kasbar, > but with a specialized API it avoids or solves a > number of problems in kasbar: > - Apps that don't maintain documents like KControl do > not necessarily benefit from thumbs over normal icons. > - Grabbing real windows is too slow for normal use > - Grabbing windows only works when windows are not > overlapped > - Grabbing windows also grabs toolbars and such. They > only distort the thumb of the actual document and > don't really help the user in any way IMHO. With the > api, the app can just use it's actual document view > widget for the preview. > - Kasbar 'polls' the app for a preview. With an API it > is possible for the app to 'push' new thumbnails to > the taskbar when there are indeed changes. The global > settings, like themes, should be configurable, like > the amount for changes in the displaying widget or the > number of idle seconds before the thumb is updated. > This, again, helps to improve performance Sounds cool (tried enlightenment lately), but even then, the thumb would probably have to be created quite often. And that would probably be a quite expensive job the app would have to do itself (b/c it knows best about the doc and the window might not show the right thing/might not be grabbable). -- Ciao, / / /--/ / / ANS .,* Hamburg, Germany *,.