Bug 53772

Additionally, the Image menu is lacking the option to copy a page's image to the 
clipboard. This is possible through drag and drop but it's nice to have it on the menu. 
My proposed image context menu would be something like this: 
 
View Image 
Copy to Clipboard 
Copy Image Location 
----- 
Save Image 
Send Image 
----- 
Stop Animations 
Image Properties 
 
And if Image blocking were ever implemented, it could be added here as well. 

I agre, Konqueror's context menus are a total mess, not only the web browser,
but the flemanager too, often giving dozens of entries which make no sense.

Also a simple "copy" should replace the "copy to" option in the web browser, who
uses that anyway!!?

Maybe copy-to can show a list of just recently visited directories to copy to. I think most people 
copy files to recently visited directories 99% of the time, right? This will make copy-to very useful. 
 
Oh, one more thing: Please display the just recently visited directories relative to the current 
directory. So, "../documents" in stead of "/home/john/documents" 

What about letting the user configure the available items in the context menu similar to how 
the toolbar can be configured?  

I COMPLETELY AGREE!!!

KDE has some context menus you wouldn't believe! They include just about
everything except an option to make you breakfast when you actually should only
see a few entries re

What annoys me the most about these super duper bloated menus all over KDE is
that they often have just about everything EXCEPT what I want.

For example, here are the context menu entries that come up when I highlight
some text and right click:

Up
Back
Forward
Reload
Open in New Window
Open in Background Tab
Open in New Tab
Add to Bookmarks
Open With
Encrypt FIle
Create Data with K3b ...
Copy To ->
Select All
Stop Animations
View Document Source
Viw Document Information
Secuirity ...
Set Encoding ->

In addition, most of these entries do nothintg to the text. For example "Copy To
->" copies the whole page and K3b sets up the whole page for burning and
"Encrypt File" would encrypt teh whole page and Open in New Tab opens the entire
page in another tab etc.

Now the funny thing is, that even with 18 context menu entries (not counting the
hundreds of submenu entries) a simple COPY command was left out!! Another odd
thing is that right clicking on a link will yield a simple COPY command but not
on highlighted text!!?

Wha the user actually needed to see when right clicking on highlighted text
should have been something simple like in Mozilla:

Copy
Web Search for "selected text"
View Selection Source

But, I'm not really suprised that Konqueror included 15 useless and confusing
entries when doing something as simple as highlgihting text, after all right
clicking on empty part of the page will give you the EXACT same menu.not exactly
context sensitive menus...

The worst part is that such bloated context menus are all over KDE, for example
clicking a floppy will yield 17 entries, albeit less than when right clicking on
text, but still a usability disaster.

I really hope that such things will get cleaned up before 3.2 this is enough to
confuse advanced users, let alone newbies, this is perhaps the biggest problem
with KDE.

The CVS "Actions" menu is good but that still leaves 16 entries for right
clicking highlighted text! 

i add my voice to this wishlist

i think that adding copy and past to the right contxet menu for highlighted 
text in webpages is some thing essential

and the suggestion in comment number 2 a bout 
adding the Web Search for "selected text" 
is vary helpfull and productive ....in configure konqueror have a new entry to 
specify the search engine such as "www.google.com" and by  highliting a text in 
a web and rightclicking to show the context menu then click the new 
entry "search" then a new webbrowser page will open where results of the 
searched text in the search engine well come out.

Actually, there is no need for a Web search menu item since this is accomplished
by middle-clicking on a nondynamic element.

Are the navigation options really necessary within the context menu?  They're already available from 
within the toolbar.  They seem really superfluous within the context menu. 

Hi again

i thought u are talking a bout copy /past

it was my mistake ....and i retype ur words "modified" because i agree....

