Bug 76324 - popup menu expanding forcing wrong selection
Summary: popup menu expanding forcing wrong selection
Status: RESOLVED INTENTIONAL
Alias: None
Product: kdelibs
Classification: Frameworks and Libraries
Component: qt (show other bugs)
Version: unspecified
Platform: unspecified FreeBSD
: NOR normal
Target Milestone: ---
Assignee: Maksim Orlovich
URL:
Keywords:
: 66957 70564 77790 78577 79747 80277 83077 87678 92557 93114 95917 96724 98134 102488 105939 108271 118066 119235 138057 140165 153841 (view as bug list)
Depends on:
Blocks:
 
Reported: 2004-02-28 00:35 UTC by joaobr
Modified: 2008-10-09 06:39 UTC (History)
25 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description joaobr 2004-02-28 00:35:58 UTC
Version:           3.2 (using KDE KDE 3.2.0)
OS:          FreeBSD

when having more items in the bookmark menu as space to expand the menu BELOW the menu bar then the popup menu starts expanding from zero X from the desktop top margin.
Since this process is fast you automaticaly select the item which is under the mouse pointer (accepting the lose-button action)
workaround only when holding the finger down, dragging the pointer to the item you want.
Since still annoying on a desktop depending on your habits an almost impossible act with a laptop and touchpad. ( In my case I ever get the new bookmark folder box ) popped up
Suggestion is to expand the menu ever below the menu bar or above but not in the middle and if not enough space to show all items then having a scroll button at the end of the list.
Comment 1 lypanov 2004-03-02 15:50:45 UTC
all qt/generic kde problems that i really don't have the time to work on.
obvious suggestion: clean up your bookmarks :P
non obvious suggestion: read this:	http://dot.kde.org/1059469759/1059615264/1059616895/1059675099/1059949085/
please report any reproducable problems you have the with the above workaround.

cheers,
Alex
Comment 2 joaobr 2004-03-03 12:26:14 UTC
yeah sure, saw this positive aspect also, forces me to do housekeeping :)

so the kstylerc do not make any difference to me, it works exactly the same way, I tried on 3.1.4 and 3.2

but I noticed a difference, the 3.1.4 menu do not take the finger-lift as selection (or has a delay build in)
Comment 3 joaobr 2004-03-05 01:52:13 UTC
some update, the problem is with plastik theme any other is controllable
Comment 4 Maksim Orlovich 2004-05-26 19:05:54 UTC
I e-mailed TT w/a patch about this bug. Qt issue #49414.
Comment 5 Maksim Orlovich 2004-05-26 22:49:37 UTC
*** Bug 78577 has been marked as a duplicate of this bug. ***
Comment 6 Maksim Orlovich 2004-05-26 22:54:21 UTC
*** Bug 79747 has been marked as a duplicate of this bug. ***
Comment 7 Maksim Orlovich 2004-05-26 22:55:55 UTC
*** Bug 80277 has been marked as a duplicate of this bug. ***
Comment 8 Maksim Orlovich 2004-05-30 02:19:16 UTC
Just moving to the right spot..
Comment 9 Maksim Orlovich 2004-06-09 14:45:10 UTC
*** Bug 83077 has been marked as a duplicate of this bug. ***
Comment 10 Maksim Orlovich 2004-08-21 20:35:54 UTC
*** Bug 87678 has been marked as a duplicate of this bug. ***
Comment 11 Ralf Hemmenstaedt 2004-10-13 11:21:45 UTC
When I use "ScrollablePopupMenus=true" as suggested in

http://dot.kde.org/1059469759/1059615264/1059616895/1059675099/1059949085/

every second click on the bookmark menu is broken, if the menu is larger then the screen height. Only a few items get displayed from the top and the menu is unusable.

KDE 3.3.0
QT 3.3.3
(SuSE packages)
Comment 12 Maksim Orlovich 2004-11-02 03:49:15 UTC
*** Bug 92557 has been marked as a duplicate of this bug. ***
Comment 13 Ron Onstenk 2004-11-02 11:41:48 UTC
With all respect to the people involved in handling the menubar code.
It looks to me simple to solve. May I suggest a way to do it?

As I see all the menu opens on mouse_down event.
On the mouse_up event the code looks on what entry it was to determine 
what to do.
For the bookmarks that is the management selections or bookmark choice.
This must be detected. The same is done on the mouse_click event.
At this stage it is(must be) also known what main menu entry it is.

The problem could be solved by in the mouse_up event to look if the 
menubar entry is 'Bookmarks' and doing a exit of the procedure that 
handles the up event.

A second method is using a timer meganism that doing the exit until
say half a second as hold off time before it work as is now to satisfy
the people that want the up event as execute the action.

More complex and better solutions are posible, checking the lengt of the
menu list and using a 'More...' option i.e., but why is it wrong to 
give up the mouse_up activate the selection for the bookmarks?

