<< | Page list | >>
Developers´ page for notes/ideas about Google Summer of Code 2011 submission
Google Summer of Code 2011 discussion
(This is a playground for brainstorming about possible projects. The real ideas page is Summer of Code 2011 Ideas).
- Improved XHTML export and ePub support.
What ideas are there about improved XHTML ? Our current XHTML is reasonable, so what's the main aim ??
Maybe we can extend this to revive the DocBook support as well, and maybe the XML file format.
Is knowledge of the (X)HTML and ePub formats a prerequisite for the project? If so, they should be listed in the real idea page.
Improved XHTML export and ePub support
ePub is gaining popularity as a free and open e-book standard. It is based
on the idea of reflowable text, which will adapt to the type of reader that
is used. This reader can either be a phone, or an iPad, or an e-book reader,
or a regular pc. One can think of this as an extension of the LaTeX idiom
that one should only care about the contents, not on the layout of it. As
ePub is already used by some major companies, LyX should be able to be used
an an ePub editor.
ePub is based upon the XHTML format and since recently LyX is able to output
XHTML code natively. However, improvements will have to be made to make it
suitable as a serious ePub editor. LyX is also capable of a related format:
DocBook, though the implementation of it has been outdated. Students who
know about these formats might also improve our DocBook support.
The expected result is to have the possibility to export ePub files directly
from LyX, which are acceptable for publishers or on-line e-Book sellers.
Prospective Mentor(s): Jose or Richard (if we can get him to it).
- ODF/DOC/DOCX import library (perhaps developed jointly with KOffice)
Prospective Mentor: Rob and someone from KDE (?).
- UI Improvements and non-linear writing enhancements.
Rob Oakes´ ouliner, section folding, etc., would fall under this.
As would an improved full-screen UI, perhaps something along the lines
of what Scrivener does? (Just some thoughts.)
Prospective Mentor: Rob.
- Layout editor.
A large part of the community dreams of one,
and as many would-be-switchers-to-LyX seek one.
The idea has been discussed at lengths in the past,
and the best specs were provided by Helge  several years ago,
although the entire (very long) discussion is worth reading for anyone interested.
Here are Helge´s specs:
- support all layout files in todays LyX and earlier. Because users
already have homegrown .layouts for earlier versions of LyX.
- The user should be able to:
- create complete new document classes
- make and maintain layout modules
- modify existing classes and make changes like a new
paragraph type or charstyle
- The user should not need to know about the .layout file format
at all. All the options for how LyX displays a paragraph type
should be contained in the GUI.
- The user may need to know latex in order to tell this layout editor
what should happen when this new kind of paragraph is used.
Still, it'd be nice if this app knows quite a few of the
easier tricks in latex, such as colors, font sizes and font
- Extending this thing should be easy, for surely the next version
of LyX will have more layout options. Design with this in mind.
- The workflow should encourage smart usage, not stupid.
I need a charstyle with green text for marking stuff in my
next online book. The smart approach is a "layout module"
implementing this. The ecessively stupid way is to copy
the entire book.layout and add this functionality to the
otherwise identical copy.
But sometimes, a new class is in place because many changes
is needed compared to existing document classes. It is still
smart to use "copystyle" to refer to existing unchanged
of copying everything and then modifying some items.
- Be robust.
- The program should not get in trouble if the file has
some errors because the user messed it up with a text editor.
- - Skipping over some errors (but logging them) is nice.
- Missing "end_something" can be added when
something new unexpectedly begins.
- Crashing should not happen, and a file should be really bad
to get rejected as "apparently not a .layout file at all."
- <Here's a first draft based on the specs in the links. Please edit as you see fit.>
Each document edited in the LyX document processor has
assigned an appropriate LaTeX class which will be used when typesetting the
final document. To have a proper GUI outlook of such a document on the
screen LyX uses layouts---files which describe how the LaTeX elements should
be visualized on the screen. The most popular LaTeX classes already have
correspondent LyX layouts, however creating a new layout for an unknown or
customized class can be a daunting task.
The Layout Editor (LE) would complement LyX, and should be written in C++
and make use of the Qt library, to ensure compatibility for potential future
inclusion in the main LyX codebase. Ideally it should also share some of the
LyX libraries, so that (incompatible) changes to the LyX layout system would
not result in breaking the LE and to allow for straightforward future
The LE should allow users with no knowledge of the LyX internals to use a
GUI to create layouts for completely new document classes; and modify
existing and future layout files (since v1.4) and modules (since v1.6). The
user may need to know LaTeX in order to specify the typesetting behavior for
a given paragraph style, although the GUI should provide an interface to
several popular LaTeX features such as colors, font sizes and font
attributes. The program should also be robust enough to handle unexpected
errors, and to avoid crashing when non-standard or customized layout files
The Layout Editor would allow users having little
previous experience with the LyX layout format to easily create and
customize LyX layouts, but also comfort advanced users, which currently can
only use plain text editors for such a tasks.
- Ledpar support
Prospective mentor: Pavel.
- LyX presentation mode
LyX has been designed to write documents in a natural way, using the WYSIWYM principle. Also, presentations can be made using specific document classes. However, the representation of a presentation is not optimal yet now. The goal of this project is to enhance LyX with a feature that allows to create presentations more intuitively.
Often a presentation has to be made of content which has previously been written down (or the other way around). Therefore, often the same images are used, and often text, images, formulas, tables, and so forth are being copy pasted from the document into the presentation. Copy-pasting of these kinds of content into other application often bring problems. If creating presentations with LyX is made easy, this would be the first WYSIWYM presentation application.
Transformation of the main UI of the LyX workarea, such that one can easily scroll through the slices, and one can grasp the contents of a certain slice more easily. We don't expect a realistic presentation of how it looks like, but just an easy representation of what information is on what slide.
Prospective mentor: Vincent.
- 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.
SF: A suggestion that was made for the (aborted) application to GSoC 2008. I think it's an excellent idea and would be willing to mentor it.
Write a book that explains how to use Lyx to produce beautiful documents in a few selected scenarios (a letter, a short paper, a book-size document, a presentation).
Many new users of Lyx are intimidated by the different approach to text editing Lyx takes: focus on the structure of the document and let the formatting engine (LaTex) worry about the document's final appearance. LyX comes with excellent documentation, but a book is different. It should (gently) guide the user through a few commmon tasks from beginning to end, rather than serve as a reference document. It is the kind of item give to a person that has just discovered his/her need to start using LyX, either personally, or within an organization. O'Reilly technical books provide an excellent illustration of what the LyX book may be (among many examples, see "The Drupal Book" http://oreilly.com/catalog/9780596515805. Existing LyX documentation will provide the starting point. The student will need to come up with a selection of scenarios (in cooperation with the mentor) and write the book chapters on the basis of the existing documentation and her own experiences with LyX.
A draft of a complete LyX book
Good English writing skills. No programming skills nor LaTex knowledge required (indeed, knowledge of LaTeX may be counterproductive).
Prospective Mentor(s): Stefano
- Systematic documentation of LyX code base
LyX has very poor documentation of source code and it keeps hard for newcomers to join us. Somebody going through the whole tree making documentation for the key structures and mechanisms could improve this a lot.
- Support for Python scripting.
Support for Python scripting in LyX
Python is one of the best choices as a scripting language for an application like LyX. The idea is
allow user code to interact with LyX through shortcuts, LFUNs (LyX user commands) and an event system
(new document opened, cursor moved and so on) to provide the ability create macros for repeating tasks
or even GUIs to generate LaTeX code for useful packages.
It's not necessary to expose a complete object model to the Python scripting engine, interaction could happen
with an improved LFUN system and events. A quick internal script editor could be a good idea.
The expected result is to have the possibility to run Python code when certain events are raised and
interact with the document and the user interface.
Prospective Contributor(s): venom00.
- tex2lyx integration
tex2lyx integration into LyX
The idea would be to integrate the tex parser from the tex2lyx
program into LyX proper. LyX would then directly construct the
memory structure of a LyX document instead of writing a .lyx file
and then parsing it.
Prospective Mentor(s): Abdel
- faster LaTeX import within LyX (no need to lanch an external process and to parse the resulting file)
- Always up to date lyx format (currently tex2lyx has to be adjusted for each format changes)
- automatic conversion of LaTeX snippet from the clipboard.
- toolbar dialog
Toolbar customization dialog
Toolbars are an important component of the LyX experience and they are used for
various tasks ranging from generating the PDF output to formatting and math editing.
LyX provides users with a flexible mechanism for toolbar creation and customization.
Its biggest drawback, however, is that it can be performed only by editing
configuration files in a text editor. The goal of this (short?) project is to
develop a dialog that would allow users to create and customize toolbars via a
graphical interface. This would eliminate the burden of studying and understanding
the syntax of configuration files, and of performing toolbar modifications in text mode.
A working prototype of a dialog in LyX that allows easy customization and creation of toolbars.
Prospective Mentor(s): Abdel
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!)
Prospective mentors: we will need your Google account data for the application and a brief bio.
Put both in the (Mentors´ Bios?) page, with the email in transmogrified (non-harvestable) form
(or remember to communicate it in private when the time is nigh).
People who have volunteered to be mentors.
- José Abílio Matos
- Rob Oakes
- Vincent van Ravesteijn
- Pavel Sanda
- Abdelrazak Younes
- Cyrille Artho (backup)
LyX is a document processor that encourages an approach to writing based on the structure of your documents and not simply their appearance. LyX combines the power and flexibility of TeX/LaTeX with the ease of use of a graphical interface. This results in world-class support for creation of mathematical content (via a fully integrated equation editor) and structured documents like academic articles, theses, and books. In addition, staples of scientific authoring such as reference list and index creation come standard. But you can also use LyX to create a letter or a novel or a theatre play or film script. A broad array of ready, well-designed document layouts are built in.
Main Organization License
Why is your organization applying to participate in GSoC 2011? What do you hope to gain by participating?
The GSoC would be an opportunity to bring into the project new developers interested in typography and in writing software. It may also allow us to start work on a few of the longstanding feature requests that are regularly discussed within the community, but seem too demanding to contemplate during the normal development cycle. The implementation of even some of the proposed ideas would directly benefit the LyX community, but would also provide additional incentives to potential users to start using LyX in their regular writing and publishing activities. This potentially will attract also more developers. And we recognize that the driving force of open source software development is based upon enthusiastic and knowledgeable contributors.
A large part of the LyX users are working within the field of academics and lots of them came into first contact with LyX when writing their master's and/or graduate thesis. Also, most of the current developers started in this way to assist the development of LyX. Therefore, we think that especially students are an interesting group of users for us to motivate to get to know LyX, to spread the usage of it among their fellow students and to contribute to the LyX project.
If accepted, would this be your first year participating in GSoC?
What is the URL for your ideas page?
What criteria did you use to select the individuals who will act as mentors for your organization? Please be as specific as possible.
Mentors were recruited from amongst existing LyX contributors. Longstanding developers who are familiar with our existing source code and have shown the ability to guide new contributors will be chosen. They all have experienced large support when entering the project themselves, they acquired the technicalities which are required by the project, and they have shared this knowledge with the new or less experienced developers.
Besides having an active developers' community, LyX heavily depends on a large share of members of the user community which have proven to contribute to the project for over a long time. They have shown to be able to help out newly started users as well as to support the developers in the development by bringing up ideas, sharing experiences and providing feedback. Also, this year's GSoC application is supported by members of this comunity. Therefore, we strive to sign up a (co-)mentor from the users' community to share the mentorship or to assist the mentor in the project.
This will guarantee both practical support and technical support for the student. We foresee that this guidance will help to assure a newly developed feature which easily integrates into the existing codebase and which offers the most usability for the users.
What is your plan for dealing with disappearing students?
Students will be asked to participate in discussions on the LyX mailing list (at least weekly), so they can seek the input from the larger community on design and coding issues. Weekly follow-up by mentors by email. If unable to reach via email, by phone.
The students are also requested to submit the code they have written to a public repository, as regularly as possible. Allowing the mentors to see the progress and comment on it.
If a student is unable to be reached via email or phone after two weeks, more drastic steps (including failing the student) will be considered.
Stefano: I am not sure the last sentence is appropriate. Neither we nor Google is in the business of passing/failing students, I believe. If the student disappears they have failed themselves, and we have failed as well---since no code will come to the LyX project
What is your plan for dealing with disappearing mentors?
Mentors have been actively recruited from within the LyX developer community. They are known both for the quality of their code, as well as for their commitment to the project. As in the case of students, mentors will be asked to keep in regular touch with the larger community via the LyX mailing list.
The LyX admins will check every few weeks with mentor/student pairs to make sure everything is working fine. In cases where a mentor is not able to complete their responsibilities, however, effort will be made to first contact the mentor privately. If no resolution can be reached, the backup mentor or GSoC administrator will step in to provide support and encouragement.
Does your organization have an application template you would like to see students use?
- If so, please provide it now. Please note that it is a very good idea to ask students to provide you with their contact information as part of your template. Their contact details will not be shared with you automatically via the GSoC 2011 site.
The template is here: GSoC2011ApplicationTemplate. SF: Someone with Wiki formatting skills better than mine should improve the look.
What steps will you take to encourage students to interact with your project's community before, during and after the program?
The LyX community makes use of two very active mailing lists. The user's list as well as the developers list. Once an interested student has contacted the project, she will will be encouraged to subscribe to both lists as these are the primary means of communication for the project.
While drafting the proposal, the student will be encouraged to go through a formal design process. She might make use of the users list to solicit opinions on the feature design and then seek the advice of the developer's list as to how the new features might be implemented.
During the program, the student will be encouraged to send regular updates to the list (and not just to her mentor) in addition to code patches. The other students and mentors will be encouraged to review and comment on the patches, and in so doing, become acquainted with the wider developer community.
<< How do we want to help encourage participation after the summer is over? >>
If you are a small or new organization applying to GSoC, please list a larger, established GSoC organization or a Googler that can vouch for you here.
KDE (Leo confirmed it)
Anything else you'd like to tell us?
<< Perhaps something about how LyX is uniquely positioned as a tool for working with both electronic and print documents? >>
Backup Admin (Link ID): Vincent (not the real ID)
Categories: Development, GSoC, Misc