Are the navigation options {back, forword, up} really necessary within the 
context menu? They're already available from 
within the toolbar {isn't that the standered place for them}. They seem really 
superfluous within the context menu. 

Here is my suggestion to help clean up the context menu: 
 
Take out Up, Back, Forward, Reload, and "Stop Animations" (put this into the view menu instead, 
it's more appropriate there), and add the Copy option, at least whenever RMB is clicked on some 
highlighted text.  This seems to be the de facto standard for all browsers except Konqueror.  It 
seems silly to break this de facto standard. 

Yes, the navigation options are necessary there, every browsr has them, they 
are commonly used and it would be a great mistake to remove them. Don't make 
the same mistake Mozilla did a few years ago when they removed these options 
and the entire userbase was furious and they were forced to put them back 
where they were in only a couple of days. Let's focus on removing context 
insensitive and rarely used items.

Also, the "View Document Source" option really should be placed back into KDE 
and be called simply 

One feature i'm missing that really is lacking from the menu is sorting.  The other two 
"major" file browsers (Nautilus and Win Explorer) both put this option in the menu.  
Currently the only way to change the order sorting order is throught View->Sort-
>Option.  This isn't the case when you run one of the list views, as you have the 
header's to click on, but I use the icon view almost extensively, unless I'm browsing 
an ftp server.  While I know someone will say, "Just run one of the list views all the 
time", you loose out on thumbnails, as well as almost always having a horizontal 
scroll bar at the bottom due to the problem with long file names and konq always 
increasing column widths to always show the longest file. 
 
Anyways, since this bug report is all about what should/should not be in the menu, I 
would really like to see this sort feature present in it, although I agree to remove 
some of the less used/can be used elsewhere options.  A few suggestions of my 
own are: 
 
-Remove "Set Encoding" from bottom, as I have nevered changed it from automatic, 
and don't see why this option needs easier accessibility in the right click menu 
when it could be reached from the main menu->View 
 
-Move the new "Frame" and submenu to under the "Duplicate in New Tab", and 
without it being surrounded with separators. 
 
-Add an option in the new context sensitive "Image" menu to "Show Image", or 
something named like that, for when an image doesn't get loaded right (instead of 
refreshing a whole page, or clicking "View Image(imagename)" and seeing it in a 
new window. 
 
-When you right click on an image in a webpage, I think the navigation options 
should not be present, just click they aren't when you right click on a file in file 
browsing mode.  This will help to continue to increase the context sensitiveness (if 
that's a word) of the menu. 
 
-There are still alot of instances where some programs are not in the actions list, 
such as Cervisia, Ark (2 Instances), and Quanta Plus.  I'm not sure if this is 
intentional, or if its planned to stay that way.  Other than Ark, I would prefer Cervisia 
and Quanta Plus to be under the action menu. 
 
-In file browsing mode, when you select more than 1 file and right click, it still shows 
the "Bookmark this file" option, but greys it out.  Since its not possible to even select 
it, why not remove it.  I'm also one not to have this option (bookmarking) to take up 
another line in the menu, although I can see how many people would/do use it 
(especially with frames), although unless it is for frames, its still the same amount of 
clicks to go to the main menu Bookmarks and select "Add bookmarks (right click [1] 
and left click [2] on Bookmark this ...; or left click [1] on Bookmarks and left click [2] 
on Add bookmark).  I propose to add this feature to the action menu as I see its 
usefulness in the right click menu, but not to be as "high profile" as it is. 
 
Ok, I think I'll stop listing suggestions as everyone probably already stopped 
reading what I've written so far.  Just thought I'd try and help with some of my 
opinions.  Hope a few are implemented ;) 

Alex Radu in comment #12 wrote that several years ago Mozilla made the mistake
of removing navigation commands from context menus. If I recall correctly, they
only removed navigation commands from the context menu for images; the
assumption being that when somebody points to an image, they want to do
something with it, not go back or reload the page. 

To make it clear: I would like navigation commands removed *only* in the
situation when we target a specific object on a page, such as an image, link or
text selection. 

I'm sorry, arkmch your right, Mozilla remvoved the navigation items only when
over  an object which is a lot less than what some people here are asking for
and even doing this caused a big uproar from the Mozilla community. I still
believe that for the sake of consistency we shouldn't do what Mozilla did, in
addition most people don't bother to look if they're over an iamge or not when
tehy want to go back, the mouse just ends up where it ends up being, imo it
might annoy a lot of people.

I really hope Clee's patches for Konqueror's Godzilla context menus will make it
in 3.2 because there are far too many entries which are poorly organized and do
not belong there. His patches removed a lot of redundant and useless things from
the cotnext menu such as 'Stop Animations’ and ‘Set Encoding’ entries taken out,
as well as rearranging the order of the link-related menu items. There is no
arguement for not agreeing with this decision, if you take out 'View Source'
which was actually quite common for a lot of KDE users and context sensitive to
the frame under the context menu, there is no reason whatsoever to keep
something like 'Set Encoding' and 'Stop Animations' in the context menu. These
options bloat the interface, are uncommon, not context sensitive and when they
are set they are not often changed.

more here: http://www.kdedevelopers.org/node/view/194

Have these changes been made to CVS or will 3.3/4 start to have usable context
menus?

The popup menus have just been cleaned up, thanks to a patch by Sashmit Bhaduri. 
Navigation items like back/forward/up are only there when clicking on the 'background' 
of the view (i.e. not on an item) - up being only there on directory views. 
Show bookmarks is gone for directory views. Clicking on images and links (and 
image-links) in KHTML shows more appropriate items. 
 
Other patches have cleaned up the frame vs document menus in KHTML, etc. 
 
I cannot close this wish though (since there are so many requests into it). 
For instance "Copy To" on an HTML page is still there, since that's a plugin, it's 
handled really differently. Without re-reading every sentence above, I'd like to know 
what else is missing - please update to CVS HEAD before making any further 
comments on this. 

Just to back post #16: 
  
If you take out 'View Document Source', there is no reason whatsoever to keep  
something like 'Set Encoding' and 'Stop Animations' in the context menu.  

Subject: Re:  Context menus in konqueror are cluttered

 WinterWolf@myway.com wrote on 2003-09-26 05:50

 AR> there is no reason whatsoever to keep something like 'Set Encoding' 
 AR> and 'Stop Animations'  in the context menu. 

'Set Encoding' is important option, at least, for all russian-speaking users 
-- e.g., when browsing site with frames.

With 'Set Encoding' is context menu user can set encoding to FRAME; but, when 
same in main application menu is used, encoding changes only for FRAMESET, 
but not nested frames.

Sometimes is required do set different encodings in different frames.

But, IMHO, items in 'Set Encoding' may looks better and be more usable, if 
group them into two levels (as in Mozilla). The long list of encoding names 
looks terrible in 800x600.

One thing 'bothers' me here, the context menus creation procedure etc. seems 
to be a very sporadic non organized/centralized procedure. If you are lucky 
someone sends in some patch and then you wait to see what it does. 
 
Mozilla does it like this: http://www.mozilla.org/mailnews/specs/ 
 
They have a project called UI. KDE usability might want to fragment itself 
into sub compononents because it seems so chaotic at this point. 
 
UI 'research' is burried somewhere in KDE usability so to speak. 
 
We are discussing context menus in some obscure burried forum in bugs.kde.org, 
very few are going to find it and very few are going to read everything on 
this page. 
 
I think Mozilla's approach http://www.mozilla.org/mailnews/specs/ could 
inspire should inpsire some KDE (usability) folks. 

I still would like to see Sort menu in the right click menu.  It only needs to be shown 
when a Icon view is used, since the List views have the headers available. 

Dmitry Kolesnikov, 'Set Encoding' is not commonly used by most people, it should 
be in the same menu 'View Source' was moved. It may be useful to some people, 
but it DOES NOT BELONG INA  CONTEXT MENU, a context menu with more than 10 items 
is alredy far too big froma  usability point of view.

'Stop Animations' SHOULD NOT BE IN KONQUEROR AT ALL!!! What's the point of it? 
To stop animations, of course, but isn't it completely REDUNDANT, this is what 
the icon of a little (X) should be for, to stop loading the page and stop any 
mvoement on the page. In technical terms it may not be quite the same thing, but 
for a user it is very much so, tehy don't understand that the animations were 
already downloaded and are just looping, they probably think it is always making 
requests to the server in order to do this. In any case, it should not be in the 
context menu, if it belongs in Konqueror at all, it belongs in the 'view' menu.

Subject: Re:  Context menus in konqueror are cluttered

On Friday 26 September 2003 18:46, Alex Radu wrote:
> 'Stop Animations' SHOULD NOT BE IN KONQUEROR AT ALL!!! What's the point of
> it? To stop animations, of course, but isn't it completely REDUNDANT, this

   The majority of people do not agree with you.  In fact we get very many 
requests for this functionality to be extended and enhanced to work with 
Flash too.  The "Stop Loading" action is not the same, and should not be.  It 
should be possible to stop loading without stopping animations.

Subject: Re:  Context menus in konqueror are cluttered

One argument pro ""View Source" in context menu" that I've never seen refered 
is consistency between applications. I think everyone wants to keep "view 
source" accessible via right click in Kmail and Knode and users that are used 
to this funcionality will most probably expect to be able to access it in 
konqueror the same way.

NOTE: I am NOT claiming we should keep it in the context menu!!! I really 
don't know the answer. I'm just pointing an argument in fauvor of it. Hope ou 
understand the difference.

IMO we should at least have a default keyboard shortcut to access "view 
source" consistent among applications.

Also thought that one possible way out could be to have one option (in the 
context) containing sub entries to access document specific information, 
and/or lower level options. This option would contain "view source" in any 
application that uses it. Again don't know if this is the right thing to do, 
just an idea.


J.A.

>  Additional Comment #22 From Alex Radu 2003-09-27 00:46 wrote 
> a context menu with more than 10 items is alredy far too big froma usability point of 
view.  
 
Do you have a updated copy of HEAD? Please update (or use HEAD) before 
commenting, because the context menu has changed a lot since 3.1 :) 
 
