Re: Proposal for UI enhancement: ticket #1624

[Jürgen Spitzmüller]

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

[Andreas Nicolai]

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

[Richard Kimberly Heck]

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

[Scott Kostyshak]

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

[Andreas Nicolai]

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

[Scott Kostyshak]

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

[Andreas Nicolai]

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

Re: Fwd: #11620: Enhancement Request: Add abbreviated git hash to Insert -> Field -> Other... -> VCI

[Jean-Marc Lasgouttes]

Le 11 août 2019 19:04:12 GMT+02:00, Joel Kulesza  a écrit :
> Happy to, I just didn't want to get ahead of myself in case this isn't
> adopted in 2.4.
>
>This has been incorporated into the master branch.  What is the path to
>know if/when it will be incorporated into a forthcoming (2.4) release? 
>Is
>it safe to assume that given the early stage in the 2.4 pre-release
>process
>that it will be?  Or, is there a more formal and/or explicit
>indication?
>Sorry for my ignorance.
>
>Thanks,
>Joel

Everything that is in master will go to 2.4, at least until we create a special 
branch.

JMarc

Fwd: #11620: Enhancement Request: Add abbreviated git hash to Insert -> Field -> Other... -> VCI

[Joel Kulesza]

-- Forwarded message -
From: LyX Ticket Tracker 
Date: Sun, Jul 28, 2019 at 7:42 PM
Subject: Re: #11620: Enhancement Request: Add abbreviated git hash to
Insert -> Field -> Other... -> VCI
To: , 
Cc: 


#11620: Enhancement Request: Add abbreviated git hash to Insert -> Field ->
Other... -> VCI
-+
 Reporter:  jkulesza |   Owner:  rikiheck
 Type:  enhancement  |  Status:  fixedinmaster
 Priority:  normal   |   Milestone:  2.4.0
Component:  insets   | Version:  2.4.0dev
 Severity:  normal   |  Resolution:
 Keywords:   |
-+

Comment (by jkulesza):

 Replying to [comment:9 sanda]:
 > And you want to add your new feature into NewInLyX24 of our wiki.

 Happy to, I just didn't want to get ahead of myself in case this isn't
 adopted in 2.4.

This has been incorporated into the master branch.  What is the path to
know if/when it will be incorporated into a forthcoming (2.4) release?  Is
it safe to assume that given the early stage in the 2.4 pre-release process
that it will be?  Or, is there a more formal and/or explicit indication?
Sorry for my ignorance.

Thanks,
Joel

Re: [enhancement] add *.xlsx to external data material dialog (table) and file handler

[Georg Baum]

Richard Heck wrote:

> On 09/06/2016 06:10 PM, Georg Baum wrote:
>> Richard Heck wrote:
>>
>>> On 09/05/2016 04:56 PM, Georg Baum wrote:
 I think he meant the missing .xlsx extension in the external material
 file dialog. I added this in master at df8e0ed9e0c37ab7.
>>> Fine for stable too.
>> I need 646d47ae9393bc for stable too, otherwise I only see one filter
>> "All files".
> 
> That is fine with me.

Thanks, both changes are in.


Georg

RE: [enhancement] add *.xlsx to external data material dialog (table) and file handler

[Jannick]

From: Helge Hafting [mailto:helge.haft...@ntnu.no] 
Sent: Monday, September 5, 2016 3:07 PM

Den 05. sep. 2016 00:53, skrev Jannick:
> Currently lyx deals with *.xls files only, while the Excel world 
> rather turns around .xlsx files. It would be great if lyx could be 
> extended including the file handler where ssconvert appears to 
> faithfully extract data from *.xlsx files.
>
> I am not subscribed to the devel list, so please copy me in if you 
> need any more information on this from my side.
>
LyX already support .xlsx, so I am not sure what you are asking for here?

I created a LyX document, inserted a file (external material). I selected
spreadsheet, and typed in "testfile.xlsx". This worked fine, the PDF
contained the spreadsheet. Anything "ssconvert" supports should indeed work.
I don't know if ssconvert handles all xlsx files, but it certainly handled
my testfile well.

I tested with LyX 2.2.1, but this sould work for most earlier versions too -
as there haven't been much changes since the excel support went in.
Conversion is handled by ssconvert, so anything ssconvert handles should
work, (unless the spreadsheet is wider than the page).

Do you have an xlsx file that ssconvert handles, but LyX does not? If so,
please send me such a file so I can look into it.

Helge Hafting

_____

Thanks. What I am suggesting is an enhancement of lyx' ssconvert interface
(i.e. for external material/tables), namely:

1 - adding *.xlsx to the file filter of the file selection dialog window (to
avoid manual entering the file name - as you suggested - and not to be
cluttered with all files in the specific folder after selecting the file
filter *.* provided as second option in the file selection dialog window)

2 - add *.xlsx in the default file handler configuration which does not
appear to exist in the default configuration (in lyx 2.1.5 (on Win10) there
is only one explicitly saying that it deals with *.xls). 

Regards,
J. 

Re: [enhancement] add *.xlsx to external data material dialog (table) and file handler

[Richard Heck]

On 09/06/2016 06:10 PM, Georg Baum wrote:
> Richard Heck wrote:
>
>> On 09/05/2016 04:56 PM, Georg Baum wrote:
>>> I think he meant the missing .xlsx extension in the external material
>>> file dialog. I added this in master at df8e0ed9e0c37ab7.
>> Fine for stable too.
> I need 646d47ae9393bc for stable too, otherwise I only see one filter "All 
> files". 

That is fine with me.

> Does anybody understand the old code? 

No.

Richard

Re: [enhancement] add *.xlsx to external data material dialog (table) and file handler

[Georg Baum]

Richard Heck wrote:

> On 09/05/2016 04:56 PM, Georg Baum wrote:
>> I think he meant the missing .xlsx extension in the external material
>> file dialog. I added this in master at df8e0ed9e0c37ab7.
> 
> Fine for stable too.

I need 646d47ae9393bc for stable too, otherwise I only see one filter "All 
files". Does anybody understand the old code? Does anybody see the same 
problem with current branch (no file browse dialog of an external inset has 
a specific filter)?


Georg

Re: [enhancement] add *.xlsx to external data material dialog (table) and file handler

[Richard Heck]

On 09/05/2016 04:56 PM, Georg Baum wrote:
> Helge Hafting wrote:
>
>> Den 05. sep. 2016 00:53, skrev Jannick:
>>> Currently lyx deals with *.xls files only, while the Excel world rather
>>> turns around .xlsx files. It would be great if lyx could be extended
>>> including the file handler where ssconvert appears to faithfully extract
>>> data from *.xlsx files.
>>>
>>> I am not subscribed to the devel list, so please copy me in if you need
>>> any more information on this from my side.
>>>
>> LyX already support .xlsx, so I am not sure what you are asking for here?
> I think he meant the missing .xlsx extension in the external material file 
> dialog. I added this in master at df8e0ed9e0c37ab7.

Fine for stable too.

rh

Re: [enhancement] add *.xlsx to external data material dialog (table) and file handler

[Georg Baum]

Helge Hafting wrote:

> Den 05. sep. 2016 00:53, skrev Jannick:
>> Currently lyx deals with *.xls files only, while the Excel world rather
>> turns around .xlsx files. It would be great if lyx could be extended
>> including the file handler where ssconvert appears to faithfully extract
>> data from *.xlsx files.
>>
>> I am not subscribed to the devel list, so please copy me in if you need
>> any more information on this from my side.
>>
> LyX already support .xlsx, so I am not sure what you are asking for here?

I think he meant the missing .xlsx extension in the external material file 
dialog. I added this in master at df8e0ed9e0c37ab7.


Georg

Re: [enhancement] add *.xlsx to external data material dialog (table) and file handler

[Helge Hafting]

Den 05. sep. 2016 00:53, skrev Jannick:

Currently lyx deals with *.xls files only, while the Excel world rather
turns around .xlsx files. It would be great if lyx could be extended
including the file handler where ssconvert appears to faithfully extract
data from *.xlsx files.

I am not subscribed to the devel list, so please copy me in if you need any
more information on this from my side.


LyX already support .xlsx, so I am not sure what you are asking for here?

I created a LyX document, inserted a file (external material). I 
selected spreadsheet, and typed in "testfile.xlsx". This worked fine, 
the PDF contained the spreadsheet. Anything "ssconvert" supports should 
indeed work. I don't know if ssconvert handles all xlsx files, but it 
certainly handled my testfile well.


I tested with LyX 2.2.1, but this sould work for most earlier versions 
too - as there haven't been much changes since the excel support went 
in. Conversion is handled by ssconvert, so anything ssconvert handles 
should work, (unless the spreadsheet is wider than the page).


Do you have an xlsx file that ssconvert handles, but LyX does not? If 
so, please send me such a file so I can look into it.


Helge Hafting

[enhancement] add *.xlsx to external data material dialog (table) and file handler

[Jannick]

Currently lyx deals with *.xls files only, while the Excel world rather
turns around .xlsx files. It would be great if lyx could be extended
including the file handler where ssconvert appears to faithfully extract
data from *.xlsx files. 

I am not subscribed to the devel list, so please copy me in if you need any
more information on this from my side.

Many thanks,
J.

Re: Enhancement Suggestion: Preamble Fixed-width Font

[Stephan Witt]

Am 15.04.2016 um 11:06 schrieb Scott Kostyshak :
> 
> On Fri, Apr 15, 2016 at 10:36:59AM +0200, Stephan Witt wrote:
>> Am 15.04.2016 um 09:51 schrieb Scott Kostyshak :
>>> 
>>> On Thu, Apr 14, 2016 at 08:53:24PM +0200, Stephan Witt wrote:
 Am 14.04.2016 um 20:16 schrieb Guillaume Munch :
> 
> Le 14/04/2016 19:05, Stephan Witt a écrit :
>> 
>> Yes, it’s attached. Thanks for testing.
>> 
> 
> 
> Works well on Linux+qt{4,5}.
> 
> Two remarks:
> 
> * isFixedPitch() would be in an anonymous namespace by what I know of 
> LyX's code style.
> * In my patch I compute typewriterFontName() from typewriterSystemFont. 
> Would you make this change?
 
 Like this one?
>>> 
>>> If you do not set the font to 12 point on Mac, it is too small?
>> 
>> Yes, this is what Joel said I’d say it too.
> 
> True, and comparing with the size on my system, it does seem to be a
> difference in platforms and not a difference in what we consider to be
> small.
> 
>>> I did read the thread and that you tried to configure Qt system
>>> settings, but it seems unfortunate to introduce platform-dependent
>>> code for something like this.
>>> 
>>> Just to confirm: hard-coding the font size should not change anything
>>> for HiDPI right?
>> 
>> It does the Right Thing - because it’s not in pixels but in points.
> 
> OK.
> 
>>> Doing a grep for "setPointSize" does not show any other examples of
>>> hardcoding, if I understand correctly. Why is it only needed here?
>> 
>> Because it’s a system font to paint with being used only here.
>> 
>> I’ve extended the patch with comments and I’ll provide some screen shots 
>> to illustrate the font sizes.
> 
> I see.
> 
> Please commit.
> 
> Scott

Done with 87c85303c5c5980b1189867c5dc9e711acf77c07.

Stephan

Re: Enhancement Suggestion: Preamble Fixed-width Font

[Scott Kostyshak]

On Fri, Apr 15, 2016 at 10:36:59AM +0200, Stephan Witt wrote:
> Am 15.04.2016 um 09:51 schrieb Scott Kostyshak :
> > 
> > On Thu, Apr 14, 2016 at 08:53:24PM +0200, Stephan Witt wrote:
> >> Am 14.04.2016 um 20:16 schrieb Guillaume Munch :
> >>> 
> >>> Le 14/04/2016 19:05, Stephan Witt a écrit :
>  
>  Yes, it’s attached. Thanks for testing.
>  
> >>> 
> >>> 
> >>> Works well on Linux+qt{4,5}.
> >>> 
> >>> Two remarks:
> >>> 
> >>> * isFixedPitch() would be in an anonymous namespace by what I know of 
> >>> LyX's code style.
> >>> * In my patch I compute typewriterFontName() from typewriterSystemFont. 
> >>> Would you make this change?
> >> 
> >> Like this one?
> > 
> > If you do not set the font to 12 point on Mac, it is too small?
> 
> Yes, this is what Joel said I’d say it too.

True, and comparing with the size on my system, it does seem to be a
difference in platforms and not a difference in what we consider to be
small.

> > I did read the thread and that you tried to configure Qt system
> > settings, but it seems unfortunate to introduce platform-dependent
> > code for something like this.
> > 
> > Just to confirm: hard-coding the font size should not change anything
> > for HiDPI right?
> 
> It does the Right Thing - because it’s not in pixels but in points.

OK.

> > Doing a grep for "setPointSize" does not show any other examples of
> > hardcoding, if I understand correctly. Why is it only needed here?
> 
> Because it’s a system font to paint with being used only here.
> 
> I’ve extended the patch with comments and I’ll provide some screen shots 
> to illustrate the font sizes.

I see.

Please commit.

Scott


signature.asc
Description: PGP signature

