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

List:       kde-usability
Subject:    Re: [KDE Usability] On the future of the menubar
From:       James Tyrer <jrtyrer () earthlink ! net>
Date:       2010-02-26 7:44:18
Message-ID: 4B877BD2.3090101 () earthlink ! net
[Download RAW message or body]

Dotan Cohen wrote:
>>> How is System Settings different than any other KDE application in this regard?
>> Many KCM modules need a lot of vertical space. Some can be improved,
>> others cannot (speaking as someone who spent quite some time trying to
>> fix some of them before 4.0 was released). Therefore it makes sense to
>> leave most space available to what matters.
>>
> 
> Is that not true of a PDF viewer? The whole page doesn't fit on a
> vertical screen (even less on a widescreen). So why does Okular still
> have a menubar?
> 
> Or how about a web browser? Or an office suite? Most apps are limited
> by vertical space, System Settings is not special in this regard.
> 
> 
>> This is not specific to System Settings, so I think it would be good to
>> standardize a "reduced menu" in the HIG, similar to what Rekonq created.
>> The use-case would be applications which do not need large menus and
>> have important vertical space needs.
>>
> 
> In general, I agree. I have not seen the rekonq implementation, though.
> 
> 
>> - This menu would be included in the toolbar either as a "Menu" button,
>> or as an icon if horizontal space is limited (that's the case for
>> Rekonq, where horizontal space is best left to the url lineedit).
>>
> 
> There is a feature request for that:
> https://bugs.kde.org/show_bug.cgi?id=211304
> 
>> - This menu would contain items like "Configure", "Quit" or "Help", with
>> "Help" being a submenu like Rekonq does.
>>
>> - A limit should be defined to let developers decide whether it makes
>> sense for them to use a "reduced menu".
>>
This is starting to not make much sense.  Consistency is very important. 
  I find SystemSettings a bit disorienting.  I presume that it is 
because it doesn't follow the HIG.  IIRC, this is called proactive 
inhibition in learning theory.  The hybridization of the MenuBar and a 
ToolBar might seem to be innovative to the person that designed it, but 
to me, it is simply inconsistency.  Does any other application have the 
"Help" MenuBar category available on a ToolBar?

SystemSettings should have a Menu.  I would presume that it could be 
hidden with <Ctrl><m> which I do in Konqueror when I need more vertical 
space.

Obviously, if SS doesn't have many major menu categories, then the menu 
is going to be rather minimal.

The question which I think needs to be considered is whether it should 
be permissible for the MenuBar and a ToolBar to appear on the same line 
the way the multiple ToolBars are.  If this were allowed, it should 
resolve the problem since a MenuBar with only:

	File
	Go
	Settings
	Help

isn't going to take much space -- less than half of the screen width.

There are other things which could be more consistent or improved.

It would probably be getter to use the correct icon: "help".  I think 
that it is OK to use the KDE specific icon since I really don't know 
what the "system-help" is supposed to be used for.  There is no standard 
icon name for the Help Menu since the word "Help" rather than an icon is 
supposed to be used.

IIUC, it is permitted for icons on ToolBars to appear and disappear 
based on context -- that they should do this rather than be grayed out 
(which is only done when they are usable in the context but not 
currently usable).  So, the "back" icon on the HybridBar should 
disappear when it can not be used rather than being grayed out.  The 
HybridBar could also have a "Quit" icon that could also appear and 
disappear when it is needed.  Actually the result would be that an icon 
for either "Back" or "Quit" (but not both) would appear on the HybridBar.

The text box on the HybridBar is labeled "Search".  Not sure if that is 
best.  It isn't really 'search', but it isn't really 'find' either, more 
like 'filter', but not exactly.  Theory suggests that a different term 
should be used, or perhaps the label isn't needed.

-- 
James Tyrer

Linux (mostly) From Scratch
_______________________________________________
kde-usability mailing list
kde-usability@kde.org
https://mail.kde.org/mailman/listinfo/kde-usability
[prev in list] [next in list] [prev in thread] [next in thread]