On 7/30/20 2:52 AM, Daniel wrote: > 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).
Yes, that could be done, but it would take some work. We already define submenus that way, though, so it might not be that bad. > By the way, why is the current ordering the other way around as usual, > i.e. (1) "command", (2) name? Entropy. Riki -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