I know it is not a bug in KDE, with all respect also not in QT, but 
a very nasty glitch for the people that have a big bookmark list.
For me it is a not before seeing posibility that can occur and result
of the wish the up event is to activate chosers selection instead
the of click event, by cloning the apple and gnome behaviour.

It can, but not must do, and for the bookmarks it should not do it.
Nobody is hurt if they heve to explicite click on the bookmark. 

Correct me if I'm wrong.
Comment 14 Maksim Orlovich 2004-11-11 20:09:11 UTC
*** Bug 93114 has been marked as a duplicate of this bug. ***
Comment 15 Maksim Orlovich 2004-11-19 06:35:24 UTC
*** Bug 77790 has been marked as a duplicate of this bug. ***
Comment 16 Paul Curry 2004-11-19 16:33:34 UTC
Using the MacOS style menu bar (at the top of the screen for each window) can prevent this problem.  Unfortunately, this doesn't work for non-kde (QT?) applications, so the menu bar position is inconsistent.
Comment 17 James Ots 2004-11-19 17:09:21 UTC
I have the MacOS style menu bar, and I still get the problem. I also get the problem on some other menus such as the kopete tasktray menu - sometimes the menu popus up with the mouse pointer on the Quit item, and then kopete quits before I get a chance to do anything.
Comment 18 Paul Curry 2004-11-19 19:14:39 UTC
Confirmed.  If I fill up my bookmarks so that the list is bigger than my screen size then the problem reappears.
Comment 19 Maksim Orlovich 2004-12-08 18:41:29 UTC
*** Bug 66957 has been marked as a duplicate of this bug. ***
Comment 20 Maksim Orlovich 2004-12-28 15:31:33 UTC
*** Bug 95917 has been marked as a duplicate of this bug. ***
Comment 21 Maksim Orlovich 2005-01-10 20:34:07 UTC
*** Bug 96724 has been marked as a duplicate of this bug. ***
Comment 22 Maksim Orlovich 2005-01-29 17:00:29 UTC
*** Bug 98134 has been marked as a duplicate of this bug. ***
Comment 23 Maksim Orlovich 2005-03-25 19:16:53 UTC
*** Bug 102488 has been marked as a duplicate of this bug. ***
Comment 24 Maksim Orlovich 2005-04-12 18:00:28 UTC
*** Bug 70564 has been marked as a duplicate of this bug. ***
Comment 25 Maksim Orlovich 2005-05-19 15:18:24 UTC
*** Bug 105939 has been marked as a duplicate of this bug. ***
Comment 26 Daniel Teske 2005-06-28 22:47:43 UTC
*** Bug 108271 has been marked as a duplicate of this bug. ***
Comment 27 William Kendrick 2005-07-03 03:38:55 UTC
Just a note, I have precisely this problem (KDE/Konqueror 3.4.1).  My suggestion is to simply make sure the pop-up menu does not go above (if popping down; below, if popping up) the menu in the toolbar.

I also have difficulty with large sub-menu pop-ups that come out to the right (or left) of a menu (e.g., K->Quick Browser) obscuring the menu I was looking at.  (See Bug 108466)  In those cases, too, simply not allowing the menu to expand in the opposite direction would help.

In other words, in the "Bookmarks" case, just pretend that the ONLY allowable area that the menu can appear at is BELOW the Konqueror window's toolbar.  (Just pretend that the bottom of the menu toolbar in Konqueror is very top of the display.  Feel free to go out to the physical left/right edges and bottom edge of the monitor... but DON'T go any higher than the bottom of the menu.)

(And in the case of something like the Quick Browser, pretend that the right edge of the K menu is the left edge of the monitor...)
Comment 28 _ 2005-07-03 12:24:01 UTC
You give quite useless suggestions as you do not mention where the menus/menu entires should be left instead. For the Bookmarks menu it could be up/down arrows, but the quick browser-style is impossible to make any different I think (where should menus be opened when you are at the right of the monitor?.
Comment 29 joaobr 2005-07-05 02:36:13 UTC
you make things complicated ... that is very easy to understand

the only problem here is and it does not matter if it is up, down, left or right ...

it should not appear another option under the mouse pointer where it actually is
means, you click on bookmarks and then the menu should NOT appear under the mouse pointer and be selected the eventual option under this pointer

so in order to satisfy your ask for usefull suggestions and for a year now nobody got it ;) because some said it is a qt issue but for me it is a positioning issue only

I suggest to set the menu's left position if it has to scroll up or down 5 points to the right of the mouse pointer elseif the menu has to scroll right or left 5 points above the mouse pointers position

and the problem should be resolved
Comment 30 Simon Perreault 2005-07-05 02:50:19 UTC
jao,

