Re: Is hiding stuff behind the "more" sub-context menu intentional?

Am Dienstag, dem 02.04.2024 um 12:47 -0400 schrieb Richard Kimberly Heck: > You can also add it to 2.4.1-devel if you wish. Done after having resolved further shortcut conflicts. I also took the liberty to add a status file to keep track of the changes. -- Jürgen -- lyx-devel mailing list lyx-

Re: Is hiding stuff behind the "more" sub-context menu intentional?

On 4/2/24 08:43, Jürgen Spitzmüller wrote: Am Mittwoch, dem 01.11.2023 um 12:50 +0100 schrieb Jürgen Spitzmüller: Attached is a patch that does this, considering not only hidden entries but also the dynamic entries that are only expanded in expand() (such as spelling suggestions). As far as I ca

Re: Is hiding stuff behind the "more" sub-context menu intentional?

Am Mittwoch, dem 01.11.2023 um 12:50 +0100 schrieb Jürgen Spitzmüller: > Attached is a patch that does this, considering not only hidden > entries > but also the dynamic entries that are only expanded in expand() (such > as spelling suggestions). As far as I can see the result is correct. > > Note

Re: Is hiding stuff behind the "more" sub-context menu intentional?

On 2023-11-01 15:41, Jürgen Spitzmüller wrote: Furthermore, most HIGs suggest a much lower number of entries per menu. "Menus should contain between three and twelve items, and submenus should contain between three and six items." https://developer.gnome.org/hig/patterns/controls/menus.html#menu

Re: Is hiding stuff behind the "more" sub-context menu intentional?

On 11/1/23 10:51, Jürgen Spitzmüller wrote: Am Mittwoch, dem 01.11.2023 um 15:05 +0100 schrieb Jürgen Spitzmüller: Am Mittwoch, dem 01.11.2023 um 12:50 +0100 schrieb Jürgen Spitzmüller: Note, however, that this will result in shortcut conflicts with items moved from sub- to main menu, so this e

Re: Is hiding stuff behind the "more" sub-context menu intentional?

On 11/1/23 10:05, Jürgen Spitzmüller wrote: Am Mittwoch, dem 01.11.2023 um 12:50 +0100 schrieb Jürgen Spitzmüller: Note, however, that this will result in shortcut conflicts with items moved from sub- to main menu, so this effectively causes string changes. Since string freeze that is lurking ar

Re: Is hiding stuff behind the "more" sub-context menu intentional?

Am Donnerstag, dem 02.11.2023 um 03:33 + schrieb Isaac Oscar Gariano: > > I think the best approach would be to write the menu's such that they > don't have too many options in the first place. Of course if a user > defines an inset or something else with lots of options, that should > be thei

Re: Is hiding stuff behind the "more" sub-context menu intentional?

ac Oscar Gariano​ From: lyx-devel on behalf of Jürgen Spitzmüller Sent: Thursday, 2 November 2023 3:51 AM To: lyx-devel@lists.lyx.org Subject: Re: Is hiding stuff behind the "more" sub-context menu intentional? Am Mittwoch, dem 01.11.2023 um 15:05 +0

Re: Is hiding stuff behind the "more" sub-context menu intentional?

Am Mittwoch, dem 01.11.2023 um 15:05 +0100 schrieb Jürgen Spitzmüller: > Am Mittwoch, dem 01.11.2023 um 12:50 +0100 schrieb Jürgen > Spitzmüller: > > Note, however, that this will result in shortcut conflicts with > > items > > moved from sub- to main menu, so this effectively causes string > > cha

Re: Is hiding stuff behind the "more" sub-context menu intentional?

Am Mittwoch, dem 01.11.2023 um 14:18 + schrieb Isaac Oscar Gariano: > Regardless, I just did a quick test, and if I lower my screen > resolution so that not everything fits on the context menu, it makes > a two column context menu, so perhaps we don't need the >50 check at > all? I am not in f

Re: Is hiding stuff behind the "more" sub-context menu intentional?

tzmüller Sent: Thursday, 2 November 2023 12:50 AM To: lyx-devel@lists.lyx.org Subject: Re: Is hiding stuff behind the "more" sub-context menu intentional? Am Mittwoch, dem 01.11.2023 um 05:14 + schrieb Isaac Oscar Gariano: > If I have time later, I may modify the code that does the

Re: Is hiding stuff behind the "more" sub-context menu intentional?

Am Mittwoch, dem 01.11.2023 um 12:50 +0100 schrieb Jürgen Spitzmüller: > Note, however, that this will result in shortcut conflicts with items > moved from sub- to main menu, so this effectively causes string > changes. Since string freeze that is lurking around the corner for > some time now, I am

Re: Is hiding stuff behind the "more" sub-context menu intentional?

Am Mittwoch, dem 01.11.2023 um 12:50 +0100 schrieb Jürgen Spitzmüller: > On my small laptop without HiDPI, 50 is not too short. More precise, on my desktop computer (a bit dated 23" monitor with 2048x1153 dpi, no HiDPI), ca. 38 entries will fill the whole screen. The mentioned menubar context men

Re: Is hiding stuff behind the "more" sub-context menu intentional?

Am Mittwoch, dem 01.11.2023 um 05:14 + schrieb Isaac Oscar Gariano: > If I have time later, I may modify the code that does the > 50​ check > to actually count properly, as it's counting context menu items that > don't even show up. Yes, this would be the way to go, the current check is too du

Re: Is hiding stuff behind the "more" sub-context menu intentional?

y, 30 October 2023 9:41 PM To: lyx-devel@lists.lyx.org Subject: Re: Is hiding stuff behind the "more" sub-context menu intentional? Am Montag, dem 30.10.2023 um 03:48 + schrieb Isaac Oscar Gariano: > Sorry for bothering you again, I'm just curious if this is an > intentio

Re: Is hiding stuff behind the "more" sub-context menu intentional?

Am Montag, dem 30.10.2023 um 03:48 + schrieb Isaac Oscar Gariano: > Sorry for bothering you again, I'm just curious if this is an > intentional design decision as it's really annoying me. It's the result of a bug fix: https://www.lyx.org/trac/ticket/10370 Here's the respective change: https:

Is hiding stuff behind the "more" sub-context menu intentional?

Sorry for bothering you again, I'm just curious if this is an intentional design decision as it's really annoying me. Basically, if I have a branch, and right click, most of my context menu is hidden behind a "More..." option. Including for example, spelling corrections (as you've probably notic