[LyX/master] Use more convenient MenuButtonPopup

[Daniel]

On 2020-07-29 15:21, Daniel wrote:
> On 2020-07-29 12:51, Jürgen Spitzmüller wrote:
>> Am Samstag, den 18.07.2020, 00:33 -0400 schrieb Scott Kostyshak:
>>> This is a nice feature (added at 9495ff66 and modified here), and I
>>> agree that MenuButtonPopup is better. There is one thing that is a
>>> little annoying, which is that the arrow is not disabled if there is
>>> no
>>> item. We shouldn't disable the entire button because the action of
>>> the
>>> button is to paste from the *system* clipboard.
>>>
>>> To reproduce what I'm talking about, start LyX, start a new document
>>> and
>>> click on the arrow next to the paste icon. The arrow lets you press
>>> it
>>> and looks like it will give something but never does. I actually
>>> expected something like the Edit > Paste Special submenu options to
>>> show, so I was confused.
>>>
>>> The attached patch attempts to improve things. It only shows an arrow
>>> if
>>> there are items. It's not as nice as having a disabled arrow, but I
>>> don't know how to achieve that. Another disadvantage of the patch is
>>> that when it shows the arrow it takes up extra space on the toolbar
>>> so
>>> shifts the items to the right, which is unpleasant to the eye. There
>>> might be some style sheet padding magic that can be done to avoid the
>>> shift but I couldn't figure it out.
>>>
>>> Any thoughts?
>>
>> Actually I don't like any overpainting of style defaults. I prefer
>> having the arrow even though the history is empty.
>>
>> Jürgen
>>
>>>
>>> Scott
>>>
> 
> I didn't see the new button before because I had deactivated the paste 
> toolbar button. It is supposed to show the LyX-internal copy history, 
> right?
> 
> As for the arrow: I find it a bit strange too that it is not disabled 
> when there is no menu. But maybe that's just a Qt thing. A way to deal 
> with this particular case other than hiding the arrow is to add the 
> (static) Special Paste menu entries to the button menu as well. This is 
> actually pretty common and hence to be expected in word processors.
> 
> Daniel
> 

These DynamicMenu toolbar buttons seem quite handy. But they are hard 
coded, right?

It would be nice if they could be customized with three arguments: (1) 
name, (2) a command for the button (lfun), (3) a context menu (maybe 
defined in stdcontext.inc).

For example, I think I would like to combine all the text properties 
into one button that opens the text properties dialog and the context 
menu shows both the custom styles as well as the recently used ones.

By the way, why is the current ordering the other way around as usual, 
i.e. (1) "command", (2) name?

Daniel