| | [ Return to Bugs & Features | Roadmap 2.0 | Post Text | Post File | SVN ⇄ GIT ]
STR #2009
| Application: | FLTK Library |
|---|
| Status: | 5 - New |
|---|
| Priority: | 2 - Low, e.g. a documentation error or undocumented side-effect |
|---|
| Scope: | 3 - Applies to all machines and operating systems |
|---|
| Subsystem: | Unassigned |
|---|
| Summary: | Parentless Popup Menus Are Not Placed Correctly |
|---|
| Version: | 2.0-current |
|---|
| Created By: | ddurham |
|---|
| Assigned To: | Unassigned |
|---|
| Fix Version: | Unassigned |
|---|
| Update Notification: | |
|---|
Trouble Report Files:
[ Post File ]
Trouble Report Comments:
[ Post Text ]
| |
| #1 | ddurham
09:42 Jul 18, 2008 |
| When a popup menu has no parent it is not always placed correctly on the screen.
I was using a context menu on a tray icon (no top-level windows, hence no parent for the context popup menu). When the system tray is at the bottom of the screen (i.e. KDE's default) things are mostly okay. However, when the system tray is at the top of the screen, the PopupMenu object made no attempt to keep the menu within the bounds of the screen.
Also, in the try_popup() method, instead of simply using the absolute screeen position to show the menu, it offset the position by event_x() and event_y(). It does this in the case that parent() returns NULL. So given that this menu is not to have a parent, I'm not sure why it should offset the position. For my purposes, it places the menu incorrectly when that offset is performed.
The attached patch file addresses these two issues.
I ran and successfully tested: clock, list, menu, menubar, subwindow. All worked fine with regards to menu placement. | |
| |
| #2 | ddurham
09:45 Jul 18, 2008 |
| Oh, the patch is against fltk-2.0 svn6148 | |
[ Return to Bugs & Features | Post Text | Post File ]
|
| |
