Help setting up a PPA
Hi, sorry, this question is unrelated to ongoing Lyx development, but I have a question regarding the setup of the Lyx package repository. I basically want to setup a similar PPA repository as Lyx does it for our project, but I need some help. Who would be the person to direct my questions to? Thanks, Andreas -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [LyX/master] Allow compiling with Qt6
Hi Stephan, Am 16.03.21 um 08:01 schrieb Stephan Witt: > That’s interesting. My plan was to go with the LTS versions of Qt. > So I had the plan to use either 5.9.x or 5.12.x. I noticed already > the incompatibility of 5.12.x with El Capitan. What can you say > about the pros and cons of Qt 5.11 versus Qt 5.12? Are you confident > with 5.11? To my knowledge, the changes from 5.11.3 to 5.12.8 (shipped with Ubuntu 20.04 LTS) are not really needed in our project. If I recall correctly, there were a few bug fixes that we have and had workarounds for (and keeps these around), but nothing critical. For example, setting the header font (size) for QTableWidget won't work correctly on Linux in older Qt versions, but that's not much of an issue. To my knowledge, the API of the standard widget classes hasn't changed in those revisions - so the code for Qt 5.12.8 should equally compile on 5.11.3. Since we generally develop on Ubuntu (I myself with 18.04 lts, others with 20.04 lts), we normally have code compiling fine across this range of Qt versions. In addition, we have a Jenkins slave running on a Mac El Capitan box - so any compile time issues appear right away and can be fixed with #if QT_VERSION > 0x050b00 checks. One thing, though: the stylesheet support has improved a lot in the later Qt versions, and some features are not yet available/working correctly in 5.9.5... but it seems the way Lyx handles colors appears to be working quite well, already. -Andreas -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [LyX/master] Allow compiling with Qt6
Hi All, just looked into Qt6 for another project of mine and noticed that there is actually nothing in Qt6 new, that's really needed. Same for Lyx - or is there really any feature of Qt6 necessary? So, I was wondering - Lyx is being used by a lot of people with not so brand-new notebooks, and hardware, that won't even support upgrading to newer os (talk about the older Macs for example, and quite a few 6 +years Linux boxes). Now, Qt6 has a compatibility limit and some of these systems won't be able to run Lyx anylonger. My suggestions would be to make Qt6 compilation an optional thing, but keep code compilable with at least a sufficiently "old" and supported Qt version. In my other projects we have set MacOS El Capitan as compability limit, and the newest Qt version running on that system appears to be 5.11.3. So, that's what we stick to during development and, honestly, a lot of the newer features of Qt (or bug fixes) aren't really needed. How about Lyx? Given the rather solid and standard Qt feature set used in Lyx, why not impose such a compatibility limit as well (at least let the code be compiling on those systems)? In case this is already considered, just ignore my rambling :-) Anyway, just a though... -Andreas Am 16.03.21 um 03:52 schrieb Scott Kostyshak: > On Mon, Mar 15, 2021 at 05:33:49PM +0100, Enrico Forestieri wrote: >> commit 635a7d77ddc94c63d52494dc4d68a930faccf45f >> Author: Enrico Forestieri >> Date: Mon Mar 15 17:09:09 2021 +0100 >> >> Allow compiling with Qt6 >> >> This commit allows compiling LyX with Qt6 when using autotools. >> For a successful compilation the following 2 conditions must be met. >> >> 1) The Qt6 qmake has to come first in PATH, so that the command >>"qmake -v | grep -o 'Qt version .'" returns "Qt version 6". >> 2) The --enable-qt6 switch has to be passed to the configure command. >> >> If --enable-qt6 is used but Qt6 is not found, Qt5 is tried as a fallback. >> If also Qt5 is not found, configuring for Qt4 is attempted. >> If --enable-qt6 is not used, then things go as usual. This means that Qt5 >> is tried first and then Qt4, unless --disable-qt5 is used, in which case >> Qt4 is directly attempted. This means that existing scripts should >> continue working unmodified. >> >> LyX should compile with Qt6 on windows and linux, and possibly also on >> mac, but I could not test that. However, it is not guaranteed that it >> works as it should. In particular I am not sure that I got right the >> conversion from QRegExp to QRegularExpression. For sure, the syntax >> highlighting seems to not work right. Someone in the know should take >> a look at that. I am able to load documents and compile them but some >> thourough testing is needed. However, when compiling for Qt5 or Qt4, >> I tried to make sure that the functionality is preserved. >> --- > > Are there still QRegExp that need to be changed? I got an error from > src/support/qstring_helpers.cpp. > > Also, why use > > #include > > in CategorizedCombo.cpp, but not other places? > > Scott > > -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Proposal for UI enhancement: ticket #1624
Hi Riki,
thanks for the ideas - quite a few things I haven't really thought about.
Am 01.10.19 um 19:54 schrieb Richard Kimberly Heck:
>
> ...
>
> I do still have some worries of the sort I expressed at
> https://www.lyx.org/trac/ticket/1624#comment:11. A label for a section
> really shouldn't be in the section heading itself, from a LaTeX point of
> view, though it's natural to put it there in LyX.
I've just analysed the available options:
a) If a label is put right at the start of a section in lyx, this gives:
Lyx-File:
.
\begin_layout Section
\begin_inset CommandInset label
LatexCommand label
name "sec:MySection"
\end_inset
MySection
\end_layout
.
and in exported tex-File:
.
\section{\label{sec:MySection}MySection}
.
This runs fine through my latex compiler, so I guess this is "proper"
latex code.
b) If a label is put it at the end of the section in lyx, this gives:
Lyx-File:
.
\begin_layout Section
MySection
\begin_inset CommandInset label
LatexCommand label
name "sec:MySection"
\end_inset
\end_layout
.
and in exported tex-File:
.
\section{MySection\label{sec:MySection}}
.
Works also as option a).
> There's been some> discussion of automatically moving such labels to
> right after the> \section command. But, now, many users don't put them
> in the heading, so> as not to generate bad LaTeX. Maybe they put
> labels at the beginning of> the first sentence.
c) The label is placed in the first paragraph past the section.
Lyx-File:
.
\begin_layout Section
MySection
\end_layout
\begin_layout Standard
\begin_inset CommandInset label
LatexCommand label
name "sec:MySection"
\end_inset
blablabla ... more text ... blablabla
\end_layout
.
and in exported tex-File:
.
\section{MySection}
\label{sec:MySection}
.
I guess option c) is what you recommend to avoid "bad Latex".
> So it's hard to tell what's meant to be a 'section'
> label.
I agree.
The good thing is - all variants run perfectly fine through my latex
compiler and generate the same result. So, maybe this "bad latex" thing
is more a style-issue, but not really a functionality problem.
Nevertheless, worth discussing.
With the current functionality, the user determines the insert position
manually before opening the "Create label" dialog.
When a label is now inserted automatically (new functionality), we
basically have two choices:
1. hardcode one of the options a, b or c
2. make option a, b or c a configurable option
I would be in favour of (1), and would only make this configureable if
users request it (avoid configuration option bloat), and further, I
would be in favour of option a (mainly, because that's how I write my
lyx documents :-)
Operation "check, which section/float has already a label":
> Possibly we could use the prefix to determine this ("sec:" in> this case),
> though any such algorithm will be error-prone. So it's
not> that easy to tell if a section 'already' has a label.
I would be worried about reliability of such an algorithm as well,
especially since we target a multi-lingual community which might use
"Kapitel:" instead of section.
Variants a and b would be fairly easy to detect (check if a label
CommandInset is inside the layout).
I would also implement the following rule: if more than one label
CommandInset is in a section layout, choose the first.
Variant c would be only realiably detected, if the following condition
is met: the layout following the section layout must start with a
CommendInset of type label -> if so, this label is accepted as existing
label for the section.
So what happens if the user has placed a label somewhere different?
Well, the new cross-reference dialog would not detect the label and
offer to insert a new one (in either of the locations discussed above).
Then, the document would possibly have two labels, but still would be
valid lyx and latex documents. IMHO, not a big problem here.
My proposal would be to agree on a "default" label placement position.
To get started with the implementation, I'm writing some code to detect
which section has a label.
Sorry for the long answer, but I guess if this were an easy ticket, it
would have been done already :-)
-Andreas
PS: Riki, thanks for the pointer to the outliner... need to check the
code there next!
Re: Proposal for UI enhancement: ticket #1624
Hi Scott,
thanks for your ideas, let me comment below.
>> I would like to contribute an improvement on this workflow:
>> 1. Button and sub-dialog approach:
>> - add a button on the dialog "Create label"
>> - sub-dialog opens and allows selecting existing
>> sections/subections/images/tables in a tree-view or filtered list-view
>> (with combo-box filter)
>> - if a label exists for this section -> close dialog using button
>> "Select label"
>
> It feels like there's an inconsistency here. At this point, the user has
> clicked on "Create label". But for this situation (the label already
> exists), there is no label that is created. I wonder if "Cancel" would
> be the correct choice by the user if they want to use a label that's
> already been created. Alternatively, perhaps my concern would be
> addressed by renaming "Create label" to something else (I don't
> currently have a suggestion).
Indeed, "create label" might be misleading. Actually, the button spawns
the regular "Insert label" Dialog (class GuiLabel). When confirmed, the
user has effectively inserted a new label at the selected section/float.
Maybe "Insert new label" or so might be better (actually, this modal
"sub-dialog" variant isn't really my favourite).
>> - in cross-reference dialog update list of labels and select newly
>> created/selected label
>
> Why do we need this step? i.e., why not directly insert the label just
> created? I'm guessing it is because the user might want to change
> something else in the cross-reference dialog, such as the "Reference
> Format", but I just wanted to check that that's what you have in mind.
Correct, that was my intention. After the label-selection normally one
may adjust the reference format (actually, in my experience this happens
only often when writing text with equation references and section/float
references).
>> 2. "switch selection list"-appraoch:
>> This facilitates also the approach when users are not 100% sure which
>> section to reference right now or when the choosen labels are not 100%
>> clear in what they describe. In such cases the document structure and
>> section captions can be a better way to select labels.
>>
>> Idea: the cross-reference dialog has two selection modes:
>> a) as before, a groupable, filter-able list of existing labels
>> b) a groupable list of all existing sections/subsections/images/tables,
>> with highlighting (bold-face) for all list items that have already
>> labels defined
>>
>> User can switch between both views via
>> toggle-button/radio-button...Toolbox-Window..?
> Interesting ideas! Just to be clear, instead of "images" I think you
> mean "figure floats".
Right. But in the tree view/list I would still distinguish between
Graphics and Tables, since IMHO authors rather think in terms of
Image-reference and table-references when writing text (such as "see
Fig. \ref{fig:xxx}" or "in Table \ref{tab:xxx})".
> And perhaps instead of "figures/tables" we can
> generalize to "floats". I don't understand variant 2 well.
Actually, variant 2 is pretty much what you would expect from a regular
text processor. You (the author) type text where a reference might be
needed/appropriate. For example: "This is the same as discussed already
in section ". Now, you want to insert a referece. You hit the shortcut
for "insert reference" and a dialog appears. Here, you select the
section in question, click ok and go on typing. The selection of the
section is hereby done based on the caption or number and caption, for
example "2.3 Equations that yield 42", just as it appears in the
navigation menu.
Since the current functionality is also needed (select label by label
name), the "select by reference text/number" approach would work better
for quite a few authors.
Remains the question on how to actually generate the new label name and
where to insert it.
For may insets a default behaviour could be formulated:
- sections/subsections... : always insert the label right at the begin
of the inset, before the caption text
- figures/tables/floats in general: always insert the label at the begin
of the caption text
- listings: require caption to create new label, if caption is present,
use as for regular floats.
> An extension that might be worth talking about later: currently, does
> LyX know how to add a label for different layouts? It might, I don't
> know. In any case, perhaps we would need some layout tag that would tell
> LyX how to add the label. For example, if a user creates a new layout
> how does LyX know where to put the \label command? Should it put it in
> one of the arguments or in the main chunk? I don't know much about
> LaTeX. Perhaps this isn't needed at all.
> I would
> suggest waiting until another dev comes along and gives a strong signal
> for you to go forward spending more time on this.
Sure, right now I'm still analysing the inset-creation code and try to
figure out, how the "GuiLabel" dialog actually works.
For (my favourite) variant 2, I still
Proposal for UI enhancement: ticket #1624
Hi and hello everyone, first of all, I'm a great fan of Lyx and I use it for my productive work since many years! Thanks for all the work you've put into. One feature I am missing for some time already is discussed in ticket https://www.lyx.org/trac/ticket/1624 It is about streamlining the "cross-reference" workflow. When writing a document often you think about referencing a section/table/image, but haven't created a label there yet. So the workflow right now involves: - click on "create reference" button - in dialog get dissappointed: no desired label yet -> close dialog - lookup section/image/table (usually involves a lot of scrolling) - click on the right spot - click on the "create label" button (or use shortcut) - enter/adjust label name - scroll back to insert position - re-open dialog for inserting cross reference - look-up and select label in dialog and finally create cross-reference I would like to contribute an improvement on this workflow: Proposed improvement: - open cross-reference dialog - select section/subsection/image/table etc. - if label exists already, choose this label -> otherwise create a new label - create cross-reference UI design/implementation ideas: 1. Button and sub-dialog approach: - add a button on the dialog "Create label" - sub-dialog opens and allows selecting existing sections/subections/images/tables in a tree-view or filtered list-view (with combo-box filter) - if a label exists for this section -> close dialog using button "Select label" - if no such label exist, enter/adjust suggested label name in line edit -> close dialog using button "Create and select"-button - in cross-reference dialog update list of labels and select newly created/selected label - create cross-reference as before 2. "switch selection list"-appraoch: This facilitates also the approach when users are not 100% sure which section to reference right now or when the choosen labels are not 100% clear in what they describe. In such cases the document structure and section captions can be a better way to select labels. Idea: the cross-reference dialog has two selection modes: a) as before, a groupable, filter-able list of existing labels b) a groupable list of all existing sections/subsections/images/tables, with highlighting (bold-face) for all list items that have already labels defined User can switch between both views via toggle-button/radio-button...Toolbox-Window..? When in mode b), user can click on a list view item. If it has already a label, the user can continue as in the current functionality. The label text is shown in a line edit below the list view (that is read-only in this case). If the selected item does not yet have a label associated, the read-only line edit becomes enabled, a default label text is composed (as in the "create label" dialog) and the button: create-label is enabled. User can click on the create label button and after a uniqueness check, the label is created in the respective section, image, table. The list view is then updated and the item with the newly created label (now also in bold-face) is selected. Then continue as above. What would be your favourite design? I personally like variant 2) better, but the first one is less intrusive (I wouldn't have to change as much existing code as for variant 2). But then again, besides a little reorganisation in ui/CreateRef.ui, it is probably not much to change. What are your thoughts? Right now I'm still investigating the code and trying to figure out how to modify the buffer correctly. Bye, Andreas
