HIG: tabwidgets

[Aaron J. Seigo]

On Thursday 09 March 2006 04:27, Ellen Reitmayr wrote:
> On Thursday, 9. March 2006 09:15, Aaron J. Seigo wrote:
> > 	 http://openusability.org/projects/kde-hig/
>
> project link points to the hig wiki now.

thanks =)

> > something should probably be said about frames in tab widgets. in Qt4 we
> > have proper control over this, which we didn't in Qt3. huzzah!
>
> aeh - what exactly does that mean?

sorry, i let the programmer in me take over for a moment there apparently ;)

if you look at konqueror or konsole, there is a frame around the contents of 
the tabwidget. in qt3 we cannot get rid of it because it is hardcoded to 
paint it. in qt4 we can control it via the style and QStyleOptions. this 
should allow us to get rid of the frame when it makes sense (e.g. maximized 
window, so that the scrollbar is right against the edge of the screen) or at 
least tone it down a bit when we don't want a full-on frame.

> > Where to place tabs in a window: Where the common locus of attention is.
> > This is usually the top of the window, except for command line and chat
> > applications which tend to put new information at the bottom of the
> > window and therefore keep the user's attention there. In such cases the
> > tabs should appear at the bottom of the window.
>
> do you know omniweb for macosx? there, tabs are in a drawer, left or right
> of the window. the good thing about it: the tabs provide a preview of the
> displayed web page, very much like the navigation bar in kpdf. even better:
> you can freely move the different tabs, detach and rejoin them via drag and
> drop, which facilitates the grouping of related pages.

for a reader/browser (konqueror, kpdf) this may make a lot more sense indeed. 
should we add something in here about multi-page readers and how they should 
avoid tabs but use a thumbnail navigator instead? and see if we can get the 
okular thumbnail navigator widget into kdelibs so it can be used by all such 
apps?

> this approach is not only useful for web/file browser, but also for kate
> and other apps where logical grouping of open document makes sense.

for kate this is doubtful since one source code file looks like another in 
thumbnails until they get REALLY large ;)

i can see it making a difference for book and web readers, however.

> however 
> - vertical navigation bars consume a lot of space.

true, but i can't imagine kpdf any other way =)

> > Standard Actions:
> > The following actions should be available if it makes sense within the
> > workflow of the application. For instance, while it makes sense to offer
> > "Duplicate Tab" in a web browser, it doesn't in a chat application.
> >
> > Action		Shortcut		Required
> > -------		---------------	-----------
> > New Tab		Ctrl+Shift+N	Yes
> > Detach Tab	Ctrl+Shift+D	No
> > Duplicate Tab			No
> > Reload Tab	F5		No
> > Next Tab		Ctrl+Left_Arrow	Yes
> > Previous Tab	Ctrl+Right_Arrow	Yes
>
> Move Tab right
> Move Tab left

hm... do you have suggestions for keyboard shortcuts?

> > Context Menus: this should be a description of the context menu including
> > spots for customization. for instance:
> >
> > New Tab
> > Reload Tab
> > Detach Tab
> > Duplicate Tab
> > -----
>
> Move Tab right
> Move Tab left

does this really need to be in the context menu?

oh, and this brings up another question: drag and drop of tabs... should that 
reorder the tabs, or drag a representation of their contents? right now in 
konqueror it drags the URL associated with the tab, for instance.

-- 
Aaron J. Seigo
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

Full time KDE developer sponsored by Trolltech (http://www.trolltech.com)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kde-usability-devel/attachments/20060309/ff1be21a/attachment.pgp