Re: LyX 2.4.0 Schedule
On 2023-12-21 02:47, Richard Kimberly Heck wrote: I've sent a note to the translators making one final call for translations, asking for them to be delivered by the New Year. Shortly after that, I will package RC2, and hopefully we can aim at an actual release by the end of January. Riki RC2? I seem to have missed RC1. Where can I get it? It seems not to be on the ftp server. Daniel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: 2.1 beta1: "use justification in LyX work area" should be a Pref
On 2023-12-02 02:30, Richard Kimberly Heck wrote: On 12/1/23 13:00, Jean-Marc Lasgouttes wrote: Le 01/12/2023 à 12:23, Daniel a écrit : This refers to a surprisingly brief discussion: https://www.mail-archive.com/lyx-devel@lists.lyx.org/msg181030.html Basically, the idea was to move "Use justification in LyX work area" from document settings to pref. I do not have much to add to what I wrote at the time, I still agree this should be a pref. But it is probably too late for 2.4. Hard to say. It would be a string change, presumably, so in that sense it is too late. But we could add the preference, without UI, and unimplemented, now, planning to implement it for 2.4.x. We would then have both the document preference and the user preference, but the former could be 'hidden' by removing the UI at the same point release as when we add UI for the pref. I know it's a bit hackish, but it would work. Riki Sounds good to me. I have created an improvement report accordingly: https://www.lyx.org/trac/ticket/13009 Daniel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: 2.1 beta1: "use justification in LyX work area" should be a Pref
On 2023-12-01 12:23, Daniel wrote: This refers to a surprisingly brief discussion: https://www.mail-archive.com/lyx-devel@lists.lyx.org/msg181030.html Basically, the idea was to move "Use justification in LyX work area" from document settings to pref. I take it the one reason to do so is that the setting is an individual preference. I for my part don't like reading text where justification is used without proper line-breaking and hyphenation that avoids huge spaces and rivers. But I can see that this is still a personal preference. So, when reading someone else's document I would like it to show up with my preferred setting and I wouldn't want to change that person's preferred setting of the document (and maybe forget to reset it). (I have not seen specific reasons against making it a preference.) Any chance this might be done after all? Daniel This was not to complain about LyX line-breaking. I think, given it's general limitations, it's quite good. But it is no LaTeX output. And the nice breaking is one reason I prefer reading LaTeX documents. (I also think typographers generally agree that unless larger spaces and rivers can be avoided, justification is to be avoided. I take it that is why it is not used on the web. Maybe a point for avoiding it by default in LyX as well.) Daniel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: 2.1 beta1: "use justification in LyX work area" should be a Pref
This refers to a surprisingly brief discussion: https://www.mail-archive.com/lyx-devel@lists.lyx.org/msg181030.html Basically, the idea was to move "Use justification in LyX work area" from document settings to pref. I take it the one reason to do so is that the setting is an individual preference. I for my part don't like reading text where justification is used without proper line-breaking and hyphenation that avoids huge spaces and rivers. But I can see that this is still a personal preference. So, when reading someone else's document I would like it to show up with my preferred setting and I wouldn't want to change that person's preferred setting of the document (and maybe forget to reset it). (I have not seen specific reasons against making it a preference.) Any chance this might be done after all? Daniel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Don't record (de)activating change tracking on undo stack
On 2023-11-30 17:46, Lorenzo Bertini wrote: Il giorno gio 30 nov 2023 alle ore 15:47 Jean-Marc Lasgouttes ha scritto: Le 30/11/2023 à 03:01, Daniel a écrit : LyX has the peculiarity of treating the (de)activating of change tracking as something that is recorded on the undo stack. Actually, everything that is stored in the file goes to the undo stack. I do not see how to avoid that. One of the problems I ran into with this is that it unexpectedly killed the redo function when I activated change tracking, i.e. I undid some changes and activated the change tracking in between and this changed what could be redone. The only other app I know of that does this is Apple Pages. But I am not sure whether Apple's change tracking should be taken as a thought through feature, e.g. it is impossible to de-activate change tracking without accepting all changes. Go figure! Do other applications save change tracking status? Would you find it good that, if you open a file for the explicit purpose of setting change tracking "on", then it will be necessary to fake another change for the purpose of being able to save it? Or that undoing all your changes may leave certain change unbeknownst to you? There might be another way to avoid killing the redo stack. Do you know of any applicaiton that has a solution to this? JMarc I agree with Daniel, it caught me off guard the first time that document settings got in the way of undo-redo. Can't really tell what other word processors use, but what I expected was that undo-redo only applied to the text of the document. However, JMarc's point about not being able to save after a setting change is very valid. If anyone has libreoffice installed, how is this handled there? Lorenzo I don't have enough insight into the LyX's undo mechanism, so I cannot answer JMarc's first question concerning how this could be done in LyX in particular. General about the necessity to fake changes: All of Writer, Word and Pages allow saving the document independently of the "dirty" state. So, there is generally no problem with not being able to save the document at any point. No faking needed. In contrast, in LyX one already has to fake a change if one wants to store e.g. close/open inset status. By the way, Libre Writer indicates a dirty document with a "shiny disk" (see also https://www.lyx.org/trac/ticket/12331). Specifically about change tracking: Other applications save the change tracking status as well. In Writer and Word, the document is temporarily rendered dirty when change tracking is activated but the undo stack is not touched. Meaning that if one undoes changes since last save it would revert to not being dirty without undoing change tracking status. But since one can still save... Seems sensible to me. Pages does it as LyX including killing the undo stack. Daniel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Don't record (de)activating change tracking on undo stack
LyX has the peculiarity of treating the (de)activating of change tracking as something that is recorded on the undo stack. One of the problems I ran into with this is that it unexpectedly killed the redo function when I activated change tracking, i.e. I undid some changes and activated the change tracking in between and this changed what could be redone. The only other app I know of that does this is Apple Pages. But I am not sure whether Apple's change tracking should be taken as a thought through feature, e.g. it is impossible to de-activate change tracking without accepting all changes. Go figure! Daniel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Text completion
On 2023-11-29 13:26, Daniel wrote:
I tried to use text completion for a bit now. Is it correct that the
feature is kind of experimental?
I am asking because unless I misunderstood how it works, it seems to
have a couple of quirks. For example, the list of words ("popup")
sometimes misses words or shows words that don't match.
Daniel
Attached is an example of missing words. And when I write one of the
missing words in a new line, it all of a sudden adds the word.
Daniel--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
Text completion
I tried to use text completion for a bit now. Is it correct that the
feature is kind of experimental?
I am asking because unless I misunderstood how it works, it seems to
have a couple of quirks. For example, the list of words ("popup")
sometimes misses words or shows words that don't match.
Daniel
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Using Comment notes the right way
I took what I learned in this discussion and created https://www.lyx.org/trac/ticket/12978. Daniel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Using Comment notes the right way
On 2023-11-21 18:19, Richard Kimberly Heck wrote: On 11/21/23 06:17, Jean-Marc Lasgouttes wrote: Le 21/11/2023 à 07:54, Daniel a écrit : I see. But my point was that I don't think that it is specific to my use case. The reason being that the comment feature is a default feature found in many applications these days and that this indicates a quite general usefulness of it. As I wrote before, the main feature that would make me like a new comment inset would be to be able to show the name and color of the user who entered it when some in change tracking mode. As Isaac said, the todonotes module provides notes with this kind of functionality. I guess the original idea was to do that automatically rather than having to do it manually which is quite cumbersome. Daniel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Using Comment notes the right way
On 2023-11-21 12:17, Jean-Marc Lasgouttes wrote: Le 21/11/2023 à 07:54, Daniel a écrit : I see. But my point was that I don't think that it is specific to my use case. The reason being that the comment feature is a default feature found in many applications these days and that this indicates a quite general usefulness of it. As I wrote before, the main feature that would make me like a new comment inset would be to be able to show the name and color of the user who entered it when some in change tracking mode. Having a comment feature that is linked to the change tracking machinery would be good. The issue of knowing how to typeset them, though, is not that easy. I am not sure which specificity of implementation you are after. But the pdfcomment package supports the "author=..." option for individual comments (as well as the "color=..." option). I also want to point out that Comment notes (mentionned in the subject of the thread) have nothing to do with that. These are just notes that are visible in the document source, but not typeset. This is in contrast with plain notes, that are not exported at all. This question of having this potentially private information present or not in the .tex file is more important IMO than having it visible to the end user. > Finally, my remark about "MSWord in a box" was undeserved, and I apologize for that. I should have fought a bit more the urge of making fun of the idea. However, if allowing free spacing in comments is considered a worthy feature (after all everybody else does that), then why not allow it everywhere then? Everybody has its own habits, after all, and I am sure some people would enjoy this. I think not allowing free spacing and empty lines in the main text is helpful because it indicates what is going on in the output. Double spaces and extra empty lines will be swallowed by LaTeX. The idea with comments was that since they are not typeset that way, it might make sense to allow for more freedom of how to enter stuff. So that seems to be an important difference. But I see now that things are not as easy as they seemed to me at first. Because one might see not being able to enter extra spaces and empty lines not only as related to the output but as help to avoid them in general. Maybe that is one of your concerns? If the pdfcomment package is used for output, I would highly recommend allowing for more freedom in spacing (something that the module lacks) since it only supports plain text as far as I can see. Daniel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Using Comment notes the right way
On 2023-11-19 22:30, Richard Kimberly Heck wrote: On 11/19/23 15:31, Daniel wrote: On 2023-11-19 12:20, Jean-Marc Lasgouttes wrote: Le 19/11/2023 à 07:47, Daniel a écrit : On 2023-11-15 11:47, Daniel wrote: 2. Allow free spacing in Comments. That is typically a feature in sticky notes in other applications which is handy if one wants just to quickly type stuff down without bothering with special formatting. It basically offers more freedom to scribble as you like. Daniel And also KeepEmpty should be enabled in commnents for similar reasons. So you want MSWord in a box? I do not see why the feature would require that. But of course it is not difficult to create a module that transforms the inset in this way. I don't see what is MS Word specific about it. But if the commenting function of PDF readers is MS Word in a box, then maybe that is what I am thinking about. I guess the thought was that because the output is not affected anyway, it's fine to let the user choose how to write the comment. No need to put limits on it. But I would be already happy if there was some nice out of the box minimal commenting function that does not inherit the font but also does (maybe optionally) not affect the output. So far LyX has only LyX Notes (which inherit the font) and Comments (which affect the output). Isn't something missing? I know that a lot can be done with modules. But I am thinking about a common feature that seems handy in other application which LyX seems to be missing. It would be strange if one would have to include a module in order to write comments. I take JMarc's point to be that what you are asking for seems very specific to your specific use case. Since it's relatively easy to create an inset like the one you want, and there are maintenance costs, etc, connected with adding new things, it's not clear the cost is worth the benefit. Note, by the way, that the PDF modules already provide for other forms of comments. Riki I see. But my point was that I don't think that it is specific to my use case. The reason being that the comment feature is a default feature found in many applications these days and that this indicates a quite general usefulness of it. To provide a more common comment feature seems to me to justify such cost. I can see how one might think differently given that one has been able to comment on ones documents for years with LyX notes. It was the same for me until I realised that the quirks I had with using LyX Notes might be solved by a more common comment feature. I don't take my suggestion to be the best idea. But I am pursuaded that there is clear room for improvement of LyX's commenting functuionality. I hope someone has some good ideas about this some day. (For my private use, I am fine with building my own feature of course.) Daniel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Using Comment notes the right way
On 2023-11-19 12:20, Jean-Marc Lasgouttes wrote: Le 19/11/2023 à 07:47, Daniel a écrit : On 2023-11-15 11:47, Daniel wrote: 2. Allow free spacing in Comments. That is typically a feature in sticky notes in other applications which is handy if one wants just to quickly type stuff down without bothering with special formatting. It basically offers more freedom to scribble as you like. Daniel And also KeepEmpty should be enabled in commnents for similar reasons. So you want MSWord in a box? I do not see why the feature would require that. But of course it is not difficult to create a module that transforms the inset in this way. I don't see what is MS Word specific about it. But if the commenting function of PDF readers is MS Word in a box, then maybe that is what I am thinking about. I guess the thought was that because the output is not affected anyway, it's fine to let the user choose how to write the comment. No need to put limits on it. But I would be already happy if there was some nice out of the box minimal commenting function that does not inherit the font but also does (maybe optionally) not affect the output. So far LyX has only LyX Notes (which inherit the font) and Comments (which affect the output). Isn't something missing? I know that a lot can be done with modules. But I am thinking about a common feature that seems handy in other application which LyX seems to be missing. It would be strange if one would have to include a module in order to write comments. Daniel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Using Comment notes the right way
On 2023-11-18 10:28, Daniel wrote: On 2023-11-17 10:12, Jean-Marc Lasgouttes wrote: Le 17/11/2023 à 08:43, Daniel a écrit : It still seems to me that LyX should provide a ready to use commenting feature that can be globally toggled on and off in the export. And it seems to me that the "Comment" note is on the right track here. It just needs a facelift (some nice label color and background color) and some additional features (toggling, free spacing) and it would be pretty close to ideal as a default commenting feature. I do not see why Comment (which is a note output using the comment.sty package) would be a good choice. Let's say instead that you want to create a specially crafted note. Then, what is free spacing doing here? Why would it be specially useful in a comment? On 2023-11-15 11:47, Daniel wrote: 2. Allow free spacing in Comments. That is typically a feature in sticky notes in other applications which is handy if one wants just to quickly type stuff down without bothering with special formatting. It basically offers more freedom to scribble as you like. Daniel And also KeepEmpty should be enabled in commnents for similar reasons. Daniel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Using Comment notes the right way
On 2023-11-17 10:12, Jean-Marc Lasgouttes wrote: Le 17/11/2023 à 08:43, Daniel a écrit : It still seems to me that LyX should provide a ready to use commenting feature that can be globally toggled on and off in the export. And it seems to me that the "Comment" note is on the right track here. It just needs a facelift (some nice label color and background color) and some additional features (toggling, free spacing) and it would be pretty close to ideal as a default commenting feature. I do not see why Comment (which is a note output using the comment.sty package) would be a good choice. Let's say instead that you want to create a specially crafted note. Then, what is free spacing doing here? Why would it be specially useful in a comment? On 2023-11-15 11:47, Daniel wrote: 2. Allow free spacing in Comments. That is typically a feature in sticky notes in other applications which is handy if one wants just to quickly type stuff down without bothering with special formatting. It basically offers more freedom to scribble as you like. Daniel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Using Comment notes the right way
On 2023-11-18 01:20, Richard Kimberly Heck wrote: On 11/17/23 04:17, Jean-Marc Lasgouttes wrote: Le 17/11/2023 à 08:00, Daniel a écrit : One difference I noted is that branches have a strange indentation at the beginning. But I seem to remember that this is a bug rather than a feature. A bug indeed. It's because we treat the beginning of the branch as the start of a paragraph. I had to deal with a similar issue in XHTML export. I think we could just check if we're in the first paragraph of a branch and not indent if so. Riki See also https://www.lyx.org/trac/ticket/12419. Daniel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Using Comment notes the right way
On 2023-11-16 15:22, Pavel Sanda wrote:
On Thu, Nov 16, 2023 at 02:00:29PM +0100, Jean-Marc Lasgouttes wrote:
I do not have time for a detailed comment, but you should really take a hard
look at branches. They are an incredibly useful tool.
I agree. Just for a inspiration I attach how 3 different branches can be used
for
3 different types of notes with the use of local layout. Each of these notes can
be (un)exported by a few clicks.
You just create 3 branches note_right, note_foot, note_inline and define in
document prefs, local layout these:
InsetLayout Branch:note_right
LabelString Brancc
MultiPar true
LatexType command
LatexName ledrightnote
Preamble
\setlength{\marginparwidth}{4.5cm}
EndPreamble
End
InsetLayout Branch:note_foot
LabelString footc
LatexType command
LatexNamefootnote
MultiPar true
RefPrefix fn
End
InsetLayout Branch:note_inline
LabelString prekl
LatexType command
LatexName" \textcolor{red}"
MultiPar true
RefPrefix fn
Preamble
\usepackage{color}
EndPreamble
End
Pavel
I think that I have figured out how this works after a while. Nice that
one can do this with LyX.
I know that you might not have intended to answer my original point, so
my comment might not be an answer to yours either, but this approach
seems a bit too complicated for a simple commenting feature.
It still seems to me that LyX should provide a ready to use commenting
feature that can be globally toggled on and off in the export. And it
seems to me that the "Comment" note is on the right track here. It just
needs a facelift (some nice label color and background color) and some
additional features (toggling, free spacing) and it would be pretty
close to ideal as a default commenting feature.
Another thing that would make Comments more comment like is to mark them
with the name (and even color) of the author in the label. Well, I am
getting carried away again...
(I take back my suggestion that it could be toggled on a per comment
basis. I have not seen such a feature elsewhere and maybe branches are
good enough for such a specific feature.)
Daniel
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Using Comment notes the right way
On 2023-11-16 14:00, Jean-Marc Lasgouttes wrote: Le 16/11/2023 à 10:58, Daniel a écrit : But couldn't there be a case where you want some people to get the comments in LaTeX but not others? Why do I have to make a decision on this by choosing a particular note. Yes, I could put stuff into branches but it feels a bit like taking a sledgehammer to break a nut. I must confess that I have never really used branches. I do not have time for a detailed comment, but you should really take a hard look at branches. They are an incredibly useful tool. Reinventing a way to insert or not a given note in such or such case is futile IMO. As it is, a yellow note is the “always inactive” branch. And it serves this purpose pretty well. If you need a bubble-like tool (for revision, for example), it has to be a new one. Don't let the yellow fool you :) I never felt the need for branches. Maybe because they are not common elsewhere and hence they are not part of my workflow. Seeing the yellow note as an "always inactive" branch seems helpful. Though I cannot help but wonder why it is more helpful than a default branch that is deactivated by default and could in principle be activated. One difference I noted is that branches have a strange indentation at the beginning. But I seem to remember that this is a bug rather than a feature. Daniel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Using Comment notes the right way
On 2023-11-16 10:58, Daniel wrote:
On 2023-11-15 23:31, Richard Kimberly Heck wrote:
On 11/15/23 05:47, Daniel wrote:
I recently discovered that I might have been using LyX Notes while I
should have been using Comment notes. I was wondering why LyX Notes
inherit the font (https://www.lyx.org/trac/ticket/12939). Comment
notes do not inherit the font of the surrounding text which seems
sensible for a comment. LyX Notes inherit and they seem to be fitting
for commenting out parts of a document out.
My guess is that the commenting feature is what people typically
expect when inserting a "sticky note" (see PDF readers' similar
features and other word processors). The prominent positioning of LyX
Notes (as the only notes in the toolbar) and the visualization (as a
sticky note) seems to have mislead me over the years to expect that
they are the analogue for what is found in other applications. What I
really wanted to do most of the time is put a comment into the text.
The difference is that comments are exported as comments, whereas
notes are never exported. So I would use a comment where in LaTeX I
would do:
% this is a comment
This is probably not a very common thing for most users to do. I'm not
sure I've ever used a comment! I always use LyX Notes for, well, notes
to myself (or my collaborators), which I do not usually want in the
exported LaTeX (which I might be sending to a journal).
That said, LyX uses a comment *environment* for the export, which
means that you can \renewenvironment{comment} if you want them printed
somehow.
It would be possible (and might make good sense) to make the toolbar
button a drop down sort of thing, like with View, so you could choose
the note type from there.
A couple of things would be nice.
1. Make Comments more prominent and visualize them as sticky notes
instead of LyX Notes.
I'm curious whether you still think this is needed, given what I've
just said. I'm also not sure what you mean by "visualized as sticky
notes". Comments and notes look the same to me (in LyX), except for
the color choices.
2. Allow free spacing in Comments. That is typically a feature in
sticky notes in other applications which is handy if one wants just
to quickly type stuff down without bothering with special formatting.
Easy to do in Local Layout. Not to say it wouldn't be a good default.
I wouldn't want to do it now, though, as that is a format change
(since 'free spacing' would get eaten on conversion to older formats).
3. Make it optional whether Comments are exported or not. Another
typical feature. There could be both a global (for all comments)
setting and a local (for individual comments).
Comments are always exported---as comments. If you want to make export
conditional (in a broadly global way), then use branches. Or you can
do something like:
InsetLayout Note:Comment
LatexName MyComment
Preamble
\newenvironment{MyComment}{...}{...}
EndPreamble
End
To get local control, define a Flex inset and give it an argument
which acts as a flag: Visible or not. I.e., if the flag is empty, it
acts like a comment; if not, then it acts like some other environment,
or just prints the argument.
One thing that would be cool, actually, would be to be able to define
new kinds of Note insets, the way we do Flex insets, but have them
then be handled like other notes. E.g.:
InsetLayout Note:MyNote
Etc
End
And now that would appears in the Notes menu and context menu.
Riki
By "visualized as sticky notes", I meant that the (default) toolbar
button for LyX Notes shows a sticky note icon and the inset has a yellow
color (though not a very pleasant one). I don't see why sticky notes on
a text should inherit font. Also, if you use LyX Notes for comments to
collaborators, isn't it annoying when you put a note on a heading and
get this massive inset due to font inheritance?
Even if the toolbar would provide all different note insets, I still
think that it could be improved. You say that you use LyX Notes because
these are comments to your collaborators and you don't want them to be
in the final LaTeX file send to a journal. But couldn't there be a case
where you want some people to get the comments in LaTeX but not others?
Why do I have to make a decision on this by choosing a particular note.
Yes, I could put stuff into branches but it feels a bit like taking a
sledgehammer to break a nut. I must confess that I have never really
used branches. But it seems to me that a seemingly simple decisions
about whether notes should be exported shouldn't depend on having used
branches or a specific note type rather than another.
Another awesome thing would of course be even the option to export the
notes to PDF. But I am getting carried away...
It just seems to me that the default commenting in LyX taking could be
improved to be more useful to the user.
Daniel
As
Re: Using Comment notes the right way
On 2023-11-15 23:31, Richard Kimberly Heck wrote:
On 11/15/23 05:47, Daniel wrote:
I recently discovered that I might have been using LyX Notes while I
should have been using Comment notes. I was wondering why LyX Notes
inherit the font (https://www.lyx.org/trac/ticket/12939). Comment
notes do not inherit the font of the surrounding text which seems
sensible for a comment. LyX Notes inherit and they seem to be fitting
for commenting out parts of a document out.
My guess is that the commenting feature is what people typically
expect when inserting a "sticky note" (see PDF readers' similar
features and other word processors). The prominent positioning of LyX
Notes (as the only notes in the toolbar) and the visualization (as a
sticky note) seems to have mislead me over the years to expect that
they are the analogue for what is found in other applications. What I
really wanted to do most of the time is put a comment into the text.
The difference is that comments are exported as comments, whereas notes
are never exported. So I would use a comment where in LaTeX I would do:
% this is a comment
This is probably not a very common thing for most users to do. I'm not
sure I've ever used a comment! I always use LyX Notes for, well, notes
to myself (or my collaborators), which I do not usually want in the
exported LaTeX (which I might be sending to a journal).
That said, LyX uses a comment *environment* for the export, which means
that you can \renewenvironment{comment} if you want them printed somehow.
It would be possible (and might make good sense) to make the toolbar
button a drop down sort of thing, like with View, so you could choose
the note type from there.
A couple of things would be nice.
1. Make Comments more prominent and visualize them as sticky notes
instead of LyX Notes.
I'm curious whether you still think this is needed, given what I've just
said. I'm also not sure what you mean by "visualized as sticky notes".
Comments and notes look the same to me (in LyX), except for the color
choices.
2. Allow free spacing in Comments. That is typically a feature in
sticky notes in other applications which is handy if one wants just to
quickly type stuff down without bothering with special formatting.
Easy to do in Local Layout. Not to say it wouldn't be a good default. I
wouldn't want to do it now, though, as that is a format change (since
'free spacing' would get eaten on conversion to older formats).
3. Make it optional whether Comments are exported or not. Another
typical feature. There could be both a global (for all comments)
setting and a local (for individual comments).
Comments are always exported---as comments. If you want to make export
conditional (in a broadly global way), then use branches. Or you can do
something like:
InsetLayout Note:Comment
LatexName MyComment
Preamble
\newenvironment{MyComment}{...}{...}
EndPreamble
End
To get local control, define a Flex inset and give it an argument which
acts as a flag: Visible or not. I.e., if the flag is empty, it acts like
a comment; if not, then it acts like some other environment, or just
prints the argument.
One thing that would be cool, actually, would be to be able to define
new kinds of Note insets, the way we do Flex insets, but have them then
be handled like other notes. E.g.:
InsetLayout Note:MyNote
Etc
End
And now that would appears in the Notes menu and context menu.
Riki
By "visualized as sticky notes", I meant that the (default) toolbar
button for LyX Notes shows a sticky note icon and the inset has a yellow
color (though not a very pleasant one). I don't see why sticky notes on
a text should inherit font. Also, if you use LyX Notes for comments to
collaborators, isn't it annoying when you put a note on a heading and
get this massive inset due to font inheritance?
Even if the toolbar would provide all different note insets, I still
think that it could be improved. You say that you use LyX Notes because
these are comments to your collaborators and you don't want them to be
in the final LaTeX file send to a journal. But couldn't there be a case
where you want some people to get the comments in LaTeX but not others?
Why do I have to make a decision on this by choosing a particular note.
Yes, I could put stuff into branches but it feels a bit like taking a
sledgehammer to break a nut. I must confess that I have never really
used branches. But it seems to me that a seemingly simple decisions
about whether notes should be exported shouldn't depend on having used
branches or a specific note type rather than another.
Another awesome thing would of course be even the option to export the
notes to PDF. But I am getting carried away...
It just seems to me that the default commenting in LyX taking could be
improved to be more useful to the user.
Daniel
--
lyx-devel mailing list
lyx-devel@list
Using Comment notes the right way
I recently discovered that I might have been using LyX Notes while I should have been using Comment notes. I was wondering why LyX Notes inherit the font (https://www.lyx.org/trac/ticket/12939). Comment notes do not inherit the font of the surrounding text which seems sensible for a comment. LyX Notes inherit and they seem to be fitting for commenting out parts of a document out. My guess is that the commenting feature is what people typically expect when inserting a "sticky note" (see PDF readers' similar features and other word processors). The prominent positioning of LyX Notes (as the only notes in the toolbar) and the visualization (as a sticky note) seems to have mislead me over the years to expect that they are the analogue for what is found in other applications. What I really wanted to do most of the time is put a comment into the text. A couple of things would be nice. 1. Make Comments more prominent and visualize them as sticky notes instead of LyX Notes. Of course that means that LyX Notes should get a new visualization as well because otherwise they would look to similar. I am not sure what would be best. If they were specifically for commenting out, it would be easier but by now many people will have used LyX notes for other stuff as I did. 2. Allow free spacing in Comments. That is typically a feature in sticky notes in other applications which is handy if one wants just to quickly type stuff down without bothering with special formatting. 3. Make it optional whether Comments are exported or not. Another typical feature. There could be both a global (for all comments) setting and a local (for individual comments). I think that would fit my commenting needs much better than what LyX currently has to offer. Daniel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
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#menus "Don't put more than 12 items within a single level of a menu." https://develop.kde.org/hig/components/navigation/menubar/ "Be mindful of menu length. People need more time and attention to read a long menu, which means they may miss the command they want. If a menu is long, you might need to break it into separate menus. In some cases, you can use a submenu to shorten the list. The exception is a menu that contains user-defined or dynamically generated content, such as the History and Bookmarks menus in Safari. In this situation, people expect the menu to accommodate the items they add to it, so a long menu is fine, and scrolling is acceptable." https://developer.apple.com/design/human-interface-guidelines/menus Is there any evidence for the "no more 12 items" rule? So many more complicated applications have much longer menus which seems to oppose this rule. If anything, the rule is a guide that can and should easily be broken for the sake of other benefits. Even Apple's own Pages has 29 menu items in a single menu. See also: https://uxmyths.com/post/931925744/myth-23-choices-should-always-be-limited-to-seven Also, while avoiding long menus (or any longish list) is a good idea in general, the means by which it is done seems to be important too. Creating submenus with very many items might not be the best choice (even according to the rules above). Neither seems it to be LyX's method of hiding items (in main menus): "Gray out any unavailable options instead of removing them: any items that cannot be selected should remain in view. [...] If disabled items are removed, the interface loses spatial consistency and becomes harder to learn [https://www.nngroup.com/articles/power-law-learning/].; https://www.nngroup.com/articles/drop-down-menus/ Best wishes, 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-14 14:48, Jean-Pierre Chrétien wrote: Le 14/10/2023 à 03:52, Daniel a écrit : 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 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. Hello Daniel, So, if I understand correctly, you would like that the LyX UI be modified to fit your peculiarities. Usually people having the same wish fill an enhancement ticket and wait for developers to have time to investigate if the enhancement is liable to improve LyX for everybody. They do not harass developers directly on the list. Moreover, I do not understand why you are so keen to have LyX UI behave like Word UI. If you like Word UI so much, just use Word. My 2cts. Hello Jean-Pierre, I still don't think that my suggestion is a personal peculiarity. It seems to be a (near?) universal standard (not even restricted to word processors like Word, Writer and Pages). And I still believe it's for a very good reason. The keenness on LyX behaving more like Word and other word processors stems from the idea that a lot of know how went into these applications that share a lot of similarities with LyX hence I think that things can be learned from them. But that really is restricted to were it seems to makes sense. I don't use Word since I prefer LaTeX and many features that LyX provides. I typically post on the tracker (under the user name "racoon"). Best wishes, 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-14 12:47, Jürgen Spitzmüller wrote: Am Samstag, dem 14.10.2023 um 12:26 +0200 schrieb Daniel: I think it's just a matter of getting used. But I understand that it's hard at the beginning as with every new interface. I use that for years and don't get used to it. It's just very bad design. Unless these word processor creators all don't listen to their users, apparently many people do. But it doesn't really matter. I don't see other ways of moving forward currently. Maybe others have better ideas. 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-14 09:08, Jürgen Spitzmüller wrote: Am Freitag, dem 13.10.2023 um 18:07 +0200 schrieb Daniel: I meant the group of "References" as in "Citation", "Cross- References", "Label", "Caption", etc. These are typically subsumed under "References" in other word processors. Ah, that. Yes, this is a very good example for Word's failed user interface (LibreOffice doesn't do that). Every time I use word, I am losing time in searching elements I'd expect in Insert which they put in References. For instance, if I want to insert a footnote, I need to find it in that References menu. Why? Thanks, but no, thanks. Not sure what you are referring to. Word does not have such a menu. And if you are referring to the "References" category of the ribbon then both Word and Writer have it. I think it's just a matter of getting used. But I understand that it's hard at the beginning as with every new interface. 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-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" +
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
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: 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
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
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
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
Don't hide menus
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.) I am referring here foremost to the main menu items. Context-menus may be treated differently because they are expected to be context-dependent (as the name suggests). Among the main reasons for why menu items should not be hidden are that with hidden menus users have a harder time 1) discovering features 2) figuring out and remembering where menu items are located Notice that these two may be hard to appreciate for developers because they typically know the entries independently of whether they are shown. And I seem to remember a couple of instances where users were asking about missing features on the list which were due to OptItems being hard to discover. In contrast to other applications, LyX has a greater number of menu entries that become hidden. I am not sure about what the history of this special behavior of LyX is but maybe it had to do with a trade-off in a time when screen size/resolution was quite limited? I have made a test and changed all OptItems to Items in the stdmenus.inc. That might not show all the menu items since there are some whose "expansion" is hard-coded. Those expansions should typically have a disabled "empty" entry when there is nothing to expand. See, e.g., Navigate > (Empty Table of Contents) which is a perfect example of informing a user about a feature with a disabled entry while the feature is unavailable. With this change I found that the length of the menus seemed totally acceptable to me (and at least not longer than for other "word processors"). The only exception were the various inset settings in the "Edit" menu. However, these seem to be mutually exclusive. So, there are different ways to resolve this problem. For example, to create one settings entry that rules them all and shows a disabled "Inset Setting..." when unavailable. In the short term, one might even have an exception here for using OptItems for this specific case. Best, Daniel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [RFC Riki!] Re: Highlighted math in dark mode is hard to see
On 2023-09-29 15:53, Jürgen Spitzmüller wrote: Am Freitag, dem 29.09.2023 um 15:11 +0200 schrieb Jürgen Spitzmüller: Or maybe introduce a Color_selectionmath. I think this could be easily implemented for 2.4 without having to fear collateral effects. Like this. Involves a new string, tough. And it only works for fully selected math insets, not for parts of it. Don't know where to set the latter. As for the latter problem, this one might be related: #12692. Daniel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Boder of Frame inset not visible in dark mode
On 2023-09-26 04:26, Daniel wrote: On 2023-09-24 22:24, Dan wrote: Hello, PROBLEM There is a frame whose outline is not visible in dark mode because it is black (Insert > Frame > Simple Frame). The box inset name is "Boxed" (https://www.lyx.org/trac/browser/lyxgit/lib/layouts/stdinsets.inc#L504). See the attached image for a showcase of all the frames showing the problem. EXPECTED BEHAVIOUR === Simple Frame Box should have the same outline colour as the other frames. A bug here that wpuld solve the problem is that the frame setting misses the proper "Default" value for its frame color. When inserted, no special color is applied to the frame but the frame color is used. You can see this by changing the Main Text color (in Document Settings > Colors). If the default is changed to, say, red, the box gets that color in the output but still has "black" as frame color in the settings. Worse, once one changes the color in the frame settings to, say, blue, it is impossible to get the default behavior back since when switching back to "black", it is explicitly applied. Daniel Filed as #12921. (Hopefully with a better description than here.) Daniel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Boder of Frame inset not visible in dark mode
On 2023-09-24 22:24, Dan wrote: Hello, PROBLEM There is a frame whose outline is not visible in dark mode because it is black (Insert > Frame > Simple Frame). The box inset name is "Boxed" (https://www.lyx.org/trac/browser/lyxgit/lib/layouts/stdinsets.inc#L504). See the attached image for a showcase of all the frames showing the problem. EXPECTED BEHAVIOUR === Simple Frame Box should have the same outline colour as the other frames. A bug here that wpuld solve the problem is that the frame setting misses the proper "Default" value for its frame color. When inserted, no special color is applied to the frame but the frame color is used. You can see this by changing the Main Text color (in Document Settings > Colors). If the default is changed to, say, red, the box gets that color in the output but still has "black" as frame color in the settings. Worse, once one changes the color in the frame settings to, say, blue, it is impossible to get the default behavior back since when switching back to "black", it is explicitly applied. Daniel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Deleting outline entry
On 2023-09-23 21:09, Daniel wrote: On 2023-09-23 18:50, Dan via lyx-users wrote: Is there a way to delete an outline entry? A right-click on the entry does not offer that option and the delete key removes characters in the chapter/section title, not the chapter/section itself. I do not see any way of accomplishing this via the GUI, but it can be done by means of the command interpreter with a pair of commands. Say you want to delete section 2.2 of your document 1. Place the cursor at the title of section 2.2. 2. Issue in the command interpreter "section-select". This will select the whole section 2.2. 3. To delete the entire section, then enter this command: "char-delete-forward". This will erase the whole section. These steps work for any kind of sectioning (division of the text hierarchycally): parts, chapters, paragraphs, etc. You could even customize your UI file to bind these pair of commands to a button in the toolbars. I was about to suggest to add a "Delete Section" menu entry to the TOC context menu. But that doesn't work for some reason and I am not sure why. In any case, such a (working) menu entry should probably be available. Daniel Maybe there is some kind of cursor update missing after the "section-select" command? command-sequence section-select;char-delete-forward apparently works fine when the cursor is already in the heading but not when executed merely from the context-menu. Daniel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Highlighted math in dark mode is hard to see
On 2023-09-23 20:09, Scott Kostyshak wrote: On Sat, Sep 23, 2023 at 07:34:29PM +0200, Dan wrote: You mean to change the math color without selection also? Perhaps. I'm new to dark theme, so I don't know. I do really like the current math color; it's just the selection issues. Scott Definitely the "math text" colour is pretty nice, but I think it is easier (and less prone to create more problems if more things are added in the future) to change it over the "selection" colour. That said, I have checked all the colours and made some tests: the only possible problem I see of modifying "selection" colour is selecting changes made by the first author (Change Tracking on), which shows poor contrast, but is still readable. The rest of the colours, either give enough contrast, have a background that prevents contrast problems (labels, cross-references, index entries, etc.) or the text selected changes to "selected text" (black); thus not arising a contrast problem with "selection" colour. So changing the colour "selection" is a sensible option too. Hope this helps to whoever have to make the decisions. That definitely helps, thanks. Let's see if others have thoughts. Is there a reason why the "selected text" color is not applied to maths? Changing that would solve the problem since this color is visible on a "selection" background. (I guess that is its point.) Daniel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Enable "Track changes" from the toolbar
Currently, it is really cumbersome to enable "Track changes" from the toolbar since it is impossible to start "Track changes" without changing the toolbar visibility settings. What one has to do in order to enable "Track changes" from the toolbar (and not make any changes to the toolbar visibility): 1) Click on the "Show review toolbar" button (not exactly aptly named) 2) Set the visibility of the Review toolbar to "On" 3) Enable "Track changes" 4) Click on the "Show review toolbar" button 5) Set the visibility of the Review toolbar to "Automatic" IMO, this is way to cumbersome and easy to forget to change back the visibility of the toolbar. Instead, I suggest that there should be just a button to turn "Track changes" on. This will also show the toolbar (already implemented). Bug: https://www.lyx.org/trac/ticket/12696 Daniel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Next Release?
On 2023-08-29 13:16, Pavel Sanda wrote: On Mon, Aug 28, 2023 at 08:49:30PM -0400, Richard Kimberly Heck wrote: Options are, we postpone this for 2.4.1 as this is not fileformat change. If deemed too dangerous, we can temporarily disable the feature and enable it again with the safeguards, your call here. Can you remind me where all this stands? Was there a bug for this? Not bug, just the recent thread on ML. The situation as I see it: 1) There seems to be consesus that: - we should ask the user by dialog before launching a) hyperlinks b) citation urls from bib file c) lyxpaperview searches. - the dialog should have "don't ask me again" option remembered per file - the dialog should explicitly contain URL/link itself 2) There is hesitation whether to have general RC variable to disable the dialog above in general. 3) Either add security warning (tooltip?) to Control>Search drive for cited files or move the whole checkbox to Converters>Security and make it obvious that way The move itself makes more sense in case we go for 2 to group everything on one spot. The immediate security concern is covered by 1. 2 can be added later or never. 3 is disabled by default and hint can be added later as well. Pavel I am wondering whether the "don't ask me again" choice should be remembered per document only for the current session. I think VC Code does this. Maybe since across session settings seem to be tricky to undo. Does that make sense? Or would that be too annoying? Daniel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Icon "padding"
On 2023-08-27 00:45, Christopher Menzel wrote: LyX folk: There is a significant difference in the "padding" around the icons in 2.4.0-beta3 compared to 2.3.7. The difference is particularly stark when comparing 2.3.7 under MacOS <https://www.dropbox.com/scl/fi/8ygwtjmy07rd371bg5dpf/Screen-Shot-2023-08-26-at-5.25.51-PM.png?rlkey=eklvvbknbvgz4poa28af2r44d=0> and 2.4.0-beta3 under Linux <https://www.dropbox.com/scl/fi/p9sjibjq3o2bwaan9g76o/Screen-Shot-2023-08-26-at-5.28.05-PM.png?rlkey=ly2set6q7om16t8f3pcq7iyh8=0> (although there is still a pronounced difference between the MacOS versions); click the preceding links for screenshots — in both cases the icon size is set to "Normal". To my eye, there is way too much padding in the beta, and the 2.3.7 MacOS version gets it about right and I can't help but think that most folks would agree, at least with regard to the excessiveness of the padding in the beta. Is this something that might be addressed before the public release? Thanks. Chris Menzel Hi Chris, Didn't manage to reproduce your case. Did you use your screen in horizontal mode? (Reminds me that these toolbars seem way to long and are non-modular.) But as far as I can see, it is actually not a padding, but there are buttons that have an arrow on the side that makes additional features accessible. This arrow takes some space which makes the toolbar look less nice in horizontal mode, I agree. But I don't think much can or will be done about it. There are a couple of ways to change the style of these buttons on the user's side in order to make the toolbar less wide again. I was hoping that I can refer you to a documentation but I didn't manage to find it. If you are interested, I can look into it. Best, Daniel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Policy for opening url links in documents
On 2023-08-16 20:33, Scott Kostyshak wrote: On Wed, Aug 16, 2023 at 06:30:38PM +0200, Daniel wrote: On 2023-08-16 16:35, Pavel Sanda wrote: Hi, as a part of #12878 Stephan raised a question to what degree should we allow opening external links which are part of citation in the document (or rather part of .bib file). Currently we allow opening links stored in the "url" field of bibtex entry or files stored in "file" field by entry in the context menu; what's worse we don't show the link, so one can not check url itself - malevolent url can be provided (e.g. attacker web site, or maybe url scheme trying to execute some local stuff). (We also allow similar thing for hyperlink insets, but we at least show the target in caption of the inset.) Now what are your opinions what we should do about it? 1) nothing. 2) add dialog before launching url. safer but super annoying. 3) add dialog before launching url + dont ask again checkbox. not implemented - we'll also need to add session keys, which get erased often. 4) add link target to context menu (non trivial to implement) 5) add (by default disabled) checkbox in security preference to allow opening links for citations and hyperlinks similarly as we do with scripts. 6) ? I tend to go for 5, but there might be other options I did not think of... FWIW, I have seen only 1, 2 and 3 implemented in other applications when launching external URLs but none of the others. A possible 6) Per document enabling: when there are external URLs in a document that could be opened, a message appears at the top asking whether the document should be trusted in that respect. It's similar to how VS Code asks whether to enable extensions for a document. Not sure whether I like myself. I think Daniel is talking about: Document > Settings > Format > Output > "Allow running external programs" No, I wasn't aware of that option's existence and still don't know what it does. :) Not sure where the misunderstanding is though. Daniel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Policy for opening url links in documents
On 2023-08-16 16:35, Pavel Sanda wrote: Hi, as a part of #12878 Stephan raised a question to what degree should we allow opening external links which are part of citation in the document (or rather part of .bib file). Currently we allow opening links stored in the "url" field of bibtex entry or files stored in "file" field by entry in the context menu; what's worse we don't show the link, so one can not check url itself - malevolent url can be provided (e.g. attacker web site, or maybe url scheme trying to execute some local stuff). (We also allow similar thing for hyperlink insets, but we at least show the target in caption of the inset.) Now what are your opinions what we should do about it? 1) nothing. 2) add dialog before launching url. safer but super annoying. 3) add dialog before launching url + dont ask again checkbox. not implemented - we'll also need to add session keys, which get erased often. 4) add link target to context menu (non trivial to implement) 5) add (by default disabled) checkbox in security preference to allow opening links for citations and hyperlinks similarly as we do with scripts. 6) ? I tend to go for 5, but there might be other options I did not think of... FWIW, I have seen only 1, 2 and 3 implemented in other applications when launching external URLs but none of the others. A possible 6) Per document enabling: when there are external URLs in a document that could be opened, a message appears at the top asking whether the document should be trusted in that respect. It's similar to how VS Code asks whether to enable extensions for a document. Not sure whether I like myself. Daniel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Breakdown of remaining 2.4 bugs
On 2023-07-27 16:13, Pavel Sanda wrote: * Mac bugs: #12279, #12820, #12418 - all point to probably the same issue; major, but it's the same with 2.3.x; we have no clue and manpower ATM There may be still ways to do better or worse here. After a brief testing, I can reproduce a clicking problem on macOS 11.7.9 (BigSur) with - LyX 2.4.0-beta3 (Qt 15.5.10) But I cannot reproduce with - LyX 2.3.7 (Qt 15.5.7) - LyX 2.4.0-beta2 (Qt 6.4.1) Daniel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Breakdown of remaining 2.4 bugs
On 2023-08-12 11:17, Daniel wrote: On 2023-07-28 17:46, Richard Kimberly Heck wrote: On 7/28/23 04:21, Pavel Sanda wrote: On Thu, Jul 27, 2023 at 11:26:09PM -0400, Richard Kimberly Heck wrote: #12577 - complex code to improve source editor within LyX; only JMarc tried to understand and failed; anyone wants to engage? This is too big for 2.4.0. I've retargeted to 2.4.1. But I'm not really sure about it. I'll have a look at it between now and then. For this particular case I think the question whether we *want* feature. In other words do we want to guarantee support and bugfixing the code we don't understand ourselves? :) Yes, I think that question has been raised before: Is it worth it essentially to embed a code editor in LyX when we can edit externally now? I hate not to use something that so much work went into, but this is a good example of why it's bad to code first and design second. I don't get the code first, design second thing because being able to edit externally was possible before I started to work on that. So, obviously, I took that into consideration (see below). I think it is more about asking the developers whether they like such a feature or not. I provided some opportunity for this, including on the list. But don't worry about my feelings or the work that went into. As I have said before, I will use my patches locally anyway. But it seems like a good idea for a couple of reasons. Yes, it is true that one can use an external editor. But for small edits, such as commenting out a part of the code, this seems to be unnecessary cumbersome. This patch is not supposed to substitute a full blown editor. It is really just to provide minimal help for small edits. Otherwise, why not just remove any possibility of editing of code inside LyX? I don't think it's a good idea because, for example, the external editing feature is too cumbersome for this. But the reasoning against the patch presented above seems to lead there. Another reason is that to get support for commenting out of LyX's own layout code is nothing that someone who is not a code editor specialist will be able to accomplish easily. And I think it should not be taken for granted that (almost) all LyX users are code editor wizards. In summary, I think there will always be people that prefer to edit code inside of LyX, at least sometimes. And for those some *minimal* code editing support is very helpful. Daniel I forgot about the support and bugfix part: It surprises me a bit that no one understands the code since there is stuff that is much harder to understand in LyX. But in any case, I have been around for ages now. I am not going anywhere. So, I don't understand why you don't leave support and bugfixes for a part of LyX that is really isolated from other parts and has only effects that are immediately visible, i.e. there are no non-obvious effects when the user is using the feature, to someone else then (even if that person is not strictly a member of "we"). -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Breakdown of remaining 2.4 bugs
On 2023-07-28 17:46, Richard Kimberly Heck wrote: On 7/28/23 04:21, Pavel Sanda wrote: On Thu, Jul 27, 2023 at 11:26:09PM -0400, Richard Kimberly Heck wrote: #12577 - complex code to improve source editor within LyX; only JMarc tried to understand and failed; anyone wants to engage? This is too big for 2.4.0. I've retargeted to 2.4.1. But I'm not really sure about it. I'll have a look at it between now and then. For this particular case I think the question whether we *want* feature. In other words do we want to guarantee support and bugfixing the code we don't understand ourselves? :) Yes, I think that question has been raised before: Is it worth it essentially to embed a code editor in LyX when we can edit externally now? I hate not to use something that so much work went into, but this is a good example of why it's bad to code first and design second. I don't get the code first, design second thing because being able to edit externally was possible before I started to work on that. So, obviously, I took that into consideration (see below). I think it is more about asking the developers whether they like such a feature or not. I provided some opportunity for this, including on the list. But don't worry about my feelings or the work that went into. As I have said before, I will use my patches locally anyway. But it seems like a good idea for a couple of reasons. Yes, it is true that one can use an external editor. But for small edits, such as commenting out a part of the code, this seems to be unnecessary cumbersome. This patch is not supposed to substitute a full blown editor. It is really just to provide minimal help for small edits. Otherwise, why not just remove any possibility of editing of code inside LyX? I don't think it's a good idea because, for example, the external editing feature is too cumbersome for this. But the reasoning against the patch presented above seems to lead there. Another reason is that to get support for commenting out of LyX's own layout code is nothing that someone who is not a code editor specialist will be able to accomplish easily. And I think it should not be taken for granted that (almost) all LyX users are code editor wizards. In summary, I think there will always be people that prefer to edit code inside of LyX, at least sometimes. And for those some *minimal* code editing support is very helpful. Daniel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: What is missing for LyX 2.4?
On 2023-06-24 12:18, Daniel wrote: On 2023-05-29 08:01, Daniel wrote: On 2023-05-04 12:39, Stephan Witt wrote: Am 04.05.2023 um 11:35 schrieb Jean-Marc Lasgouttes : Le 04/05/2023 à 03:39, Richard Kimberly Heck a écrit : The big issue is the OSX shortcut bug, which I'm still not clear about. I don't think anything else is a must-have. This one can be solved for now by building with Qt5, right? Yes, that’s my plan. Is there anything good enough on Qt6 for macOS that makes this a bad option? I don’t think so. The only bad thing is to not switch major Qt release with „major“ LyX release. Qt 5 has some strange graphical glitches on macOS. For example, suddenly appearing colored lines between tabs. It's not great but I guess there is not much of an alternative. Daniel Also, the button click issues may be related to the Qt version: Ticket #12279, #12418, #12820. It is not clear what the cause is, but it might be good flagging the possibility. Daniel Furthermore, there bug where when one double-clicks on word and instead of selecting the whole word, only the part up to the cursor gets selected. That is quite annoying. And it is a general Qt thing, because it also happens in normal text fields. Wasn't that bug fixed in Qt 6? Daniel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Joining newlines in paste
On 2023-07-28 13:46, Scott Kostyshak wrote: On Thu, Jul 27, 2023 at 10:28:51PM -0400, Richard Kimberly Heck wrote: On 7/27/23 12:07, Pavel Sanda wrote: On Thu, Apr 22, 2021 at 12:38:32PM -0400, Scott Kostyshak wrote: On Tue, Apr 20, 2021 at 12:15:56AM +0200, Dr Eberhard W Lisse wrote: On 2021-04-19 14:47 , Christoph Schmitz wrote: Am 19.04.2021 um 14:43 schrieb Daniel : On 10/4/21 16:07, Mario D wrote: Paul, Ctrl+Shift+V works just fine for me, thanks! My fault, and I beg your pardon for this, for not having tried the relative option in "Edit -> Paste Special" : I just tried the "Paste from LaTeX", which doesn't work in my case (I am pasting tikz figures, so @rich: I was referring to the second option). Thank you everybody. :) Actually, I am wondering whether preserving newlines should be the default. I don't think one can expect that the default paste command changes the format that way. Instead the "special" option should be paste with removing newlines, I think. -- Daniel [...] I want to second this proposal! I do not know how much work it would be to create a new setting, which would allow users to use whatever method they prefer. If I have to chose between the two options, Daniel's proposal is my preference. Chris Me three :-)-O I also get confused by this and I think new LyX users are especially confused. I also vote for considering a change of the default behavior. Dear all, this is one of my last items on the TODO list for the 2.4 release. Bunch of people expressed their opinion that our default for paste operation should preserve newlines. I do not have strong opinion but agree that in my experience I have to go to Paste Special sub menu quite often to preserve the newlines. Before looking what would need change, is there reasonable unanimous agreement that this should be the default or are there folks who prefer current behaviour which joins the lines by default? I agree that the default should be to preserve newlines. +1 Scott +1 One thing I am wondering about is whether if this change is made, the shortcut Ctrl+Shift+V should be re-assigned to pasting with joined lines (old behaviour). Daniel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Windows Dark Mode and "fusion" style
On 2023-07-05 09:43, Yu Jin wrote: Am Di., 4. Juli 2023 um 15:42 Uhr schrieb Pavel Sanda: On Tue, Jul 04, 2023 at 10:55:14AM +0200, Yu Jin wrote: > Am Di., 4. Juli 2023 um 10:40 Uhr schrieb Jürgen Spitzmüller: > > > Am Dienstag, dem 04.07.2023 um 10:33 +0200 schrieb Yu Jin: > > > How do you switch on Linux/MacOS? Or does it just follow the system > > > setting? > > > > It follows the system settings unless you use a dark style via cl > > switch. On linux systems where desktop manager does not do it automatically, you can use (in case of QT 5) qt5ct tool to set it up. E.g. you select fusion style and "darker" (or any other you might like) color scheme. Then before running lyx you set the environment variable QT_QPA_PLATFORMTHEME=qt5ct and that should work (tested on oldstable debian). > What if we make "fusion" style default on windows then? That would make > LyX's behavior the same as on Linux and MacOS. Given that you are now the principal maintainer of the windows port I think that's up to you to decide. Advantage of fusion is that it will look the same across platform disadvantage might be that it looks less native to windows than other apps on your desktop? Actually Qt blog says that "their" preferred style on Windows is fusion ¯\_(ツ)_/¯. So would that be something we want to set on all platforms? or only Windows? I attached 2 patches accordingly, the style can be overwritten by the user through command line arguments as before. Which one should I push? -- Eugene IMO, the way to go is to have a setting in Preferences, User Interface that lets the user choose the style (which is then applied after a restart of LyX). A simple combobox that let's one choose between the styles which can be queried from QStyleFactory::keys(). This would be good to have on both Windows and macOS. Maybe the default should still be the default native style on both systems since it provides the most native look and feel? But one could then optionally choose the fusion style (among others). On Windows, this would apparently offer dark mode support. On macOS, one could get around a buggy native style if wanted (e.g. remember the time when labels on tabs disappeared and the still blue lines between tabs with Qt 5). I am ignorant about Linux. Daniel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: What is missing for LyX 2.4?
On 2023-05-29 08:01, Daniel wrote: On 2023-05-04 12:39, Stephan Witt wrote: Am 04.05.2023 um 11:35 schrieb Jean-Marc Lasgouttes : Le 04/05/2023 à 03:39, Richard Kimberly Heck a écrit : The big issue is the OSX shortcut bug, which I'm still not clear about. I don't think anything else is a must-have. This one can be solved for now by building with Qt5, right? Yes, that’s my plan. Is there anything good enough on Qt6 for macOS that makes this a bad option? I don’t think so. The only bad thing is to not switch major Qt release with „major“ LyX release. Qt 5 has some strange graphical glitches on macOS. For example, suddenly appearing colored lines between tabs. It's not great but I guess there is not much of an alternative. Daniel Also, the button click issues may be related to the Qt version: Ticket #12279, #12418, #12820. It is not clear what the cause is, but it might be good flagging the possibility. Daniel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Bug opening and closing insets
On 2023-06-16 10:24, Pavel Sanda wrote: On Thu, Jun 15, 2023 at 11:03:06PM +0200, R H van der Gaag wrote: (I tried to use the bug tracker, but my credentials are not recognised, having a new password sent to me fails, as does registering anew. So I???ll report this here instead.) Sent private reply. Insets open and close fine on my M1 iMac, but it???s hit and miss on my (Intel) MacBook Pro. Sometimes I will be clicking the inset ten times or more before it opens or closes: an annoying bug. Sounds related to bug #12279. BTW is this related only to LyX 2.4 or it's the same on 2.3? See also #12418. Daniel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Patches
On 2023-06-14 12:33, Scott Kostyshak wrote: On Wed, Jun 14, 2023 at 07:15:27AM +0200, Daniel wrote: Dear developers, I have decided to try to make fewer (if any) patches and rather only suggest improvements at least for now. This is driven by a number of personal factors. But also that I have made the experience that most of the patches most important to me depend highly on whether some developer finds it interesting enough to consider it carefully, in which case I think they may be willing to implement it themselves. There seems to be too little difference in whether and when the suggestion gets committed. Thanks to all of you for all your work on LyX! And good luck with the next release! Hi Daniel, Thanks for all of your work on the patches. You've put an enormous time into them, and I can understand why you're discouraged. I'm sorry I did not spend more time reviewing them. In order to reduce the time you spend on patches that might not be accepted, I strongly suggest you "check in" and ask for feedback before working on a patch. I hope you continue your involvement with LyX, in whichever way you find productive and fun. I think you provide a valuable perspective, and I can see by the progression of your patches over the years that you have achieved a good knowledge and feeling of the code base. Scott Hi Scott, Thanks! Sorry, if my message was a bit misleading. I did not try to criticize. I just wanted to state my reasons. I fully understood the risk of creating patches without asking and the time constraints the LyX developers are working on. The "check in" part, which is probably best done on the ML, seemed tricky for me since the way I discuss and argue for ideas seemed to frustrate or trigger some people on the list too much. Again, no criticism just an incompatibility that is hard to solve without more personal contact, I guess. Anyway, many patches that I just posted on trac were considered, not least thanks to you! And most of the patches I wanted to create anyway. I will try to create a (local!) fork with them. I might be able to find creating patches more productive again at some future point. Maybe in a couple of years when 2.5 is around the corner. ;) Best, Daniel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Patches
Dear developers, I have decided to try to make fewer (if any) patches and rather only suggest improvements at least for now. This is driven by a number of personal factors. But also that I have made the experience that most of the patches most important to me depend highly on whether some developer finds it interesting enough to consider it carefully, in which case I think they may be willing to implement it themselves. There seems to be too little difference in whether and when the suggestion gets committed. Thanks to all of you for all your work on LyX! And good luck with the next release! All the best, Daniel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: LyX 2.4 Again
On 2023-06-11 19:04, Richard Kimberly Heck wrote: I'm intending to build 2.4-beta3 (I guess) early this week (other obligations having been met, at last), unless there are objections. Any? Hopefully, we can move to RC1 soon after that. I don't know how it works here but there are still tickets with milestone 2.4.0: https://www.lyx.org/trac/wiki/BugTrackerHome#Unresolvedbugstargetedtonextmajorrelease2.4 Some with patches: https://www.lyx.org/trac/query?status=accepted=assigned=new=reopened=~=~=~=2.4.0=~patch=id=summary=reporter=status=type=severity=keywords=1=id I guess they should be considered (applied or re-targeted) before moving on. Daniel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Some text editing improvements that would make me forget Vim
On 2023-06-11 23:28, R. H. van der Gaag wrote: On 11 Jun 2023, at 18:57, Richard Kimberly Heck wrote: On 6/11/23 10:15, R. H. van der Gaag wrote: […] I would love to see the following text editing commands implemented: * select around a word (cursor is on a word; the command selects the word) Already possible: Just bind a key to word-select. (Double click on a word does this.) Thanks for the pointer; I didn’t know this. By the way: double-clicking often only selects part of a word on my Mac. I think this was a bug reported earlier. And I seem to remember that it has been fixed. But I am not fully sure since cannot find it just now. * select around a paragraph Same for paragraph-select. (Triple click does this.) I found commands to select backward to the beginning of the paragraph and forwards to the end, but no command that selects the paragraph the cursor is in as a whole (the way word-select works with a word). Triple-clicking selects a line, not a paragraph (or sentence) on my system. What version of LyX are you using? Paragraph-select works only in 2.4 development version yet: https://www.lyx.org/trac/ticket/9175 * find the word under the cursor (i.e. show other occurrences of the same word, by highlighting them simultaneously) There's a bug report about highlighting all matches. The 'find highlighted word' part should not be too bad. We would just need to extend word-find-* to use data from the clipboard (or to grab the current selection). Or perhaps not the selection but simply the word the cursor is in (so a separate word-select command is not needed). I agree that this is helpful (and quite common not only in vim). If I understood it correctly, the "use word under cursor" is a patch that is waiting for commit: https://www.lyx.org/trac/ticket/10235 Daniel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Allow space at beginning of (some?) insets
On 2023-06-11 18:57, Richard Kimberly Heck wrote: On 6/10/23 13:06, Daniel wrote: On 2023-06-07 16:16, Jean-Marc Lasgouttes wrote: Le 01/06/2023 à 17:42, Scott Kostyshak a écrit : I come across the example in the attachment often in various forms. It would be nice if I could insert a space at the beginning of an inset. Personally, I add the space before the branch. But I can see that it is mildly annoying. I am probably missing something here but I don't see how that is possible at the end of the sentence as in Scott's examples. Wouldn't you end up with a superfluous space before the period when deactivating the branch? Or what kind of spaces are you using? My solution is to add a protected space at the start of the inset. With text insets, you can modify them to accept 'free spacing', if you wish. Riki I was just wondering how the space "before the branch" is working. As to the possibilities you mention: wouldn't it nice if LyX allowed to insert a space at the beginning in those insets where it makes a difference without going all the way to allow free spacing? I mean, I can understand why inserting spaces at the beginning of some insets does not make sense, e.g. footnotes, because leading spaces are just swallowed there. But "free spacing" in branches seems to give the wrong impression that multiple spaces are honored, right? By the way, why is there an indentation at the beginning of the branch inset? Doesn't that give the wrong impression of some spacing? Shouldn't the first paragraph in a branch inset behave like the first paragraph in a section, i.e. not be indented, and then only the next paragraph be indented? Daniel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Allow space at beginning of (some?) insets
On 2023-06-07 16:16, Jean-Marc Lasgouttes wrote: Le 01/06/2023 à 17:42, Scott Kostyshak a écrit : I come across the example in the attachment often in various forms. It would be nice if I could insert a space at the beginning of an inset. Personally, I add the space before the branch. But I can see that it is mildly annoying. JMarc I am probably missing something here but I don't see how that is possible at the end of the sentence as in Scott's examples. Wouldn't you end up with a superfluous space before the period when deactivating the branch? Or what kind of spaces are you using? Daniel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Modernize Introduction
I just started to read the Introduction manual for the first time (I might not remember having read it before). It seems to me a bit outdated. I am not sure how many people are reading the Introduction, at least it seems that I didn't, but at least if people do, then maybe it should be modernized a bit. It is using "author"/"his" at one point. It also states that "At one time, all we had for creating documents were typewriters, so we all learned certain tricks to get around their limitations." I don't think that many people reading the Introduction these days for the first time feel included in this "we". They might not even know what typewriters are. (Despite some people still using them.) It also seems to describe an outdated "word processor". "To begin your report, you want a section called 'Introduction.' So, you go into whatever menu it is in your word processor that changes font sizes and decide on a new font size. Then you turn on bold face. Then you type, '1. Introduction'." I don't know many people who use word processors like this these days. And you could "misuse" LyX in the same way. "In LyX, you go to the pull-down on the far left of the button bar and select Section, and type 'Introduction'." This is exactly what you should do in other word processors as well, I take it. These days the outdated description of a word processor looks more like a straw man. And I don't think that people will get a good idea from reading this what advantages they get out of LyX. Daniel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: What is missing for LyX 2.4?
On 2023-05-04 12:39, Stephan Witt wrote: Am 04.05.2023 um 11:35 schrieb Jean-Marc Lasgouttes : Le 04/05/2023 à 03:39, Richard Kimberly Heck a écrit : The big issue is the OSX shortcut bug, which I'm still not clear about. I don't think anything else is a must-have. This one can be solved for now by building with Qt5, right? Yes, that’s my plan. Is there anything good enough on Qt6 for macOS that makes this a bad option? I don’t think so. The only bad thing is to not switch major Qt release with „major“ LyX release. Qt 5 has some strange graphical glitches on macOS. For example, suddenly appearing colored lines between tabs. It's not great but I guess there is not much of an alternative. Daniel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Document -> Change Tracking menu
On 2023-02-15 22:33, Scott Kostyshak wrote: On Wed, Feb 15, 2023 at 09:39:36PM +0100, Pavel Sanda wrote: Hi, we added in master new entries to the menu Document -> Change Tracking, in particular Accept All Changes (incl. Master/Children/Siblings) Reject All Changes (incl. Master/Children/Siblings) and it looks in the menu way too wide (in some translations even longer). I propose that we shorten it, though I am not sure how. Perhaps Accept All Changes (incl. linked) ? Another proposal: Accept All Changes (incl. relatives) But neither those seems very informative. What about a sub-menu? e.g., "Accept all Changes" -> "Only current doc." e.g., "Accept all Changes" -> "Incl. Master/Children/Sibling" Scott Even by the longish name, I find it a bit confusing what exactly the entry does (is it documented somewhere?). Maybe leave the entries as they have been but create a new sub-menu for the new "Master" functions: Master -> Accept All Changes Master -> Reject All Changes Then show an dialog that allows the user to make an informed decision. Having to deal with a dialog seems to be no problem since this function does not have to be executed often. Or instead Master/Children/Siblings -> Accept All Changes Master/Children/Siblings -> Reject All Changes I also noticed that the menu "Change Tracking" menu misses the "Next Change" entry. Daniel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Line breaking on beta2
On 2023-02-12 14:16, Jean-Marc Lasgouttes wrote: Le 12/02/2023 à 10:36, Daniel a écrit : Oddly enough I cannot. It happened while I was working on a text. (And I checked a couple of times that there was no extra space inserted.) But I seem unable to reproduce it as well. Unfortunately, I don't know what kind of context is needed for it to happen. Will let you know if it happens again. I understand how it can happen and it was probably the same with earlier versions. Please create a ticket to that I remember it. I am not sure that it will be 100% easy to solve, though. JMarc Done at https://www.lyx.org/trac/ticket/12660. Daniel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Line breaking on beta2
On 2023-02-11 18:04, Scott Kostyshak wrote: On Sat, Feb 11, 2023 at 03:35:03PM +0100, Daniel wrote: I cannot test current master for the next week, but just noticed that line breaking happens within words when there are different formats applied to parts of the word, say "*un*breakable" will break after "un" if "un" is emphasized. Maybe this has already been fixed in current master. I can't reproduce on current master. I emphasized "un" but can't seem to get a linebreak after it. Can you send a screenshot? Scott Oddly enough I cannot. It happened while I was working on a text. (And I checked a couple of times that there was no extra space inserted.) But I seem unable to reproduce it as well. Unfortunately, I don't know what kind of context is needed for it to happen. Will let you know if it happens again. Daniel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Line breaking on beta2
I cannot test current master for the next week, but just noticed that line breaking happens within words when there are different formats applied to parts of the word, say "*un*breakable" will break after "un" if "un" is emphasized. Maybe this has already been fixed in current master. Daniel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Modules excluded
On 2023-02-03 01:18, Richard Kimberly Heck wrote: On 2/2/23 17:31, Jean-Marc Lasgouttes wrote: Le 02/02/2023 à 23:12, Daniel a écrit : The problem is when the depencies/exclusion graph contains furstrated loops. Something like - one has B, which provides feature "foo" - want to insert A, which requires C - C is incompatible with B - of course the solution is to install D instead of B, because it also provides feature "foo" like B does, but how to find this solution? Automatically installing another module because it provides a certain feature seems over the top. In your case I would just go with what the user had done, i.e. tried to add A. So, ask: Add A and C and remove B? [Yes] [No] Obviously, I botched my exemple. My intention was to add the A requires the feature "foo" provided by B. I see. So in this case it would be - Add A, C and D and remove B [Yes] [No] But I guess that is tricky to implement. I can't remember who used to say this all the time---maybe it was you, JMarc---but one of the rules I learned early on here was: Don't try to outsmart the user. So my worry was along these lines: Sometimes there might be different ways to proceed, but we are going to have to choose one, but on what ground? Better to let the user figure this out. That sounds reasonable. Though my idea would be "let the user choose" (not to "choose for the user"). So, in a case of disjunctive requirements, the user could be presented with the list of possible options. But again, maybe that is too tricky. One thing we might do, though, is provide a bit more information about why certain modules can't be installed. At the moment, the Add button gets disabled, and there is information in the description of what it excludes and requires. But maybe it would help to add to the tooltip, say: "Cannot be added because it conflicts with..." or "...because it depends upon module X...". Something felt oddly cumbersome when playing around with the theorems modules. I haven't used them for a while, so I felt like a new user would be a bit perplexed too. Also, I had to scroll the description in order to see the requirements and exclusions. But I guess if one has used it a couple of times, in particular the same combinations, it feels rather easy. I am not sure I would be inclined to expect a helpful tooltip on a disabled button. I guess excluded modules and modules with unsatisfied requirements could be grayed out with "(unsatisfied req.)" and "(excluded)". (We only have grayed out with "(missing req.)" for missing package requirements so far.) So, one would get direct information in the list, and also when something becomes or ceases to be available due to the user's action. It will give the user a better feel for what is happening in the module dialog, I think. Daniel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Modules excluded
On 2023-02-02 22:26, Jean-Marc Lasgouttes wrote: Le 02/02/2023 à 17:42, Daniel a écrit : If I understood it correctly, the case is: - Want to add: A - Already added: C, D - A depends on B - B excludes C - C depends on D LyX suggests: Add B and remove C? [Yes] [No] But probably it is the implementation that would be the issue. The problem is when the depencies/exclusion graph contains furstrated loops. Something like - one has B, which provides feature "foo" - want to insert A, which requires C - C is incompatible with B - of course the solution is to install D instead of B, because it also provides feature "foo" like B does, but how to find this solution? Automatically installing another module because it provides a certain feature seems over the top. In your case I would just go with what the user had done, i.e. tried to add A. So, ask: Add A and C and remove B? [Yes] [No] Then the user can chose [Yes] and install manually D. But I don't think the automatic part is useless just because it does not automatically install D. But maybe you had another case in mind? (I don't know what a frustrated loop is.) My idea was just to suggest the necessary parts for the user's action (clicking "Add"). Daniel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Modules excluded
On 2023-02-02 17:29, Richard Kimberly Heck wrote: On 2/2/23 08:49, Daniel wrote: Some modules exclude other modules. I took this to be a symmetric relationship. However, for example, compare AMS Theorems: "Modules excluded: Standard Theorems and Standard Theorems (Unnumbered)." and AMS Theorems (Numbered by Type): "Modules excluded: Standard Theorems, Standard Theorems (Unnumbered), *AMS Theorems*, and Standard Theorems (Numbered by Type)." Yes, it should be symmetric. Also, has the feasibility of automatic inclusion/exclusion been considered? I mean: when a module A is added and another module B is incompatible/a dependency, then the user is asked whether B should be removed/added in order to add A. At present, you can't add incompatible modules, or ones that have unsatisfied dependencies. It would be helpful to do it the way you suggest, but this could get very messy (too messy) in some cases. E.g., someone wants to add a module that has unsatisfied dependencies, and those dependencies exclude some module already installed, which itself was a dependency for some other module. I don't think we want to do that automatically, or even suggest it. Riki I am not fully sure whether the problem is in the implementation or the usefulness? Your last sentence sounds a bit like the latter is the case. I think, in your example case it would be particularly useful to have an automatic removal because it would be so hard to figure the dependencies out by oneself. If I understood it correctly, the case is: - Want to add: A - Already added: C, D - A depends on B - B excludes C - C depends on D LyX suggests: Add B and remove C? [Yes] [No] But probably it is the implementation that would be the issue. Daniel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Modules excluded
Some modules exclude other modules. I took this to be a symmetric relationship. However, for example, compare AMS Theorems: "Modules excluded: Standard Theorems and Standard Theorems (Unnumbered)." and AMS Theorems (Numbered by Type): "Modules excluded: Standard Theorems, Standard Theorems (Unnumbered), *AMS Theorems*, and Standard Theorems (Numbered by Type)." Is that a mistake or have I misunderstood what "Modules excluded" means? Also, has the feasibility of automatic inclusion/exclusion been considered? I mean: when a module A is added and another module B is incompatible/a dependency, then the user is asked whether B should be removed/added in order to add A. Daniel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Translation with variables
On 2023-01-31 11:13, Jean-Marc Lasgouttes wrote:
Le 31/01/2023 à 11:02, Daniel a écrit :
How do I make a string with a variable translatable?
Say in English I have
"Press " + X + " to find."
But for a translation to other languages it might not be sufficient to
translate "Press " and " to find." and string them together in the
same way as in English. So, maybe it is not sufficient to do:
_("Press ") + X + _(" to find.")
Or is it up to the translator to figure this out (maybe the added
spaces are an indication for there being a particular context)?
Use bformat(). Random example:
docstring s = bformat(_("The document class `%1$s' "
"could not be loaded."), from_utf8(argument));
JMarc
Thanks!
Daniel
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Translation with variables
On 2023-01-31 11:02, Daniel wrote:
How do I make a string with a variable translatable?
Say in English I have
"Press " + X + " to find."
But for a translation to other languages it might not be sufficient to
translate "Press " and " to find." and string them together in the same
way as in English. So, maybe it is not sufficient to do:
_("Press ") + X + _(" to find.")
Or is it up to the translator to figure this out (maybe the added spaces
are an indication for there being a particular context)?
Daniel
Okay, I think I can express it in a way that avoids the issue which is
probably preferable. But anyway, it would be interesting to know.
Daniel
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
Translation with variables
How do I make a string with a variable translatable?
Say in English I have
"Press " + X + " to find."
But for a translation to other languages it might not be sufficient to
translate "Press " and " to find." and string them together in the same
way as in English. So, maybe it is not sufficient to do:
_("Press ") + X + _(" to find.")
Or is it up to the translator to figure this out (maybe the added spaces
are an indication for there being a particular context)?
Daniel
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Update lyx-2.4 docs
On 2023-01-29 17:37, Jürgen Spitzmüller wrote: Am Sonntag, dem 29.01.2023 um 17:23 +0100 schrieb Jean-Pierre Chrétien: I would like to search easily what has been updated since (but for the new index features that I have already updated in the UserGuide). Is it possible to search for modifications after a given date in the documents ? I could search for changes in Trac, but is is quite lengthy. Document > Track Changes > Accept and Reject Changes. This dialog has the change dates (not ideal for sure). I am curious, since I don't have an entry named "Accept and Reject Changes". Did you mean "Merge Changes..."? Daniel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: LyX 2.4.0-beta2; zoom slider
On 2023-01-27 07:30, Jürgen Spitzmüller wrote: Am Mittwoch, dem 25.01.2023 um 19:26 +0100 schrieb Daniel: Anyway, for system default, there is a solutions that seem compatible with your position: Set the system default to 100% (and even better make the system default so that it matches the actual size of the font). There was a discussion about this on the list if I remember correctly. 100% is way too low on all Linux system I have used. This is not a good default. Ah, that was poor explanation on my side. I meant: whatever LyX considers the correct system default, say 150% on macOS, make that show up as 100%. Anyway, I also think the scaling factor alternative is better since it can satisfy more needs (for people who use a different default zoom). Daniel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Limit text width in the editor window (non-fullscreen mode)
On 2022-10-31 08:36, Daniel wrote: On 24/10/2022 00:15, Christopher Hillenbrand wrote: Dear LyX developers, Here's a patch for adjusting editor text width in windowed mode (see ticket https://www.lyx.org/trac/ticket/9376). It's an adaptation of the previous patch uploaded by stwitt (two years ago). Please try it out when you get a chance! Since I couldn't access the true screen DPI from within prefs2prefs.py, this patch removes the old settings \fullscreen_width and \fullscreen_limit rather than hardcoding a default DPI value. But if you think a different approach would be preferable, I'd be happy to change it. Best regards, Christopher Well done! Thanks for pushing the patch over the commit line. Best regards, Daniel ps. Wikipedia's reasoning behind the change: https://www.mediawiki.org/wiki/Reading/Web/Desktop_Improvements/Features/Limiting_content_width -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Limit text width in the editor window (non-fullscreen mode)
On 2022-10-24 00:15, Christopher Hillenbrand wrote: Dear LyX developers, Here's a patch for adjusting editor text width in windowed mode (see ticket https://www.lyx.org/trac/ticket/9376). It's an adaptation of the previous patch uploaded by stwitt (two years ago). Please try it out when you get a chance! Since I couldn't access the true screen DPI from within prefs2prefs.py, this patch removes the old settings \fullscreen_width and \fullscreen_limit rather than hardcoding a default DPI value. But if you think a different approach would be preferable, I'd be happy to change it. Best regards, Christopher By the way, LyX is in good company with this patch: "Line width and font size Wikipedia articles will now have a maximum line width, which supports a more comfortable reading experience and better retention of the content. The default font-size has also been increased to make reading long paragraphs more comfortable. (4/9)" (https://twitter.com/Wikipedia/status/1615756196820168705) Maybe time for making the limited line width the new default (at least after it has been tested thoroughly)? :) Best regards, Daniel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: LyX 2.4.0-beta2; zoom slider
On 2023-01-25 19:26, Daniel wrote: On 2023-01-25 18:00, Jürgen Spitzmüller wrote: Am Mittwoch, dem 25.01.2023 um 17:02 +0100 schrieb Daniel: I cannot reproduce with preview beta2. When clicking on +/-, I get steps of 15%. Given that the (system) default is 150%, Well, 15% is 10% of 150%. I cannot get to 200% that way. You need to set default zoom to either 100% or 200% to achieve that. Also, once one has used the slider, one cannot get "round numbers" anymore. I suggest to change it to how Word does it: the + and - buttons always get you to "round numbers" with steps of 10%. Then, for example, you can get fast to a certain point by using the slider and then adjust to a round number with +/-. This does not make sense to me, as you'd get a smaller range with 200% default zoom that way. The larger the default, the larger the steps. 20% jumps make perfect sense to me on my setting with 200% default zoom. Word does not have the concept of an adjustable default zoom AFAIK. They always have 100% as mean value. Same for Libre. It might not make sense to you but now you know that it does to some people who are using not 100% or 200% zoom default and rather, say, 150% like the system default (at least on macOS). Anyway, for system default, there is a solutions that seem compatible with your position: Set the system default to 100% (and even better make the system default so that it matches the actual size of the font). There was a discussion about this on the list if I remember correctly. That leaves people who are not happy with system default in the rain. You would lose round numbers that way, but I guess that is acceptable to you if you are consistent. Alternatively, just name whatever is set as the default 100%? Daniel And in order to not confuse users about different percentages, we would call the "Default zoom %" just "Font scaling %" or so. It's already in the Preferences font section anyway between fonts and font sizes, so the user will make the connection easily. So, the default zoom will always be 100% but the default font scaling can differ. This makes 10% increases round numbers. This will also make setting the font scaling to something more reasonable appear less strange. For example, on macOS the default zoom is currently 150% while something closer to 152% is a better representation of the actual font size on screen. We can calculate the exact number from the DPI of the display and set it as system defaut and also provide a "Reset to system default" button next to the "Font scaling %". If the approach sounds reasonable, and no one else wants the job, I can prepare a patch. Daniel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: LyX 2.4.0-beta2; zoom slider
On 2023-01-25 18:00, Jürgen Spitzmüller wrote: Am Mittwoch, dem 25.01.2023 um 17:02 +0100 schrieb Daniel: I cannot reproduce with preview beta2. When clicking on +/-, I get steps of 15%. Given that the (system) default is 150%, Well, 15% is 10% of 150%. I cannot get to 200% that way. You need to set default zoom to either 100% or 200% to achieve that. Also, once one has used the slider, one cannot get "round numbers" anymore. I suggest to change it to how Word does it: the + and - buttons always get you to "round numbers" with steps of 10%. Then, for example, you can get fast to a certain point by using the slider and then adjust to a round number with +/-. This does not make sense to me, as you'd get a smaller range with 200% default zoom that way. The larger the default, the larger the steps. 20% jumps make perfect sense to me on my setting with 200% default zoom. Word does not have the concept of an adjustable default zoom AFAIK. They always have 100% as mean value. Same for Libre. It might not make sense to you but now you know that it does to some people who are using not 100% or 200% zoom default and rather, say, 150% like the system default (at least on macOS). Anyway, for system default, there is a solutions that seem compatible with your position: Set the system default to 100% (and even better make the system default so that it matches the actual size of the font). There was a discussion about this on the list if I remember correctly. That leaves people who are not happy with system default in the rain. You would lose round numbers that way, but I guess that is acceptable to you if you are consistent. Alternatively, just name whatever is set as the default 100%? Daniel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: LyX 2.4.0-beta2; zoom slider
On 2023-01-25 07:53, Jürgen Spitzmüller wrote: Am Mittwoch, dem 25.01.2023 um 09:43 +1300 schrieb Andrew Parsloe: The urge to get a round number like 150 or 200 is strong, almost compulsive, but fiddly with the slider requiring multiple attempts. The zoom slider values are relative to the zoom you have set in Preferences > Look & Feel > Screen Fonts. If you set that to 200% (or 100%), you'll get round numbers. Otherwise you get steps of 10% from the default. I cannot reproduce with preview beta2. When clicking on +/-, I get steps of 15%. Given that the (system) default is 150%, I cannot get to 200% that way. Also, once one has used the slider, one cannot get "round numbers" anymore. I suggest to change it to how Word does it: the + and - buttons always get you to "round numbers" with steps of 10%. Then, for example, you can get fast to a certain point by using the slider and then adjust to a round number with +/-. Daniel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: ESC Key
On 2023-01-23 00:29, Richard Kimberly Heck wrote:
On 1/22/23 10:36, racoon wrote:
On 2023-01-22 13:44, Daniel wrote:
On 2023-01-22 10:25, Evan Langlois wrote:
Is there some way to reconfigure LyX to not have ESC cancel a dialog
or at least ask me first? I tried to remove the keybinding for esc in
the preferences, but that didn't help. The issue is that I use vi, so
when editing the preamble my hand just hits the esc key to save out of
habit. All my changes are then gone without a "Hey you changed stuff!
Are you sure?"
I don't think there is a way. And I am not sure it is a common enough
case to allow for a preference or so.
But it sounds like you would be satisfied with LyX asking whether to
discard changes made to the preamble before cancelling the dialog. I
think that is generally a good idea. After all, it is like editing your
document where we also don't just let the user close the window without
asking.
Daniel
Attached is a simple patch that avoids the dialog being closed when the
Esc key is pressed. The patch presupposes the source code patch to
ticket #12577 (https://www.lyx.org/trac/ticket/12577).
As suggested above, at least additionally, there should also be a
warning when source codes where changed whether the dialog should be
closed. But that is not implemented with this patch.
Probalby the better solution is the other one you mentioned: If there
are changes, do not close without asking first. This could be
implemented quite generally, I suspect, though the GuiDialog class (and
whatever one is the other one---remember we have two parallel dialog
classes for no terribly good reason).
Riki
I guess the greatest loss is with changes in the preamble (and maybe
local layout). So, I would restrict asking for changes in that.
Otherwise, it might just be annoying.
The attached patch does that. However, I changed a function into a
virtual which made me a bit uncomfortable about possible side effects
(there are also a couple of override warnings triggered, obviously, that
haven't corrected either) since I am not fluent with these concepts.
The main challenge is to handle the cancel button, the window close
button and the escape key the same way. It seems to works well as I
implemented it. Maybe someone else could check whether it looks correct.
DanielFrom 4af7fa2c0236eaa96e361104589e59770ec34076 Mon Sep 17 00:00:00 2001
From: Daniel Ramoeller
Date: Mon, 23 Jan 2023 11:43:56 +0100
Subject: [PATCH] Ask to discard preamble
---
src/frontends/qt/GuiDialog.cpp | 17 -
src/frontends/qt/GuiDialog.h | 12 +++-
src/frontends/qt/GuiDocument.cpp | 16
src/frontends/qt/GuiDocument.h | 2 ++
4 files changed, 45 insertions(+), 2 deletions(-)
diff --git a/src/frontends/qt/GuiDialog.cpp b/src/frontends/qt/GuiDialog.cpp
index 70d086c7f8..6fe8b36ce7 100644
--- a/src/frontends/qt/GuiDialog.cpp
+++ b/src/frontends/qt/GuiDialog.cpp
@@ -37,10 +37,25 @@ GuiDialog::GuiDialog(GuiView & lv, QString const & name,
QString const & title)
}
+void GuiDialog::keyPressEvent(QKeyEvent * event)
+{
+if (event->key() == Qt::Key_Escape) {
+ // Let the esc key trigger the close event so we can handle it
uniformly
+close();
+return;
+}
+QDialog::keyPressEvent(event);
+}
+
+
void GuiDialog::closeEvent(QCloseEvent * ev)
{
+ setCloseStopped(false);
slotClose();
- ev->accept();
+ if (closeStopped())
+ ev->ignore();
+ else
+ ev->accept();
}
diff --git a/src/frontends/qt/GuiDialog.h b/src/frontends/qt/GuiDialog.h
index 160357dbc6..2d2af2be75 100644
--- a/src/frontends/qt/GuiDialog.h
+++ b/src/frontends/qt/GuiDialog.h
@@ -42,6 +42,9 @@ public:
QWidget * asQWidget() override { return this; }
QWidget const * asQWidget() const override { return this; }
+protected:
+ void keyPressEvent(QKeyEvent * event) override;
+
public Q_SLOTS:
/** \name Buttons
* These methods are publicly accessible because they are invoked
@@ -58,7 +61,7 @@ public Q_SLOTS:
// AutoApply checkbox clicked
void slotAutoApply();
// Close button clicked or closed from WindowManager
- void slotClose();
+ virtual void slotClose();
// A collectiong slot for QDialogButtonBox
void slotButtonBox(QAbstractButton *);
///
@@ -77,6 +80,9 @@ public:
// Set whether to stop the apply process
void setApplyStopped(bool stop) { apply_stopped_ = stop; };
+ // Set whether to stop the close process
+ void setCloseStopped(bool stop) { close_stopped_ = stop; };
+
/** \name Dialog Components
* Methods to access the various components making up a dialog.
*/
@@ -122,6 +128,10 @@ private:
/// stop the apply process?
bool applyStopped() { return apply_stopped_; };
bool apply_stopped_;
+
Re: ESC Key
On 2023-01-22 10:25, Evan Langlois wrote: Is there some way to reconfigure LyX to not have ESC cancel a dialog or at least ask me first? I tried to remove the keybinding for esc in the preferences, but that didn't help. The issue is that I use vi, so when editing the preamble my hand just hits the esc key to save out of habit. All my changes are then gone without a "Hey you changed stuff! Are you sure?" I don't think there is a way. And I am not sure it is a common enough case to allow for a preference or so. But it sounds like you would be satisfied with LyX asking whether to discard changes made to the preamble before cancelling the dialog. I think that is generally a good idea. After all, it is like editing your document where we also don't just let the user close the window without asking. Daniel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Lexer and optional arguments
On 2022-04-18 19:46, Jean-Marc Lasgouttes wrote: Le 18/03/2022 à 18:45, Daniel a écrit : Is it possible to have optional arguments read with Lexer? I imagine something like: Command [] So Parameter1 is necessary but Parameter2 is optional. The Lexer would only look on the same line for an optional parameter. Going back to old mails... Me too... Unfortunately, I still find the lexer stuff hard to understand. What is possible is to read one line with eatLine() and then parse it, possibly with the lexer itself. Maybe someone can give me a hint on how to create a lexer from a string that I get via eatLine()? Or do something like in Layout::readAlignPossible. So, could I alternatively just use lex.next() and still don't eat too many commands because it would be somehow reset once I use lex.popTable(), or what would be the idea? Background: I am back to getting the DynamicMenuButton to work with classic menus rather than having to hard code every menu in a cumbersome and non-customizable way. It works, but I would like to combine two different button styles: (1) a simple menu when one clicks on a button (as with Custom text styles) (2) a function on the button itself and a menu to the side (as with Paste). So, I thought about a function like this: DynamicMenuButton [] where the last argument is optional. /Daniel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
argument "-style fusion" not working on beta2
I used to be able to test the fusion style with LyX on macOS via the command: open LyX-2.4dev.app --args -style fusion That stopped working when using the development version beta2: open LyX-2.4-beta2.app --args -style fusion just shows the normal macOS style. But when I download the binary of beta2 via ftp, the argument works again. It is nice to be able to test another style when working with the qt UI. So, it would be great to get that functionality back. Daniel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Indentation and (un)commenting in local layout and preamble
On 2022-09-14 09:04, Daniel wrote: On 13/09/2022 18:27, Jean-Marc Lasgouttes wrote: Le 13/09/2022 à 16:12, Daniel a écrit : And I guess more importantly in license.rtf it says: "LyX. You can redistribute LyX and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version." That means that QtCreator can take code from LyX and use it as GPLv3 ;) JMarc Or LyX can take code from LyX. ;) Well, looks like open source isn't as open as I thought. I see a couple of possible routes to resolve this: 1) I seem to remember that it was stated in the Qt Creator code somewhere that smaller parts of the code can be used without license. So, I could check with the Qt people what they mean by smaller parts. My guess is that re-use of smaller parts would be in their interest since it gives people a source of example code that allows people to work more easily with Qt. This would also be helpful for the future since something like "look at how Qt Creator does it" often comes up. 2) Check whether a previous Qt Creator release under another license has the same or similar code. 3) Re-invent the wheel, i.e. I could start from scratch and try to come up with my own method for the (un)commenting part. Any suggestions? Daniel Went for 3 at https://www.lyx.org/trac/ticket/12577. Daniel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Master broken due to febd1855eb
With febd1855eb ("XML: overhaul the tag-comparison operators."), I get
/src/tex2lyx/dummy_impl.cpp:102:16: error: out-of-line
definition of 'operator==' does not match any declaration in
'lyx::xml::StartTag'
bool StartTag::operator==(FontTag const & rhs) const { return rhs ==
*this; }
^~~~
/src/tex2lyx/dummy_impl.cpp:103:15: error: out-of-line
definition of 'operator==' does not match any declaration in
'lyx::xml::FontTag'
bool FontTag::operator==(StartTag const & tag) const { FontTag const * c...
^~~~
Daniel
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Can I push this 20MB commit to update the format of the docs?
On 2022-12-10 14:52, Scott Kostyshak wrote: On Sat, Dec 10, 2022 at 11:48:24AM +, José Matos wrote: On Fri, 2022-12-09 at 17:11 -0500, Richard Kimberly Heck wrote: I think it's ok myself. But we could also go ahead and produce a new alpha. I can do that if you wish, when I do the 2.3.7 tarball this weekend. Riki If you do this (for 2.4) please call it beta-2 since we already have a beta-1, LyX 2.4.0-beta1 (2021-05-24). I know that this is just a detail but then later it becomes difficult to explain these idiosyncratic choices. :-) Makes sense! Scott I am surprised there is a beta1. There is none here: https://ftp.lip6.fr/pub/lyx/devel/lyx-2.4/ Where can one download it? Daniel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Line numbers
Why does the code preview, at least for Complete Source, not have line numbers? Wouldn't that be sometimes handy for tracking down LaTeX errors? Daniel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: About upgrading to MacOS 13
Le 7 déc. 2022 à 17:21, Stephan Witt a écrit : > > Am 07.12.2022 um 16:21 schrieb Daniel CLEMENT via lyx-users > : >> >> Dear list members, >> >> I have monitored last month’s threads about LyX woes under macOS 13. There >> wasn’t a definite conclusion it seems. >> >> Would you say it’s safe to upgrade to MacOS13 now (with LyX 2.3.6.2)? >> >> When I installed it, it complained about Python missing, but I somehow >> managed to get Python installed too. >> >> I’m rather new to Mac, and in no hurry at all to do the upgrade. Perhaps it >> would be best to wait for LyX 2.4? >> >> I’ll take your advice - best regards, > > Hi Daniel, > > I’m on Mojave for production as primary macOS (because I’m using Aperture > from Apple - a 32bit application w/o 64bit upgrade option!). > > I have access to a M1 system with Big Sur for development builds of LyX. I > don’t want to upgrade because I’ll loose the option to test LyX on Big Sur. > > I’ve tested LyX 2.3.6.2 on different VMs with macOS 12.x and didn’t have time > and resources to try macOS 13 yet. > > My experience is: starting with Monterey 12.3 Apple dropped the support for > Python 2.x and the upgrade from earlier versions removes it. There is a > replacement Python 3 installed as a stub and if this gets called it asks the > user to download and install the real thing from Apple. > > There is one report of having a problem after upgrade from Monterey to > Ventura (macOS 13) with Python again. I couldn’t get the information how this > happened. Probably the upgrade to Ventura breaks the installed Python 3 from > Apple. One has to reinstall it manually. > > All this is a consequence of Apples decision to pass the responsibility for a > working Python software to app developers and/or end users. So they cannot be > blamed for security problems with it, IMO. It makes no sense to include a > Python package with LyX and therefore it is ok to install either Apples or > the „official“ open-source Python for Apple on the system. It’s an open task > to detect the current situation on the users system and give more prominent > and useful advice how to proceed. > > There is another issue I’m aware of. On some systems the gatekeeper keeps > nagging and says the LyX binary is a suspicious one. Probably it’s because of > the bundle permissions, the certificate used for signing or the security > settings of users system. > > My advice would be to try the upgrade if you’re able to go back with time > machine w/o hassle. I’ll be there to answer questions and help to solve > problems. If you don’t want to risk anything I can understand it and you may > wait for the results of my experiments in a virtual machine. Another option > is to create a virtual machine yourself and try it there and contact me if > something is broken. > > Hope that helps and regards, > Stephan Thank you all for your input. I conclude that there is a risk, however little, that something _can_ go wrong. Since I cannot afford to break anything for the next months, I think I’ll play it safe and delay the upgrade. I need to learn MacOS better first. (Marcus: I didn’t even know that the downgrade relied on Time Machine…) In the meantime, there’s a couple of very minor annoyances that I cannot solve alone; I’ll ask about them in another thread. BR - Daniel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Limit text width in the editor window (non-fullscreen mode)
On 24/10/2022 00:15, Christopher Hillenbrand wrote: Dear LyX developers, Here's a patch for adjusting editor text width in windowed mode (see ticket https://www.lyx.org/trac/ticket/9376). It's an adaptation of the previous patch uploaded by stwitt (two years ago). Please try it out when you get a chance! Since I couldn't access the true screen DPI from within prefs2prefs.py, this patch removes the old settings \fullscreen_width and \fullscreen_limit rather than hardcoding a default DPI value. But if you think a different approach would be preferable, I'd be happy to change it. Best regards, Christopher Well done! Thanks for pushing the patch over the commit line. Best regards, Daniel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Limit text width in the editor window (non-fullscreen mode)
On 27/10/2022 18:12, Jean-Marc Lasgouttes wrote: Concerning the 7in default: I see in LaTeX sources that the default text width is 360pt, that is, 5in. What does the 7in come from? [I am not asking for change, I ask :)] I am not asking for change, I just answer: It came from you: https://www.lyx.org/trac/ticket/9376#comment:20 (It had to do with a pref2pref requirement you suggested. Since I wasn't able to do it back then and no one else jumped in, the original patch was never committed. Since the new patch does not take care of pref2pref either, I guess it wasn't that important after all. :) Daniel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Tutorial
I just looked at the Tutorial for the first time ever. It says: "2.1.1 Typing, Viewing, and Exporting • Open a new file with File->New • Type a sentence like: This is my first LyX document! • Save your document with File->Save As. • Create a PDF file, with Document->View or the toolbar button . LyX will open a PDF-viewer program displaying your document as it will look when printed. • Export the ready to print document with File->Export to a format you want. Congratulations! You have written your first LyX document. All of the rest is just details." Since this deviates a bit from how I use LyX, I was curious whether some explanation might be helpful. I think it could be clearer that the "Save" step is optional for viewing a document. LyX is totally fine with just viewing a temporary created document which I often find handy, in particular if I just want to try something out. So, the step might be more accurately, "• *Optionally, s*ave your document with File->Save As." Also, once the viewer shows the document, I found it handy to just use the viewer's Save feature instead of LyX's Export feature. Is that something that is not advised for some reason? While looking at the Export feature I noticed that the Export menu might be a bit intimidating for the newcomer who might not know what to choose here in order to get the desired export format, in particular if it is not advised to use the viewer for this operation. In that case, maybe the step could be explained better like "• Export the ready to print document with File->Export*->Export [PDF (pdflatex)] to the PDF format viewed in the previous step or* to a*nother* format you want." Daniel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Font size representation on macOS is off
On 2022-09-19 00:34, Jean-Marc Lasgouttes wrote: Le 01/09/2022 à 21:29, Daniel a écrit : I think we should calculate the right size ourselves for macOS as Writer does. Otherwise, it is all really confusing. See also https://apple.stackexchange.com/a/445862/377509 Either we do that, or we do as other real macOS apps do and add this "actual size" thing. I tend towards calculating the right size at 100% if possible. I think that is more fitting to a cross-platform application. Besides Writer, Firefox also sets 100% at the correct size. I do not think that the cross-platform part is relevant: LyX should feel like a macOS application on macOS. It is more important to feel right for macOS users than for users who use LyX on multiple platforms IMO. I think enabling people to seamlessly switch between OSs, say at work and at home, is a super important benefit of cross-platform applications. Also, most of the cross-platform apps I use seem to generally emphasize cross-platform consistency (e.g. Inkscape, Gimp, LibreOffice, Zotero, VS Code, Firefox, Thunderbird) over nativity. I do not think we should introduce a change that make all user have to change their setting when upgrading LyX. I don't see why people would need to change their settings. I might have misunderstood what pref2pref is though. We could change the default default zoom to be computed, though. I always wondered why LyX uses a 150% zoom by default. Now, that I know that someone might have eyeballed what the "actual size" looks like (and got it wrong by a couple of percentage points) it's just strange. And I don't think making it 153% by default will help with this strangeness. LyX shouldn't embrace macOSs strange sides. Having said that, it is just zoom we are concerned with here which is not that important, just strange. But the general point seems quite important to me. Daniel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: word-select surprise
On 2022-09-18 16:26, Scott Kostyshak wrote: On Sat, Sep 17, 2022 at 11:09:52AM +1200, Andrew Parsloe wrote: I have a command-sequence that uses word-select prior to using cut. Recently I was surprised to find the content of the *previous* item saved to the clipboard being pasted rather than the expected one. After experimenting, I think an unintuitive cursor positioning is the cause. Suppose your word is abcdefghijk. If the cursor is positioned after the k and you invoke word-select the whole word abcdefghijk is selected. Howeve if you start selecting character by character from the right (Shift + left arrow) and then after a few characters invoke word-select the selection is cancelled, leaving the cursor where it started after the k (meaning the cut operation of my command sequence had nothing to save to the clipboard). In the other direction, with cursor positioned before the a and then (Shift+right arrow) a few characters selected, invoking word-select expands the selection to the whole word. To my mind this is the behaviour I would expect also in the backward direction (as is the case in LibfreOffice). This is in 2.4.0 alpha3 on windows 10. Andrew Testing the latest master commit, I confirm the behavior you describe and I agree it should be improved. Scott I am not fully sure whether I understood the recipe. But it's the same in stable (no regression), right? Daniel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Increase max range of zoom slider?
On 2022-09-14 17:44, Scott Kostyshak wrote: I tested the zoom slider today out of curiosity and it works very smoothly. One thing I noticed is that the maximum of the range is too small for my computer/eyes. The maximum is 290. The range is set as follows: zoom_slider_->setRange(10, (lyxrc.defaultZoom * 2) - 10); Perhaps my complaint should be with lyxrc.defaultZoom. I slightly recall that we've discussed it, and even took a poll on lyx-users, but I forgot what came of that. For me, 10% is extremely small, and 290% is not that big. I know it is difficult to make it perfect for all computers/resolutions/eyes, but I'm curious about others. Is there support for increasing the upper range of the zoom slider? From a personal point of view, I don't use the slider so I don't have a strong opinion. Scott I don't think default zoom is the problem. To avoid the problem you encountered, other applications use non-linear zoom levels. For example, Word, Writer, Pages and Firefox with the former two having non-linear zoom sliders. Daniel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Indentation and (un)commenting in local layout and preamble
On 13/09/2022 18:27, Jean-Marc Lasgouttes wrote: Le 13/09/2022 à 16:12, Daniel a écrit : And I guess more importantly in license.rtf it says: "LyX. You can redistribute LyX and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version." That means that QtCreator can take code from LyX and use it as GPLv3 ;) JMarc Or LyX can take code from LyX. ;) Well, looks like open source isn't as open as I thought. I see a couple of possible routes to resolve this: 1) I seem to remember that it was stated in the Qt Creator code somewhere that smaller parts of the code can be used without license. So, I could check with the Qt people what they mean by smaller parts. My guess is that re-use of smaller parts would be in their interest since it gives people a source of example code that allows people to work more easily with Qt. This would also be helpful for the future since something like "look at how Qt Creator does it" often comes up. 2) Check whether a previous Qt Creator release under another license has the same or similar code. 3) Re-invent the wheel, i.e. I could start from scratch and try to come up with my own method for the (un)commenting part. Any suggestions? Daniel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Indentation and (un)commenting in local layout and preamble
On 13/09/2022 15:56, Daniel wrote: On 13/09/2022 12:56, Jean-Marc Lasgouttes wrote: Le 10/08/2022 à 04:15, Daniel a écrit : In the attached Qt project, I implemented those features. It probably needs some more cleaning up. But it seems to work and you could already try it out if you like. The (un)commenting feature leans heavily on code from QtCreator. (I tried to improve a bit upon it, e.g. comments are added at the deepest common indentation as in Hello Daniel, I see that QtCreator is licensed under GPLv3. Are we allowed to take code from there in our GPLv2 source? I would think that we can't. JMarc You might be mistaken: "9. The Free Software Foundation may publish revised and/or new versions of the General Public License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns. Each version is given a distinguishing version number. If the Program specifies a version number of this License which applies to it and "any later version", you have the option of following the terms and conditions either of that version or of any later version published by the Free Software Foundation. If the Program does not specify a version number of this License, you may choose any version ever published by the Free Software Foundation." (https://www.lyx.org/License) Daniel And I guess more importantly in license.rtf it says: "LyX. You can redistribute LyX and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version." Daniel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Indentation and (un)commenting in local layout and preamble
On 13/09/2022 12:56, Jean-Marc Lasgouttes wrote: Le 10/08/2022 à 04:15, Daniel a écrit : In the attached Qt project, I implemented those features. It probably needs some more cleaning up. But it seems to work and you could already try it out if you like. The (un)commenting feature leans heavily on code from QtCreator. (I tried to improve a bit upon it, e.g. comments are added at the deepest common indentation as in Hello Daniel, I see that QtCreator is licensed under GPLv3. Are we allowed to take code from there in our GPLv2 source? I would think that we can't. JMarc You might be mistaken: "9. The Free Software Foundation may publish revised and/or new versions of the General Public License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns. Each version is given a distinguishing version number. If the Program specifies a version number of this License which applies to it and "any later version", you have the option of following the terms and conditions either of that version or of any later version published by the Free Software Foundation. If the Program does not specify a version number of this License, you may choose any version ever published by the Free Software Foundation." (https://www.lyx.org/License) Daniel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: More questions about statusbar menu
On 2022-09-08 07:15, Daniel wrote:
On 2022-09-05 12:36, Jean-Marc Lasgouttes wrote:
Le 05/09/2022 à 12:26, Jean-Marc Lasgouttes a écrit :
Do as you see fit.
I did, but I have more questions now.
PS: I realize that I should have read tickets #12182 and #12187 before
posting point 3/. I do not want to initiate an endless discussion
about these things :) It is just that I noticed this while looking at
the statistics thing.
3/ The contextual menu is a weird merge of what LibreOffice and MS
Office do:
* LO: each element has its menu, the zoom menu has example values
to set (fit width, fit page, 50%, 75%, etc.), no way to tell which
statistics should be there
* MSO: only one menu with checkboxes to indicate which elements
should be shown, no way to tell which statistics should be there, no
way to set zoom from menu
* LyX one menu that does both selection of elements and zooming,
zoom in/out and reset to default (main use IMO is to learn
shortcuts), weird-looking precomputed zoom values
I understand that splitting the menu would make zoom menu unavailable
when both count and slider are off; some solution would be needed if
splitting the menus. OTOH I am not sure that the zoom menu is useful,
except maybe for the reset to default, which is not available via a
mouse click. In this respect, I like the Firefox approach, where
clicking on the zoom indicator resets zoom to default.
I don't remember that splitting menus was suggested yet at #12182 and
#12187. (Feel free to ignore my comment otherwise.) I seem to remember
that I suggested the whole status bar menu originally. Back then, there
were was only zoom options which made it rather unproblematic to show
zoom stuff on there. But now that more options were added (and probably
not the last ones), I agree that it should be split up. Further zoom
options are available in both Word and Writer by pressing the zoom
value. I suggest we just use the same (standard) mechanism. Stopping
short of creating a dialog, I suggest to just show a menu as in the
attached patch.
(By the way, setting 100% zoom to be actual zoom as suggested elsewhere
might partly help with the number strangeness - at least as long as the
default zoom is not changed.)
Sorry, slightly improved version attached. (The pressed signal was
previously also emitted on right click which interfered with the context
menu event.)
Daniel
From c5daa4cbb8c1c2191ab07877d70820572ebbf2af Mon Sep 17 00:00:00 2001
From: Daniel Ramoeller
Date: Thu, 8 Sep 2022 07:44:15 +0200
Subject: [PATCH] Disentangle status bar and zoom menu
- Moves the zoom menu to the zoom value
---
lib/ui/stdcontext.inc | 9 +++--
src/frontends/qt/GuiClickableLabel.cpp | 7 ++-
src/frontends/qt/GuiClickableLabel.h | 2 ++
src/frontends/qt/GuiView.cpp | 14 --
src/frontends/qt/GuiView.h | 4 +++-
5 files changed, 30 insertions(+), 6 deletions(-)
diff --git a/lib/ui/stdcontext.inc b/lib/ui/stdcontext.inc
index eb44a58f30..b9a23040c6 100644
--- a/lib/ui/stdcontext.inc
+++ b/lib/ui/stdcontext.inc
@@ -723,12 +723,17 @@ Menuset
Item "Giant-sized Icons" "icon-size giant"
End
+#
+# Status bar zoom context menu
+#
+ Menu "context-zoom"
+ ZoomOptions
+ End
+
#
# Status bar context menu
#
Menu "context-statusbar"
- ZoomOptions
- Separator
Item "Zoom Level|Z" "ui-toggle zoomlevel"
Item "Zoom Slider|S" "ui-toggle zoomslider"
Separator
diff --git a/src/frontends/qt/GuiClickableLabel.cpp
b/src/frontends/qt/GuiClickableLabel.cpp
index 311755d130..bad90f3b8e 100644
--- a/src/frontends/qt/GuiClickableLabel.cpp
+++ b/src/frontends/qt/GuiClickableLabel.cpp
@@ -11,7 +11,7 @@
#include "GuiClickableLabel.h"
-#include
+#include
namespace lyx {
namespace frontend {
@@ -23,6 +23,11 @@ GuiClickableLabel::GuiClickableLabel(QWidget * parent)
GuiClickableLabel::~GuiClickableLabel()
{}
+void GuiClickableLabel::mousePressEvent(QMouseEvent * e) {
+ if (e->button() == Qt::LeftButton)
+ Q_EMIT pressed();
+}
+
void GuiClickableLabel::mouseReleaseEvent(QMouseEvent *) {
Q_EMIT clicked();
}
diff --git a/src/frontends/qt/GuiClickableLabel.h
b/src/frontends/qt/GuiClickableLabel.h
index b14ba15de8..2fb4e8e25e 100644
--- a/src/frontends/qt/GuiClickableLabel.h
+++ b/src/frontends/qt/GuiClickableLabel.h
@@ -25,8 +25,10 @@ public:
Q_SIGNALS:
void clicked();
+ void pressed();
protected:
+ void mousePressEvent(QMouseEvent *) override;
void mouseReleaseEvent(QMouseEvent *) override;
};
diff --git a/src/frontends/qt/GuiView.cpp b/src/frontends/qt/GuiView.cpp
index b87b494dac..24d6703e30 100644
--- a/src/frontends/qt/GuiView.cpp
+++ b/src/frontends/qt/GuiView.cpp
@@ -
Re: More questions about statusbar menu
On 2022-09-05 12:36, Jean-Marc Lasgouttes wrote:
Le 05/09/2022 à 12:26, Jean-Marc Lasgouttes a écrit :
Do as you see fit.
I did, but I have more questions now.
PS: I realize that I should have read tickets #12182 and #12187 before
posting point 3/. I do not want to initiate an endless discussion about
these things :) It is just that I noticed this while looking at the
statistics thing.
3/ The contextual menu is a weird merge of what LibreOffice and MS
Office do:
* LO: each element has its menu, the zoom menu has example values
to set (fit width, fit page, 50%, 75%, etc.), no way to tell which
statistics should be there
* MSO: only one menu with checkboxes to indicate which elements
should be shown, no way to tell which statistics should be there, no
way to set zoom from menu
* LyX one menu that does both selection of elements and zooming,
zoom in/out and reset to default (main use IMO is to learn shortcuts),
weird-looking precomputed zoom values
I understand that splitting the menu would make zoom menu unavailable
when both count and slider are off; some solution would be needed if
splitting the menus. OTOH I am not sure that the zoom menu is useful,
except maybe for the reset to default, which is not available via a
mouse click. In this respect, I like the Firefox approach, where
clicking on the zoom indicator resets zoom to default.
I don't remember that splitting menus was suggested yet at #12182 and
#12187. (Feel free to ignore my comment otherwise.) I seem to remember
that I suggested the whole status bar menu originally. Back then, there
were was only zoom options which made it rather unproblematic to show
zoom stuff on there. But now that more options were added (and probably
not the last ones), I agree that it should be split up. Further zoom
options are available in both Word and Writer by pressing the zoom
value. I suggest we just use the same (standard) mechanism. Stopping
short of creating a dialog, I suggest to just show a menu as in the
attached patch.
(By the way, setting 100% zoom to be actual zoom as suggested elsewhere
might partly help with the number strangeness - at least as long as the
default zoom is not changed.)
DanielFrom 468517474274a356746ab75afe0bdd76f95b0fad Mon Sep 17 00:00:00 2001
From: Daniel Ramoeller
Date: Thu, 8 Sep 2022 07:04:07 +0200
Subject: [PATCH] Disentangle status bar and zoom menu
- Moves the zoom menu to the zoom value
---
lib/ui/stdcontext.inc | 9 +++--
src/frontends/qt/GuiClickableLabel.cpp | 4
src/frontends/qt/GuiClickableLabel.h | 2 ++
src/frontends/qt/GuiView.cpp | 14 --
src/frontends/qt/GuiView.h | 4 +++-
5 files changed, 28 insertions(+), 5 deletions(-)
diff --git a/lib/ui/stdcontext.inc b/lib/ui/stdcontext.inc
index eb44a58f30..b9a23040c6 100644
--- a/lib/ui/stdcontext.inc
+++ b/lib/ui/stdcontext.inc
@@ -723,12 +723,17 @@ Menuset
Item "Giant-sized Icons" "icon-size giant"
End
+#
+# Status bar zoom context menu
+#
+ Menu "context-zoom"
+ ZoomOptions
+ End
+
#
# Status bar context menu
#
Menu "context-statusbar"
- ZoomOptions
- Separator
Item "Zoom Level|Z" "ui-toggle zoomlevel"
Item "Zoom Slider|S" "ui-toggle zoomslider"
Separator
diff --git a/src/frontends/qt/GuiClickableLabel.cpp
b/src/frontends/qt/GuiClickableLabel.cpp
index 311755d130..f2c1cd4d52 100644
--- a/src/frontends/qt/GuiClickableLabel.cpp
+++ b/src/frontends/qt/GuiClickableLabel.cpp
@@ -23,6 +23,10 @@ GuiClickableLabel::GuiClickableLabel(QWidget * parent)
GuiClickableLabel::~GuiClickableLabel()
{}
+void GuiClickableLabel::mousePressEvent(QMouseEvent *) {
+ Q_EMIT pressed();
+}
+
void GuiClickableLabel::mouseReleaseEvent(QMouseEvent *) {
Q_EMIT clicked();
}
diff --git a/src/frontends/qt/GuiClickableLabel.h
b/src/frontends/qt/GuiClickableLabel.h
index b14ba15de8..2fb4e8e25e 100644
--- a/src/frontends/qt/GuiClickableLabel.h
+++ b/src/frontends/qt/GuiClickableLabel.h
@@ -25,8 +25,10 @@ public:
Q_SIGNALS:
void clicked();
+ void pressed();
protected:
+ void mousePressEvent(QMouseEvent *) override;
void mouseReleaseEvent(QMouseEvent *) override;
};
diff --git a/src/frontends/qt/GuiView.cpp b/src/frontends/qt/GuiView.cpp
index b87b494dac..24d6703e30 100644
--- a/src/frontends/qt/GuiView.cpp
+++ b/src/frontends/qt/GuiView.cpp
@@ -706,7 +706,8 @@ GuiView::GuiView(int id)
// QPalette palette = statusBar()->palette();
- zoom_value_ = new QLabel(statusBar());
+ zoom_value_ = new GuiClickableLabel(statusBar());
+ connect(zoom_value_, SIGNAL(pressed()), this,
SLOT(showZoomContextMenu()));
// zoom_value_->setPalette(palette);
zoom_value_->setFor
Re: Indentation and (un)commenting in local layout and preamble
On 2022-08-14 20:20, Daniel wrote: On 2022-08-14 18:38, Kornel Benko wrote: Applies cleanly and compiles. Rudimentary test looks good. (At least writing local format feels better than what we have now). Kornel Thanks for testing. I realized that I changed the tab stop size before setting the font which could lead to a wrong size. Very slightly modified patch attached. I only added preambleTE->setTabStop(4); and locallayoutTE->setTabStop(4); at the correct positions. Daniel I have moved the finalized patch to https://www.lyx.org/trac/ticket/12577. Daniel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Font size representation on macOS is off
On 2022-09-01 16:52, Jean-Marc Lasgouttes wrote: Le 28/08/2022 à 21:33, Daniel a écrit : On 2022-08-27 16:39, Daniel wrote: When using a 10pt font-size at 100% zoom in the work area, this is way smaller on screen than 10pt in reality. Something seems to be off. However, I noticed that both Apple's own Pages and Word are having the same problem. Only Writer manages to get it right. Is there a chance we could get the Writer result? Daniel I think we should calculate the right size ourselves for macOS as Writer does. Otherwise, it is all really confusing. See also https://apple.stackexchange.com/a/445862/377509 Either we do that, or we do as other real macOS apps do and add this "actual size" thing. JMarc I tend towards calculating the right size at 100% if possible. I think that is more fitting to a cross-platform application. Besides Writer, Firefox also sets 100% at the correct size. Daniel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