Re: Enhancement Suggestion: Preamble Fixed-width Font

[Andrew Parsloe]

On 15/04/2016 7:51 p.m., Scott Kostyshak wrote:

On Thu, Apr 14, 2016 at 08:53:24PM +0200, Stephan Witt wrote:

Am 14.04.2016 um 20:16 schrieb Guillaume Munch :

Le 14/04/2016 19:05, Stephan Witt a écrit :

Yes, it’s attached. Thanks for testing.



Works well on Linux+qt{4,5}.

Two remarks:

* isFixedPitch() would be in an anonymous namespace by what I know of LyX's 
code style.
* In my patch I compute typewriterFontName() from typewriterSystemFont. Would 
you make this change?

Like this one?

If you do not set the font to 12 point on Mac, it is too small?

I did read the thread and that you tried to configure Qt system
settings, but it seems unfortunate to introduce platform-dependent
code for something like this.

Just to confirm: hard-coding the font size should not change anything
for HiDPI right?

Doing a grep for "setPointSize" does not show any other examples of
hardcoding, if I understand correctly. Why is it only needed here?

Scott
On windows there has been a noticeable reduction in font size in the 
preamble window. In the attached file, the one on the left is 2.1.4, the 
one on the right rc1.


Andrew


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

Re: Enhancement Suggestion: Preamble Fixed-width Font

[Scott Kostyshak]

On Thu, Apr 14, 2016 at 08:53:24PM +0200, Stephan Witt wrote:
> Am 14.04.2016 um 20:16 schrieb Guillaume Munch :
> > 
> > Le 14/04/2016 19:05, Stephan Witt a écrit :
> >> 
> >> Yes, it’s attached. Thanks for testing.
> >> 
> > 
> > 
> > Works well on Linux+qt{4,5}.
> > 
> > Two remarks:
> > 
> > * isFixedPitch() would be in an anonymous namespace by what I know of LyX's 
> > code style.
> > * In my patch I compute typewriterFontName() from typewriterSystemFont. 
> > Would you make this change?
> 
> Like this one?

If you do not set the font to 12 point on Mac, it is too small?

I did read the thread and that you tried to configure Qt system
settings, but it seems unfortunate to introduce platform-dependent
code for something like this.

Just to confirm: hard-coding the font size should not change anything
for HiDPI right?

Doing a grep for "setPointSize" does not show any other examples of
hardcoding, if I understand correctly. Why is it only needed here?

Scott


signature.asc
Description: PGP signature

Re: Enhancement Suggestion: Preamble Fixed-width Font

[Guillaume Munch]

Le 14/04/2016 19:53, Stephan Witt a écrit :

Am 14.04.2016 um 20:16 schrieb Guillaume Munch :


Le 14/04/2016 19:05, Stephan Witt a écrit :


Yes, it’s attached. Thanks for testing.




Works well on Linux+qt{4,5}.

Two remarks:

* isFixedPitch() would be in an anonymous namespace by what I know of LyX's 
code style.
* In my patch I compute typewriterFontName() from typewriterSystemFont. Would 
you make this change?


Like this one?



+1

Re: Enhancement Suggestion: Preamble Fixed-width Font

[Stephan Witt]

Am 14.04.2016 um 20:16 schrieb Guillaume Munch :
> 
> Le 14/04/2016 19:05, Stephan Witt a écrit :
>> 
>> Yes, it’s attached. Thanks for testing.
>> 
> 
> 
> Works well on Linux+qt{4,5}.
> 
> Two remarks:
> 
> * isFixedPitch() would be in an anonymous namespace by what I know of LyX's 
> code style.
> * In my patch I compute typewriterFontName() from typewriterSystemFont. Would 
> you make this change?

Like this one?

Stephan



typewriter-systemfont-patch-3.diff
Description: Binary data

Re: Enhancement Suggestion: Preamble Fixed-width Font

[Guillaume Munch]

Le 14/04/2016 19:05, Stephan Witt a écrit :


Yes, it’s attached. Thanks for testing.




Works well on Linux+qt{4,5}.

Two remarks:

* isFixedPitch() would be in an anonymous namespace by what I know of 
LyX's code style.
* In my patch I compute typewriterFontName() from typewriterSystemFont. 
Would you make this change?

Re: Enhancement Suggestion: Preamble Fixed-width Font

[Stephan Witt]

Am 14.04.2016 um 19:46 schrieb Guillaume Munch :
> 
> Le 14/04/2016 18:41, Stephan Witt a écrit :
>> Am 14.04.2016 um 19:28 schrieb Guillaume Munch :
>>> 
>>> Le 14/04/2016 18:10, Stephan Witt a écrit :
 Am 14.04.2016 um 18:18 schrieb Joel Kulesza
 :
> 
> On Thu, Apr 14, 2016 at 10:24 AM, Guillaume Munch 
> wrote:
> 
> Can you please try the attached patch?
> 
> That patch seemed to work to correct the issue in both places
> (see attached). The font seems small (I'm not sure if that's
> perception or reality).  Regardless, it is fixed width.  Thank
> you! 
 
 Good idea. I can confirm this. Though some refactoring should be
 done, IMO. See the attached patch. This allows some consistent
 tweaking of font site too.
 
 Stephan
 
>>> 
>>> Thanks for your patch. Then it should probably more be as the
>>> attached.
>> 
>> Yes, Qt < 5.2 doesn’t have the QFontDatabase::systemFont etc.
>> 
>> While googling I found this (and adapted it) for Mac:
> 
> Looks fine to me. Can you please make a patch out of it so that I can test?

Yes, it’s attached. Thanks for testing.

Stephan

> 
>> ...
>> 
>> 
>>> 
>>> The font size of 12 appears too big here.
>> 
>> I couldn’t come up with a solution to configure Qt system settings on
>> Mac. I already searched for something like that to solve the cursor
>> thickness issue (should be configurable too) and failed.
>> 
>>> I'm more thinking of a local configuration issue. I do not
>>> recommend keeping this font size line.
>> 
>> Yes, probably better.
> 
> I'm fine with the "#ifdef Q_OS_MAC"



typewriter-systemfont-patch-2.diff
Description: Binary data

Re: Enhancement Suggestion: Preamble Fixed-width Font

[Guillaume Munch]

Le 14/04/2016 18:41, Stephan Witt a écrit :

Am 14.04.2016 um 19:28 schrieb Guillaume Munch :


Le 14/04/2016 18:10, Stephan Witt a écrit :

Am 14.04.2016 um 18:18 schrieb Joel Kulesza
:


On Thu, Apr 14, 2016 at 10:24 AM, Guillaume Munch 
wrote:

Can you please try the attached patch?

That patch seemed to work to correct the issue in both places
(see attached). The font seems small (I'm not sure if that's
perception or reality).  Regardless, it is fixed width.  Thank
you! 


Good idea. I can confirm this. Though some refactoring should be
done, IMO. See the attached patch. This allows some consistent
tweaking of font site too.

Stephan



Thanks for your patch. Then it should probably more be as the
attached.


Yes, Qt < 5.2 doesn’t have the QFontDatabase::systemFont etc.

While googling I found this (and adapted it) for Mac:


Looks fine to me. Can you please make a patch out of it so that I can test?


...




The font size of 12 appears too big here.


I couldn’t come up with a solution to configure Qt system settings on
Mac. I already searched for something like that to solve the cursor
thickness issue (should be configurable too) and failed.


I'm more thinking of a local configuration issue. I do not
recommend keeping this font size line.


Yes, probably better.


I'm fine with the "#ifdef Q_OS_MAC"

Re: Enhancement Suggestion: Preamble Fixed-width Font

[Stephan Witt]

Am 14.04.2016 um 19:28 schrieb Guillaume Munch :
> 
> Le 14/04/2016 18:10, Stephan Witt a écrit :
>> Am 14.04.2016 um 18:18 schrieb Joel Kulesza :
>>> 
>>> On Thu, Apr 14, 2016 at 10:24 AM, Guillaume Munch 
>>> wrote:
>>> 
>>> Can you please try the attached patch?
>>> 
>>> That patch seemed to work to correct the issue in both places (see
>>> attached). The font seems small (I'm not sure if that's perception
>>> or reality).  Regardless, it is fixed width.  Thank you! >> Shot 2016-04-14 at 12.18.34 PM.png>
>> 
>> Good idea. I can confirm this. Though some refactoring should be
>> done, IMO. See the attached patch. This allows some consistent
>> tweaking of font site too.
>> 
>> Stephan
>> 
> 
> Thanks for your patch. Then it should probably more be as the attached.

Yes, Qt < 5.2 doesn’t have the QFontDatabase::systemFont etc.

While googling I found this (and adapted it) for Mac:

=
static bool isFixedPitch(const QFont & font) {
const QFontInfo fi(font);
return fi.fixedPitch();
}


QFont const GuiApplication::typewriterSystemFont()
{
#if QT_VERSION >= 0x050200
QFont font = QFontDatabase::systemFont(QFontDatabase::FixedFont);
#else
QFont font("monospace");
#endif
if (!isFixedPitch(font)) {
font.setStyleHint(QFont::Monospace);
if (!isFixedPitch(font)) {
font.setStyleHint(QFont::TypeWriter);
if (!isFixedPitch(font)) font.setFamily("courier");
}
}
#ifdef Q_OS_MAC
font.setPointSize(12);
#endif 
return font;
}
=


> 
> The font size of 12 appears too big here.

I couldn’t come up with a solution to configure Qt system settings on Mac.
I already searched for something like that to solve the cursor thickness 
issue (should be configurable too) and failed.

> I'm more thinking of a local
> configuration issue. I do not recommend keeping this font size line.

Yes, probably better.

Stephan

> 
> <0001-Fix-monospace-fonts-on-Mac.patch>

Re: Enhancement Suggestion: Preamble Fixed-width Font

[Guillaume Munch]

Le 14/04/2016 18:10, Stephan Witt a écrit :

Am 14.04.2016 um 18:18 schrieb Joel Kulesza :


On Thu, Apr 14, 2016 at 10:24 AM, Guillaume Munch 
wrote:

Can you please try the attached patch?

That patch seemed to work to correct the issue in both places (see
attached). The font seems small (I'm not sure if that's perception
or reality).  Regardless, it is fixed width.  Thank you! 


Good idea. I can confirm this. Though some refactoring should be
done, IMO. See the attached patch. This allows some consistent
tweaking of font site too.

Stephan



Thanks for your patch. Then it should probably more be as the attached.

The font size of 12 appears too big here. I'm more thinking of a local
configuration issue. I do not recommend keeping this font size line.

>From 45a1bffe5964965c39266fe606e0c20b895a0591 Mon Sep 17 00:00:00 2001
From: Guillaume Munch 
Date: Thu, 14 Apr 2016 18:17:46 +0100
Subject: [PATCH] Fix monospace fonts on Mac

Based on a patch by Stephan Witt

http://mid.gmane.org/caagogw97a-j9zxy6sdrj-g_-zewdz+fstkgudsso3udx3tp...@mail.gmail.com
---
 src/frontends/qt4/GuiApplication.cpp  | 16 ++--
 src/frontends/qt4/GuiApplication.h|  3 +++
 src/frontends/qt4/GuiDocument.cpp |  5 +
 src/frontends/qt4/GuiLog.cpp  |  5 +
 src/frontends/qt4/GuiProgressView.cpp |  5 +
 src/frontends/qt4/GuiViewSource.cpp   |  5 +
 6 files changed, 21 insertions(+), 18 deletions(-)

diff --git a/src/frontends/qt4/GuiApplication.cpp b/src/frontends/qt4/GuiApplication.cpp
index 12f99d5..cde8a56 100644
--- a/src/frontends/qt4/GuiApplication.cpp
+++ b/src/frontends/qt4/GuiApplication.cpp
@@ -82,6 +82,7 @@
 
 #include 
 
+#include 
 #include 
 #include 
 #include 
@@ -2557,11 +2558,22 @@ QString const GuiApplication::sansFontName()
 
 QString const GuiApplication::typewriterFontName()
 {
+	return QFontInfo(typewriterSystemFont()).family();
+}
+
+
+QFont const GuiApplication::typewriterSystemFont()
+{
+#if QT_VERSION >= 0x050200
+	QFont font = QFontDatabase::systemFont(QFontDatabase::FixedFont);
+#else
 	QFont font;
 	font.setStyleHint(QFont::TypeWriter);
 	font.setFamily("monospace");
-
-	return QFontInfo(font).family();
+	font.setFixedPitch(true);
+#endif
+	font.setPointSize(12);
+	return font;
 }
 
 
diff --git a/src/frontends/qt4/GuiApplication.h b/src/frontends/qt4/GuiApplication.h
index 350adc8..861810d 100644
--- a/src/frontends/qt4/GuiApplication.h
+++ b/src/frontends/qt4/GuiApplication.h
@@ -25,6 +25,7 @@
 class QAbstractItemModel;
 class QIcon;
 class QSessionManager;
