Re: Proposal for UI enhancement: ticket #1624
Am Di., 1. Okt. 2019 um 19:55 Uhr schrieb Richard Kimberly Heck < rikih...@lyx.org>: > 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. There's been some > discussion of automatically moving such labels to right after the > \section command. > Not only discussions. In master, this is already implemented. Jürgen
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
Sorry to top post, but since this isn't a response to anything
particular
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. 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. So it's hard to tell what's meant to be a 'section'
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.
Contradicting my former self, I think it would be best to skip this sort
of check and just have some mechanism through which one could "create a
label" for some pre-existing section, etc, which would be automatically
inserted at an appropriate point, and return you to the cross-ref dialog
with that reference pre-selected. That does make me wonder, along with
my former self, whether a clean way to do it would not be just to add
this "Create label..." functionality to the outliner, and add a button
to the cross-ref dialog that would, in effect, open the outliner, or put
the focus there if it already is open. The dialog, after all, will need
to look very similar. At the very least, though, you can get a list of
the sections, etc, that exist from the outliner backend.
Riki
On 9/29/19 7:34 AM, Andreas Nicolai wrote:
> 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
Re: Proposal for UI enhancement: ticket #1624
On Sun, Sep 29, 2019 at 01:34:14PM +0200, Andreas Nicolai wrote:
> 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
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
Re: Proposal for UI enhancement: ticket #1624
On Tue, Sep 24, 2019 at 04:19:48PM +0200, Andreas Nicolai wrote: > 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. Hi Andreas, thanks for all of the time you've put thinking about this and for volunteering to work on it! I've only spent a few minutes thinking about this, so don't take any of my comments too seriously. > 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" 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). > - if no such label exist, enter/adjust suggested label name in line edit > -> close dialog using button "Create and select"-button Makes sense. > - 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. > - 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. Interesting ideas! Just to be clear, instead of "images" I think you mean "figure floats". And perhaps instead of "figures/tables" we can generalize to "floats". I don't understand variant 2 well. I would suggest waiting until another dev comes along
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
