LyX participates in the Google Summer of Code - which project ideas could be suggested?

Question

This year, LyX participates in the Google Summer of Code. This is a great opportunity to get improvements and new features implemented. I appreciate that LyX makes entering the TeX and LaTeX world easier, I'm sure there are many LaTeX users who started with it. And for sure, many LaTeX friends use LyX for rapid writing.

So this question goes to both LyX and LaTeX users, who are interested in supporting the GUI way of TeX and LaTeX:

Which improvements would you suggest to the LyX project?

I.e. which feature do you miss, what would you suggest as a project idea? We will make sure that the LyX project will see the ideas here.

Postscript (added by Charles)

The LyX team have put up a page with their project proposals at LyX 2013 Summer of Code Ideas. The deadline (May 3rd) has passed.

Answer 1

I know there are already many LaTeX online compilers. Once I thought, it would be great to have an online LyX editor, so I don't need to install a whole TeX distribution and the LyX software on my computer. But I know it would be challenging to port a complete GUI to the web. So my suggestion would be:

Making the LyX program capable of using online LaTeX compilers.

This means having an API and usable connections to existing online services. I'm sure the vendors of such services would support it. So a user could simply install LyX, and benefit from the newest TeX version without installing it - slim but capable and up-to-date installations would be possible.

File storage services such as dropbox could be connected, the storage of an online compiling service used, or files could simply be uploaded each time when being compiled - LaTeX files are small, and compressed uploads or syncs would be quick.

Answer 2

Simplification and extension of module support

Motivation: "LyX can hardly support all LaTeX packages". For example, users want to use the following LaTeX packages but they have no native support in LyX at the moment: "mdframe" (Create new paragraph style in LyX), "parallel" (Cornell Notes - A lyx or latex solution needed), "glossaries", "chapterbib", ...

Therefore, LyX can be extended by modules. A user can write such a module and publish it to the benefit of others. This should be more encouraged and modules should be made more powerful.

Goals:

1. Make modules more powerful by introducing configuration options for modules in the GUI.
2. Extending (certain) "Style" constructs (defined by modules) such that they can be configured during use by a GUI dialog.
3. Simplify the selection and installation of modules such that they can be more easily distributed to the benefit of other users.

Overall, this project would integrate LaTeX better into LyX and would allow for easier community contributions.

---

1. Configuration options of module in GUI

It should be possible that a module can register an own configuration page under "Documents Settings". Such a "configuration page" should be separated from the native "configuration pages". Certain configuration settings in the module file (to be introduced) should be displayed by LyX on such a configuration page. Graphical elements like check boxes or items of a drop down list should be mapped automatically to LaTeX code blocks. Furthermore, there should be beginning (pre-) code blocks and ending (post-) code blocks. Here is how the configuration of "theorem" might look like in future using this project. This would replace the bunch of existing "theorem" modules by only one:

A good candidate to look at might be the "PDF Properties" page that translates to the settings of the "hyperref" package. This package is important but not always used. Hence, if this project were realized one could decide whether "PDF Properties" / "hyperref" package should be provided as module - instead of selecting "Use Hyperref Support" one would activate it as module.

2. Extending "Style" constructs with GUI dialog

With similar techniques as for the configuration page of modules, it should be possible that "Style" constructs (especially, when "LatexType" is set to "Command" or "Environment") have configuration options (via context menu).

At the moment, LaTeX commands or environments with several arguments are not supported (see also Parameterised Enviroments in Lyx). An example that might be helpful to study is the "minipage" environment. It is supported natively by LyX but cannot be supported by a module at the moment. Furthermore, it should be possible in some way for a "Style" of a module to hook into menus (again, for an example see "Insert > Box > ....").

3. Selection and installation of modules

Improve the "Modules" page of "Document Settings". Basically make a list with following columns (some fields needed to be introduced in the module files): "Used (Position)" shows whether module is active (if so then the position among the active modules); "Module-Name"; "Category": "all" or a combination of "LaTeX", "HTML", ... (i.e., supported output formats of LyX); "Version/Release Date". For a selected module, the description, the required module(s), the excluded module(s), and the location (file name) should be displayed similar as in the following picture...