There is only one place in HEAD that I can count where there is more than ten items 
in a context menu. That is the context menu when clickong on the background of web 
pages. 
 
> 'Set Encoding' is not commonly used by most people, it should  
 be in the same menu 'View Source' was moved.  
 
No.. they are not the same kind of case. Similiar, but not the same. View Source is a 
debugging tool and Set Encoding isn't. I'm also willing to bet that somebody who 
needs to switch between encodings uses this *much* more regularily than a web 
developer using view source.  
 
>  ------- Additional Comment #24 From Jorge Adriano 2003-09-27 01:10 said: 
>  IMO we should at least have a default keyboard shortcut to access "view  
>  source" consistent among applications. 
 
Do you have a updated copy of HEAD? Please update (or use HEAD) before 
commenting, because the context menu has changed a lot since 3.1 :) 

While I for one probably will ever use the set encoding, I can see when it needs to 
be frame dependent that it must be in there.  Why not then, move it to the new frame 
submenu.  That way, when you need to set it differently per frame, it is still 
available, but for all the non framed pages (which are the majority on the net), its 
still accessible from the View Main Menu. 
 
BTW, I'm running a day old CVS HEAD and noticed taht Quanta Plus is still in the 
main context menu, and not as an action.  Is this planned to stay?  Do I need to 
clean up some of my config files?  I've noticed this on a few other cases for other 
apps (ark and cervisia). 

