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

List:       kde-usability
Subject:    Re: Cleaning up KDE: Context-menus
From:       Janne Ojaniemi <janne.ojaniemi () nbl ! fi>
Date:       2004-03-30 5:49:05
Message-ID: 200403300849.06122.janne.ojaniemi () nbl ! fi
[Download RAW message or body]

On Tuesday 30 March 2004 02:06, Maks Orlovich wrote:
> > That's 5 groups with 12 selections, 5 with submenus. Looking at the
> > selections, the first ones that caught my eye was the
> > "Bookmarks"-selection. Why do we need it in the context-menu for the
> > desktop? How is web-browsing related to the desktop? If I want to surf
> > the web, I'll fire up Konqueror or I select a bookmark from the Universal
> > Sidebar.
>
> The universal sidebar is not enabled by default; so I don't think it is
> relevant for this discussion.

true, I was just telling how I do it ;). 

Seriously, why do we need bookmarks in the desktop's context-menu? Shouldn't 
the context-menu be about the desktop and actions you can perform on it? Such 
actions like arranging icons and windows, moving/copying items to/from the 
desktop, configuring the desktop and the like. Having bookmarks to the 
filesystem or to the web is not in any shape or form related to the desktop. 
Those actions are done in Konqueror, therefore they should be in Konqueror, 
and not on the desktop.

>
> > Another one is the "Help"-selection. Why do we need it in the
> > context-menu? We could just a well access it through the regural
> > help-tool. Or it could be inserted to the Desktop Configuration-tool. And
> > since it's already in the K-menu, having it in the desktop-menu as well
> > seems redundant.
>
> Removing ways to access help in name of usability seems a bit contradictary
> at best.

No it isn't. Having the help in the context-menu makes it seem more cluttered. 
And having a huge context-menu is not usable. Help is already available 
through the K-menu and it's in the Kicker as well (IMO we should remove it 
from the Kicker too), so there's no real need to have it in the context-menu 
as well.

By your logic, access to help should be available everywhere. Every single 
submenu in the K-menu, in the toolbar, in the Kicker, in the K-menu itself 
etc. etc. since that would be more "usable", right?

> > 14 selections (3 with submenus) and 5 groups. How to clean that up? I
> > think "Copy To" and "Move To" could be removed.
>
> Well, you are free to not install kdeaddons. But I would like to point out
> that there have been multiple bug reports from people who forgot to install
> the kdeaddons package asking to put back the "Copy To/Move To" entries, and
> asking why in the world we would remove such a convenient feature.

I wasn't aware that that service is provided by kdeaddons. But I still don't 
see the point. Same funtionality can be achieved by using regural "Cut" and 
"Copy". Why add yet another menuentry for action that is not used that often 
and could be conveniently done using other available tools (tools that have 
more use than such specialised tools like "Copy To/Move To")

>
> > window" being in a submenu. Also, "Actions >" could be moved under the
> > "Open in... >" selection in the first group, eliminating one group. Doing
>
> Actions do not generally open things in applications; such a label would be
> misleading, and hence confusing.

I'm sorry, I'm not following you. In case you mean that "Open in..." would 
show a submenu with "Actions" in it, that was not my point. My point was to 
simply move "Actions" to another location in the menu, not to a submenu. When 
I said "under Open in..." I mean that it would be located under the "Open 
in..." entry in the menu. Same way as "Copy" is under "Cut" in the menu. 
Moving "Actions" like that would eliminate one entire group in the menu.
_______________________________________________
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]