One should think about the possibility of automatic download of new modules from a site like http://wiki.lyx.org/Layouts/Modules (going a little bit into the direction of CTAN or CRAN or ...; see also this question). Furthermore, one should state clearly the license of a module, and consider introducing some status about modules on the website (quality/rating of module, most downloaded). Finally, a little module documentation should become mandatory as it is for LaTeX packages!

Answer 3

Something fairly easy to do that can't be done now and that would be very useful in collaborative editing of Latex documents: write a Latex highlighter that takes any Latex document and turns it into a Lyx document whose contents are the original document, with highlighting as appropriate and as far as the parse allows. If it were supported by some additional features in the LyX user interface, this would let us use Lyx as a Latex IDE (cf. Can I think of LyX as a LaTeX IDE?).

Highlighter

This could be implemented as a command-line program, say one that when invoked lyx-highlighter somedoc will create a highlighted somedoc.lyx file from the somedoc.tex source.

The highlighter should ensure the first two of the following properties, and satisfy as many of the others as possible:

1. Ensure that all Latex source would be represented character for character in the output, even when the tex2lyx parser fails;
2. Ensure, where the tex2lyx parser allows, that it is easy to distinguish textual content from Latex markup. For example, in the chapter heads, while the \chapter{ and } markup would be the same size as the chapter name, they would be highlighted in a different colour to make their status in the text clear (see example mock screenshot above);
3. Represent chapter/ section heads as Lyx chapter/ sections;
4. Represent title/ author/ date in the preamble; and
5. I think it is not straightforward to represent arbitrary Latex colours in Lyx, and the UI aspect is tricky (conflict with second point), but it would be nice if Latex colour macros could be displayed in an intuitive manner.
6. Support for latexdiff or similar change-marking markup.

LaTeX IDE

With such a highlighter, Lyx could be used function as a Latex source editor somewhat comparable to Kile or Texshop, by besides also carrying out its existing role as a WYSIWYM editor, and bringing its features such as change-tracking to this new role.

Additional changes to the main Lyx application could support this: these marked up files could be treated specially, and offering new specialised menu items to support such tasks as compiling the source (which differs from the Lyx file) or reparsing the Latex (could this be done only in a section?) after changes are made.

Implementing such a highlighter would get the SoC coder familiar with how the tex2lyx parser works and how Lyx represents text internally. It might be a good "first deliverable" as part of a more ambitious Lyx project.

Answer 4

Provide auto formatting feature that behaves like what Microsoft Visual Studio does.

For example, if we type or paste the following code snippet inside the editor,

\psset{arrows=->,linecolor=red,fillstyle=solid,fillcolor=blue,}

\def\function#1{%
\psclip{%
\pscustom[#1]{%
\psframe(1,2)(3,4)
\pspolygon(1,2)(3,4)(5,6)(7,8)
}%
}
\psframe*(4,4)
\endpsclip
}

LyX will automatically reformat it as follows,

\psset
{
    arrows=->,
    linecolor=red,
    fillstyle=solid,
    fillcolor=blue,
}

\def\function#1%
{%
    \psclip
    {%
        \pscustom[#1]
        {%
            \psframe(1,2)(3,4)
            \pspolygon(1,2)(3,4)(5,6)(7,8)
        }%
    }%
        \psframe*(4,4)
    \endpsclip
}

It makes coding in TeX syntax more fun, doesn't it?

Edit:

The code snippet above was accidentally chosen in PSTricks syntax but my intent is not specific to PSTricks.

Answer 5

Even though LyX provides with its WYSIWYM (what you see is what you mean) philosophy a much more visual feedback of the document structure than plain LaTeX, this is not at all close to WYSIWYG. What I really miss in LyX is a continuous compilation mode, so that the PDF gets updated while editing. So my proposal is:

Implement a continuous background compilation mode for LyX

Answer 6

I don't know if this is possible, but it would be really nice to be able to edit the source directly. Currently, LyX only supports inputting LaTeX codes through the ERT box, but not editing the codes generated by LyX itself.

In my experience, the .lyx to .tex export works more or less smoothly, but importing .tex into .lyx doesn't work very well, especially when the .tex document is large and contains a lot of user defined macros.

I would like to see these two aspects of LyX improved, in addition to the above suggestions.