Can't we at least make the context menu at least configurable so that individual distributions 
can set it the way they think is best?  I don't know the overall answer to this question, but 
making it configurable, and allowing distributions to make this decision would allow us to see this 
question in a bigger light. 

> Can't we at least make the context menu at least configurable so that individual  
> distributions  
 
individual distributions already have access to all of the source, so they can do 
whatever they want with it. 

Going along with what I stated above, I think Security should also be moved to the 
frame submenu, as its already available in 2 areas (bottom right, which is where alot 
of people usually default to looking imo, as well as being in the menubar).  That 
way, once again, if you need to know the security of a specific frame, its available, 
but out of the way when you don't need it. 
 
Another idea is maybe to submenu the mainmenu to allow for frame support to (in 
conjunction with my previous statements).  That way if you always default to going 
to the mainmenu, you'll still have the option to pick the frame (maybe use the name 
there from what they put in <frame name="HERE"> for each frame. 

Subject: Re:  Context menus in konqueror are cluttered

On Saturday 27 September 2003 00:51, Sean Lynch wrote:
> ------- Going along with what I stated above, I think Security should also
> be moved to the frame submenu, as its already available in 2 areas (bottom
> right, which is where alot of people usually default to looking imo, as
> well as being in the menubar).  That way, once again, if you need to know
> the security of a specific frame, its available, but out of the way when
> you don't need it.

  No this is incorrect and I won't allow it.  Security options are extremely 
important and must remain consistent under all circumstances.  Frame security 
has to be in the context menu, as does security for all other embedded parts 
(including images).  Having the security option appear and disappear is 
inconsistent.  A user does not know what is a frame and what is not.  Don't 
forget that frames and parts can be embedded (secure, insecure, secure, 
secure, insecure, ....).

  Sorry, this one menu item is not going to break the bank and security is not 
optional.

If you think about it, View Document Source is still in the right click menu, in 2 
interations.  You can setup whatever view you like (kwrite, kvim, etc) to either 
preview in same window, or open with in a new window.  While its not as explicitly 
stated as "View Document Source", it does the exact same thing (especially the 
View Document Source), and gives you the ability to use whatever viewer you 
want (quanta plus even). 
 
 

Just food for thought: you can always make a Konqueror Popupmenu Plugin that adds view 
source to the popup menu. 

Yes and there is one by Clee. I hope his other improvements are in CVS too.

http://www.kdedevelopers.org/node/view/194

It's not really a plugin but it serves the same purpose.

I can't build CVS right now, I hope this khtml_popupmenu.rc does NOT have 
the encoding since this is important when viewing some framesets where 
the encoding may be correct for the parent HTML but not for frame. 
 
I absolutely agree that stop animations needn't be in the popup, though. 
There's no need for it at all. One thing that no one has fixed, though, is that 
images absolutely need to have the Copy function. This is a very basic 
function. Interestingly enough, the code for copying images has already 
been implemented. As of now, though, the user can only copy web images 
through drag-and-drop. 

Correction: I hope the Clee popup is not adopted if the Encoding adjustment option is 
removed. This is an important function for some that cannot be taken out just because it 
irritates a few to have it there.  

ARK: i want feature to add selected (and than right-clicked) files to (new) 
archive. As WinRar does in non-alternative OS

I've tried to collect a few proposals to improve Konqueror's context menu when clicking on a simple link and added a few screenshots. I'm using KDE 3.2 as of today. Please don't beat me if the things stated are totally nonsense. :-)

Here wo go: http://www.steffenweber.net/konqueror_context_menus/index.html

Subject: Re:  Context menus in konqueror are cluttered

> I've tried to collect a few proposals to improve Konqueror's
> context menu when clicking on a simple link and added a few screenshots.
> I'm using KDE 3.2 as of today. Please don't beat me if the things stated
> are totally nonsense. :-)
>
> Here wo go: http://www.steffenweber.net/konqueror_context_menus/index.html

Thanks for the screenshots and the comments.  First of all I'd like to add one 
comment of my own. 

The Actions menu can get huge as you install programs, therefore it seems 
important to be able to configure wether you want them to add their specific 
entries (and which ones) to the menu or not. This should be configurable in 
each of these programs, and also somewhere in the control panel.

Now on to your comments:
1. "Open With..." and "KWrite
Yes I think you're right.

2. "Preview In" and "Actions" Submenu
Agree, I see no point in providing those actions in Web Browser profile.
The previews on the other hand, to me make perfect sense... you may want to 
browse a text file with embeded kvim or kate... am I missing something?

3. "Copy To" Submenu
Once again, I agree. It's almost the same as "save as", you can also drag and 
drop the file, I see no need for yet another similar way of doing the same 
thing.

J.A.

Steffen:
Are those menus going to be context-dependent?  For example, I don't see the reason for some of the things in the actions to be there for the web profile.  Basically, I agree with your comments.

I don't think you need to get rid of the navigation commands (Up, Back, Forward, etc., unlike what I said earlier), but rather, perhaps you could group those, along with the "Open in..." commands into a "Navigation" submenu.  The "Preview In" menu seems redundant in relativity to "Open with..." and "KWrite."  Perhaps all of that should be in a "Open with..." submenu, something like in Explorer for Windows perhaps?  Perhaps it can check the MIME type and setup an "Open with..." submenu according to that?

Oh, and also, will there be any way of having context menu for selected text at all?  I understand that Konqueror assumes that selected text will be copied, but most people still expect a "Copy" option to be there.  Also, selecting the text merely uses the X clipboard, and it won't make it into KDE's clipboard if Klipper is set to have a seperate clipboard from X.  That is, perhaps, an even better reason to have a "Copy" option in some context menu with selected text.

Is the actions menu in 3.2 going to be context sensitive, I really think it needs to be.

I've updated my page (http://www.steffenweber.net/konqueror_context_menus/index.html) and for example changed my statement according to the "Preview In" submenu.

Rene, I think that the items in the Actions submenu are already context sensitive (at least when right clicking a gzipped file you get an option to extract it which is not present in other cases), but I'm not a developer and only wanted to post my proposals for the context menu for Konqueror's Web Browsing mode. :-)

Thanks to the great work of various individuals, I think we can safely say that this one is fixed now.  Not everyone will agree with what should or should not be in the menu, but we have to strike a balance and I think we reached that balance a few weeks ago.

This issue can't be closed yet IMHO because no one has added the option to Copy an image to the clipboard (at least since 19/10). This is possible via drag-n-drop but is such a very basic function that it must be on the RMB menu for every image.

Yes, there's the risk that a person can click on a transparent spacer but that will do little harm other than add an extra entry to her menu. Not a problem.

I can't tell you how many new users I've seen who have been completely confused that they cannot copy an image over to the clipboard.

I apologise if this has been added in CVS.

I don't think directly copying images on websites should be made easier as is, most of the time it's a legally questionable action anyway. In any case this wish was a generic wish for cleaning up context menus, this has been done and thus this report is closed. Being able to copy images is not necessarily a part of such a generic wish and furthermore debatable, so please comment to/vote for bug 36029 if you really need it.