[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-usability
Subject: Re: Cleaning up KDE: Context-menus
From: Sashmit Bhaduri <smt () inbox ! lv>
Date: 2004-03-29 16:34:41
Message-ID: 1080579622.4068562663ce2 () www1 ! inbox ! lv
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
Quoting Janne Ojaniemi <janne.ojaniemi@nbl.fi>:
> 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.
You can bookmark file management items as much as you can bookmark web browsing
items. However, removing this might be a good idea, for the very same reasons
why I removed "Add Bookmark" from Konqui's file part's context menus: bookmarks
are simply used much more in web browsing than in file management. The desktop
is primarily a file management view.
> 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.
I agree.. Help isn't in very many context menus in KDE (esp, Konqui and
kdesktop.. while it is in Internet Explorer), and khelpcenter is sitting in the
kicker. Providing quick access to help is extremely important, and I think that
kicker is probably the easiest place to do that from. Most novice users won't
typically use the context menu to find help, while most intermediate and
advanced users will likely know where it is.
> Another one is the "Run Command..."-selection. Again, that's not really
> relevant to the desktop as such. And since it's already present in the
> K-menu, it could be dropped from the desktop-menu.
> That 9 selections, with 3 submenus and 4 groups. I think it would look alot
> better than the current context-menu. Also, "Lock screen" and "lockout user"
>
> could also be removed, since they are already available in the K-menu and
> they are not relevant to the desktop as such. Also, user can add them to the
> Kicker.
I don't agree here.. while they may not be specific to the desktop per say,
these commands are certainly specific to the mental model of the desktop in
user's minds.
> I think
> "Copy To" and "Move To" could be removed.
This is implemented in a konqueror menu plugin in kdeaddons. Yeah, judging from
the number of people who think that it's part of konqueror, it very well might
be part of it.. especially since we don't have a way to turn off konqueror
plugins :)
I was going to implement KonqMenuPlugins being able to check what flags the
enclosing part hinted at, but I ran out of time in 3.2. This would, for
example, allow the CopyTo/MoveTo plugin to not appear in HTML views, which was
not possible without nasty hacks before 3.2.
> Also, why do we need the "Preview with FSviewpart"?
> could be dropped as well. And what does "Open with" do here? If I'm browsing
> folders, I'm browsing them with Konqueror obviously, why would I want to
> change to some other app all of a sudden? So it could be dropped as well.
These are dynamic... it would be very hard to subclass them without removing
perfectly usable places in which these actions are needed. Perhaps they can be
merged somehow, but I don't have any good ideas about that.
> Also, "Open in new tab" and "Open in new windows" could be merged in to a
> "Open in... >" selection with "new tab" and "new window" being in a submenu.
I think this is a situation where quick access is better than producing
clutter.. open in new tab/new window is especially used quite a lot in web
browsing, and we want that part of the menu to stay consistant between file
management and web browsing.
> 9 selections (two with submenu) and 3 groups. Alot nicer looking, no? Also,
> maybe we could remove either "delete" or "move to trash"? Having both there
> is a bit redundant.
Perhaps when we have the long fabeled trash ioslave that doesn't copy over 600
mb CD images to the trash.. until then we need it :-)
> Now, if we look at the "Actions >" submenu, it looks like this:
>
> Encrypt file
> Create gzipped tar archive
> Create bzipped tar archive
> Create zip archive
> Archive & Encrypt folder
> Open Terminal here
>
> Maybe it should be cleaned up a bit? Couldn't the archiving-selections be
> merged as one? Maybe have just selection titled "Archive" with submenu
> showing different archiving-possibilities. Or the user could enter his
> default choice in preferences, and "Archive" selection would always use his
> default choices?
These are dynamic (service menus).. perhaps file a bug report to ark asking em
to create a Create archive submenu.
> Also (I'm going to get flamed for this....), do we REALLY need the "Open
> terminal here"? KDE is a GUI, therefore it should really be a GUI, and it
> should not use the terminal for hand-holding. If the user wants to open a
> Konsole, he could do it, but why put it in here? Konsole is already available
> through the K-menu. I think "Actions"-menu should be reserved for activities
> the user could do using third-party KDE-apps. Konsole is not one of those
> apps. Also, if the user wants to open a terminal in that folder, he could
> just drag the folder to Konsole, that achieves the same functionality.
Uh oh, don't ask to do that! :)
> My next subject: Toolbars and the Kicker. Stay tuned ;)
-- Your free mail Inbox.lv
---
This message contains no viruses.
Guaranteed by Kaspersky Anti-Virus.
http://www.antivirus.lv
[Attachment #5 (text/html)]
<pre>Quoting Janne Ojaniemi <janne.ojaniemi@nbl.fi>:
> 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.
You can bookmark file management items as much as you can bookmark web browsing
items. However, removing this might be a good idea, for the very same reasons
why I removed "Add Bookmark" from Konqui's file part's context menus: \
bookmarks are simply used much more in web browsing than in file management. The \
desktop is primarily a file management view.
> 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.
I agree.. Help isn't in very many context menus in KDE (esp, Konqui and
kdesktop.. while it is in Internet Explorer), and khelpcenter is sitting in the
kicker. Providing quick access to help is extremely important, and I think that
kicker is probably the easiest place to do that from. Most novice users won't
typically use the context menu to find help, while most intermediate and
advanced users will likely know where it is.
> Another one is the "Run Command..."-selection. Again, that's not \
really > relevant to the desktop as such. And since it's already present in the
> K-menu, it could be dropped from the desktop-menu.
> That 9 selections, with 3 submenus and 4 groups. I think it would look alot
> better than the current context-menu. Also, "Lock screen" and \
"lockout user" >
> could also be removed, since they are already available in the K-menu and
> they are not relevant to the desktop as such. Also, user can add them to the
> Kicker.
I don't agree here.. while they may not be specific to the desktop per say,
these commands are certainly specific to the mental model of the desktop in
user's minds.
> I think
> "Copy To" and "Move To" could be removed.
This is implemented in a konqueror menu plugin in kdeaddons. Yeah, judging from
the number of people who think that it's part of konqueror, it very well might
be part of it.. especially since we don't have a way to turn off konqueror
plugins :)
I was going to implement KonqMenuPlugins being able to check what flags the
enclosing part hinted at, but I ran out of time in 3.2. This would, for
example, allow the CopyTo/MoveTo plugin to not appear in HTML views, which was
not possible without nasty hacks before 3.2.
> Also, why do we need the "Preview with FSviewpart"?
> could be dropped as well. And what does "Open with" do here? If I'm \
browsing > folders, I'm browsing them with Konqueror obviously, why would I want \
to > change to some other app all of a sudden? So it could be dropped as well.
These are dynamic... it would be very hard to subclass them without removing
perfectly usable places in which these actions are needed. Perhaps they can be
merged somehow, but I don't have any good ideas about that.
> Also, "Open in new tab" and "Open in new windows" could be \
merged in to a > "Open in... >" selection with "new tab" \
and "new window" being in a submenu.
I think this is a situation where quick access is better than producing
clutter.. open in new tab/new window is especially used quite a lot in web
browsing, and we want that part of the menu to stay consistant between file
management and web browsing.
> 9 selections (two with submenu) and 3 groups. Alot nicer looking, no? Also,
> maybe we could remove either "delete" or "move to trash"? \
Having both there > is a bit redundant.
Perhaps when we have the long fabeled trash ioslave that doesn't copy over 600
mb CD images to the trash.. until then we need it :-)
> Now, if we look at the "Actions >" submenu, it looks like this:
>
> Encrypt file
> Create gzipped tar archive
> Create bzipped tar archive
> Create zip archive
> Archive & Encrypt folder
> Open Terminal here
>
> Maybe it should be cleaned up a bit? Couldn't the archiving-selections be
> merged as one? Maybe have just selection titled "Archive" with submenu \
> showing different archiving-possibilities. Or the user could enter his
> default choice in preferences, and "Archive" selection would always \
use his > default choices?
These are dynamic (service menus).. perhaps file a bug report to ark asking em
to create a Create archive submenu.
> Also (I'm going to get flamed for this....), do we REALLY need the "Open
> terminal here"? KDE is a GUI, therefore it should really be a GUI, and it
> should not use the terminal for hand-holding. If the user wants to open a
> Konsole, he could do it, but why put it in here? Konsole is already available
> through the K-menu. I think "Actions"-menu should be reserved for \
activities > the user could do using third-party KDE-apps. Konsole is not one of \
those > apps. Also, if the user wants to open a terminal in that folder, he could \
> just drag the folder to Konsole, that achieves the same functionality.
Uh oh, don't ask to do that! :)
> My next subject: Toolbars and the Kicker. Stay tuned ;)</pre><br>
-- Your free mail Inbox.lv ---<br>
This message contains no viruses.<br>
Guaranteed by <b>Kaspersky Anti-Virus</b>.<br>
<a href="http://ads.inbox.lv/htmlclick.php?bannerID=1012&dest=http%3A%2F%2Fwww.antivirus.lv" \
target="_blank">http://www.antivirus.lv</a>
_______________________________________________
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]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic