[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-look
Subject:    Re: MDI + SDI = FDI ?
From:       Hans Meine <hans_meine () gmx ! net>
Date:       2001-03-21 3:32:44
[Download RAW message or body]

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 <mklingens@yahoo.com> writes:
> On Sunday 18 March 2001 19:53, Hans Meine wrote:
> > Matt Newell <newellm@proaxis.com> 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 *,.

[prev in list] [next in list] [prev in thread] [next in thread]