+class QFont;
 
 namespace lyx {
 
@@ -145,6 +146,8 @@ public:
 
 	/// return a suitable monospaced font name.
 	QString const typewriterFontName();
+	QFont const typewriterSystemFont();
+
 	///
 	void unregisterView(GuiView * gv);
 	///
diff --git a/src/frontends/qt4/GuiDocument.cpp b/src/frontends/qt4/GuiDocument.cpp
index e4dff1d..2eedec9 100644
--- a/src/frontends/qt4/GuiDocument.cpp
+++ b/src/frontends/qt4/GuiDocument.cpp
@@ -453,10 +453,7 @@ PreambleModule::PreambleModule() : current_id_(0)
 	// This is not a memory leak. The object will be destroyed
 	// with this.
 	(void) new LaTeXHighlighter(preambleTE->document());
-	QFont font(guiApp->typewriterFontName());
-	font.setFixedPitch(true);
-	font.setStyleHint(QFont::TypeWriter);
-	preambleTE->setFont(font);
+	preambleTE->setFont(guiApp->typewriterSystemFont());
 	preambleTE->setWordWrapMode(QTextOption::NoWrap);
 	setFocusProxy(preambleTE);
 	connect(preambleTE, SIGNAL(textChanged()), this, SIGNAL(changed()));
diff --git a/src/frontends/qt4/GuiLog.cpp b/src/frontends/qt4/GuiLog.cpp
index dec7c25..23ba276 100644
--- a/src/frontends/qt4/GuiLog.cpp
+++ b/src/frontends/qt4/GuiLog.cpp
@@ -133,10 +133,7 @@ GuiLog::GuiLog(GuiView & lv)
 	highlighter = new LogHighlighter(logTB->document());
 
 	logTB->setReadOnly(true);
-	QFont font(guiApp->typewriterFontName());
-	font.setFixedPitch(true);
-	font.setStyleHint(QFont::TypeWriter);
-	logTB->setFont(font);
+	logTB->setFont(guiApp->typewriterSystemFont());
 }
 
 
