Re: Helping out
On Thursday 03 March 2011 22:11:13 Jean-Marc Lasgouttes wrote: Le 03/03/11 22:17, Richard Heck a écrit : It would certainly be worth standardizing these, in so far as that is possible. Note that this would be a format change, in effect, and would require lyx2lyx conversion. If you want to put this on the list for 2.1, that'd be great. I'd be happy to help with lyx2lyx where necessary. We can use ObsoletedBy for that. JMarc If those are styles that we distribute a lyx2lyx solution is cleaner, IMHO. -- José Abílio
Re: Helping out
Le 04/03/2011 11:17, José Matos a écrit : On Thursday 03 March 2011 22:11:13 Jean-Marc Lasgouttes wrote: We can use ObsoletedBy for that. If those are styles that we distribute a lyx2lyx solution is cleaner, IMHO. How predictable we are, aren't we? JMarc
Re: Helping out
On Friday 04 March 2011 10:43:08 Jean-Marc Lasgouttes wrote: How predictable we are, aren't we? JMarc I have a word for you: Latex_Title. If any of the readers do not remember this consider yourself lucky. :-) -- José Abílio
Re: Helping out
On Thursday 03 March 2011 22:11:13 Jean-Marc Lasgouttes wrote: > Le 03/03/11 22:17, Richard Heck a écrit : > > It would certainly be worth standardizing these, in so far as that is > > possible. Note that this would be a format change, in effect, and would > > require lyx2lyx conversion. If you want to put this on the list for 2.1, > > that'd be great. I'd be happy to help with lyx2lyx where necessary. > > We can use ObsoletedBy for that. > > JMarc If those are styles that we distribute a lyx2lyx solution is cleaner, IMHO. -- José Abílio
Re: Helping out
Le 04/03/2011 11:17, José Matos a écrit : On Thursday 03 March 2011 22:11:13 Jean-Marc Lasgouttes wrote: We can use ObsoletedBy for that. If those are styles that we distribute a lyx2lyx solution is cleaner, IMHO. How predictable we are, aren't we? JMarc
Re: Helping out
On Friday 04 March 2011 10:43:08 Jean-Marc Lasgouttes wrote: > How predictable we are, aren't we? > > JMarc I have a word for you: "Latex_Title". If any of the readers do not remember this consider yourself lucky. :-) -- José Abílio
Re: Helping out
On 03/02/2011 07:44 PM, Julien Rioux wrote: For example, a simple grep -h ^Style lib/layout/*.* | sort | uniq | wc in trunk gives 519 different styles. OK, I should do this case-insensitively but still, that number for sure can be reduced. e.g. grepping for mail: Style Author_Email Style EMail Style E-Mail Style Email Style Mail Style Specialmail Style YourMail Style Yourmail It would certainly be worth standardizing these, in so far as that is possible. Note that this would be a format change, in effect, and would require lyx2lyx conversion. If you want to put this on the list for 2.1, that'd be great. I'd be happy to help with lyx2lyx where necessary. Richard
Re: Helping out
On 2011-03-02, Julien Rioux wrote:
On 02/03/2011 5:21 PM, Tommaso Cucinotta wrote:
one possibility could be of course to define a lyx-specific LaTeX macro
package which is actually used when generating latex code, for example
in the author style case, one would generate smth. like \lyxauthor{}
or \lyxsection{} similar. Then, these macros could be implemented in a
different way depending on the style that is being used.
Well, in some cases this is already done, but to me that is the wrong
approach. I would like to see special-casing being done at the LyX level
in the .layout files, not at the latex level.
There is the ObsoletedBy keyword for conversion of Styles. See e.g.
dinbrief.layout.
Most cases where LyX defines \lyxinternal macros are workarounds for
latex syntax which is unsupported by LyX.
Or Unicode characters which are unsupported by LaTeX (see
LyXDIR/unicodesymbols)
Günter
Re: Helping out
Le 03/03/11 22:17, Richard Heck a écrit : It would certainly be worth standardizing these, in so far as that is possible. Note that this would be a format change, in effect, and would require lyx2lyx conversion. If you want to put this on the list for 2.1, that'd be great. I'd be happy to help with lyx2lyx where necessary. We can use ObsoletedBy for that. JMarc
Re: Helping out
Il 03/03/2011 01:44, Julien Rioux ha scritto:
On 02/03/2011 5:29 PM, Jean-Marc Lasgouttes wrote:
You mean having he styl Author use IEEEauthor for IEEE documents? It
looks like our IEEEtran layout does not do that, but it could. Besides
bizarre \and issues, many things are already possible for layout file
authors.
Of course many things are possible with layout files, and that's fine.
I mean to come up with a set of standard rules for environment names,
which will be applied uniformly among the layout files (at least those
layout files distributed with LyX).
and probably also to expand slightly the layout language (and
accordingly the GUI behavior, if needed) at least in those cases which
are recurrent.
For example, in a recently written paper I had to use:
\documentclass[...]{elsarticle}
...
\address[x]{Address of X}
\address[y]{Address of Y}
\cortext[cor1]{Corresponding author}
\author[x]{First X author}
\ead{First X author e-mail}
\author[y]{First Y Author\corref{cor1}}
\ead{First Y Author e-mail}
\author[y]{Second Y Author}
\ead{e-mail}
\author[ctu]{Second X Author}
\ead{e-mail}
In another case:
\documentclass[...]{IEEEtran}
...
\author{
\IEEEauthorblockN{Authors belonging to X\\}
\IEEEauthorblockA{Address of X\\
{\tt e-mail addresses\\}
\and
\IEEEauthorblockN{Authors belonging to Y}
\IEEEauthorblockA{Address of Y\\
{\tt e-mail addresses\\}
}
and each time it's always different. However, the needed information is
always the same:
-) author names
-) affiliations
-) physical addresses
-) e-mail addresses
with the possibility to specify authors in an arbitrary order keeping a
link/cross-ref to the institution.
T.
Re: Helping out
On 03/02/2011 07:44 PM, Julien Rioux wrote: For example, a simple grep -h "^Style" lib/layout/*.* | sort | uniq | wc in trunk gives 519 different styles. OK, I should do this case-insensitively but still, that number for sure can be reduced. e.g. grepping for mail: Style Author_Email Style EMail Style E-Mail Style Email Style Mail Style Specialmail Style YourMail Style Yourmail It would certainly be worth standardizing these, in so far as that is possible. Note that this would be a format change, in effect, and would require lyx2lyx conversion. If you want to put this on the list for 2.1, that'd be great. I'd be happy to help with lyx2lyx where necessary. Richard
Re: Helping out
On 2011-03-02, Julien Rioux wrote:
> On 02/03/2011 5:21 PM, Tommaso Cucinotta wrote:
>> one possibility could be of course to define a lyx-specific LaTeX macro
>> package which is actually used when generating latex code, for example
>> in the "author style" case, one would generate smth. like \lyxauthor{}
>> or \lyxsection{} similar. Then, these macros could be implemented in a
>> different way depending on the style that is being used.
> Well, in some cases this is already done, but to me that is the wrong
> approach. I would like to see special-casing being done at the LyX level
> in the .layout files, not at the latex level.
There is the "ObsoletedBy" keyword for conversion of Styles. See e.g.
dinbrief.layout.
> Most cases where LyX defines \lyxinternal macros are workarounds for
> latex syntax which is unsupported by LyX.
Or Unicode characters which are unsupported by LaTeX (see
LyXDIR/unicodesymbols)
Günter
Re: Helping out
Le 03/03/11 22:17, Richard Heck a écrit : It would certainly be worth standardizing these, in so far as that is possible. Note that this would be a format change, in effect, and would require lyx2lyx conversion. If you want to put this on the list for 2.1, that'd be great. I'd be happy to help with lyx2lyx where necessary. We can use ObsoletedBy for that. JMarc
Re: Helping out
Il 03/03/2011 01:44, Julien Rioux ha scritto:
On 02/03/2011 5:29 PM, Jean-Marc Lasgouttes wrote:
You mean having he styl Author use IEEEauthor for IEEE documents? It
looks like our IEEEtran layout does not do that, but it could. Besides
bizarre \and issues, many things are already possible for layout file
authors.
Of course many things are possible with layout files, and that's fine.
I mean to come up with a set of standard rules for environment names,
which will be applied uniformly among the layout files (at least those
layout files distributed with LyX).
and probably also to expand slightly the layout "language" (and
accordingly the GUI behavior, if needed) at least in those cases which
are recurrent.
For example, in a recently written paper I had to use:
\documentclass[...]{elsarticle}
...
\address[x]{Address of X}
\address[y]{Address of Y}
\cortext[cor1]{Corresponding author}
\author[x]{First X author}
\ead{First X author e-mail}
\author[y]{First Y Author\corref{cor1}}
\ead{First Y Author e-mail}
\author[y]{Second Y Author}
\ead{e-mail}
\author[ctu]{Second X Author}
\ead{e-mail}
In another case:
\documentclass[...]{IEEEtran}
...
\author{
\IEEEauthorblockN{Authors belonging to X\\}
\IEEEauthorblockA{Address of X\\
{\tt e-mail addresses\\}
\and
\IEEEauthorblockN{Authors belonging to Y}
\IEEEauthorblockA{Address of Y\\
{\tt e-mail addresses\\}
}
and each time it's always different. However, the needed information is
always the same:
-) author names
-) affiliations
-) physical addresses
-) e-mail addresses
with the possibility to specify authors in an arbitrary order keeping a
link/cross-ref to the institution.
T.
Re: Helping out
Il 02/03/2011 02:03, Julien Rioux ha scritto:
You are right! The multiplicity of styles when it comes to macro names
in latex is very annoying. In LyX it can be worked around and I think
this should be looked into very seriously. Then you can easily switch
from layout to layout in a document without problems, i.e. not have
the environments get messed up. The environment names should be
standardized in a meaningful way and let the .layout file perform the
translation \author -- \IEEEauthor etc.
This requires some more thinking from the LyX side to establish a
standard but it would be worthwhile in my opinion.
one possibility could be of course to define a lyx-specific LaTeX macro
package which is actually used when generating latex code, for example
in the author style case, one would generate smth. like \lyxauthor{}
or \lyxsection{} similar. Then, these macros could be implemented in a
different way depending on the style that is being used.
Such a package could seem wonderful to me (e.g., think of when you
change your mind and submit to a different conference or journal, or
simply you extend/rework a previously rejected paper -- you would only
change the macro package you use :-) ).
However, I can spot a problem in that the generated LaTeX export would
contain these lyx-specific macros which would probably make unhappy
people (and sometimes publishers require you to not use custom macros as
much as possible).
What could be perhaps more appreciated or more concretely usable, would
be to have the possibility to expand those lyx-specific macros in the
generated LaTeX.
Bye,
T.
Re: Helping out
Le 02/03/11 02:03, Julien Rioux a écrit : You are right! The multiplicity of styles when it comes to macro names in latex is very annoying. In LyX it can be worked around and I think this should be looked into very seriously. Then you can easily switch from layout to layout in a document without problems, i.e. not have the environments get messed up. The environment names should be standardized in a meaningful way and let the .layout file perform the translation \author -- \IEEEauthor etc. You mean having he styl Author use IEEEauthor for IEEE documents? It looks like our IEEEtran layout does not do that, but it could. Besides bizarre \and issues, many things are already possible for layout file authors. JMarc
Re: Helping out
On 02/03/2011 5:21 PM, Tommaso Cucinotta wrote:
one possibility could be of course to define a lyx-specific LaTeX macro
package which is actually used when generating latex code, for example
in the author style case, one would generate smth. like \lyxauthor{}
or \lyxsection{} similar. Then, these macros could be implemented in a
different way depending on the style that is being used.
Well, in some cases this is already done, but to me that is the wrong
approach. I would like to see special-casing being done at the LyX level
in the .layout files, not at the latex level.
Most cases where LyX defines \lyxinternal macros are workarounds for
latex syntax which is unsupported by LyX. Less and less of these should
be needed as support in LyX becomes available. For example the LyX
layout language now has basic support for \macros[with]{lots of}{arguments}.
--
Julien
Re: Helping out
On 02/03/2011 5:29 PM, Jean-Marc Lasgouttes wrote: You mean having he styl Author use IEEEauthor for IEEE documents? It looks like our IEEEtran layout does not do that, but it could. Besides bizarre \and issues, many things are already possible for layout file authors. Of course many things are possible with layout files, and that's fine. I mean to come up with a set of standard rules for environment names, which will be applied uniformly among the layout files (at least those layout files distributed with LyX). Otherwise, taking a clue from latex, we will eventually see the proliferation of different environment names for essentially the same functionality. For example, a simple grep -h ^Style lib/layout/*.* | sort | uniq | wc in trunk gives 519 different styles. OK, I should do this case-insensitively but still, that number for sure can be reduced. e.g. grepping for mail: Style Author_Email Style EMail Style E-Mail Style Email Style Mail Style Specialmail Style YourMail Style Yourmail -- Julien
Re: Helping out
Il 02/03/2011 02:03, Julien Rioux ha scritto:
You are right! The multiplicity of styles when it comes to macro names
in latex is very annoying. In LyX it can be worked around and I think
this should be looked into very seriously. Then you can easily switch
from layout to layout in a document without problems, i.e. not have
the environments get messed up. The environment names should be
standardized in a meaningful way and let the .layout file perform the
translation \author --> \IEEEauthor etc.
This requires some more thinking from the LyX side to establish a
standard but it would be worthwhile in my opinion.
one possibility could be of course to define a lyx-specific LaTeX macro
package which is actually used when generating latex code, for example
in the "author style" case, one would generate smth. like \lyxauthor{}
or \lyxsection{} similar. Then, these macros could be implemented in a
different way depending on the style that is being used.
Such a package could seem wonderful to me (e.g., think of when you
change your mind and submit to a different conference or journal, or
simply you extend/rework a previously rejected paper -- you would only
change the macro package you use :-) ).
However, I can spot a problem in that the generated LaTeX export would
contain these lyx-specific macros which would probably make unhappy
people (and sometimes publishers require you to not use custom macros as
much as possible).
What could be perhaps more appreciated or more concretely usable, would
be to have the possibility to expand those lyx-specific macros in the
generated LaTeX.
Bye,
T.
Re: Helping out
Le 02/03/11 02:03, Julien Rioux a écrit : You are right! The multiplicity of styles when it comes to macro names in latex is very annoying. In LyX it can be worked around and I think this should be looked into very seriously. Then you can easily switch from layout to layout in a document without problems, i.e. not have the environments get messed up. The environment names should be standardized in a meaningful way and let the .layout file perform the translation \author --> \IEEEauthor etc. You mean having he styl Author use IEEEauthor for IEEE documents? It looks like our IEEEtran layout does not do that, but it could. Besides bizarre \and issues, many things are already possible for layout file authors. JMarc
Re: Helping out
On 02/03/2011 5:21 PM, Tommaso Cucinotta wrote:
one possibility could be of course to define a lyx-specific LaTeX macro
package which is actually used when generating latex code, for example
in the "author style" case, one would generate smth. like \lyxauthor{}
or \lyxsection{} similar. Then, these macros could be implemented in a
different way depending on the style that is being used.
Well, in some cases this is already done, but to me that is the wrong
approach. I would like to see special-casing being done at the LyX level
in the .layout files, not at the latex level.
Most cases where LyX defines \lyxinternal macros are workarounds for
latex syntax which is unsupported by LyX. Less and less of these should
be needed as support in LyX becomes available. For example the LyX
layout language now has basic support for \macros[with]{lots of}{arguments}.
--
Julien
Re: Helping out
On 02/03/2011 5:29 PM, Jean-Marc Lasgouttes wrote: You mean having he styl Author use IEEEauthor for IEEE documents? It looks like our IEEEtran layout does not do that, but it could. Besides bizarre \and issues, many things are already possible for layout file authors. Of course many things are possible with layout files, and that's fine. I mean to come up with a set of standard rules for environment names, which will be applied uniformly among the layout files (at least those layout files distributed with LyX). Otherwise, taking a clue from latex, we will eventually see the proliferation of different environment names for essentially the same functionality. For example, a simple grep -h "^Style" lib/layout/*.* | sort | uniq | wc in trunk gives 519 different styles. OK, I should do this case-insensitively but still, that number for sure can be reduced. e.g. grepping for mail: Style Author_Email Style EMail Style E-Mail Style Email Style Mail Style Specialmail Style YourMail Style Yourmail -- Julien
Re: Helping out
On 19/02/2011 5:47 AM, Tommaso Cucinotta wrote:
Il 16/02/2011 14:20, Vincent van Ravesteijn ha scritto:
2) A layout editor for creating your own layouts/character
styles/insets and so forth.
This one would be a very nice feature to have.
I have to say that, AFAICS, currently there is also a problem
in merely *using* the available styles. The problem is due
to the custom macros that each style requires you to use.
For example, I can remember a latex8 style that I used various
times, in which you had to write sections like this: \Section{},
\Subsection{}, etc.. Styles that I used more recently have always
specific macros for authors, addresses, institutions, e-mail addresses,
as well as thanks or acknowledgements in the first page. For example,
I can remember at least such macros as:
\and: to separate authors
\inst{}: to refer institutions
\institute{}: to declare institutions
\IEEEauthorblockN{}: declare author names
\IEEEauthorblockA{}: declare author affiliations/addresses
\IEEEauthorrefmark{}: cross-connect author names and affiliations
\IEEEoverridecommandlockouts: I have no clue, it was in the sample ..tex
after \documentclass{}
\IEEEpeerreviewmaketitle: I have no clue, it was in the sample .tex
\Section{}, \Subsection{}, etc.: mentioned above
\category{}, \terms{}, \keyword{}: don't know whether these were
style-specific or not
and sometimes custom environments, such as:
\begin{IEEEkeywords}...\end{IEEEkeywords}
\begin{IEEEproof}...\end{IEEEproof}
This may mainly a problem specific to LaTeX styles and how they are
engineered
(i.e., there is not a common widely recognized LaTeX macros/environments
abstraction
in order to support those features), not really a problem specific to
LyX, but I wonder
whether in LyX we can make the whole thing more usable.
For example, how could a user interface cope with editing a
multi-authors/multi-institution
paper in a reasonable way ? I mean, without the user having to learn all
these macros
and LaTeX-specific instructions of the publisher ?
The problem that I can see, is that, even if we had a user-interface
supporting this kind
of editing, the LaTeX code to generate cannot be universal anyway, but
it would need
to be style-specific.
I'd like to hear comments from the LyX and LaTeX experts, here.
T.
You are right! The multiplicity of styles when it comes to macro names
in latex is very annoying. In LyX it can be worked around and I think
this should be looked into very seriously. Then you can easily switch
from layout to layout in a document without problems, i.e. not have the
environments get messed up. The environment names should be standardized
in a meaningful way and let the .layout file perform the translation
\author -- \IEEEauthor etc.
This requires some more thinking from the LyX side to establish a
standard but it would be worthwhile in my opinion.
--
Julien
Re: Helping out
On 19/02/2011 5:47 AM, Tommaso Cucinotta wrote:
Il 16/02/2011 14:20, Vincent van Ravesteijn ha scritto:
2) A layout editor for creating your own layouts/character
styles/insets and so forth.
This one would be a very nice feature to have.
I have to say that, AFAICS, currently there is also a problem
in merely *using* the available styles. The problem is due
to the custom macros that each style requires you to use.
For example, I can remember a latex8 style that I used various
times, in which you had to write sections like this: \Section{},
\Subsection{}, etc.. Styles that I used more recently have always
specific macros for authors, addresses, institutions, e-mail addresses,
as well as thanks or acknowledgements in the first page. For example,
I can remember at least such macros as:
\and: to separate authors
\inst{}: to refer institutions
\institute{}: to declare institutions
\IEEEauthorblockN{}: declare author names
\IEEEauthorblockA{}: declare author affiliations/addresses
\IEEEauthorrefmark{}: cross-connect author names and affiliations
\IEEEoverridecommandlockouts: I have no clue, it was in the sample ..tex
after \documentclass{}
\IEEEpeerreviewmaketitle: I have no clue, it was in the sample .tex
\Section{}, \Subsection{}, etc.: mentioned above
\category{}, \terms{}, \keyword{}: don't know whether these were
style-specific or not
and sometimes custom environments, such as:
\begin{IEEEkeywords}...\end{IEEEkeywords}
\begin{IEEEproof}...\end{IEEEproof}
This may mainly a problem specific to LaTeX styles and how they are
engineered
(i.e., there is not a common widely recognized LaTeX macros/environments
abstraction
in order to support those features), not really a problem specific to
LyX, but I wonder
whether in LyX we can make the whole thing more usable.
For example, how could a user interface cope with editing a
multi-authors/multi-institution
paper in a reasonable way ? I mean, without the user having to learn all
these macros
and LaTeX-specific instructions of the publisher ?
The problem that I can see, is that, even if we had a user-interface
supporting this kind
of editing, the LaTeX code to generate cannot be universal anyway, but
it would need
to be style-specific.
I'd like to hear comments from the LyX and LaTeX experts, here.
T.
You are right! The multiplicity of styles when it comes to macro names
in latex is very annoying. In LyX it can be worked around and I think
this should be looked into very seriously. Then you can easily switch
from layout to layout in a document without problems, i.e. not have the
environments get messed up. The environment names should be standardized
in a meaningful way and let the .layout file perform the translation
\author --> \IEEEauthor etc.
This requires some more thinking from the LyX side to establish a
standard but it would be worthwhile in my opinion.
--
Julien
Custom styles and author/institution xrefs (was: Re: Helping out)
Il 19/02/2011 11:47, Tommaso Cucinotta ha scritto:
Il 16/02/2011 14:20, Vincent van Ravesteijn ha scritto:
2) A layout editor for creating your own layouts/character
styles/insets and so forth.
This one would be a very nice feature to have.
I have to say that, AFAICS, currently there is also a problem
in merely *using* the available styles. The problem is due
to the custom macros that each style requires you to use.
For example, I can remember a latex8 style that I used various
times, in which you had to write sections like this: \Section{},
\Subsection{}, etc.. Styles that I used more recently have always
specific macros for authors, addresses, institutions, e-mail addresses,
as well as thanks or acknowledgements in the first page. For example,
I can remember at least such macros as:
\and: to separate authors
\inst{}: to refer institutions
\institute{}: to declare institutions
[...]
for example, given that the current LyX allows you to select the
address parstyle, which results in defining the custom lyxaddress{}
macro definition and its usage, then I would be tempted to say that we
could have lyxXXX{} macros (and environments) for these other
functionality as well, which could be then implemented in the preamble
in a different way depending on the chosen style/layout.
However, I'm not really sure I would promote definition of lyx custom
macros/envs.
On a related note, what is the LyX way of referencing multiple times to
the same footnote (i.e., using these|\footnotemark|{} tricks and/or
\cref{} or others) ? Guess the same principle may apply to referencing
authors institutions.
T.
\IEEEauthorblockN{}: declare author names
\IEEEauthorblockA{}: declare author affiliations/addresses
\IEEEauthorrefmark{}: cross-connect author names and affiliations
\IEEEoverridecommandlockouts: I have no clue, it was in the sample
.tex after \documentclass{}
\IEEEpeerreviewmaketitle: I have no clue, it was in the sample .tex
\Section{}, \Subsection{}, etc.: mentioned above
\category{}, \terms{}, \keyword{}: don't know whether these were
style-specific or not
and sometimes custom environments, such as:
\begin{IEEEkeywords}...\end{IEEEkeywords}
\begin{IEEEproof}...\end{IEEEproof}
This may mainly a problem specific to LaTeX styles and how they are
engineered
(i.e., there is not a common widely recognized LaTeX
macros/environments abstraction
in order to support those features), not really a problem specific to
LyX, but I wonder
whether in LyX we can make the whole thing more usable.
For example, how could a user interface cope with editing a
multi-authors/multi-institution
paper in a reasonable way ? I mean, without the user having to learn
all these macros
and LaTeX-specific instructions of the publisher ?
The problem that I can see, is that, even if we had a user-interface
supporting this kind
of editing, the LaTeX code to generate cannot be universal anyway, but
it would need
to be style-specific.
I'd like to hear comments from the LyX and LaTeX experts, here.
T.
Custom styles and author/institution xrefs (was: Re: Helping out)
Il 19/02/2011 11:47, Tommaso Cucinotta ha scritto:
Il 16/02/2011 14:20, Vincent van Ravesteijn ha scritto:
2) A layout editor for creating your own layouts/character
styles/insets and so forth.
This one would be a very nice feature to have.
I have to say that, AFAICS, currently there is also a problem
in merely *using* the available styles. The problem is due
to the custom macros that each style requires you to use.
For example, I can remember a latex8 style that I used various
times, in which you had to write sections like this: \Section{},
\Subsection{}, etc.. Styles that I used more recently have always
specific macros for authors, addresses, institutions, e-mail addresses,
as well as thanks or acknowledgements in the first page. For example,
I can remember at least such macros as:
\and: to separate authors
\inst{}: to refer institutions
\institute{}: to declare institutions
[...]
for example, given that the current LyX allows you to select the
"address" parstyle, which results in defining the custom "lyxaddress{}"
macro definition and its usage, then I would be tempted to say that we
could have "lyxXXX{}" macros (and environments) for these other
functionality as well, which could be then implemented in the preamble
in a different way depending on the chosen style/layout.
However, I'm not really sure I would promote definition of lyx custom
macros/envs.
On a related note, what is the LyX way of referencing multiple times to
the same footnote (i.e., using these|\footnotemark|{} tricks and/or
\cref{} or others) ? Guess the same principle may apply to referencing
authors institutions.
T.
\IEEEauthorblockN{}: declare author names
\IEEEauthorblockA{}: declare author affiliations/addresses
\IEEEauthorrefmark{}: cross-connect author names and affiliations
\IEEEoverridecommandlockouts: I have no clue, it was in the sample
.tex after \documentclass{}
\IEEEpeerreviewmaketitle: I have no clue, it was in the sample .tex
\Section{}, \Subsection{}, etc.: mentioned above
\category{}, \terms{}, \keyword{}: don't know whether these were
style-specific or not
and sometimes custom environments, such as:
\begin{IEEEkeywords}...\end{IEEEkeywords}
\begin{IEEEproof}...\end{IEEEproof}
This may mainly a problem specific to LaTeX styles and how they are
engineered
(i.e., there is not a common widely recognized LaTeX
macros/environments abstraction
in order to support those features), not really a problem specific to
LyX, but I wonder
whether in LyX we can make the whole thing more usable.
For example, how could a user interface cope with editing a
multi-authors/multi-institution
paper in a reasonable way ? I mean, without the user having to learn
all these macros
and LaTeX-specific instructions of the publisher ?
The problem that I can see, is that, even if we had a user-interface
supporting this kind
of editing, the LaTeX code to generate cannot be universal anyway, but
it would need
to be style-specific.
I'd like to hear comments from the LyX and LaTeX experts, here.
T.
Re: Helping out
Il 16/02/2011 14:20, Vincent van Ravesteijn ha scritto:
2) A layout editor for creating your own layouts/character
styles/insets and so forth.
This one would be a very nice feature to have.
I have to say that, AFAICS, currently there is also a problem
in merely *using* the available styles. The problem is due
to the custom macros that each style requires you to use.
For example, I can remember a latex8 style that I used various
times, in which you had to write sections like this: \Section{},
\Subsection{}, etc.. Styles that I used more recently have always
specific macros for authors, addresses, institutions, e-mail addresses,
as well as thanks or acknowledgements in the first page. For example,
I can remember at least such macros as:
\and: to separate authors
\inst{}: to refer institutions
\institute{}: to declare institutions
\IEEEauthorblockN{}: declare author names
\IEEEauthorblockA{}: declare author affiliations/addresses
\IEEEauthorrefmark{}: cross-connect author names and affiliations
\IEEEoverridecommandlockouts: I have no clue, it was in the sample
.tex after \documentclass{}
\IEEEpeerreviewmaketitle: I have no clue, it was in the sample .tex
\Section{}, \Subsection{}, etc.: mentioned above
\category{}, \terms{}, \keyword{}: don't know whether these were
style-specific or not
and sometimes custom environments, such as:
\begin{IEEEkeywords}...\end{IEEEkeywords}
\begin{IEEEproof}...\end{IEEEproof}
This may mainly a problem specific to LaTeX styles and how they are
engineered
(i.e., there is not a common widely recognized LaTeX macros/environments
abstraction
in order to support those features), not really a problem specific to
LyX, but I wonder
whether in LyX we can make the whole thing more usable.
For example, how could a user interface cope with editing a
multi-authors/multi-institution
paper in a reasonable way ? I mean, without the user having to learn all
these macros
and LaTeX-specific instructions of the publisher ?
The problem that I can see, is that, even if we had a user-interface
supporting this kind
of editing, the LaTeX code to generate cannot be universal anyway, but
it would need
to be style-specific.
I'd like to hear comments from the LyX and LaTeX experts, here.
T.
Re: Helping out
Il 16/02/2011 14:20, Vincent van Ravesteijn ha scritto:
2) A layout editor for creating your own layouts/character
styles/insets and so forth.
This one would be a very nice feature to have.
I have to say that, AFAICS, currently there is also a problem
in merely *using* the available styles. The problem is due
to the custom macros that each style requires you to use.
For example, I can remember a latex8 style that I used various
times, in which you had to write sections like this: \Section{},
\Subsection{}, etc.. Styles that I used more recently have always
specific macros for authors, addresses, institutions, e-mail addresses,
as well as thanks or acknowledgements in the first page. For example,
I can remember at least such macros as:
\and: to separate authors
\inst{}: to refer institutions
\institute{}: to declare institutions
\IEEEauthorblockN{}: declare author names
\IEEEauthorblockA{}: declare author affiliations/addresses
\IEEEauthorrefmark{}: cross-connect author names and affiliations
\IEEEoverridecommandlockouts: I have no clue, it was in the sample
.tex after \documentclass{}
\IEEEpeerreviewmaketitle: I have no clue, it was in the sample .tex
\Section{}, \Subsection{}, etc.: mentioned above
\category{}, \terms{}, \keyword{}: don't know whether these were
style-specific or not
and sometimes custom environments, such as:
\begin{IEEEkeywords}...\end{IEEEkeywords}
\begin{IEEEproof}...\end{IEEEproof}
This may mainly a problem specific to LaTeX styles and how they are
engineered
(i.e., there is not a common widely recognized LaTeX macros/environments
abstraction
in order to support those features), not really a problem specific to
LyX, but I wonder
whether in LyX we can make the whole thing more usable.
For example, how could a user interface cope with editing a
multi-authors/multi-institution
paper in a reasonable way ? I mean, without the user having to learn all
these macros
and LaTeX-specific instructions of the publisher ?
The problem that I can see, is that, even if we had a user-interface
supporting this kind
of editing, the LaTeX code to generate cannot be universal anyway, but
it would need
to be style-specific.
I'd like to hear comments from the LyX and LaTeX experts, here.
T.
Re: Helping out
Hi Amir, I downloaded the code base and I want to help out. Does anyone have an idea for a simple needed task/bug fix that a newbie to the code can do? Right at the moment, we are very much in bugfixing mode prior to the 2.0 release, so I'd suggest looking here: http://www.lyx.org/trac/wiki/BugTrackerHome especially at the very bottom, where the bugs targeted at 2.0 are listed. Have you already thought about something you think is interesting to fix/create. Some suggestions: 1) I thought about making a somewhat more user friendly way of choosing a document class. Some UI to explain why a certain class is unavailable, we might think of showing the user whether we have found a *.layout file, while the TeX class is available, wether there is a parse error and so on. Also, we want to be able to use specified .cls files by creating a layout on the fly. 2) A layout editor for creating your own layouts/character styles/insets and so forth. 3) UI for named sessions, such that you can easily manage related documents and master/child relations and so on. http://wiki.lyx.org/Devel/NamedSessions 4) Automatically checking whether included bib files have unicode characters in them (as this is not supported by bibtex). Then we can warn the user in time that there might happen strange things when compiling the document. Or just tell us what you like/dislike in LyX and we can think of something useful. Vincent
Re: Helping out
Hi Amir, >> I downloaded the code base and I want to help out. Does anyone have an >> idea for a simple needed task/bug fix that a newbie to the code can do? >> > Right at the moment, we are very much in bugfixing mode prior to the 2.0 > release, so I'd suggest looking here: > http://www.lyx.org/trac/wiki/BugTrackerHome > especially at the very bottom, where the bugs targeted at 2.0 are listed. Have you already thought about something you think is interesting to fix/create. Some suggestions: 1) I thought about making a somewhat more user friendly way of choosing a document class. Some UI to explain why a certain class is unavailable, we might think of showing the user whether we have found a *.layout file, while the TeX class is available, wether there is a parse error and so on. Also, we want to be able to use specified .cls files by creating a layout on the fly. 2) A layout editor for creating your own layouts/character styles/insets and so forth. 3) UI for named sessions, such that you can easily manage related documents and master/child relations and so on. http://wiki.lyx.org/Devel/NamedSessions 4) Automatically checking whether included bib files have unicode characters in them (as this is not supported by bibtex). Then we can warn the user in time that there might happen strange things when compiling the document. Or just tell us what you like/dislike in LyX and we can think of something useful. Vincent
Helping out
Hi all, I downloaded the code base and I want to help out. Does anyone have an idea for a simple needed task/bug fix that a newbie to the code can do? Thanks, - Amir Rachum ***Theory is when you know something, but it doesn't work. * *Practice is when something works, but you don't know why. * *Programmers combine theory and practice:* *Nothing works and they don't know why.*
Re: Helping out
On 02/11/2011 02:21 PM, Amir Rachum wrote: Hi all, I downloaded the code base and I want to help out. Does anyone have an idea for a simple needed task/bug fix that a newbie to the code can do? Right at the moment, we are very much in bugfixing mode prior to the 2.0 release, so I'd suggest looking here: http://www.lyx.org/trac/wiki/BugTrackerHome especially at the very bottom, where the bugs targeted at 2.0 are listed. I'm not sure how many of these are terribly easy---most of those got squashed---but maybe #6302 isn't too bad. If that doesn't appeal, then feel free to look elsewhere, or just think of something that annoys you and work on that. I'll be happy to answer questions about the code, by the way. Richard
Helping out
Hi all, I downloaded the code base and I want to help out. Does anyone have an idea for a simple needed task/bug fix that a newbie to the code can do? Thanks, - Amir Rachum *"**Theory is when you know something, but it doesn't work. * *Practice is when something works, but you don't know why. * *Programmers combine theory and practice:* *Nothing works and they don't know why."*
Re: Helping out
On 02/11/2011 02:21 PM, Amir Rachum wrote: Hi all, I downloaded the code base and I want to help out. Does anyone have an idea for a simple needed task/bug fix that a newbie to the code can do? Right at the moment, we are very much in bugfixing mode prior to the 2.0 release, so I'd suggest looking here: http://www.lyx.org/trac/wiki/BugTrackerHome especially at the very bottom, where the bugs targeted at 2.0 are listed. I'm not sure how many of these are terribly easy---most of those got squashed---but maybe #6302 isn't too bad. If that doesn't appeal, then feel free to look elsewhere, or just think of something that annoys you and work on that. I'll be happy to answer questions about the code, by the way. Richard
Re: Helping out
On Fri, Jun 04, 2010 at 07:58:13AM +0200, Peter Kümmel wrote: Am Sonntag, den 30.05.2010, 19:56 +0300 schrieb Amir Rachum: Hi guys, I just downloaded the LyX code base and I would like to help you people with one of the most useful pieces software I ever had. However, I am not sure how I can help seeing as the code base is really big and confusing and I was wondering if there's some external documentation for the code, and whether there's some low hanging fruits bugs/enhancements that I can handle at this point. Any pointers? Here's an idea: The Debug/Progress Messages widget is very slow: enable all debug messages an load the User's Guide and you will see. The reason is the QTextEdit which is used for displaying the messages (outTE defined in ProgressViewUi.ui). Using a QTreeView and as model a QStandardModel should be much faster, at least it is worth a try. QPlainTextEdit might be an option, too. Andre'
Re: Helping out
I've been using QPlainTextEdit as a test widget for the outliner/corkboard extensions, and I've been very happy with its performance. Even when running in my laptop within a virtual machine, performance is near instantaneous. On Jun 7, 2010, at 12:34 PM, Andre Poenitz wrote: On Fri, Jun 04, 2010 at 07:58:13AM +0200, Peter Kümmel wrote: Am Sonntag, den 30.05.2010, 19:56 +0300 schrieb Amir Rachum: Hi guys, I just downloaded the LyX code base and I would like to help you people with one of the most useful pieces software I ever had. However, I am not sure how I can help seeing as the code base is really big and confusing and I was wondering if there's some external documentation for the code, and whether there's some low hanging fruits bugs/enhancements that I can handle at this point. Any pointers? Here's an idea: The Debug/Progress Messages widget is very slow: enable all debug messages an load the User's Guide and you will see. The reason is the QTextEdit which is used for displaying the messages (outTE defined in ProgressViewUi.ui). Using a QTreeView and as model a QStandardModel should be much faster, at least it is worth a try. QPlainTextEdit might be an option, too. Andre'
Re: Helping out
Am Montag, den 07.06.2010, 20:34 +0200 schrieb Andre Poenitz: On Fri, Jun 04, 2010 at 07:58:13AM +0200, Peter Kümmel wrote: Am Sonntag, den 30.05.2010, 19:56 +0300 schrieb Amir Rachum: Hi guys, I just downloaded the LyX code base and I would like to help you people with one of the most useful pieces software I ever had. However, I am not sure how I can help seeing as the code base is really big and confusing and I was wondering if there's some external documentation for the code, and whether there's some low hanging fruits bugs/enhancements that I can handle at this point. Any pointers? Here's an idea: The Debug/Progress Messages widget is very slow: enable all debug messages an load the User's Guide and you will see. The reason is the QTextEdit which is used for displaying the messages (outTE defined in ProgressViewUi.ui). Using a QTreeView and as model a QStandardModel should be much faster, at least it is worth a try. QPlainTextEdit might be an option, too. What's our minimum for Qt? QPlainTextEdit was introduced with 4.4. Peter
Re: Helping out
Am Montag, den 07.06.2010, 12:37 -0600 schrieb Rob Oakes: I've been using QPlainTextEdit as a test widget for the outliner/corkboard extensions, and I've been very happy with its performance. Even when running in my laptop within a virtual machine, performance is near instantaneous. I've tested it, it's still too slow, even the messages in qtcreator are faster. Maybe there are other reasons which slow down lyx so much. Peter
Re: Helping out
Am Montag, den 07.06.2010, 21:42 +0200 schrieb Peter Kümmel: Am Montag, den 07.06.2010, 12:37 -0600 schrieb Rob Oakes: I've been using QPlainTextEdit as a test widget for the outliner/corkboard extensions, and I've been very happy with its performance. Even when running in my laptop within a virtual machine, performance is near instantaneous. I've tested it, it's still too slow, even the messages in qtcreator are faster. Maybe there are other reasons which slow down lyx so much. Found the reason: the debug messages were not buffered. Now it waits 200ms until the progress widget is updated. So opening the User's Guide is now possible with all messages enabled. Peter
Re: Helping out
On Mon, Jun 07, 2010 at 10:29:56PM +0200, Peter Kümmel wrote: Am Montag, den 07.06.2010, 21:42 +0200 schrieb Peter Kümmel: Am Montag, den 07.06.2010, 12:37 -0600 schrieb Rob Oakes: I've been using QPlainTextEdit as a test widget for the outliner/corkboard extensions, and I've been very happy with its performance. Even when running in my laptop within a virtual machine, performance is near instantaneous. I've tested it, it's still too slow, even the messages in qtcreator are faster. Maybe there are other reasons which slow down lyx so much. Found the reason: the debug messages were not buffered. Now it waits 200ms until the progress widget is updated. So opening the User's Guide is now possible with all messages enabled. Would a queued connection between whateven produced the debug messages and whatever puts them in the view help? Andre'
Re: Helping out
Am Dienstag, den 08.06.2010, 00:03 +0200 schrieb Andre Poenitz: On Mon, Jun 07, 2010 at 10:29:56PM +0200, Peter Kümmel wrote: Am Montag, den 07.06.2010, 21:42 +0200 schrieb Peter Kümmel: Am Montag, den 07.06.2010, 12:37 -0600 schrieb Rob Oakes: I've been using QPlainTextEdit as a test widget for the outliner/corkboard extensions, and I've been very happy with its performance. Even when running in my laptop within a virtual machine, performance is near instantaneous. I've tested it, it's still too slow, even the messages in qtcreator are faster. Maybe there are other reasons which slow down lyx so much. Found the reason: the debug messages were not buffered. Now it waits 200ms until the progress widget is updated. So opening the User's Guide is now possible with all messages enabled. Would a queued connection between whateven produced the debug messages and whatever puts them in the view help? There was already a queued connection in GuiProgressView: connect(progress, SIGNAL(appendLyXErrMessage(QString const )), this, SLOT(appendLyXErrText(QString const )), Qt::QueuedConnection); Peter
Re: Helping out
On Fri, Jun 04, 2010 at 07:58:13AM +0200, Peter Kümmel wrote: > Am Sonntag, den 30.05.2010, 19:56 +0300 schrieb Amir Rachum: > > Hi guys, > > I just downloaded the LyX code base and I would like to help you > > people with one of the most useful pieces software I ever had. > > However, I am not sure how I can help seeing as the code base is > > really big and confusing and I was wondering if there's some external > > documentation for the code, > > and whether there's some "low hanging fruits" bugs/enhancements that I > > can handle at this point. > > Any pointers? > > Here's an idea: The "Debug/Progress Messages" widget is very slow: > enable all debug messages an load the User's Guide and you will see. > > The reason is the QTextEdit which is used for displaying the messages > (outTE defined in ProgressViewUi.ui). Using a QTreeView and as model a > QStandardModel should be much faster, at least it is worth a try. QPlainTextEdit might be an option, too. Andre'
Re: Helping out
I've been using QPlainTextEdit as a test widget for the outliner/corkboard extensions, and I've been very happy with its performance. Even when running in my laptop within a virtual machine, performance is near instantaneous. On Jun 7, 2010, at 12:34 PM, Andre Poenitz wrote: > On Fri, Jun 04, 2010 at 07:58:13AM +0200, Peter Kümmel wrote: >> Am Sonntag, den 30.05.2010, 19:56 +0300 schrieb Amir Rachum: >>> Hi guys, >>> I just downloaded the LyX code base and I would like to help you >>> people with one of the most useful pieces software I ever had. >>> However, I am not sure how I can help seeing as the code base is >>> really big and confusing and I was wondering if there's some external >>> documentation for the code, >>> and whether there's some "low hanging fruits" bugs/enhancements that I >>> can handle at this point. >>> Any pointers? >> >> Here's an idea: The "Debug/Progress Messages" widget is very slow: >> enable all debug messages an load the User's Guide and you will see. >> >> The reason is the QTextEdit which is used for displaying the messages >> (outTE defined in ProgressViewUi.ui). Using a QTreeView and as model a >> QStandardModel should be much faster, at least it is worth a try. > > QPlainTextEdit might be an option, too. > > Andre'
Re: Helping out
Am Montag, den 07.06.2010, 20:34 +0200 schrieb Andre Poenitz: > On Fri, Jun 04, 2010 at 07:58:13AM +0200, Peter Kümmel wrote: > > Am Sonntag, den 30.05.2010, 19:56 +0300 schrieb Amir Rachum: > > > Hi guys, > > > I just downloaded the LyX code base and I would like to help you > > > people with one of the most useful pieces software I ever had. > > > However, I am not sure how I can help seeing as the code base is > > > really big and confusing and I was wondering if there's some external > > > documentation for the code, > > > and whether there's some "low hanging fruits" bugs/enhancements that I > > > can handle at this point. > > > Any pointers? > > > > Here's an idea: The "Debug/Progress Messages" widget is very slow: > > enable all debug messages an load the User's Guide and you will see. > > > > The reason is the QTextEdit which is used for displaying the messages > > (outTE defined in ProgressViewUi.ui). Using a QTreeView and as model a > > QStandardModel should be much faster, at least it is worth a try. > > QPlainTextEdit might be an option, too. What's our minimum for Qt? QPlainTextEdit was introduced with 4.4. Peter
Re: Helping out
Am Montag, den 07.06.2010, 12:37 -0600 schrieb Rob Oakes: > I've been using QPlainTextEdit as a test widget for the outliner/corkboard > extensions, and I've been very happy with its performance. Even when running > in my laptop within a virtual machine, performance is near instantaneous. I've tested it, it's still too slow, even the messages in qtcreator are faster. Maybe there are other reasons which slow down lyx so much. Peter
Re: Helping out
Am Montag, den 07.06.2010, 21:42 +0200 schrieb Peter Kümmel: > Am Montag, den 07.06.2010, 12:37 -0600 schrieb Rob Oakes: > > I've been using QPlainTextEdit as a test widget for the outliner/corkboard > > extensions, and I've been very happy with its performance. Even when > > running in my laptop within a virtual machine, performance is near > > instantaneous. > > I've tested it, it's still too slow, even the messages in qtcreator > are faster. Maybe there are other reasons which slow down lyx so much. Found the reason: the debug messages were not buffered. Now it waits 200ms until the progress widget is updated. So opening the User's Guide is now possible with all messages enabled. Peter
Re: Helping out
On Mon, Jun 07, 2010 at 10:29:56PM +0200, Peter Kümmel wrote: > Am Montag, den 07.06.2010, 21:42 +0200 schrieb Peter Kümmel: > > Am Montag, den 07.06.2010, 12:37 -0600 schrieb Rob Oakes: > > > I've been using QPlainTextEdit as a test widget for the > > > outliner/corkboard extensions, and I've been very happy with its > > > performance. Even when running in my laptop within a virtual machine, > > > performance is near instantaneous. > > > > I've tested it, it's still too slow, even the messages in qtcreator > > are faster. Maybe there are other reasons which slow down lyx so much. > > Found the reason: the debug messages were not buffered. Now it waits > 200ms until the progress widget is updated. So opening the User's Guide > is now possible with all messages enabled. Would a queued connection between whateven produced the debug messages and whatever puts them in the view help? Andre'
Re: Helping out
Am Dienstag, den 08.06.2010, 00:03 +0200 schrieb Andre Poenitz: > On Mon, Jun 07, 2010 at 10:29:56PM +0200, Peter Kümmel wrote: > > Am Montag, den 07.06.2010, 21:42 +0200 schrieb Peter Kümmel: > > > Am Montag, den 07.06.2010, 12:37 -0600 schrieb Rob Oakes: > > > > I've been using QPlainTextEdit as a test widget for the > > > > outliner/corkboard extensions, and I've been very happy with its > > > > performance. Even when running in my laptop within a virtual machine, > > > > performance is near instantaneous. > > > > > > I've tested it, it's still too slow, even the messages in qtcreator > > > are faster. Maybe there are other reasons which slow down lyx so much. > > > > Found the reason: the debug messages were not buffered. Now it waits > > 200ms until the progress widget is updated. So opening the User's Guide > > is now possible with all messages enabled. > > Would a queued connection between whateven produced the debug messages > and whatever puts them in the view help? There was already a queued connection in GuiProgressView: connect(progress, SIGNAL(appendLyXErrMessage(QString const &)), this, SLOT(appendLyXErrText(QString const &)), Qt::QueuedConnection); Peter
Re: Helping out
Am Sonntag, den 30.05.2010, 19:56 +0300 schrieb Amir Rachum: Hi guys, I just downloaded the LyX code base and I would like to help you people with one of the most useful pieces software I ever had. However, I am not sure how I can help seeing as the code base is really big and confusing and I was wondering if there's some external documentation for the code, and whether there's some low hanging fruits bugs/enhancements that I can handle at this point. Any pointers? Here's an idea: The Debug/Progress Messages widget is very slow: enable all debug messages an load the User's Guide and you will see. The reason is the QTextEdit which is used for displaying the messages (outTE defined in ProgressViewUi.ui). Using a QTreeView and as model a QStandardModel should be much faster, at least it is worth a try. You could also google a bit if QTreeView is the best replacement. Peter
Re: Helping out
Am Sonntag, den 30.05.2010, 19:56 +0300 schrieb Amir Rachum: > Hi guys, > I just downloaded the LyX code base and I would like to help you > people with one of the most useful pieces software I ever had. > However, I am not sure how I can help seeing as the code base is > really big and confusing and I was wondering if there's some external > documentation for the code, > and whether there's some "low hanging fruits" bugs/enhancements that I > can handle at this point. > Any pointers? Here's an idea: The "Debug/Progress Messages" widget is very slow: enable all debug messages an load the User's Guide and you will see. The reason is the QTextEdit which is used for displaying the messages (outTE defined in ProgressViewUi.ui). Using a QTreeView and as model a QStandardModel should be much faster, at least it is worth a try. You could also google a bit if QTreeView is the best replacement. Peter
Re: Helping out
Amir Rachum wrote: Hi guys, I just downloaded the LyX code base and I would like to help you people with one of the most useful pieces software I ever had. However, I am not sure how I can help seeing as the code base is really big and confusing and I was wondering if there's some external documentation for the code, and whether there's some low hanging fruits bugs/enhancements that I can handle at this point. Any pointers? what about putting hebrew translation up-to-date? another pointer: http://www.lyx.org/DevFAQ pavel
Re: Helping out
Amir Rachum wrote: > Hi guys, > I just downloaded the LyX code base and I would like to help you people with > one of the most useful pieces software I ever had. > However, I am not sure how I can help seeing as the code base is really big > and confusing and I was wondering if there's some external documentation for > the code, > and whether there's some "low hanging fruits" bugs/enhancements that I can > handle at this point. > Any pointers? what about putting hebrew translation up-to-date? another pointer: http://www.lyx.org/DevFAQ pavel
Helping out
Hi guys, I just downloaded the LyX code base and I would like to help you people with one of the most useful pieces software I ever had. However, I am not sure how I can help seeing as the code base is really big and confusing and I was wondering if there's some external documentation for the code, and whether there's some low hanging fruits bugs/enhancements that I can handle at this point. Any pointers? Thanks, - Amir Rachum
Re: Helping out
On 05/30/2010 12:56 PM, Amir Rachum wrote: Hi guys, I just downloaded the LyX code base and I would like to help you people with one of the most useful pieces software I ever had. However, I am not sure how I can help seeing as the code base is really big and confusing and I was wondering if there's some external documentation for the code, and whether there's some low hanging fruits bugs/enhancements that I can handle at this point. Any pointers? You can search for bugs tagged easyfix on trac. But the best way to start learning the code is just to dive in somewhere that interests you and try to find your way around. It takes a while, but the code does actually make some sense. ;-) Feel free to ask questions if it's not clear how certain pieces fit together. rh
Helping out
Hi guys, I just downloaded the LyX code base and I would like to help you people with one of the most useful pieces software I ever had. However, I am not sure how I can help seeing as the code base is really big and confusing and I was wondering if there's some external documentation for the code, and whether there's some "low hanging fruits" bugs/enhancements that I can handle at this point. Any pointers? Thanks, - Amir Rachum
Re: Helping out
On 05/30/2010 12:56 PM, Amir Rachum wrote: Hi guys, I just downloaded the LyX code base and I would like to help you people with one of the most useful pieces software I ever had. However, I am not sure how I can help seeing as the code base is really big and confusing and I was wondering if there's some external documentation for the code, and whether there's some "low hanging fruits" bugs/enhancements that I can handle at this point. Any pointers? You can search for bugs tagged "easyfix" on trac. But the best way to start learning the code is just to dive in somewhere that interests you and try to find your way around. It takes a while, but the code does actually make some sense. ;-) Feel free to ask questions if it's not clear how certain pieces fit together. rh
