Re: Don't hide menus
Am Freitag, dem 13.10.2023 um 17:44 +0200 schrieb Jean-Marc Lasgouttes: > What we could provide is a HUD, like Apple's Cmd-space, but for menu > entries. We had that in Ubuntu in the old days. I have not the slightest idea what a HUD is. -- Jürgen -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Don't hide menus
On 2023-10-14 03:52, Daniel wrote: On 2023-10-13 18:07, Daniel wrote: On 2023-10-13 17:24, Jürgen Spitzmüller wrote: Am Freitag, dem 13.10.2023 um 17:08 +0200 schrieb Daniel: I agree that the menus of these apps are complex. But that might be in their nature. Well, they are aware of it: https://design.blog.documentfoundation.org/2016/01/22/way-down-in-the-libreoffice-menus/ Notice that the (obvious?) option of removing disabled menu entries apparently wasn't a viable option. I guess the Ribbon was a (maybe controversial) attempt to solve this problem. Yes, probably. With the result that you don't find things anymore at all. And Ribbons even more infringe the policy you refer to. They hide function from the user if they place it in (rather opaque) categories. But I think LyX with its hidden menus is actually worse to figure out. I am still discovering (otherwise) hidden menu entries and I have been using LyX for quite some time now. I keep on discovering menu entries in LO and Word although they have been displayed all the time. It might be different habits, but I search for menu entries when I need them. And this is when they are usually enabled. The problem is that one does not even know what to look for if one doesn't know of a possible functionality. This seems even worse in LyX because it is in certain ways a more unique application. In context when they do not work at all they only distract attention. I have not noticed that. I usually find that disabled menus are easy to disregard when I do not explicitly try to discover some function. And typically I have greater problems with disregarding stuff than other people. Another problem with disappearing menus is that the other menus shift positions. That is a bit annoying too. If I want to learn about LyX's functionality, I consult the manuals. I think people typically don't read software manuals. Maybe too bad but a fact that developers should honor. Maybe LyX users are different but I have my doubts. If it is really necessary to cut down on menu entries in the "Insert" menu when disabled entries get enabled: For example, create a separate "References" menu. References is just a single submenu in the Insert menu. That won't solve the problem. And, after all, if References are to be _inserted_, I would expect them under Insert. I meant the group of "References" as in "Citation", "Cross-References", "Label", "Caption", etc. These are typically subsumed under "References" in other word processors. (But if more entries for such a menu are needed, then entries in "List/TOC/References" might be added as well.) The attached patch exemplifies this (radical?) change. Want to go wild? Also add a "Format" menu. Probably more items can be added there. But this is one way. I am not persuaded yet that LyX's menus are actually too long. But for what it's worth... DanielFrom dd37294bdc00ccd2d65231d83199297bea23a7fa Mon Sep 17 00:00:00 2001 From: Daniel Ramoeller Date: Sat, 14 Oct 2023 04:06:44 +0200 Subject: [PATCH 2/2] Add a "Format" main menu Add a "Format" main menu --- lib/ui/stdmenus.inc | 18 -- 1 file changed, 12 insertions(+), 6 deletions(-) diff --git a/lib/ui/stdmenus.inc b/lib/ui/stdmenus.inc index 4a8b9d1c28..ea7d0db218 100644 --- a/lib/ui/stdmenus.inc +++ b/lib/ui/stdmenus.inc @@ -32,6 +32,7 @@ Menuset Submenu "View|V" "view" Submenu "Insert|I" "insert" Submenu "References|R" "references" + Submenu "Format|O" "format" Submenu "Navigate|N" "navigate" Submenu "Document|D" "document" Submenu "Tools|T" "tools" @@ -121,12 +122,6 @@ Menuset Item "Move Paragraph Up|o" "paragraph-move-up" Item "Move Paragraph Down|v" "paragraph-move-down" Separator - Item "Paragraph Settings...|P" "layout-paragraph" - Submenu "Text Properties|x" "edit_textprops" - OptSubmenu "Custom Text Styles|S" "edit_textstyles" - Item "Manage Counter Values..." "dialog-show-new-inset counter" - LanguageSelector - Separator # Mathed b0rkage means these don't work properly OptSubmenu "Table|T" "edit_tabular" OptSubmenu "Math|M" "edit_math" @@ -571,6 +566,17 @@ Menuset Item "Marginal Note|M" "marginalnote-insert" End +# +# FORMAT MENU +# + Menu "format" + Item "Paragraph Settings...|P" "layout-paragraph" + Submenu "Text Properties|x" "edit_textprops" + OptSubmenu "Custom Text Styles|S" "edit_textstyles" + Item "Manage Counter Values..." "dialog-show-new-inset counter" + LanguageSelector + End + # # DOCUMENT MENU # -- 2.24.3 (Apple Git-128) -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-deve
Re: Don't hide menus
On 2023-10-13 18:07, Daniel wrote: On 2023-10-13 17:24, Jürgen Spitzmüller wrote: Am Freitag, dem 13.10.2023 um 17:08 +0200 schrieb Daniel: I agree that the menus of these apps are complex. But that might be in their nature. Well, they are aware of it: https://design.blog.documentfoundation.org/2016/01/22/way-down-in-the-libreoffice-menus/ Notice that the (obvious?) option of removing disabled menu entries apparently wasn't a viable option. I guess the Ribbon was a (maybe controversial) attempt to solve this problem. Yes, probably. With the result that you don't find things anymore at all. And Ribbons even more infringe the policy you refer to. They hide function from the user if they place it in (rather opaque) categories. But I think LyX with its hidden menus is actually worse to figure out. I am still discovering (otherwise) hidden menu entries and I have been using LyX for quite some time now. I keep on discovering menu entries in LO and Word although they have been displayed all the time. It might be different habits, but I search for menu entries when I need them. And this is when they are usually enabled. The problem is that one does not even know what to look for if one doesn't know of a possible functionality. This seems even worse in LyX because it is in certain ways a more unique application. In context when they do not work at all they only distract attention. I have not noticed that. I usually find that disabled menus are easy to disregard when I do not explicitly try to discover some function. And typically I have greater problems with disregarding stuff than other people. Another problem with disappearing menus is that the other menus shift positions. That is a bit annoying too. If I want to learn about LyX's functionality, I consult the manuals. I think people typically don't read software manuals. Maybe too bad but a fact that developers should honor. Maybe LyX users are different but I have my doubts. If it is really necessary to cut down on menu entries in the "Insert" menu when disabled entries get enabled: For example, create a separate "References" menu. References is just a single submenu in the Insert menu. That won't solve the problem. And, after all, if References are to be _inserted_, I would expect them under Insert. I meant the group of "References" as in "Citation", "Cross-References", "Label", "Caption", etc. These are typically subsumed under "References" in other word processors. (But if more entries for such a menu are needed, then entries in "List/TOC/References" might be added as well.) The attached patch exemplifies this (radical?) change. DanielFrom 1aac8f973da22069e65504473ebc45c5f1cf880f Mon Sep 17 00:00:00 2001 From: Daniel Ramoeller Date: Sat, 14 Oct 2023 03:49:52 +0200 Subject: [PATCH] Add a "References" main menu Adds a "References" main menu in order to make the "Insert" menu less long. --- lib/ui/stdmenus.inc | 34 +- 1 file changed, 21 insertions(+), 13 deletions(-) diff --git a/lib/ui/stdmenus.inc b/lib/ui/stdmenus.inc index 93db305124..4a8b9d1c28 100644 --- a/lib/ui/stdmenus.inc +++ b/lib/ui/stdmenus.inc @@ -31,6 +31,7 @@ Menuset Submenu "Edit|E" "edit" Submenu "View|V" "view" Submenu "Insert|I" "insert" + Submenu "References|R" "references" Submenu "Navigate|N" "navigate" Submenu "Document|D" "document" Submenu "Tools|T" "tools" @@ -378,7 +379,6 @@ Menuset Submenu "Special Character|p" "insert_special" Submenu "Formatting|o" "insert_formatting" Submenu "Field|i" "insert_fields" - Submenu "List/Contents/References|/" "insert_toc" Submenu "Float|a" "insert_float" Submenu "Note|N" "insert_note" Submenu "Branch|B" "insert_branches" @@ -387,20 +387,8 @@ Menuset Submenu "Box[[Menu]]|x" "insert_box" OptSubmenu "Regular Expression" "context-edit-regexp" Separator - Item "Citation...|C" "dialog-show-new-inset citation" - Item "Cross-Reference...|R" "dialog-show-new-inset ref" - Item "Label...|L" "label-insert" - Captions - Indices - OptSubmenu "Index Properties" "index_properties" - Item "Nomenclature Entry...|y" "nomencl-insert" - Separator Item "Table...|T" "tabular-insert" Item "Graphics...|G" "dialog-show-new-inset graphics" - Item "URL|U" "flex-insert URL" - Item "Hyperlink...|k" "href-insert" - Item "Footnote|F" "footnote-insert" - Item "Marginal Note|M" "marginalnote-insert" Item "Program Listing[[Menu]]" "listing-insert" Separator EnvironmentSeparators @@ -563,6 +
Re: Don't hide menus
On 2023-10-13 17:44, Jean-Marc Lasgouttes wrote: Le 13/10/2023 à 17:08, Daniel a écrit : > I agree that the menus of these apps are complex. But that might be in their nature. I guess the Ribbon was a (maybe controversial) attempt to solve this problem. But I think LyX with its hidden menus is actually worse to figure out. I am still discovering (otherwise) hidden menu entries and I have been using LyX for quite some time now. What we could provide is a HUD, like Apple's Cmd-space, but for menu entries. We had that in Ubuntu in the old days. I can try to provide the backend for that if someone is ready to do the nice interface. JMarc Could you explain what you mean? Some kind of search function? How does that help if one does not know what to search for? What is the difference to the command buffer? Daniel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Europe CV not compiling
11 d’oct. de 2023, 1:08 per udifog...@gmail.com: > On Wed, Oct 11, 2023 at 1:50 AM José Matos wrote: > >> >> On Tue, 2023-10-10 at 23:58 +0200, Dan wrote: >> > Hello, >> > >> > I stumbled upon a problem compiling with pdflatex the "Europe CV" >> > example. I get the following error, in both languages available: >> > Spanish and English. >> > Can someone try and reproduce the problem so that I know whether it >> > is specific to me or the document itself? Thanks. >> > >> > PROBLEM >> > --- >> > 1. File > Open Examples... > Europe CV. >> > 2. Generate the preview of the document. >> > 3. Check whether the following error arises. >> > > See > https://github.com/gsilano/EuropeCV/pull/30 > > Since LyX does not load inputenc with utf8x in this document, > maybe you just don't have the latest version of europecv? > Thank you so much for the information and the suggestion. It is exactly the problem: my LaTeX distribution is installed via the OS's package manager, and the TeXLive packages for LinuxMint 21.2 happen to use the TeXLive 2021 pool. Hence, my version lacks the changes for version 2022. I installed it manually in my user tree and the error is gone. Thanks! I will check the sources in the future before posting to the list. For now, I do not dare to replace my current TeXLive distribution for a newer one (2023), since I am not very acquainted with managing and troubleshooting it, although I am getting familiar with tlmgr. Thanks again. Best regards. Daniel. -- Enviat amb Tutanota. -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Don't hide menus
On 2023-10-13 17:24, Jürgen Spitzmüller wrote: Am Freitag, dem 13.10.2023 um 17:08 +0200 schrieb Daniel: I agree that the menus of these apps are complex. But that might be in their nature. Well, they are aware of it: https://design.blog.documentfoundation.org/2016/01/22/way-down-in-the-libreoffice-menus/ I guess the Ribbon was a (maybe controversial) attempt to solve this problem. Yes, probably. With the result that you don't find things anymore at all. And Ribbons even more infringe the policy you refer to. They hide function from the user if they place it in (rather opaque) categories. But I think LyX with its hidden menus is actually worse to figure out. I am still discovering (otherwise) hidden menu entries and I have been using LyX for quite some time now. I keep on discovering menu entries in LO and Word although they have been displayed all the time. It might be different habits, but I search for menu entries when I need them. And this is when they are usually enabled. The problem is that one does not even know what to look for if one doesn't know of a possible functionality. This seems even worse in LyX because it is in certain ways a more unique application. In context when they do not work at all they only distract attention. I have not noticed that. I usually find that disabled menus are easy to disregard when I do not explicitly try to discover some function. And typically I have greater problems with disregarding stuff than other people. Another problem with disappearing menus is that the other menus shift positions. That is a bit annoying too. If I want to learn about LyX's functionality, I consult the manuals. I think people typically don't read software manuals. Maybe too bad but a fact that developers should honor. Maybe LyX users are different but I have my doubts. If it is really necessary to cut down on menu entries in the "Insert" menu when disabled entries get enabled: For example, create a separate "References" menu. References is just a single submenu in the Insert menu. That won't solve the problem. And, after all, if References are to be _inserted_, I would expect them under Insert. I meant the group of "References" as in "Citation", "Cross-References", "Label", "Caption", etc. These are typically subsumed under "References" in other word processors. (But if more entries for such a menu are needed, then entries in "List/TOC/References" might be added as well.) Daniel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Don't hide menus
Le 13/10/2023 à 17:08, Daniel a écrit : > I agree that the menus of these apps are complex. But that might be in their nature. I guess the Ribbon was a (maybe controversial) attempt to solve this problem. But I think LyX with its hidden menus is actually worse to figure out. I am still discovering (otherwise) hidden menu entries and I have been using LyX for quite some time now. What we could provide is a HUD, like Apple's Cmd-space, but for menu entries. We had that in Ubuntu in the old days. I can try to provide the backend for that if someone is ready to do the nice interface. JMarc -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Don't hide menus
Am Freitag, dem 13.10.2023 um 17:08 +0200 schrieb Daniel: > I agree that the menus of these apps are complex. But that might be > in their nature. Well, they are aware of it: https://design.blog.documentfoundation.org/2016/01/22/way-down-in-the-libreoffice-menus/ > I guess the Ribbon was a (maybe controversial) attempt to > solve this problem. Yes, probably. With the result that you don't find things anymore at all. And Ribbons even more infringe the policy you refer to. They hide function from the user if they place it in (rather opaque) categories. > But I think LyX with its hidden menus is actually > worse to figure out. I am still discovering (otherwise) hidden menu > entries and I have been using LyX for quite some time now. I keep on discovering menu entries in LO and Word although they have been displayed all the time. It might be different habits, but I search for menu entries when I need them. And this is when they are usually enabled. In context when they do not work at all they only distract attention. If I want to learn about LyX's functionality, I consult the manuals. > If it is really necessary to cut down on menu entries in the "Insert" > menu when disabled entries get enabled: For example, create a > separate "References" menu. References is just a single submenu in the Insert menu. That won't solve the problem. And, after all, if References are to be _inserted_, I would expect them under Insert. -- Jürgen -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Don't hide menus
On 2023-10-13 16:37, Jürgen Spitzmüller wrote: Am Freitag, dem 13.10.2023 um 16:27 +0200 schrieb Daniel: It seems to have a not unusual length as compared to Writer and Word. which have both a horrible UI. I regularly get lost in the intransparent structure when using either of these apps. However, I have noticed that LyX does have rather few main menus: LyX: 8 Word: 9 Pages: 9 Writer: 11 So, creating a new menu might be a way to have it all. It also needs to make sense. "Insert" is hard to split sensibly. I agree that the menus of these apps are complex. But that might be in their nature. I guess the Ribbon was a (maybe controversial) attempt to solve this problem. But I think LyX with its hidden menus is actually worse to figure out. I am still discovering (otherwise) hidden menu entries and I have been using LyX for quite some time now. If it is really necessary to cut down on menu entries in the "Insert" menu when disabled entries get enabled: For example, create a separate "References" menu. Daniel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Don't hide menus
On 2023-10-13 15:10, Scott Kostyshak wrote: On Fri, Oct 13, 2023 at 10:43:45AM +0200, Jürgen Spitzmüller wrote: Am Freitag, dem 13.10.2023 um 08:05 +0200 schrieb Daniel: It seems to be a rather universally accepted UI rule that menu items should not be hidden. Feel free to can check your favorite apps or search the recommendation on the web. (There is also the more extreme recommendations to not even disable menu entries but I think it is generally agreed that this is a bad idea because it leaves the user clicking in vain.) Don't like it since 1.) we will end up in overcrowded menus full of disabled entries. Too long for sure in some cases 2.) we will run out of accelerators. We currently can provide accelerators in the insert and edit menus only since we only show active items. I know you don't care about accelerators as they seem to be not common on Mac OS. However, I find them a key element of accessibility and much more important that some sort of user didactic by showing which functions there might be. I also don't see what users gain if they see a disabled function as long as they don't learn when and how it is enabled. I have mixed opinions. If we don't include the disabled items, perhaps we can agree on a guideline for which items to include when disabled and which not. This way we can try to at least be consistent. As a start, I would suggest that hiding a menu should be a last resort. That is not very specific, but at least in some menus, such as "Document", there seems to be no need to hide menus according to this rule. It might be helpful to have a few "use cases" to discuss. For example, "Document" > Cancel Export is included only when an export is present. Yes, that is a good example of a menu entry that is hard to discover and is located in a menu that is hardly long. In fact, I only stumbled upon it this morning: https://www.lyx.org/trac/ticket/12932. (But maybe that is how you came to think of it.) Daniel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Don't hide menus
Am Freitag, dem 13.10.2023 um 16:27 +0200 schrieb Daniel: > It seems to have a not unusual length as compared to Writer and Word. which have both a horrible UI. I regularly get lost in the intransparent structure when using either of these apps. > However, I have noticed that LyX does have rather few main menus: > > LyX: 8 > Word: 9 > Pages: 9 > Writer: 11 > > So, creating a new menu might be a way to have it all. It also needs to make sense. "Insert" is hard to split sensibly. -- Jürgen -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Don't hide menus
On 2023-10-13 16:18, Jürgen Spitzmüller wrote: Am Freitag, dem 13.10.2023 um 16:11 +0200 schrieb Daniel: An example would be interesting. As I mentioned, I enabled all menu items and didn't notice too long menus (not longer than in other popular apps anyway). The Insert menu is already too long now, with entries hidden. It seems to have a not unusual length as compared to Writer and Word. However, I have noticed that LyX does have rather few main menus: LyX: 8 Word: 9 Pages: 9 Writer: 11 So, creating a new menu might be a way to have it all. But I am a bit puzzled how hiding the menus fixes the accelerator problem. Doesn't that mean that some menus entries don't have any accelerators or that some menu entries will have the same as others? Some entries of which we know they are not shown at the same time can have the same accelerator. I see. That sounds indeed very tricky to maintain. Daniel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Don't hide menus
Am Freitag, dem 13.10.2023 um 16:11 +0200 schrieb Daniel: > An example would be interesting. As I mentioned, I enabled all menu > items and didn't notice too long menus (not longer than in other > popular apps anyway). The Insert menu is already too long now, with entries hidden. > But I am a bit puzzled how hiding the menus fixes the accelerator > problem. > Doesn't that mean that some menus entries don't have any accelerators > or that some menu entries will have the same as others? Some entries of which we know they are not shown at the same time can have the same accelerator. -- Jürgen -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Don't hide menus
On 2023-10-13 10:43, Jürgen Spitzmüller wrote: Am Freitag, dem 13.10.2023 um 08:05 +0200 schrieb Daniel: It seems to be a rather universally accepted UI rule that menu items should not be hidden. Feel free to can check your favorite apps or search the recommendation on the web. (There is also the more extreme recommendations to not even disable menu entries but I think it is generally agreed that this is a bad idea because it leaves the user clicking in vain.) Don't like it since 1.) we will end up in overcrowded menus full of disabled entries. Too long for sure in some cases An example would be interesting. As I mentioned, I enabled all menu items and didn't notice too long menus (not longer than in other popular apps anyway). 2.) we will run out of accelerators. We currently can provide accelerators in the insert and edit menus only since we only show active items. You are right, that I don't know much about the accelerator stuff. But I am a bit puzzled how hiding the menus fixes the accelerator problem. Doesn't that mean that some menus entries don't have any accelerators or that some menu entries will have the same as others? I know you don't care about accelerators as they seem to be not common on Mac OS. However, I find them a key element of accessibility and much more important that some sort of user didactic by showing which functions there might be. I also don't see what users gain if they see a disabled function as long as they don't learn when and how it is enabled. Users have a chance of directly inferring from a disabled menu when and how it is enabled or they can then try to look it up. Not seeing a menu entry in the first place seems not help in that respect. The two HIGs I consulted (and actually the two we base LyX UI on) have this to say: "Menus should contain between three and twelve items, and submenus should contain between three and six items." No word about hiding or not hiding items, but it's clear that you can only achieve this by selective display. https://developer.gnome.org/hig/patterns/controls/menus.html?highlight=menu And "Don't put more than 12 items within a single level of a menu. Add separators between logical groups within a menu. Organize the menu items into groups of seven or fewer strongly related items." It also says: "Disable menu items that don't apply to the current context instead of removing them from view. Exception: It is acceptable to hide menu items completely if they are permanently unavailable on the user's system due to missing hardware capabilities." But this is hard to achieve with the number of items we have. I think the "(3 to) 12 item" rule is often broken by larger apps while, as far as I can see, the "don't hide menu items" rule is not. In any case, however this discussion turns out, this is not something to be implemented so shortly before a major release. If done, it has to be implemented very early in a development cycle and then carefully tested. For sure. Daniel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Don't hide menus
On Fri, Oct 13, 2023 at 10:43:45AM +0200, Jürgen Spitzmüller wrote: > Am Freitag, dem 13.10.2023 um 08:05 +0200 schrieb Daniel: > > It seems to be a rather universally accepted UI rule that menu items > > should not be hidden. Feel free to can check your favorite apps or > > search the recommendation on the web. (There is also the more extreme > > recommendations to not even disable menu entries but I think it is > > generally agreed that this is a bad idea because it leaves the user > > clicking in vain.) > > Don't like it since > > 1.) we will end up in overcrowded menus full of disabled entries. Too > long for sure in some cases > > 2.) we will run out of accelerators. We currently can provide > accelerators in the insert and edit menus only since we only show > active items. > > I know you don't care about accelerators as they seem to be not common > on Mac OS. However, I find them a key element of accessibility and much > more important that some sort of user didactic by showing which > functions there might be. I also don't see what users gain if they see > a disabled function as long as they don't learn when and how it is > enabled. I have mixed opinions. If we don't include the disabled items, perhaps we can agree on a guideline for which items to include when disabled and which not. This way we can try to at least be consistent. It might be helpful to have a few "use cases" to discuss. For example, "Document" > Cancel Export is included only when an export is present. Scott signature.asc Description: PGP signature -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Big number of inverted docbook5 tests
Am Thu, 12 Oct 2023 13:59:17 +0200 schrieb Thibaut Cuvelier : > On Thu, 12 Oct 2023, 11:11 Kornel Benko, wrote: > > > > > Master trunk as of today: > > I count 406 tests for docbook5. 149 of them are inverted. > > Thibaut, is there a reason for such a huge ratio? > > > There are two major reasons. > - Many tests are for Beamer: someone would need to write the layouts for > it, there is little from the other documents that can be used for Beamer. > - There are modules that are hard to support (they would need a lot of > custom code only for one module). Basically, that means that LaTeX and > DocBook are vastly different in terms of concepts and levels of abstraction. > I think I "documented" the inversion in the commit messages. Overall, > having all tests pass would require tens of hours of work, which I > preferred to invest in improving the quantity of the existing > implementation. Good reasons. We could also select some of them to be ignored, so they do not show anymore. Also, tests which are planed to not fail in the future, deserve entry in suspendedTests too. Kornel pgpxRnhdGu45e.pgp Description: Digitale Signatur von OpenPGP -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Don't hide menus
Am Freitag, dem 13.10.2023 um 10:43 +0200 schrieb Jürgen Spitzmüller: > And > > "Don't put more than 12 items within a single level of a menu. Add > separators between logical groups within a menu. Organize the menu > items into groups of seven or fewer strongly related items." > > It also says: > > "Disable menu items that don't apply to the current context instead > of > removing them from view. Exception: It is acceptable to hide menu > items > completely if they are permanently unavailable on the user's system > due > to missing hardware capabilities." > > But this is hard to achieve with the number of items we have. That's from https://develop.kde.org/hig/components/navigation/menubar/ -- Jürgen -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Don't hide menus
Am Freitag, dem 13.10.2023 um 08:05 +0200 schrieb Daniel: > It seems to be a rather universally accepted UI rule that menu items > should not be hidden. Feel free to can check your favorite apps or > search the recommendation on the web. (There is also the more extreme > recommendations to not even disable menu entries but I think it is > generally agreed that this is a bad idea because it leaves the user > clicking in vain.) Don't like it since 1.) we will end up in overcrowded menus full of disabled entries. Too long for sure in some cases 2.) we will run out of accelerators. We currently can provide accelerators in the insert and edit menus only since we only show active items. I know you don't care about accelerators as they seem to be not common on Mac OS. However, I find them a key element of accessibility and much more important that some sort of user didactic by showing which functions there might be. I also don't see what users gain if they see a disabled function as long as they don't learn when and how it is enabled. The two HIGs I consulted (and actually the two we base LyX UI on) have this to say: "Menus should contain between three and twelve items, and submenus should contain between three and six items." No word about hiding or not hiding items, but it's clear that you can only achieve this by selective display. https://developer.gnome.org/hig/patterns/controls/menus.html?highlight=menu And "Don't put more than 12 items within a single level of a menu. Add separators between logical groups within a menu. Organize the menu items into groups of seven or fewer strongly related items." It also says: "Disable menu items that don't apply to the current context instead of removing them from view. Exception: It is acceptable to hide menu items completely if they are permanently unavailable on the user's system due to missing hardware capabilities." But this is hard to achieve with the number of items we have. In any case, however this discussion turns out, this is not something to be implemented so shortly before a major release. If done, it has to be implemented very early in a development cycle and then carefully tested. -- Jürgen -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