diff --git a/src/frontends/qt4/GuiProgressView.cpp b/src/frontends/qt4/GuiProgressView.cpp
index fa15786..af455f2 100644
--- a/src/frontends/qt4/GuiProgressView.cpp
+++ b/src/frontends/qt4/GuiProgressView.cpp
@@ -71,10 +71,7 @@ GuiProgressView::GuiProgressView(GuiView & parent, Qt::DockWidgetArea area,
 	widget_->adjustSize();
 	setWidget(widget_);
 
-	QFont font(guiApp->typewriterFontName());
-	font.setFixedPitch(true);
-	font.setStyleHint(QFont::TypeWriter);
-	widget_->outTE->setFont(font);
+	widget_->outTE->setFont(guiApp->typewriterSystemFont());
 	widget_->tabWidget->widget(0)->setContentsMargins(-5, -7, 0, -7);
 
 	connect(widget_->debugNoneRB, SIGNAL(clicked()),
diff --git a/src/frontends/qt4/GuiViewSource.cpp b/src/frontends/qt4/GuiViewSource.cpp
index e528222..192a163 100644
--- a/src/frontends/qt4/GuiViewSource.cpp
+++ b/src/frontends/qt4/GuiViewSource.cpp
@@ -86,10 +86,7 @@ 

Re: Enhancement Suggestion: Preamble Fixed-width Font

[Stephan Witt]

Am 14.04.2016 um 18:18 schrieb Joel Kulesza :
> 
> On Thu, Apr 14, 2016 at 10:24 AM, Guillaume Munch  wrote:
> 
> Can you please try the attached patch?
> 
> That patch seemed to work to correct the issue in both places (see attached). 
> The font seems small (I'm not sure if that's perception or reality).  
> Regardless, it is fixed width.  Thank you!
> 

Good idea. I can confirm this. Though some refactoring should be done, IMO. See 
the attached patch.
This allows some consistent tweaking of font site too.

Stephan



typewriter-systemfont-patch.diff
Description: Binary data

Re: Enhancement Suggestion: Preamble Fixed-width Font

[Guillaume Munch]

Le 14/04/2016 17:18, Joel Kulesza a écrit :

On Thu, Apr 14, 2016 at 10:24 AM, Guillaume Munch > wrote:


Can you please try the attached patch?


That patch seemed to work to correct the issue in both places (see
attached). The font seems small (I'm not sure if that's perception or
reality).  Regardless, it _is_ fixed width.  Thank you!


The font size did not change... Can you change it externally from your 
system settings?


Here's a cleaned-up patch that I will recommend for inclusion if 
successful. Can you please try it?
>From 959d6fc0a945f09fc383f86d915b2f29e5002117 Mon Sep 17 00:00:00 2001
From: Guillaume Munch 
Date: Thu, 14 Apr 2016 15:22:26 +0100
Subject: [PATCH] Fix monospace fonts in the source panel and preamble on Mac

http://mid.gmane.org/caagogw97a-j9zxy6sdrj-g_-zewdz+fstkgudsso3udx3tp...@mail.gmail.com
---
 src/frontends/qt4/GuiDocument.cpp   | 4 
 src/frontends/qt4/GuiViewSource.cpp | 4 
 2 files changed, 8 insertions(+)

diff --git a/src/frontends/qt4/GuiDocument.cpp b/src/frontends/qt4/GuiDocument.cpp
index e4dff1d..f76c3fe 100644
--- a/src/frontends/qt4/GuiDocument.cpp
+++ b/src/frontends/qt4/GuiDocument.cpp
@@ -453,9 +453,13 @@ PreambleModule::PreambleModule() : current_id_(0)
 	// This is not a memory leak. The object will be destroyed
 	// with this.
 	(void) new LaTeXHighlighter(preambleTE->document());
+#if QT_VERSION >= 0x050200
+	QFont font = QFontDatabase::systemFont(QFontDatabase::FixedFont);
+#else
 	QFont font(guiApp->typewriterFontName());
 	font.setFixedPitch(true);
 	font.setStyleHint(QFont::TypeWriter);
+#endif
 	preambleTE->setFont(font);
 	preambleTE->setWordWrapMode(QTextOption::NoWrap);
 	setFocusProxy(preambleTE);
diff --git a/src/frontends/qt4/GuiViewSource.cpp b/src/frontends/qt4/GuiViewSource.cpp
index e528222..8506fb4 100644
--- a/src/frontends/qt4/GuiViewSource.cpp
+++ b/src/frontends/qt4/GuiViewSource.cpp
@@ -86,9 +86,13 @@ ViewSourceWidget::ViewSourceWidget()
 	viewSourceTV->setReadOnly(true);
 	///dialog_->viewSourceTV->setAcceptRichText(false);
 	// this is personal. I think source code should be in fixed-size font
+#if QT_VERSION >= 0x050200
+	QFont font = QFontDatabase::systemFont(QFontDatabase::FixedFont);
+#else
 	QFont font(guiApp->typewriterFontName());
 	font.setFixedPitch(true);
 	font.setStyleHint(QFont::TypeWriter);
+#endif
 	viewSourceTV->setFont(font);
 	// again, personal taste
 	viewSourceTV->setWordWrapMode(QTextOption::NoWrap);
-- 
2.1.4

Re: Enhancement Suggestion: Preamble Fixed-width Font

[Guillaume Munch]

Le 14/04/2016 13:33, Joel Kulesza a écrit :

On Thu, Apr 14, 2016 at 8:29 AM, Joel Kulesza > wrote:

On Thu, Apr 14, 2016 at 8:18 AM, Guillaume Munch > wrote:

Yes it's there. Code is very now similar to the source panel.
What font
do you see on the source panel?


There is no apparent change; see attached.


Sorry for spam, I had an email misfire.  See attached for both screenshots.

There is no apparent change. The preamble appears consistent with the
source pane.  I would not have knowingly changed the source pane font —
how can I change it to fixed-width?  Better asked: how can we assure it
is fixed width by default?



Can you please try the attached patch?

>From e25849aeebddd2dd7fe139cba1c119c980ca7cad Mon Sep 17 00:00:00 2001
From: Guillaume Munch 
Date: Thu, 14 Apr 2016 15:22:26 +0100
Subject: [PATCH] Fix monospace fonts in Mac

This requires qt >= 5.2
---
 src/frontends/qt4/GuiDocument.cpp   | 2 +-
 src/frontends/qt4/GuiViewSource.cpp | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/frontends/qt4/GuiDocument.cpp b/src/frontends/qt4/GuiDocument.cpp
index e4dff1d..9de5cfa 100644
--- a/src/frontends/qt4/GuiDocument.cpp
+++ b/src/frontends/qt4/GuiDocument.cpp
@@ -453,7 +453,7 @@ PreambleModule::PreambleModule() : current_id_(0)
 	// This is not a memory leak. The object will be destroyed
 	// with this.
 	(void) new LaTeXHighlighter(preambleTE->document());
-	QFont font(guiApp->typewriterFontName());
+	QFont font = QFontDatabase::systemFont(QFontDatabase::FixedFont);
 	font.setFixedPitch(true);
 	font.setStyleHint(QFont::TypeWriter);
 	preambleTE->setFont(font);
diff --git a/src/frontends/qt4/GuiViewSource.cpp b/src/frontends/qt4/GuiViewSource.cpp
index e528222..2b70299 100644
--- a/src/frontends/qt4/GuiViewSource.cpp
+++ b/src/frontends/qt4/GuiViewSource.cpp
@@ -86,7 +86,7 @@ ViewSourceWidget::ViewSourceWidget()
 	viewSourceTV->setReadOnly(true);
 	///dialog_->viewSourceTV->setAcceptRichText(false);
 	// this is personal. I think source code should be in fixed-size font
-	QFont font(guiApp->typewriterFontName());
+	QFont font = QFontDatabase::systemFont(QFontDatabase::FixedFont);
 	font.setFixedPitch(true);
 	font.setStyleHint(QFont::TypeWriter);
 	viewSourceTV->setFont(font);
-- 
2.1.4

Re: Enhancement Suggestion: Preamble Fixed-width Font

[Guillaume Munch]

Le 14/04/2016 12:13, Joel Kulesza a écrit :

On Wed, Feb 17, 2016 at 10:39 PM, Scott Kostyshak > wrote:

On Wed, Feb 17, 2016 at 10:11:27PM -0500, Richard Heck wrote:
> Seems to me a change better for 2.2.0, if Scott is all right with it.
Yes go ahead. And thanks for the patch.
Scott


Is this a feature that would have been included in 2.2.0rc1?  That was
my understanding but I'm not seeing it.




Yes it's there. Code is very now similar to the source panel. What font
do you see on the source panel?

Re: Enhancement Suggestion: Preamble Fixed-width Font

[Joel Kulesza]

On Wed, Feb 17, 2016 at 10:39 PM, Scott Kostyshak  wrote:

> On Wed, Feb 17, 2016 at 10:11:27PM -0500, Richard Heck wrote:
> > Seems to me a change better for 2.2.0, if Scott is all right with it.
> Yes go ahead. And thanks for the patch.
> Scott
>

Is this a feature that would have been included in 2.2.0rc1?  That was my
understanding but I'm not seeing it.

Thank you,
Joel

Re: Enhancement Suggestion: Preamble Fixed-width Font

[Scott Kostyshak]

On Wed, Feb 17, 2016 at 10:11:27PM -0500, Richard Heck wrote:
> On 02/17/2016 09:09 PM, Guillaume Munch wrote:
> > Le 18/02/2016 01:58, Richard Heck a écrit :
> >> On 02/17/2016 05:11 PM, Pavel Sanda wrote:
> >>> Guillaume Munch wrote:
>  The attached patch copies code from the source panel, so it is safe.
> >>> I don't know what is the current beta policy, if Scott is fine with
> >>> that it has my +1.
> >>
> >> Tested? If so, has my +1, too. (No time myself right now.)
> >>
> >
> > Yes. Thanks. I do not care whether it is for 2.2.0 or 2.2.1. Scott's
> > call.
> 
> Seems to me a change better for 2.2.0, if Scott is all right with it.

Yes go ahead. And thanks for the patch.

Scott


signature.asc
Description: PGP signature

Re: Enhancement Suggestion: Preamble Fixed-width Font

[Richard Heck]

On 02/17/2016 09:09 PM, Guillaume Munch wrote:
> Le 18/02/2016 01:58, Richard Heck a écrit :
>> On 02/17/2016 05:11 PM, Pavel Sanda wrote:
>>> Guillaume Munch wrote:
 The attached patch copies code from the source panel, so it is safe.
>>> I don't know what is the current beta policy, if Scott is fine with
>>> that it has my +1.
>>
>> Tested? If so, has my +1, too. (No time myself right now.)
>>
>
> Yes. Thanks. I do not care whether it is for 2.2.0 or 2.2.1. Scott's
> call.

Seems to me a change better for 2.2.0, if Scott is all right with it.

Richard

Re: Enhancement Suggestion: Preamble Fixed-width Font

[Guillaume Munch]

Le 18/02/2016 01:58, Richard Heck a écrit :

On 02/17/2016 05:11 PM, Pavel Sanda wrote:

Guillaume Munch wrote:

The attached patch copies code from the source panel, so it is safe.

I don't know what is the current beta policy, if Scott is fine with that it has 
my +1.


Tested? If so, has my +1, too. (No time myself right now.)



Yes. Thanks. I do not care whether it is for 2.2.0 or 2.2.1. Scott's call.

Re: Enhancement Suggestion: Preamble Fixed-width Font

[Richard Heck]

On 02/17/2016 05:11 PM, Pavel Sanda wrote:
> Guillaume Munch wrote:
>> The attached patch copies code from the source panel, so it is safe.
> I don't know what is the current beta policy, if Scott is fine with that it 
> has my +1.

Tested? If so, has my +1, too. (No time myself right now.)

rh

Re: Enhancement Suggestion: Preamble Fixed-width Font

[Pavel Sanda]

Guillaume Munch wrote:
> The attached patch copies code from the source panel, so it is safe.

I don't know what is the current beta policy, if Scott is fine with that
it has my +1.
Pavel

Re: Enhancement Suggestion: Preamble Fixed-width Font

[Guenter Milde]

On 2016-02-17, Guillaume Munch wrote:

> [-- Type: text/plain, Encoding: 8bit --]

> Le 17/02/2016 19:10, Pavel Sanda a écrit :
>> Joel Kulesza wrote:
>>> My suggestion is to change the default font of the Settings->Preamble text
>>> box to a fixed-width font because the content is effectively code.  This
>>> change should improve readability for those that make extensive use of the
>>> preamble.

>>> Going a step further with the topic: would it also make sense to disable
>>> (or make optional) line-wrapping in the preamble dialog?

>>> I would appreciate hearing your thoughts on this.

>> Seems like trivial and sensible fix, if anyone comes with patch it can make
>> it into 2.2.0/x.

+1 for the idea

> The attached patch copies code from the source panel, so it is safe.

I hope so, but would prefer someone with C++ experience to review.

Günter

Re: Enhancement Suggestion: Preamble Fixed-width Font

[Guillaume Munch]

Le 17/02/2016 19:10, Pavel Sanda a écrit :

Joel Kulesza wrote:

My suggestion is to change the default font of the Settings->Preamble text
box to a fixed-width font because the content is effectively code.  This
change should improve readability for those that make extensive use of the
preamble.

Going a step further with the topic: would it also make sense to disable
(or make optional) line-wrapping in the preamble dialog?

I would appreciate hearing your thoughts on this.


Seems like trivial and sensible fix, if anyone comes with patch it can make
it into 2.2.0/x.




The attached patch copies code from the source panel, so it is safe.


>From 3339ed951d8bec5ac1783182baca7d51f6516326 Mon Sep 17 00:00:00 2001
From: Guillaume Munch 
Date: Wed, 17 Feb 2016 21:45:44 +
Subject: [PATCH] Set the preamble in fixed-width font and without line breaks
 (#9966)

---
 src/frontends/qt4/GuiDocument.cpp | 5 +
 1 file changed, 5 insertions(+)

diff --git a/src/frontends/qt4/GuiDocument.cpp b/src/frontends/qt4/GuiDocument.cpp
index cf64849..60aee1c 100644
--- a/src/frontends/qt4/GuiDocument.cpp
+++ b/src/frontends/qt4/GuiDocument.cpp
@@ -453,6 +453,11 @@ PreambleModule::PreambleModule() : current_id_(0)
 	// This is not a memory leak. The object will be destroyed
 	// with this.
 	(void) new LaTeXHighlighter(preambleTE->document());
+	QFont font(guiApp->typewriterFontName());
+	font.setFixedPitch(true);
+	font.setStyleHint(QFont::TypeWriter);
+	preambleTE->setFont(font);
+	preambleTE->setWordWrapMode(QTextOption::NoWrap);
 	setFocusProxy(preambleTE);
 	connect(preambleTE, SIGNAL(textChanged()), this, SIGNAL(changed()));
 }
-- 
2.1.4

Re: Enhancement Suggestion: Preamble Fixed-width Font

[Pavel Sanda]

Joel Kulesza wrote:
> My suggestion is to change the default font of the Settings->Preamble text
> box to a fixed-width font because the content is effectively code.  This
> change should improve readability for those that make extensive use of the
> preamble.
> 
> Going a step further with the topic: would it also make sense to disable
> (or make optional) line-wrapping in the preamble dialog?
> 
> I would appreciate hearing your thoughts on this.

Seems like trivial and sensible fix, if anyone comes with patch it can make
it into 2.2.0/x.

Pavel

Enhancement Suggestion: Preamble Fixed-width Font

[Joel Kulesza]

LyX Developers,

I recently submitted an enhancement request through the bug tracker and it
was suggested I post here to initiate discussion on it.  The TRAC ticket
number is #9966 <http://www.lyx.org/trac/ticket/9966>.

My suggestion is to change the default font of the Settings->Preamble text
box to a fixed-width font because the content is effectively code.  This
change should improve readability for those that make extensive use of the
preamble.

Going a step further with the topic: would it also make sense to disable
(or make optional) line-wrapping in the preamble dialog?

I would appreciate hearing your thoughts on this.

Thank you,
Joel

Re: Corkboard/Non-linear workflow enhancement?

[Ketil Thorgersen]

Scott Kostyshak skostysh at lyx.org writes:

 
 On Mon, Oct 20, 2014 at 9:43 AM, Ketil Thorgersen lyx at rytmisk.net
wrote:
  Hi
 
  I have eagerly been awaiting the development of the Corboard module for Lyx
  outlined here: http://wiki.lyx.org/GSoC/NonLinearWriting in 2013 as a
  continuation of what Rob Oakes developed as Lyx-outline. I used to be using
  Lyx-outline but then this Google summer code project came up and everything
  stagnated... I would really hate to see this disappear as it was one of the
  most useful things ever for a researcher like myself.
 
  Does anyone know what is the status?
 
 Hi Ketil, this is the most recent that I've seen:
 http://comments.gmane.org/gmane.editors.lyx.devel/148955
 It looks like the code is in good shape. It just needs to be merged
 and some of the code needs to be refactored. So perhaps it's just a
 lack of developer time. You might try contacted Rob directly. I'm not
 sure he follows lyx-devel and he might want to know that there is
 interest.
 
 Also, please let us know if by chance you are willing to help.
 

Hi
Thanks for your reply! I have tried to contact Rob, but he has vanished it
seems - has not updated his homepage, twitter or launchpad
https://code.launchpad.net/~lyx-outline-devel. I will try to contact Xueqing
Shan  who got the Google summer code assignment and see if he knows anything.

I will be more than wiling to help with testing and translating, but I can
do nothing when it comes to coding unfortunately.

All the best
Ketil

Re: Corkboard/Non-linear workflow enhancement?

[Scott Kostyshak]

On Tue, Oct 21, 2014 at 5:02 AM, Ketil Thorgersen l...@rytmisk.net wrote:
 Scott Kostyshak skostysh at lyx.org writes:


 On Mon, Oct 20, 2014 at 9:43 AM, Ketil Thorgersen lyx at rytmisk.net
 wrote:
  Hi
 
  I have eagerly been awaiting the development of the Corboard module for Lyx
  outlined here: http://wiki.lyx.org/GSoC/NonLinearWriting in 2013 as a
  continuation of what Rob Oakes developed as Lyx-outline. I used to be using
  Lyx-outline but then this Google summer code project came up and everything
  stagnated... I would really hate to see this disappear as it was one of the
  most useful things ever for a researcher like myself.
 
  Does anyone know what is the status?

 Hi Ketil, this is the most recent that I've seen:
 http://comments.gmane.org/gmane.editors.lyx.devel/148955
 It looks like the code is in good shape. It just needs to be merged
 and some of the code needs to be refactored. So perhaps it's just a
 lack of developer time. You might try contacted Rob directly. I'm not
 sure he follows lyx-devel and he might want to know that there is
 interest.

 Also, please let us know if by chance you are willing to help.


 Hi
 Thanks for your reply! I have tried to contact Rob, but he has vanished it
 seems - has not updated his homepage, twitter or launchpad
 https://code.launchpad.net/~lyx-outline-devel. I will try to contact Xueqing
 Shan  who got the Google summer code assignment and see if he knows anything.

he - she

 I will be more than wiling to help with testing and translating, but I can
 do nothing when it comes to coding unfortunately.

 All the best
 Ketil

Sounds good. I'm interested in getting some news on this also. Thanks
for being interested and trying to push things forward.

Best,

Scott

Re: Corkboard/Non-linear workflow enhancement?

[Ketil Thorgersen]

Scott Kostyshak  lyx.org> writes:

> 
> On Mon, Oct 20, 2014 at 9:43 AM, Ketil Thorgersen  rytmisk.net>
wrote:
> > Hi
> >
> > I have eagerly been awaiting the development of the Corboard module for Lyx
> > outlined here: http://wiki.lyx.org/GSoC/NonLinearWriting in 2013 as a
> > continuation of what Rob Oakes developed as Lyx-outline. I used to be using
> > Lyx-outline but then this Google summer code project came up and everything
> > stagnated... I would really hate to see this disappear as it was one of the
> > most useful things ever for a researcher like myself.
> >
> > Does anyone know what is the status?
> 
> Hi Ketil, this is the most recent that I've seen:
> http://comments.gmane.org/gmane.editors.lyx.devel/148955
> It looks like the code is in good shape. It just needs to be merged
> and some of the code needs to be refactored. So perhaps it's just a
> lack of developer time. You might try contacted Rob directly. I'm not
> sure he follows lyx-devel and he might want to know that there is
> interest.
> 
> Also, please let us know if by chance you are willing to help.
> 

Hi
Thanks for your reply! I have tried to contact Rob, but he has vanished it
seems - has not updated his homepage, twitter or launchpad
https://code.launchpad.net/~lyx-outline-devel. I will try to contact Xueqing
Shan  who got the Google summer code assignment and see if he knows anything.

I will be more than wiling to help with testing and translating, but I can
do nothing when it comes to coding unfortunately.

All the best
Ketil

Re: Corkboard/Non-linear workflow enhancement?

[Scott Kostyshak]

On Tue, Oct 21, 2014 at 5:02 AM, Ketil Thorgersen  wrote:
> Scott Kostyshak  lyx.org> writes:
>
>>
>> On Mon, Oct 20, 2014 at 9:43 AM, Ketil Thorgersen  rytmisk.net>
> wrote:
>> > Hi
>> >
>> > I have eagerly been awaiting the development of the Corboard module for Lyx
>> > outlined here: http://wiki.lyx.org/GSoC/NonLinearWriting in 2013 as a
>> > continuation of what Rob Oakes developed as Lyx-outline. I used to be using
>> > Lyx-outline but then this Google summer code project came up and everything
>> > stagnated... I would really hate to see this disappear as it was one of the
>> > most useful things ever for a researcher like myself.
>> >
>> > Does anyone know what is the status?
>>
>> Hi Ketil, this is the most recent that I've seen:
>> http://comments.gmane.org/gmane.editors.lyx.devel/148955
>> It looks like the code is in good shape. It just needs to be merged
>> and some of the code needs to be refactored. So perhaps it's just a
>> lack of developer time. You might try contacted Rob directly. I'm not
>> sure he follows lyx-devel and he might want to know that there is
>> interest.
>>
>> Also, please let us know if by chance you are willing to help.
>>
>
> Hi
> Thanks for your reply! I have tried to contact Rob, but he has vanished it
> seems - has not updated his homepage, twitter or launchpad
> https://code.launchpad.net/~lyx-outline-devel. I will try to contact Xueqing
> Shan  who got the Google summer code assignment and see if he knows anything.

"he" -> "she"

> I will be more than wiling to help with testing and translating, but I can
> do nothing when it comes to coding unfortunately.
>
> All the best
> Ketil

Sounds good. I'm interested in getting some news on this also. Thanks
for being interested and trying to push things forward.

Best,

Scott

Corkboard/Non-linear workflow enhancement?

[Ketil Thorgersen]

Hi 

I have eagerly been awaiting the development of the Corboard module for Lyx
outlined here: http://wiki.lyx.org/GSoC/NonLinearWriting in 2013 as a
continuation of what Rob Oakes developed as Lyx-outline. I used to be using
Lyx-outline but then this Google summer code project came up and everything
stagnated... I would really hate to see this disappear as it was one of the
most useful things ever for a researcher like myself.

Does anyone know what is the status?

All the best!
Ketil

Re: Corkboard/Non-linear workflow enhancement?

[Scott Kostyshak]

On Mon, Oct 20, 2014 at 9:43 AM, Ketil Thorgersen l...@rytmisk.net wrote:
 Hi

 I have eagerly been awaiting the development of the Corboard module for Lyx
 outlined here: http://wiki.lyx.org/GSoC/NonLinearWriting in 2013 as a
 continuation of what Rob Oakes developed as Lyx-outline. I used to be using
 Lyx-outline but then this Google summer code project came up and everything
 stagnated... I would really hate to see this disappear as it was one of the
 most useful things ever for a researcher like myself.

 Does anyone know what is the status?

Hi Ketil, this is the most recent that I've seen:
http://comments.gmane.org/gmane.editors.lyx.devel/148955
It looks like the code is in good shape. It just needs to be merged
and some of the code needs to be refactored. So perhaps it's just a
lack of developer time. You might try contacted Rob directly. I'm not
sure he follows lyx-devel and he might want to know that there is
interest.

Also, please let us know if by chance you are willing to help.

Best,

Scott

Corkboard/Non-linear workflow enhancement?

[Ketil Thorgersen]

Hi 

I have eagerly been awaiting the development of the Corboard module for Lyx
outlined here: http://wiki.lyx.org/GSoC/NonLinearWriting in 2013 as a
continuation of what Rob Oakes developed as Lyx-outline. I used to be using
Lyx-outline but then this Google summer code project came up and everything
stagnated... I would really hate to see this disappear as it was one of the
most useful things ever for a researcher like myself.

Does anyone know what is the status?

All the best!
Ketil

Re: Corkboard/Non-linear workflow enhancement?

[Scott Kostyshak]

On Mon, Oct 20, 2014 at 9:43 AM, Ketil Thorgersen  wrote:
> Hi
>
> I have eagerly been awaiting the development of the Corboard module for Lyx
> outlined here: http://wiki.lyx.org/GSoC/NonLinearWriting in 2013 as a
> continuation of what Rob Oakes developed as Lyx-outline. I used to be using
> Lyx-outline but then this Google summer code project came up and everything
> stagnated... I would really hate to see this disappear as it was one of the
> most useful things ever for a researcher like myself.
>
> Does anyone know what is the status?

Hi Ketil, this is the most recent that I've seen:
http://comments.gmane.org/gmane.editors.lyx.devel/148955
It looks like the code is in good shape. It just needs to be merged
and some of the code needs to be refactored. So perhaps it's just a
lack of developer time. You might try contacted Rob directly. I'm not
sure he follows lyx-devel and he might want to know that there is
interest.

Also, please let us know if by chance you are willing to help.

Best,

Scott

Re: Copier enquiry/enhancement

[Richard Heck]

On 07/08/2014 02:09 AM, aparsloe wrote:
Is there a reason why the copier ext_copy.py in the LyX 
2.1.0/Resources/scripts folder does NOT have an option for copying to 
the same directory as the LyX file? At present the  copied files end 
up in a subdirectory of the directory containing the LyX file.


I have a use case where copying to the same directory as the LyX file 
is the natural thing to do. I've made a simple adjustment to the 
script so that it allows this option, but it involved some wriggling 
around permissions to get access to it. It would be good to have this 
possibility written-in to the script so that the option was there 
already for users (unless, that is, there is a strong reason for not 
providing it).


There's no reason that isn't an option. I didn't implement it that way 
because its generally our policy not to pollute the user's directory 
structure, and copying a bazillion image files would do that. But, as an 
option, it's fine.


Richard

Re: Copier enquiry/enhancement

[aparsloe]

On 9/07/2014 12:36 a.m., Richard Heck wrote:

On 07/08/2014 02:09 AM, aparsloe wrote:
Is there a reason why the copier ext_copy.py in the LyX 
2.1.0/Resources/scripts folder does NOT have an option for copying to 
the same directory as the LyX file? At present the  copied files end 
up in a subdirectory of the directory containing the LyX file.


I have a use case where copying to the same directory as the LyX file 
is the natural thing to do. I've made a simple adjustment to the 
script so that it allows this option, but it involved some wriggling 
around permissions to get access to it. It would be good to have this 
possibility written-in to the script so that the option was there 
already for users (unless, that is, there is a strong reason for not 
providing it).


There's no reason that isn't an option. I didn't implement it that way 
because its generally our policy not to pollute the user's directory 
structure, and copying a bazillion image files would do that. But, as 
an option, it's fine.


Richard
I understand the pollution rationale and suspected that was the reason 
for the LyXconv subdirectory. In my case I have one file (plus pdf) to 
copy and burying it in a subdirectory seems excessive. My hope is that 
the adjustment is made to ext_copy.py so that the option is available to 
users for this kind of situation. Then I could refer to this copier and 
its new option in the documentation to a latex package I've written.


(I've only just realised that the reason I couldn't get it to work from 
the scripts folder of my personal LyX directory -- hence the battle with 
permissions -- is that lyxpreview_tools.py also needs to be copied 
across. I remember an item from a science class in my first year at high 
school about 55 years ago: simple animals learn slowly and soon forget.)


Andrew

Re: Copier enquiry/enhancement

[Richard Heck]

On 07/08/2014 02:09 AM, aparsloe wrote:
Is there a reason why the copier ext_copy.py in the LyX 
2.1.0/Resources/scripts folder does NOT have an option for copying to 
the same directory as the LyX file? At present the  copied files end 
up in a subdirectory of the directory containing the LyX file.


I have a use case where copying to the same directory as the LyX file 
is the natural thing to do. I've made a simple adjustment to the 
script so that it allows this option, but it involved some wriggling 
around permissions to get access to it. It would be good to have this 
possibility written-in to the script so that the option was there 
already for users (unless, that is, there is a strong reason for not 
providing it).


There's no reason that isn't an option. I didn't implement it that way 
because its generally our policy not to "pollute" the user's directory 
structure, and copying a bazillion image files would do that. But, as an 
option, it's fine.


Richard

Re: Copier enquiry/enhancement

[aparsloe]

On 9/07/2014 12:36 a.m., Richard Heck wrote:

On 07/08/2014 02:09 AM, aparsloe wrote:
Is there a reason why the copier ext_copy.py in the LyX 
2.1.0/Resources/scripts folder does NOT have an option for copying to 
the same directory as the LyX file? At present the  copied files end 
up in a subdirectory of the directory containing the LyX file.


I have a use case where copying to the same directory as the LyX file 
is the natural thing to do. I've made a simple adjustment to the 
script so that it allows this option, but it involved some wriggling 
around permissions to get access to it. It would be good to have this 
possibility written-in to the script so that the option was there 
already for users (unless, that is, there is a strong reason for not 
providing it).


There's no reason that isn't an option. I didn't implement it that way 
because its generally our policy not to "pollute" the user's directory 
structure, and copying a bazillion image files would do that. But, as 
an option, it's fine.


Richard
I understand the pollution rationale and suspected that was the reason 
for the LyXconv subdirectory. In my case I have one file (plus pdf) to 
copy and burying it in a subdirectory seems excessive. My hope is that 
the adjustment is made to ext_copy.py so that the option is available to 
users for this kind of situation. Then I could refer to this copier and 
its new option in the documentation to a latex package I've written.


(I've only just realised that the reason I couldn't get it to work from 
the scripts folder of my personal LyX directory -- hence the battle with 
permissions -- is that lyxpreview_tools.py also needs to be copied 
across. I remember an item from a science class in my first year at high 
school about 55 years ago: "simple animals learn slowly and soon forget".)


Andrew

Copier enquiry/enhancement

[aparsloe]

Is there a reason why the copier ext_copy.py in the LyX 
2.1.0/Resources/scripts folder does NOT have an option for copying to 
the same directory as the LyX file? At present the  copied files end up 
in a subdirectory of the directory containing the LyX file.


I have a use case where copying to the same directory as the LyX file is 
the natural thing to do. I've made a simple adjustment to the script so 
that it allows this option, but it involved some wriggling around 
permissions to get access to it. It would be good to have this 
possibility written-in to the script so that the option was there 
already for users (unless, that is, there is a strong reason for not 
providing it).


Andrew

Copier enquiry/enhancement

[aparsloe]

Is there a reason why the copier ext_copy.py in the LyX 
2.1.0/Resources/scripts folder does NOT have an option for copying to 
the same directory as the LyX file? At present the  copied files end up 
in a subdirectory of the directory containing the LyX file.


I have a use case where copying to the same directory as the LyX file is 
the natural thing to do. I've made a simple adjustment to the script so 
that it allows this option, but it involved some wriggling around 
permissions to get access to it. It would be good to have this 
possibility written-in to the script so that the option was there 
already for users (unless, that is, there is a strong reason for not 
providing it).


Andrew

Enhancement request: parent-child relations among preview insets

[aparsloe]

Suppose you have a preview inset wrapped around some latex that gives a 
value to a control sequence, call it \foo. If you put \foo in ERT later 
in the text and wrap a preview inset around that, the value of \foo is 
not shown until the buffer is reloaded (when *every* preview inset is 
re-evaluated).  If you change the contents of the initial preview inset, 
so that the value of \foo changes, that change is not reflected in the 
later use of \foo until the document is reloaded again (and every 
preview inset is re-evaluated). Looking at the lyxpreview.tex files in 
the temporary directory where LyX does its work, it doesn't look hard to 
my c++less eyes to include the child (or dependent) preview items along 
with the parent so that they are all updated at the same time, but 
unconnected preview insets are left undisturbed.


Two ways come to mind:

1. number all preview insets from 1 from the start of the document. 
(Perhaps that is done already?) Right-clicking on a preview inset would 
show  two items, one giving the number of the inset, the other having a 
slot for the number of a parent preview inset. The parent would then 
need to be informed of the child's number, and one would need to check 
that the parent's number is smaller than the child's, that it occurs 
earlier in the document. Insertion of a new preview inset early in the 
document would require updating all numbers.


2. alternatively, make preview insets label-able and 
cross-reference-able, although in the nature of a preview inset the 
labels and references should not be displayed, but be accessible by 
right-clicking. LyX already keeps track of parent-child relations among 
labels and references. A change to a labelled preview inset would send 
not only it to lyxpreview.tex but all preview insets referencing it. 
Using labels would avoid the renumbering problem if a new preview inset 
is inserted early in the document, although I don't know how you check 
that the parent precedes the child in the document.


Andrew

Enhancement request: parent-child relations among preview insets

[aparsloe]

Suppose you have a preview inset wrapped around some latex that gives a 
value to a control sequence, call it \foo. If you put \foo in ERT later 
in the text and wrap a preview inset around that, the value of \foo is 
not shown until the buffer is reloaded (when *every* preview inset is 
re-evaluated).  If you change the contents of the initial preview inset, 
so that the value of \foo changes, that change is not reflected in the 
later use of \foo until the document is reloaded again (and every 
preview inset is re-evaluated). Looking at the lyxpreview.tex files in 
the temporary directory where LyX does its work, it doesn't look hard to 
my c++less eyes to include the child (or dependent) preview items along 
with the parent so that they are all updated at the same time, but 
unconnected preview insets are left undisturbed.


Two ways come to mind:

1. number all preview insets from 1 from the start of the document. 
(Perhaps that is done already?) Right-clicking on a preview inset would 
show  two items, one giving the number of the inset, the other having a 
slot for the number of a parent preview inset. The parent would then 
need to be informed of the child's number, and one would need to check 
that the parent's number is smaller than the child's, that it occurs 
earlier in the document. Insertion of a new preview inset early in the 
document would require updating all numbers.


2. alternatively, make preview insets label-able and 
cross-reference-able, although in the nature of a preview inset the 
labels and references should not be displayed, but be accessible by 
right-clicking. LyX already keeps track of parent-child relations among 
labels and references. A change to a labelled preview inset would send 
not only it to lyxpreview.tex but all preview insets referencing it. 
Using labels would avoid the renumbering problem if a new preview inset 
is inserted early in the document, although I don't know how you check 
that the parent precedes the child in the document.


Andrew

Re: Re: enhancement request: support biblatex

[Neal Becker]

José Matos wrote:

 On Monday 28 April 2014 08:13:49 Neal Becker wrote:
 https://bugzilla.redhat.com/show_bug.cgi?id=584063
 
 Seems fedora is not shipping biber, it is still an open bug
 
 Why don't you install the package from the copr repository pointed there?
 
 With some feedback it will possible to place this package in Fedora.
 
 FWIW I had/have a copr repository for lyx-2.1 before it was released.
 
 Regards,
Oh thanks!  I didn't know about biber in copr.

Re: Re: enhancement request: support biblatex

[Neal Becker]

José Matos wrote:

> On Monday 28 April 2014 08:13:49 Neal Becker wrote:
>> https://bugzilla.redhat.com/show_bug.cgi?id=584063
>> 
>> Seems fedora is not shipping biber, it is still an open bug
> 
> Why don't you install the package from the copr repository pointed there?
> 
> With some feedback it will possible to place this package in Fedora.
> 
> FWIW I had/have a copr repository for lyx-2.1 before it was released.
> 
> Regards,
Oh thanks!  I didn't know about biber in copr.

Re: Re: enhancement request: support biblatex

[José Matos]

On Monday 28 April 2014 08:13:49 Neal Becker wrote:
 https://bugzilla.redhat.com/show_bug.cgi?id=584063
 
 Seems fedora is not shipping biber, it is still an open bug

Why don't you install the package from the copr repository pointed there?

With some feedback it will possible to place this package in Fedora.

FWIW I had/have a copr repository for lyx-2.1 before it was released.

Regards,
-- 
José Abílio

Re: Re: enhancement request: support biblatex

[José Matos]

On Monday 28 April 2014 08:13:49 Neal Becker wrote:
> https://bugzilla.redhat.com/show_bug.cgi?id=584063
> 
> Seems fedora is not shipping biber, it is still an open bug

Why don't you install the package from the copr repository pointed there?

With some feedback it will possible to place this package in Fedora.

FWIW I had/have a copr repository for lyx-2.1 before it was released.

Regards,
-- 
José Abílio

enhancement request: support biblatex

[Neal Becker]

I have read that biblatex is the way of the future.  Unfortunately, I 
understand 
that lyx does not currently support biblatex.

Re: enhancement request: support biblatex

[stefano franchi]

On Mon, Apr 28, 2014 at 6:29 AM, Neal Becker ndbeck...@gmail.com wrote:

 I have read that biblatex is the way of the future.  Unfortunately, I
 understand
 that lyx does not currently support biblatex.


Lyx supports biblatex *partially*. You can use biblatex in lyx with a few
workarounds, all detailed in the corresponding wiki page:
http://wiki.lyx.org/BibTeX/Biblatex.

In short, you have to load biblatex and the bib files manually in the
preamble, and you have to enter a command in ERT in your text to instruct
LyX to print out the list of references. You are still able to enter
references through a dialog box as you would when using bibtex. In
practical terms, using biblatex in lyx is not much different from using
bibtex, at least if you use the standard styles and citing commands.
Having full support would be great, but the current setup is more than
usable.


Cheers,

Stefano



-- 
__
Stefano Franchi
Associate Research Professor
Department of Hispanic Studies Ph:   +1 (979) 845-2125
Texas AM University  Fax:  +1 (979) 845-6421
College Station, Texas, USA

stef...@tamu.edu
http://stefano.cleinias.org

Re: enhancement request: support biblatex

[Neal Becker]

stefano franchi wrote:

 On Mon, Apr 28, 2014 at 6:29 AM, Neal Becker ndbeck...@gmail.com wrote:
 
 I have read that biblatex is the way of the future.  Unfortunately, I
 understand
 that lyx does not currently support biblatex.

 
 Lyx supports biblatex *partially*. You can use biblatex in lyx with a few
 workarounds, all detailed in the corresponding wiki page:
 http://wiki.lyx.org/BibTeX/Biblatex.
 
 In short, you have to load biblatex and the bib files manually in the
 preamble, and you have to enter a command in ERT in your text to instruct
 LyX to print out the list of references. You are still able to enter
 references through a dialog box as you would when using bibtex. In
 practical terms, using biblatex in lyx is not much different from using
 bibtex, at least if you use the standard styles and citing commands.
 Having full support would be great, but the current setup is more than
 usable.
 
 
 Cheers,
 
 Stefano
 
 
 

Oh, thanks!

One note.  It seems biber is not supported at least on Fedora linux.  Fedora 
ships texlive 2013.  I can't seem to find any biber there, and from what 
messages I found on google, I think maybe it's not maintained?  I have used 
biblatex using bibtex backend instead of biber.

Re: enhancement request: support biblatex

[stefano franchi]

On Mon, Apr 28, 2014 at 7:02 AM, Neal Becker ndbeck...@gmail.com wrote:

 stefano franchi wrote:

  On Mon, Apr 28, 2014 at 6:29 AM, Neal Becker ndbeck...@gmail.com
 wrote:
 
  I have read that biblatex is the way of the future.  Unfortunately, I
  understand
  that lyx does not currently support biblatex.
 
 
  Lyx supports biblatex *partially*. You can use biblatex in lyx with a few
  workarounds, all detailed in the corresponding wiki page:
  http://wiki.lyx.org/BibTeX/Biblatex.
 
  In short, you have to load biblatex and the bib files manually in the
  preamble, and you have to enter a command in ERT in your text to instruct
  LyX to print out the list of references. You are still able to enter
  references through a dialog box as you would when using bibtex. In
  practical terms, using biblatex in lyx is not much different from using
  bibtex, at least if you use the standard styles and citing commands.
  Having full support would be great, but the current setup is more than
  usable.
 
 
  Cheers,
 
  Stefano
 
 
 

 Oh, thanks!

 One note.  It seems biber is not supported at least on Fedora linux.
  Fedora
 ships texlive 2013.  I can't seem to find any biber there, and from what
 messages I found on google, I think maybe it's not maintained?  I have used
 biblatex using bibtex backend instead of biber.


Biber is under active development, actually, and well maintained. I use the
version distributed with TexLive 2013, which is now frozen at 1.8 (TexLive
2013 is frozen, since the TexLive 2014 is about to come out). I don't know
how Fedora packages Texlive (I'm on Archlnux), perhaps it behaves like
Debian/Ubuntu and splits it into several packages? In hat case you may be
missing one of the extra packages.

Cheers,

Stefano


-- 
__
Stefano Franchi
Associate Research Professor
Department of Hispanic Studies Ph:   +1 (979) 845-2125
Texas AM University  Fax:  +1 (979) 845-6421
College Station, Texas, USA

stef...@tamu.edu
http://stefano.cleinias.org

Re: enhancement request: support biblatex

[Neal Becker]

https://bugzilla.redhat.com/show_bug.cgi?id=584063

Seems fedora is not shipping biber, it is still an open bug


On Mon, Apr 28, 2014 at 8:07 AM, stefano franchi
stefano.fran...@gmail.comwrote:




 On Mon, Apr 28, 2014 at 7:02 AM, Neal Becker ndbeck...@gmail.com wrote:

 stefano franchi wrote:

  On Mon, Apr 28, 2014 at 6:29 AM, Neal Becker ndbeck...@gmail.com
 wrote:
 
  I have read that biblatex is the way of the future.  Unfortunately, I
  understand
  that lyx does not currently support biblatex.
 
 
  Lyx supports biblatex *partially*. You can use biblatex in lyx with a
 few
  workarounds, all detailed in the corresponding wiki page:
  http://wiki.lyx.org/BibTeX/Biblatex.
 
  In short, you have to load biblatex and the bib files manually in the
  preamble, and you have to enter a command in ERT in your text to
 instruct
  LyX to print out the list of references. You are still able to enter
  references through a dialog box as you would when using bibtex. In
  practical terms, using biblatex in lyx is not much different from using
  bibtex, at least if you use the standard styles and citing commands.
  Having full support would be great, but the current setup is more than
  usable.
 
 
  Cheers,
 
  Stefano
 
 
 

 Oh, thanks!

 One note.  It seems biber is not supported at least on Fedora linux.
  Fedora
 ships texlive 2013.  I can't seem to find any biber there, and from what
 messages I found on google, I think maybe it's not maintained?  I have
 used
 biblatex using bibtex backend instead of biber.


 Biber is under active development, actually, and well maintained. I use
 the version distributed with TexLive 2013, which is now frozen at 1.8
 (TexLive 2013 is frozen, since the TexLive 2014 is about to come out). I
 don't know how Fedora packages Texlive (I'm on Archlnux), perhaps it
 behaves like Debian/Ubuntu and splits it into several packages? In hat case
 you may be missing one of the extra packages.

 Cheers,

 Stefano


 --
 __
 Stefano Franchi
 Associate Research Professor
 Department of Hispanic Studies Ph:   +1 (979) 845-2125
 Texas AM University  Fax:  +1 (979) 845-6421
 College Station, Texas, USA

 stef...@tamu.edu
 http://stefano.cleinias.org

Re: enhancement request: support biblatex

[stefano franchi]

On Mon, Apr 28, 2014 at 7:13 AM, Neal Becker ndbeck...@gmail.com wrote:

 https://bugzilla.redhat.com/show_bug.cgi?id=584063

 Seems fedora is not shipping biber, it is still an open bug



You can always install it from their site, if you are willing to bypass
Fedora's package management system:
http://biblatex-biber.sourceforge.net/

Cheers,

S.

-- 
__
Stefano Franchi
Associate Research Professor
Department of Hispanic Studies Ph:   +1 (979) 845-2125
Texas AM University  Fax:  +1 (979) 845-6421
College Station, Texas, USA

stef...@tamu.edu
http://stefano.cleinias.org

Re: enhancement request: support biblatex

[Richard Heck]

On 04/28/2014 08:37 AM, stefano franchi wrote:




On Mon, Apr 28, 2014 at 7:13 AM, Neal Becker ndbeck...@gmail.com 
mailto:ndbeck...@gmail.com wrote:


https://bugzilla.redhat.com/show_bug.cgi?id=584063

Seems fedora is not shipping biber, it is still an open bug



You can always install it from their site, if you are willing to 
bypass Fedora's package management system:

http://biblatex-biber.sourceforge.net/


Recommended course would be to install it under /usr/local/. Then there 
is no potential conflict.


Richard

enhancement request: support biblatex

[Neal Becker]

I have read that biblatex is the way of the future.  Unfortunately, I 
understand 
that lyx does not currently support biblatex.

Re: enhancement request: support biblatex

[stefano franchi]

On Mon, Apr 28, 2014 at 6:29 AM, Neal Becker  wrote:

> I have read that biblatex is the way of the future.  Unfortunately, I
> understand
> that lyx does not currently support biblatex.
>

Lyx supports biblatex *partially*. You can use biblatex in lyx with a few
workarounds, all detailed in the corresponding wiki page:
http://wiki.lyx.org/BibTeX/Biblatex.

In short, you have to load biblatex and the bib files manually in the
preamble, and you have to enter a command in ERT in your text to instruct
LyX to print out the list of references. You are still able to enter
references through a dialog box as you would when using bibtex. In
practical terms, using biblatex in lyx is not much different from using
bibtex, at least if you use the standard styles and citing commands.
Having full support would be great, but the current setup is more than
usable.


Cheers,

Stefano



-- 
__
Stefano Franchi
Associate Research Professor
Department of Hispanic Studies Ph:   +1 (979) 845-2125
Texas A University  Fax:  +1 (979) 845-6421
College Station, Texas, USA

stef...@tamu.edu
http://stefano.cleinias.org

Re: enhancement request: support biblatex

[Neal Becker]

stefano franchi wrote:

> On Mon, Apr 28, 2014 at 6:29 AM, Neal Becker  wrote:
> 
>> I have read that biblatex is the way of the future.  Unfortunately, I
>> understand
>> that lyx does not currently support biblatex.
>>
> 
> Lyx supports biblatex *partially*. You can use biblatex in lyx with a few
> workarounds, all detailed in the corresponding wiki page:
> http://wiki.lyx.org/BibTeX/Biblatex.
> 
> In short, you have to load biblatex and the bib files manually in the
> preamble, and you have to enter a command in ERT in your text to instruct
> LyX to print out the list of references. You are still able to enter
> references through a dialog box as you would when using bibtex. In
> practical terms, using biblatex in lyx is not much different from using
> bibtex, at least if you use the standard styles and citing commands.
> Having full support would be great, but the current setup is more than
> usable.
> 
> 
> Cheers,
> 
> Stefano
> 
> 
> 

Oh, thanks!

One note.  It seems biber is not supported at least on Fedora linux.  Fedora 
ships texlive 2013.  I can't seem to find any biber there, and from what 
messages I found on google, I think maybe it's not maintained?  I have used 
biblatex using bibtex backend instead of biber.

Re: enhancement request: support biblatex

[stefano franchi]

On Mon, Apr 28, 2014 at 7:02 AM, Neal Becker  wrote:

> stefano franchi wrote:
>
> > On Mon, Apr 28, 2014 at 6:29 AM, Neal Becker 
> wrote:
> >
> >> I have read that biblatex is the way of the future.  Unfortunately, I
> >> understand
> >> that lyx does not currently support biblatex.
> >>
> >
> > Lyx supports biblatex *partially*. You can use biblatex in lyx with a few
> > workarounds, all detailed in the corresponding wiki page:
> > http://wiki.lyx.org/BibTeX/Biblatex.
> >
> > In short, you have to load biblatex and the bib files manually in the
> > preamble, and you have to enter a command in ERT in your text to instruct
> > LyX to print out the list of references. You are still able to enter
> > references through a dialog box as you would when using bibtex. In
> > practical terms, using biblatex in lyx is not much different from using
> > bibtex, at least if you use the standard styles and citing commands.
> > Having full support would be great, but the current setup is more than
> > usable.
> >
> >
> > Cheers,
> >
> > Stefano
> >
> >
> >
>
> Oh, thanks!
>
> One note.  It seems biber is not supported at least on Fedora linux.
>  Fedora
> ships texlive 2013.  I can't seem to find any biber there, and from what
> messages I found on google, I think maybe it's not maintained?  I have used
> biblatex using bibtex backend instead of biber.
>
>
Biber is under active development, actually, and well maintained. I use the
version distributed with TexLive 2013, which is now frozen at 1.8 (TexLive
2013 is frozen, since the TexLive 2014 is about to come out). I don't know
how Fedora packages Texlive (I'm on Archlnux), perhaps it behaves like
Debian/Ubuntu and splits it into several packages? In hat case you may be
missing one of the extra packages.

Cheers,

Stefano


-- 
__
Stefano Franchi
Associate Research Professor
Department of Hispanic Studies Ph:   +1 (979) 845-2125
Texas A University  Fax:  +1 (979) 845-6421
College Station, Texas, USA

stef...@tamu.edu
http://stefano.cleinias.org

Re: enhancement request: support biblatex

[Neal Becker]

https://bugzilla.redhat.com/show_bug.cgi?id=584063

Seems fedora is not shipping biber, it is still an open bug


On Mon, Apr 28, 2014 at 8:07 AM, stefano franchi
wrote:

>
>
>
> On Mon, Apr 28, 2014 at 7:02 AM, Neal Becker  wrote:
>
>> stefano franchi wrote:
>>
>> > On Mon, Apr 28, 2014 at 6:29 AM, Neal Becker 
>> wrote:
>> >
>> >> I have read that biblatex is the way of the future.  Unfortunately, I
>> >> understand
>> >> that lyx does not currently support biblatex.
>> >>
>> >
>> > Lyx supports biblatex *partially*. You can use biblatex in lyx with a
>> few
>> > workarounds, all detailed in the corresponding wiki page:
>> > http://wiki.lyx.org/BibTeX/Biblatex.
>> >
>> > In short, you have to load biblatex and the bib files manually in the
>> > preamble, and you have to enter a command in ERT in your text to
>> instruct
>> > LyX to print out the list of references. You are still able to enter
>> > references through a dialog box as you would when using bibtex. In
>> > practical terms, using biblatex in lyx is not much different from using
>> > bibtex, at least if you use the standard styles and citing commands.
>> > Having full support would be great, but the current setup is more than
>> > usable.
>> >
>> >
>> > Cheers,
>> >
>> > Stefano
>> >
>> >
>> >
>>
>> Oh, thanks!
>>
>> One note.  It seems biber is not supported at least on Fedora linux.
>>  Fedora
>> ships texlive 2013.  I can't seem to find any biber there, and from what
>> messages I found on google, I think maybe it's not maintained?  I have
>> used
>> biblatex using bibtex backend instead of biber.
>>
>>
> Biber is under active development, actually, and well maintained. I use
> the version distributed with TexLive 2013, which is now frozen at 1.8
> (TexLive 2013 is frozen, since the TexLive 2014 is about to come out). I
> don't know how Fedora packages Texlive (I'm on Archlnux), perhaps it
> behaves like Debian/Ubuntu and splits it into several packages? In hat case
> you may be missing one of the extra packages.
>
> Cheers,
>
> Stefano
>
>
> --
> __
> Stefano Franchi
> Associate Research Professor
> Department of Hispanic Studies Ph:   +1 (979) 845-2125
> Texas A University  Fax:  +1 (979) 845-6421
> College Station, Texas, USA
>
> stef...@tamu.edu
> http://stefano.cleinias.org
>

Re: enhancement request: support biblatex

[stefano franchi]

On Mon, Apr 28, 2014 at 7:13 AM, Neal Becker  wrote:

> https://bugzilla.redhat.com/show_bug.cgi?id=584063
>
> Seems fedora is not shipping biber, it is still an open bug
>
>

You can always install it from their site, if you are willing to bypass
Fedora's package management system:
http://biblatex-biber.sourceforge.net/

Cheers,

S.

-- 
__
Stefano Franchi
Associate Research Professor
Department of Hispanic Studies Ph:   +1 (979) 845-2125
Texas A University  Fax:  +1 (979) 845-6421
College Station, Texas, USA

stef...@tamu.edu
http://stefano.cleinias.org

Re: enhancement request: support biblatex

[Richard Heck]

On 04/28/2014 08:37 AM, stefano franchi wrote:




On Mon, Apr 28, 2014 at 7:13 AM, Neal Becker > wrote:


https://bugzilla.redhat.com/show_bug.cgi?id=584063

Seems fedora is not shipping biber, it is still an open bug



You can always install it from their site, if you are willing to 
bypass Fedora's package management system:

http://biblatex-biber.sourceforge.net/


Recommended course would be to install it under /usr/local/. Then there 
is no potential conflict.


Richard

Re: [LyX/master] Adding wrap-around pop-up question to simple find and replace dialog (fixing enhancement request #1262).

[Tommaso Cucinotta]

On 21/07/13 19:11, Scott Kostyshak wrote:
 Thanks, Tommaso. I tested and this works very well. One minor thing
 that is inconsistent with Advanced Find is that if you search for a
 string that is nowhere in the document and you click on yes to the
 wrap search dialog, Advanced Find does not move the cursor from its
 original position; Normal Find moves the cursor to the beginning of
 the buffer.

Right, I just fixed that as well in [b32ce2cf/lyxgit].

T.

Re: [LyX/master] Adding wrap-around pop-up question to simple find and replace dialog (fixing enhancement request #1262).

[Scott Kostyshak]

On Mon, Jul 22, 2013 at 6:58 PM, Tommaso Cucinotta tomm...@lyx.org wrote:
 On 21/07/13 19:11, Scott Kostyshak wrote:
 Thanks, Tommaso. I tested and this works very well. One minor thing
 that is inconsistent with Advanced Find is that if you search for a
 string that is nowhere in the document and you click on yes to the
 wrap search dialog, Advanced Find does not move the cursor from its
 original position; Normal Find moves the cursor to the beginning of
 the buffer.

 Right, I just fixed that as well in [b32ce2cf/lyxgit].

Works well. The cursor does blink to the beginning, but this is not
worth fixing.

Thanks,

Scott

Re: [LyX/master] Adding wrap-around pop-up question to simple find and replace dialog (fixing enhancement request #1262).

[Tommaso Cucinotta]

On 23/07/13 00:34, Scott Kostyshak wrote:
 Right, I just fixed that as well in [b32ce2cf/lyxgit].
 
 Works well. The cursor does blink to the beginning, but this is not
 worth fixing.

Yeah, I noticed that, but it's something belonging to a dimension unknown to me 
:-).
For now, I prefer to address other problems with Adv FR, I'm seeing they're 
slowly coming in, as people use it...

T.

Re: [LyX/master] Adding wrap-around pop-up question to simple find and replace dialog (fixing enhancement request #1262).

[Scott Kostyshak]

On Mon, Jul 22, 2013 at 8:27 PM, Tommaso Cucinotta tomm...@lyx.org wrote:
 On 23/07/13 00:34, Scott Kostyshak wrote:
 Right, I just fixed that as well in [b32ce2cf/lyxgit].

 Works well. The cursor does blink to the beginning, but this is not
 worth fixing.

 Yeah, I noticed that, but it's something belonging to a dimension unknown to 
 me :-).
 For now, I prefer to address other problems with Adv FR

Yes, that is a much better use of time.

 I'm seeing they're slowly coming in, as people use it...

Yes, this is good to see. I get the impression that many people use
Adv FR as their main FR, even for simple queries.

Scott

Re: [LyX/master] Adding wrap-around pop-up question to simple find and replace dialog (fixing enhancement request #1262).

[Tommaso Cucinotta]

On 23/07/13 02:01, Scott Kostyshak wrote:
 Yes, this is good to see. I get the impression that many people use
 Adv FR as their main FR, even for simple queries.

This sounds good, as that was the original intention, to replace the simple 
FR. This duplication of features among the 2 worlds seems a bit wasteful so 
far.

T.

Re: [LyX/master] Adding wrap-around pop-up question to simple find and replace dialog (fixing enhancement request #1262).

[Tommaso Cucinotta]

On 21/07/13 19:11, Scott Kostyshak wrote:
> Thanks, Tommaso. I tested and this works very well. One minor thing
> that is inconsistent with Advanced Find is that if you search for a
> string that is nowhere in the document and you click on "yes" to the
> "wrap search" dialog, Advanced Find does not move the cursor from its
> original position; Normal Find moves the cursor to the beginning of
> the buffer.

Right, I just fixed that as well in [b32ce2cf/lyxgit].

T.

Re: [LyX/master] Adding wrap-around pop-up question to simple find and replace dialog (fixing enhancement request #1262).

[Scott Kostyshak]

On Mon, Jul 22, 2013 at 6:58 PM, Tommaso Cucinotta  wrote:
> On 21/07/13 19:11, Scott Kostyshak wrote:
>> Thanks, Tommaso. I tested and this works very well. One minor thing
>> that is inconsistent with Advanced Find is that if you search for a
>> string that is nowhere in the document and you click on "yes" to the
>> "wrap search" dialog, Advanced Find does not move the cursor from its
>> original position; Normal Find moves the cursor to the beginning of
>> the buffer.
>
> Right, I just fixed that as well in [b32ce2cf/lyxgit].

Works well. The cursor does blink to the beginning, but this is not
worth fixing.

Thanks,

Scott

Re: [LyX/master] Adding wrap-around pop-up question to simple find and replace dialog (fixing enhancement request #1262).

[Tommaso Cucinotta]

On 23/07/13 00:34, Scott Kostyshak wrote:
>> Right, I just fixed that as well in [b32ce2cf/lyxgit].
> 
> Works well. The cursor does blink to the beginning, but this is not
> worth fixing.

Yeah, I noticed that, but it's something belonging to a dimension unknown to me 
:-).
For now, I prefer to address other problems with Adv F, I'm seeing they're 
slowly coming in, as people use it...

T.

Re: [LyX/master] Adding wrap-around pop-up question to simple find and replace dialog (fixing enhancement request #1262).

[Scott Kostyshak]

On Mon, Jul 22, 2013 at 8:27 PM, Tommaso Cucinotta  wrote:
> On 23/07/13 00:34, Scott Kostyshak wrote:
>>> Right, I just fixed that as well in [b32ce2cf/lyxgit].
>>
>> Works well. The cursor does blink to the beginning, but this is not
>> worth fixing.
>
> Yeah, I noticed that, but it's something belonging to a dimension unknown to 
> me :-).
> For now, I prefer to address other problems with Adv F

Yes, that is a much better use of time.

> I'm seeing they're slowly coming in, as people use it...

Yes, this is good to see. I get the impression that many people use
Adv F as their main F, even for simple queries.

Scott

Re: [LyX/master] Adding wrap-around pop-up question to simple find and replace dialog (fixing enhancement request #1262).

[Tommaso Cucinotta]

On 23/07/13 02:01, Scott Kostyshak wrote:
> Yes, this is good to see. I get the impression that many people use
> Adv F as their main F, even for simple queries.

This sounds good, as that was the original intention, to replace the simple 
F This duplication of features among the 2 worlds seems a bit wasteful so 
far.

T.

Re: [LyX/master] Adding wrap-around pop-up question to simple find and replace dialog (fixing enhancement request #1262).

[Scott Kostyshak]

On Sun, Jul 21, 2013 at 12:53 PM, Tommaso Cucinotta tomm...@lyx.org wrote:
 commit 2a86379ea7c589a75ff84d86755d214f45748550
 Author: Tommaso Cucinotta tomm...@lyx.org
 Date:   Sun Jul 21 17:51:53 2013 +0100

 Adding wrap-around pop-up question to simple find and replace dialog 
 (fixing enhancement request #1262).

Thanks, Tommaso. I tested and this works very well. One minor thing
that is inconsistent with Advanced Find is that if you search for a
string that is nowhere in the document and you click on yes to the
wrap search dialog, Advanced Find does not move the cursor from its
original position; Normal Find moves the cursor to the beginning of
the buffer.

Scott

Re: [LyX/master] Adding wrap-around pop-up question to simple find and replace dialog (fixing enhancement request #1262).

[Scott Kostyshak]

On Sun, Jul 21, 2013 at 12:53 PM, Tommaso Cucinotta <tomm...@lyx.org> wrote:
> commit 2a86379ea7c589a75ff84d86755d214f45748550
> Author: Tommaso Cucinotta <tomm...@lyx.org>
> Date:   Sun Jul 21 17:51:53 2013 +0100
>
> Adding wrap-around pop-up question to simple find and replace dialog 
> (fixing enhancement request #1262).

Thanks, Tommaso. I tested and this works very well. One minor thing
that is inconsistent with Advanced Find is that if you search for a
string that is nowhere in the document and you click on "yes" to the
"wrap search" dialog, Advanced Find does not move the cursor from its
original position; Normal Find moves the cursor to the beginning of
the buffer.

Scott

Re: GSoC: UI Improvement and Non-Linear Writing Enhancement

[Pavel Sanda]

Cyrille Artho wrote:
 I agree that it's much better to update progress on the GSoC projects on 
 the wiki. First, we need the original proposal (on Melange) as a reference; 

Note that original proposal are not visible to non-mentors, so maybe good
idea to copypaste them into wiki.

Pavel

Re: GSoC: UI Improvement and Non-Linear Writing Enhancement

[Pavel Sanda]

Cyrille Artho wrote:
> I agree that it's much better to update progress on the GSoC projects on 
> the wiki. First, we need the original proposal (on Melange) as a reference; 

Note that original proposal are not visible to non-mentors, so maybe good
idea to copy them into wiki.

Pavel

Re: GSoC: UI Improvement and Non-Linear Writing Enhancement

[Vincent van Ravesteijn]

Op 28-5-2013 16:41, Ashley Shan schreef:

Hi LyX developers,

My name is Xueqing Shan, and I'm a rising sophomore in Vanderbilt 
University. I'm very excited to participate in Google Summer of Code 
with LyX this year. I write this email to briefly introduce the state 
of my project and our (me and my mentor, Rob) plans for the project, 
and ask for advice (about documentations to read and other steps to 
take) from the community.


Since my school is on semester, and we have our summer break from May 
to August, I have started working on the project since the beginning 
of May for more than 3 weeks. We splited the project into three 
phases, specifically:


1. Implement a Corkboard user interface using the graphic 
framework of Qt;

2. Integrate the Corkboard with LyX's underlying model.
3. Wrap up everything, including enhancing the performance of the 
Corkboard view and the Outline view.


Should I update my proposal on google-melange.com 
http://google-melange.com so that it reflects the actual plan for 
the project?


Right now, we almost finished the first phase and are starting the 
second phase, although there are still some bugs I need to fix in the 
Corkboard view.


I have been using LyX to write my progress report, but I couldn't 
compile LyX on my computer (which uses Mac OS X 10.8.3 and Qt 5.0.2). 
It seems that I have both Qt 4.8 and Qt 5.0.2 on my computer, but I 
couldn't find 4.8 or delete one of them. I finished implementation of 
the Corkboard using Qt 5.0.2.


All suggestions welcomed. Again, I really look forward to the summer 
with LyX!


Best Regards,
Ashley

*Xueqing Shan*
Vanderbilt University, '16


Hi Ashley,

Welcome to LyX!

Vincent

Re: GSoC: UI Improvement and Non-Linear Writing Enhancement

[Ashley Shan]

Hi developers,

Thank you for the help! I'm very excited to participate in the project! I
will put information about my project in the wiki page soon.

Ashley


*Xueqing Shan*
Vanderbilt University, '16


On Thu, May 30, 2013 at 3:08 AM, Vincent van Ravesteijn v...@lyx.org wrote:

  Op 28-5-2013 16:41, Ashley Shan schreef:

  Hi LyX developers,

  My name is Xueqing Shan, and I'm a rising sophomore in Vanderbilt
 University. I'm very excited to participate in Google Summer of Code with
 LyX this year. I write this email to briefly introduce the state of my
 project and our (me and my mentor, Rob) plans for the project, and ask for
 advice (about documentations to read and other steps to take) from the
 community.

  Since my school is on semester, and we have our summer break from May to
 August, I have started working on the project since the beginning of May
 for more than 3 weeks. We splited the project into three phases,
 specifically:

  1. Implement a Corkboard user interface using the graphic framework
 of Qt;
  2. Integrate the Corkboard with LyX's underlying model.
 3. Wrap up everything, including enhancing the performance of the
 Corkboard view and the Outline view.

  Should I update my proposal on google-melange.com so that it reflects
 the actual plan for the project?

  Right now, we almost finished the first phase and are starting the
 second phase, although there are still some bugs I need to fix in the
 Corkboard view.

  I have been using LyX to write my progress report, but I couldn't
 compile LyX on my computer (which uses Mac OS X 10.8.3 and Qt 5.0.2). It
 seems that I have both Qt 4.8 and Qt 5.0.2 on my computer, but I couldn't
 find 4.8 or delete one of them. I finished implementation of the Corkboard
 using Qt 5.0.2.

  All suggestions welcomed. Again, I really look forward to the summer
 with LyX!

  Best Regards,
 Ashley
  
 *Xueqing Shan*
 Vanderbilt University, '16


 Hi Ashley,

 Welcome to LyX!

 Vincent

Re: GSoC: UI Improvement and Non-Linear Writing Enhancement

[Vincent van Ravesteijn]

Op 28-5-2013 16:41, Ashley Shan schreef:

Hi LyX developers,

My name is Xueqing Shan, and I'm a rising sophomore in Vanderbilt 
University. I'm very excited to participate in Google Summer of Code 
with LyX this year. I write this email to briefly introduce the state 
of my project and our (me and my mentor, Rob) plans for the project, 
and ask for advice (about documentations to read and other steps to 
take) from the community.


Since my school is on semester, and we have our summer break from May 
to August, I have started working on the project since the beginning 
of May for more than 3 weeks. We splited the project into three 
phases, specifically:


1. Implement a Corkboard user interface using the graphic 
framework of Qt;

2. Integrate the Corkboard with LyX's underlying model.
3. Wrap up everything, including enhancing the performance of the 
Corkboard view and the Outline view.


Should I update my proposal on google-melange.com 
 so that it reflects the actual plan for 
the project?


Right now, we almost finished the first phase and are starting the 
second phase, although there are still some bugs I need to fix in the 
Corkboard view.


I have been using LyX to write my progress report, but I couldn't 
compile LyX on my computer (which uses Mac OS X 10.8.3 and Qt 5.0.2). 
It seems that I have both Qt 4.8 and Qt 5.0.2 on my computer, but I 
couldn't find 4.8 or delete one of them. I finished implementation of 
the Corkboard using Qt 5.0.2.


All suggestions welcomed. Again, I really look forward to the summer 
with LyX!


Best Regards,
Ashley

*Xueqing Shan*
Vanderbilt University, '16


Hi Ashley,

Welcome to LyX!

Vincent

Re: GSoC: UI Improvement and Non-Linear Writing Enhancement

[Ashley Shan]

Hi developers,

Thank you for the help! I'm very excited to participate in the project! I
will put information about my project in the wiki page soon.

Ashley


*Xueqing Shan*
Vanderbilt University, '16


On Thu, May 30, 2013 at 3:08 AM, Vincent van Ravesteijn  wrote:

>  Op 28-5-2013 16:41, Ashley Shan schreef:
>
>  Hi LyX developers,
>
>  My name is Xueqing Shan, and I'm a rising sophomore in Vanderbilt
> University. I'm very excited to participate in Google Summer of Code with
> LyX this year. I write this email to briefly introduce the state of my
> project and our (me and my mentor, Rob) plans for the project, and ask for
> advice (about documentations to read and other steps to take) from the
> community.
>
>  Since my school is on semester, and we have our summer break from May to
> August, I have started working on the project since the beginning of May
> for more than 3 weeks. We splited the project into three phases,
> specifically:
>
>  1. Implement a Corkboard user interface using the graphic framework
> of Qt;
>  2. Integrate the Corkboard with LyX's underlying model.
> 3. Wrap up everything, including enhancing the performance of the
> Corkboard view and the Outline view.
>
>  Should I update my proposal on google-melange.com so that it reflects
> the actual plan for the project?
>
>  Right now, we almost finished the first phase and are starting the
> second phase, although there are still some bugs I need to fix in the
> Corkboard view.
>
>  I have been using LyX to write my progress report, but I couldn't
> compile LyX on my computer (which uses Mac OS X 10.8.3 and Qt 5.0.2). It
> seems that I have both Qt 4.8 and Qt 5.0.2 on my computer, but I couldn't
> find 4.8 or delete one of them. I finished implementation of the Corkboard
> using Qt 5.0.2.
>
>  All suggestions welcomed. Again, I really look forward to the summer
> with LyX!
>
>  Best Regards,
> Ashley
>  
> *Xueqing Shan*
> Vanderbilt University, '16
>
>
> Hi Ashley,
>
> Welcome to LyX!
>
> Vincent
>

GSoC: UI Improvement and Non-Linear Writing Enhancement

[Ashley Shan]

Hi LyX developers,

My name is Xueqing Shan, and I'm a rising sophomore in Vanderbilt
University. I'm very excited to participate in Google Summer of Code with
LyX this year. I write this email to briefly introduce the state of my
project and our (me and my mentor, Rob) plans for the project, and ask for
advice (about documentations to read and other steps to take) from the
community.

Since my school is on semester, and we have our summer break from May to
August, I have started working on the project since the beginning of May
for more than 3 weeks. We splited the project into three phases,
specifically:

1. Implement a Corkboard user interface using the graphic framework of
Qt;
2. Integrate the Corkboard with LyX's underlying model.
3. Wrap up everything, including enhancing the performance of the
Corkboard view and the Outline view.

Should I update my proposal on google-melange.com so that it reflects the
actual plan for the project?

Right now, we almost finished the first phase and are starting the second
phase, although there are still some bugs I need to fix in the Corkboard
view.

I have been using LyX to write my progress report, but I couldn't compile
LyX on my computer (which uses Mac OS X 10.8.3 and Qt 5.0.2). It seems that
I have both Qt 4.8 and Qt 5.0.2 on my computer, but I couldn't find 4.8 or
delete one of them. I finished implementation of the Corkboard using Qt
5.0.2.

All suggestions welcomed. Again, I really look forward to the summer with
LyX!

Best Regards,
Ashley

*Xueqing Shan*
Vanderbilt University, '16

Re: GSoC: UI Improvement and Non-Linear Writing Enhancement

[Richard Heck]

On 05/28/2013 10:41 AM, Ashley Shan wrote:

Hi LyX developers,

My name is Xueqing Shan, and I'm a rising sophomore in Vanderbilt 
University. I'm very excited to participate in Google Summer of Code 
with LyX this year. I write this email to briefly introduce the state 
of my project and our (me and my mentor, Rob) plans for the project, 
and ask for advice (about documentations to read and other steps to 
take) from the community.


Since my school is on semester, and we have our summer break from May 
to August, I have started working on the project since the beginning 
of May for more than 3 weeks. We splited the project into three 
phases, specifically:


1. Implement a Corkboard user interface using the graphic 
framework of Qt;

2. Integrate the Corkboard with LyX's underlying model.
3. Wrap up everything, including enhancing the performance of the 
Corkboard view and the Outline view.


Should I update my proposal on google-melange.com 
http://google-melange.com so that it reflects the actual plan for 
the project?


I've created a wiki page here:
http://wiki.lyx.org/GSoC/NonLinearWriting
You might put information about your project there.

Richard

Re: GSoC: UI Improvement and Non-Linear Writing Enhancement

[Cyrille Artho]

I agree that it's much better to update progress on the GSoC projects on 
the wiki. First, we need the original proposal (on Melange) as a 
reference; second, the wiki is more accessible than the GSoC pages 
(which are not public), so it is good for LyX users to see what we are 
working on.




I've created a wiki page here:
http://wiki.lyx.org/GSoC/NonLinearWriting
You might put information about your project there.

Richard



--
Regards,
Cyrille Artho - http://artho.com/
Those who will not reason, are bigots, those who cannot,
are fools, and those who dare not, are slaves.
-- George Gordon Noel Byron

GSoC: UI Improvement and Non-Linear Writing Enhancement

[Ashley Shan]

Hi LyX developers,

My name is Xueqing Shan, and I'm a rising sophomore in Vanderbilt
University. I'm very excited to participate in Google Summer of Code with
LyX this year. I write this email to briefly introduce the state of my
project and our (me and my mentor, Rob) plans for the project, and ask for
advice (about documentations to read and other steps to take) from the
community.

Since my school is on semester, and we have our summer break from May to
August, I have started working on the project since the beginning of May
for more than 3 weeks. We splited the project into three phases,
specifically:

1. Implement a Corkboard user interface using the graphic framework of
Qt;
2. Integrate the Corkboard with LyX's underlying model.
3. Wrap up everything, including enhancing the performance of the
Corkboard view and the Outline view.

Should I update my proposal on google-melange.com so that it reflects the
actual plan for the project?

Right now, we almost finished the first phase and are starting the second
phase, although there are still some bugs I need to fix in the Corkboard
view.

I have been using LyX to write my progress report, but I couldn't compile
LyX on my computer (which uses Mac OS X 10.8.3 and Qt 5.0.2). It seems that
I have both Qt 4.8 and Qt 5.0.2 on my computer, but I couldn't find 4.8 or
delete one of them. I finished implementation of the Corkboard using Qt
5.0.2.

All suggestions welcomed. Again, I really look forward to the summer with
LyX!

Best Regards,
Ashley

*Xueqing Shan*
Vanderbilt University, '16

Re: GSoC: UI Improvement and Non-Linear Writing Enhancement

[Richard Heck]

On 05/28/2013 10:41 AM, Ashley Shan wrote:

Hi LyX developers,

My name is Xueqing Shan, and I'm a rising sophomore in Vanderbilt 
University. I'm very excited to participate in Google Summer of Code 
with LyX this year. I write this email to briefly introduce the state 
of my project and our (me and my mentor, Rob) plans for the project, 
and ask for advice (about documentations to read and other steps to 
take) from the community.


Since my school is on semester, and we have our summer break from May 
to August, I have started working on the project since the beginning 
of May for more than 3 weeks. We splited the project into three 
phases, specifically:


1. Implement a Corkboard user interface using the graphic 
framework of Qt;

2. Integrate the Corkboard with LyX's underlying model.
3. Wrap up everything, including enhancing the performance of the 
Corkboard view and the Outline view.


Should I update my proposal on google-melange.com 
 so that it reflects the actual plan for 
the project?


I've created a wiki page here:
http://wiki.lyx.org/GSoC/NonLinearWriting
You might put information about your project there.

Richard

Re: GSoC: UI Improvement and Non-Linear Writing Enhancement

[Cyrille Artho]

I agree that it's much better to update progress on the GSoC projects on 
the wiki. First, we need the original proposal (on Melange) as a 
reference; second, the wiki is more accessible than the GSoC pages 
(which are not public), so it is good for LyX users to see what we are 
working on.




I've created a wiki page here:
http://wiki.lyx.org/GSoC/NonLinearWriting
You might put information about your project there.

Richard



--
Regards,
Cyrille Artho - http://artho.com/
Those who will not reason, are bigots, those who cannot,
are fools, and those who dare not, are slaves.
-- George Gordon Noel Byron