• Browse GIT
• View
• Edit
• Upload
• History
• Print

GSoC2008

<< | Page list | >>

Use these pages for notes/ideas about Google Summer of Code 2008. See also GSoC2011 for the 2011 submission.

1.  Links

• http://code.google.com/soc
• http://permalink.gmane.org/gmane.editors.lyx.devel/78493 - original thread
• LyxNewsDevel:78493

2.  Suggestions

Feel free to add more suggestions, as well as adding comments to the various sections. You can move suggestion you feel are less good to the end (with a comment/motivation about it!)

2.1  GUI-based editor for .layout files

Either standalone or included in LyX

<+1> Charles. Maybe a GUI for the custom paragraph styles

<+1> Martin... though already a HOWTO would help (how much is there in the docs?)

<+1> Pierre. It would be vital. And with color&size handling. (+100)

2.2  Automatic creation of .layout files from .cls files

This could be combined with the layout file editor, and it could also include a semiautomatic wizard that asks a few questions.

<-1> Martin. Nearly impossible to get right. <-1> Richard. Ditto.

2.3  Change file format to something XML-based (ODT even, maybe)

Probably too much for a project, since it involves a lot of research and also a lot of code changes. Furthermore the decision process needs tight interaction with core LyX developers, this also makes it less suitable as a project.

2.4  Export/import to ODF

<-1> Charles. It is a huge project. GSoC leaves one month, 1.5 month of programming

<-1> Richard. Export to ODF already exists in the form of oolatex, and it's probably possible to adapt Plastex to do it, too. In any event, this isn't really a LyX issue. What one wants is a reliable LaTeX to ODF converter.

2.5  Export/import to HTML

<-1> Richard. As with ODF, what is wanted is a reliable LaTeX to HTML (and back) converter. There are now several. There are some issues related to getting them to work properly on different platforms, but in many cases this is due to upstream issues, e.g., the fact that tex4ht has problems on Windows. These are not LyX issues, though of course that's not a reason for someone not to work on them.

2.6  Quoting of Index Inset contents

2.7  Converter from EMF/WMF to EPS or some other well supported vector graphics format.

Currently no decent converter for WMF/EMF to EPS exists, the existing ones like wvware cannot handle many files.

2.8  Rewrite the tabular code

This code would benefit enormously from a cleanup (or even rewrite from scratch). Also some nice packages could be supported, like colortable or multirow. longtable and booktabs support could be completed.

Relevance: for a document processor for demanding authors, tables are of central importance. The current implementation is not up to snuff and may prevent some from adopting LyX for their professional work.

Tabular-type objects appear in both text and math. The LyX front-end to them is partly unified ("Rows & Colums"), but the back-end logic is mostly separate.

This project involves the text version of tabulars. The LaTeX interface, and functionality, is very versatile and only partly supported by LyX.

• clean up and re-factor the code, which is currently rather messy
• make the user interface more consistent and implement (most of) the unimplemented features
• speed up the code, which is slow esp. for big tables
• implement support for packages like colortbl, and clean up longtabular support
• an easy way to import, e.g., CSV tables, as well as convert textual "naive" tables into true tables
• figure out how to do cut and paste right, for text within cells, and for multi-cell material. This requires understanding of X clipboard and selection and same (or rather: not the same) on Windows.

2.9  Rework the math editor

The math editor currently has lots of open bugs. There are at least three things to do:

• Use InsetText for text-in-math, which would solve various bugs, like ⚠ bug 1435.
• Allow to edit labels to equations, see ⚠ bug 2556.
• change the math-macro feature to make it really usable, see e.g. ⚠ bug 1391, 1394, etc. At the same time math macros could be extended to normal text, too.

2.10  Rewrite spellchecker interface and implement inline spell checking

This point can be crucial to facilitate the edition of documents like other common word processor as Word or OpenOffice Writer. Perhaps, this is the main characteristic that many users of LyX are waiting.

2.11  Package manager for the preamble

This would let you choose the order of LaTeX packages that are put into the preamble, and also disable some if needed.

<+1> Charles.

2.12  Import from TeX (re-use of tex2lyx parsing inside LyX code).

This is probably not enough for a whole project, since only a bit of code refactoring is needed. Abdel: There is more to it than simple refactoring. The idea would be that tex2lyx fills in LyX internal buffer structure directly instead of outputting to LyX format. LyX itself will take care of the writing to a file. This means that tex2lyx will always stays up to date, no more version lags.

2.13  Make tex2lyx output the current file format

That means to add a number of smaller features (easy) and to take text encodings into account, with full support of encoding switching via \inputencoding and the CJK package (a bit more work).

2.14  Design and implement a fully automated testing service

This can be useful for LyX, tex2lyx and lyx2lyx. It would include a cron jobn that runs the tests automatically from svn, and a web page with the results.

2.15  Context menu with right-click