Your suggestions are as helpful as saying "Just fix the bug and the problem should be resolved." It seems you don't have much Qt experience so please don't think the problem is simple when in fact it isn't.
Comment 31 joaobr 2005-07-05 04:16:29 UTC
you are right I have not but it could not be as difficult as you say that it couldn't be solved in over a year and 5 month now, specially as annoying this bug is. 
qt is 3.3.x now isn't it? It is something hard for me to understand that this bug is a generic one and that nobody is as irritaded by it as me. So my conclusion is that only me is using bookmarks then ... so thanks who invented them only for me ;) 
but may be another workaround could be to limit the max items of the bookmark menu so then this menu does not flip under my mouse anymore, is this then a better suggestion?
Comment 32 Ron Onstenk 2005-07-07 08:49:38 UTC
I do not beleave there is no way to change for the bookmarks the behaviour of the mouse events.
QT gives any way a MouseUp event (signal) to the code handling the selected
item.
There it is figured out if it is a Add/Edit/Bookmark_tabs_as_folder or a real book mark.
This MouseUp event(signal) and the current activation of the bookmark handling can simply be dropped, in space.

It is now posible to do a simple second MouseClick on any of the bookmarks or action because the list stays on screen.
This 2'nd click (down/up) event should do the action as now is done on on the
first MouseClick (MouseUp).

KMIX does the same in the systray.
The mouse is exact on the button but the second click does the realy action for the button.

I do not see why this can not be done the menubar if it is the bookmark item.




Comment 33 Maksim Orlovich 2005-12-10 16:33:14 UTC
*** Bug 118066 has been marked as a duplicate of this bug. ***
Comment 34 Maksim Orlovich 2005-12-30 18:01:37 UTC
*** Bug 119235 has been marked as a duplicate of this bug. ***
Comment 35 Dik Takken 2006-03-16 23:32:11 UTC
Is the patch for this problem available for download anywhere please? 
Comment 36 _ 2006-03-16 23:40:43 UTC
If there were a patch available for this bug it'd have been uploaded here.
Comment 37 Tommi Tervo 2006-11-29 10:14:02 UTC
*** Bug 138057 has been marked as a duplicate of this bug. ***
Comment 38 Tommi Tervo 2006-11-29 10:14:25 UTC
*** Bug 123528 has been marked as a duplicate of this bug. ***
Comment 39 Maksim Orlovich 2007-04-18 08:20:08 UTC
*** Bug 140165 has been marked as a duplicate of this bug. ***
Comment 40 Sebastian Kemper 2007-04-18 13:38:29 UTC
I get it that keeping your bookmarks clean is a good thing, but say you got a laptop with a small vertical resolution then this is not so easy anymore. We have a 1280x800 display and this bug hits use frequently.

Regards
Sebastian
Comment 41 Jeffrey Parke 2007-04-18 15:59:29 UTC
I think that we should devise a new way to display bookmarks. Konqueror tries display them all at the same time which is not working. Maybe we should follow Firefox's method of having a scrollable list or opera's way of having a set number  items to show and then at the bottom have a "show more of my bookmarks" menu.
Comment 42 Maciej Pilichowski 2007-04-18 19:31:58 UTC
Jeffrey, good idea -- I would also opt to organize bookmarks into blocks. Bookmarks then would be sorted by date/time of last usage of such bookmarks.
So the menu would look like this:

www.1.com
www.2.com
www.3.com
vvv older bookmarks vvv

when you click on older (by old I mean time of usage, not time of saving the bookmark) you will get:

^^^ newer bookmarks ^^^
www.7.com
www.4.com
www.5.com
vvv older bookmarks vvv

but with solution (or maybe even without it) search edit-box a'la search in KMenu in opensuse (but with difference -- temporary removing entries from the menu).
Comment 43 Reiner Goerlach 2007-04-21 17:52:24 UTC
This is a interesting discussion about Konqueror bookmarks. I prefer OPERA system, which is very useful, and I see do disadvantage in that system.

regards

Reiner


-------- Original-Nachricht --------
Datum: 18 Apr 2007 17:32:01 -0000
Von: Maciej Pilichowski <bluedzins@wp.pl>
An: reiner.goerlach@gmx.de
Betreff: [Bug 76324] popup menu expanding forcing wrong selection

[bugs.kde.org quoted mail]
Comment 44 Daniel Teske 2007-08-17 21:33:13 UTC
Fixed in Qt4. Which means KDE 4 won't have that problem.
Comment 45 Tommi Tervo 2007-12-11 15:19:21 UTC
*** Bug 153841 has been marked as a duplicate of this bug. ***
Comment 46 S. Burmeister 2008-01-24 18:16:22 UTC
I can still reproduce this with KDE4.
Comment 47 S. Burmeister 2008-03-04 20:10:36 UTC
This does not happen the first time one clicks on the bookmarks-menu, but every other time. Could someone with access to TT's bug database re-open their bug please?
Comment 48 David A Thompson 2008-10-09 06:39:05 UTC
This is a significant usability issue for users of laptops or other devices with small screens, especially as the bookmarks browser is a significant part of web browsing functionality. A status of "RESOLVED" doesn't seem to be an appropriate choice as the issue still exists (regardless of whether it easy or difficult to resolve the issue from a programming standpoint). Please consider reopening the bug.