Bug Hunting Session
Bug 85786 - TOOLBAR: Do not hide customize toolbar context menu after toggling a visible icon
Summary: TOOLBAR: Do not hide customize toolbar context menu after toggling a visible ...
Status: RESOLVED WONTFIX
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: Other All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Context-Menu Toolbars
  Show dependency treegraph
 
Reported: 2014-11-03 05:02 UTC by Yousuf Philips (jay) (retired)
Modified: 2017-05-19 21:31 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Yousuf Philips (jay) (retired) 2014-11-03 05:02:11 UTC
When your right-click on a toolbar, a context menu appears with a 'Visible Buttons' submenu, which allows you to hide and show buttons. Unfortunately, it only allows you to do this one at a time, so it would be better if the context menu stayed visible until the user decides to exit the context menu.
Comment 1 Cor Nouws 2014-11-03 08:26:52 UTC
To be precise: how does the context menu close then? By slicking 'somewhere' else?
Comment 2 Cor Nouws 2014-11-03 08:27:01 UTC
s/s/c
Comment 3 Yousuf Philips (jay) (retired) 2014-11-03 13:27:36 UTC
(In reply to Cor Nouws from comment #1)
> To be precise: how does the context menu close then? By clicking 'somewhere'
> else?

The same way all context menus close. Clicking somewhere else or pressing Esc. :D
Comment 4 Cor Nouws 2014-11-03 13:38:07 UTC
Hmm ,stupid me - should do more with menu's
Comment 5 Gülşah Köse 2017-05-18 08:17:26 UTC
Hi @Yousuf. According to my research behaviour completely comes from gtk. Here are some code pointer

PopupMenu::ImplExecute
http://opengrok.libreoffice.org/xref/core/vcl/source/window/menu.cxx#2906

GtkSalMenu::ShowNativePopupMenu
http://opengrok.libreoffice.org/xref/core/vcl/unx/gtk/gtksalmenu.cxx#456
"gtk_menu_popup"

Solution suggestion:
GtkMenu has GtkSalMenuItems. Note that: When submenu was open focus still on its parent menu untill you click a menu item. After you click it "activate" signal occurs. Solution i think copy gtk_menu_popup parameters in a struct, connect that the activate signal to button_press_event(Left click). And reopen that gtk_menu_popup with copied parameters.

Needed help frome someone who experienced with gtk.

Asked a question to stackoverflow: https://stackoverflow.com/questions/43981246/gtk-how-is-it-possible-to-keep-the-popup-menu-open-when-a-click-event-occurs-on

Maybe comes help from there.
Comment 6 Yousuf Philips (jay) (retired) 2017-05-18 08:29:43 UTC
@Caolan: Could you give your expert gtk input on Gulsah's comment.
Comment 7 Caolán McNamara 2017-05-18 10:12:15 UTC
Its probably super difficult to do it via menus. The gtk stuff is "underneath" our own menus and there are other backends as well as the gtk one. Another possibility is to change "visible buttons" from a submenu to menu item which launches an actual dialog where you have a list of entries in a list and check/uncheck them
Comment 8 Yousuf Philips (jay) (retired) 2017-05-18 13:06:45 UTC
(In reply to Caolán McNamara from comment #7)
> Another possibility is to change "visible buttons" from a submenu to
> menu item which launches an actual dialog where you have a list of entries
> in a list and check/uncheck them

Not really as we already have the 'customize toolbar...' entry just below it which opens the dialog. I guess this technically cant be achieved and we should just close it. @Maxim: Any thoughts?
Comment 9 Maxim Monastirsky 2017-05-18 18:19:56 UTC
(In reply to Yousuf Philips (jay) from comment #8)
> I guess this technically cant be achieved and we
> should just close it. @Maxim: Any thoughts?
Yes, it will not be possible technically, unless we replace the menu with some kind of a floating panel or maybe something similar to gtk's Popover.
Comment 10 Yousuf Philips (jay) (retired) 2017-05-19 21:31:57 UTC
Well lets just close it then. Thanks gulsah for researching it.