<+1> Charles. Or maybe something similar to the new MsOffice ... Richard. Abdel has just implemented this.

2.16  Redirect optionally lyxerr to a QTextEdit (and get rid of the console)

2.17  Improve CAS (Computer Algebra System) support (e.g. on a plug-in basis)

see http://article.gmane.org/gmane.editors.lyx.devel/78508/

2.18  Add support for beagle

http://beagle-project.org/Main_Page

(It's not clear whether this needs to be done. Adding the following to the external-filters.xml file of your beagle distribution will enable Beagle to search .lyx files:

<external-filters>

<filter>

 <mimetype>application/x-lyx</mimetype>
 <extension>.lyx</extension>
 <command>cat</command>
 <arguments>%s</arguments>

</filter> </external-filters>

James

2.19  Adapt LyX so that it can edit wiki pages

2.20  Add install support to the cmake build

Currently it is not possible to install LyX by the cmake build system.

2.21  Add a more comfortable TeX editor

Maybe it is possible to merge in Kile as a editor for plain TeX.

2.22  Make LyX also a KDE program

Currently LyX only uses Qt, not kdelibs, so it is not optimally integrated into KDE. In future kdelibs will be also available on Mac/Windows, so this would not be a Linux-only project.

<-1> Richard. If this is done at all, it should be an optional part of the build. Users of lower end machines (e.g., me, when I'm working on my old Vaio) may not want to install kdelibs or deal with the overhead.

2.23  Add OCR support

Use the Google sponsored OCR tesseract for a OCR input dialog. Links:

• http://groups.google.com/group/tesseract-ocr/
• http://sourceforge.net/projects/tesseract-ocr
• http://code.google.com/p/ocropus/

Work to be done

• make tesseract a cross plattform library (buildsystem, library API-design)
• create a Qt dialog for the picture input
• pipe the output of the OCR into LyX

2.24  Write The LyX Book

We can use Lulu for this. Lots of good material already there; we should collect the best, make it consistent, clean it up, and make it look like a book. This is not the same as putting the existing documentation between covers! A book is different.

I see it as the kind of item that I would give to a person that has just discovered his/her need to start using LyX, either personally, or within an organization -- like a journal publisher, a university's publishing service, or the documentation department of a technology company, to mention some. The book should make this initial process smoother. I would hope though that the book would remain a useful reference also after that -- requiring an index.

3.  Controversial projects

3.1  Export/import to MS-Word

Should be done via ODF (Open Document Format), which is gaining in popularity and constitutes a gateway away from these legacy formats.

Providing this gateway is again highly relevant in an collaborative authoring context, as it facilitates migration. Collaborative authoring between LyX and OpenOffice users is probably not realistic, due to the paradigmatic differences between the two.

<0> Richard. I'm a little unclear how this is supposed to differ from the Export/Import ODT project. If you can do ODT, then it's just a matter of being able to convert between DOC and ODT, which certainly isn't a LyX issue. For what it's worth, however, the easiest way to implement doc2odt, it seems to me, would be to use the PyUno framework in OOo, and let OOo do the actual work. Indeed, since OOo will convert to LaTeX, you could implement doc2tex the same way.

3.2  Port to Maemo and/or OpenEmbedded platform.

Will only add little to potential user base. OTOH the embedded form factor brings interesting challenges that may be more generally relevant. Also, this will bring LyX to the attention of yet another community of early adopters; note that for an Open Source project, critical for viability is recruitment, not of end users, but of contributors.

The TeX toolchain up to pdflatex is already available on Maemo.

4.  Mentors

Prospective mentors: we will need your Google account data for the application. Put it here in transmogrified (non-harvestable) form, or remember to communicate it in private when the time is nigh.

People that could consider being mentors.

• Abdelrazak Younes
• Martin Vermeer
• José Abílio Matos
• Peter Kümmel

5.  Application planner

This is a tool for planning the next application, for Google Summer of Code 2008.

This uses as example one of the propasals that I (MV) submitted in 2007, which failed. Reasons I suspect for failure are the short time for preparation (it wasn't really a community process) and as a result, a somewhat rambling text. Next time we should do better:

1. Collect willing mentors and their Google contact emails in good time
2. Use the below draft as a basis for developing a good proposal. The Web application for mentoring organizations asks these points, offering really small text fields to put them in.
3. Concentrate on what we as an organization hope to achieve from a user and community viewpoint, not coding of functionality technicalities (i.e., the draft is actually bad)
4. Edit boldly, including weeding out bad text.
5. Short is good
6. Use the draft page also as a "notebook" for things to remember, to pay attention to, good ideas (about writing the application, not about the project itself, which should be in this page).

This is the working draft: GSoC2008-lyxtab

Instructions for mentoring orgs:

http://code.google.com/support/bin/answer.py?answer=60303&topic=10727&ctx=sibling

The deadline for 2007 is past.

---

Category: Development, GSoC 2008, Misc