Pavel Sanda wrote:
call for help,

it would be possible for me to lead lyx layout editor as a small school project
provided that it is work complicated enough.

If the end goal is a working, complete and useful layout editor then
I can't see how that wouldn't be "complicated enough"?

i know there are people mastering layouts better than me, so it would help if 
you
can help to write down some specification of features it should have.

by 'complicated enough' i mean it should know more than just provide database 
sheet
for the attributes described in our customization manual, since that is trivial 
to
write and won't need more people/months to code... so its a question whether we 
can
produce such a feature-list :)

Not just a database sheet - a working C++ app that can read all of the
existing layout files that comes with LyX, and allow any kind
of supported modification that we today do with text editors.


Helge, iirc you have advertised small java beast some time ago - do you have 
some
specification? i'm also CC-ing Guenter and Steve as our layout power users from 
the
second maillist.

The spec was small - basically to be able to open a layout file in a GUI, and modify it and save it. It should support the stuff found
in existing layout files at the time.

Due to limited time, my students didn't have to implement _everything_. And they used java, so nobody picked it up later. The program they made could open and modify layout files, but not those that comes with LyX. First - it doesn't support every construct. Secondly, it is not robust at all, so an extra blank line and so on will trip it up and crash.



So, for a more serious spec:
* 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
  attributes.
* Write the thing in C++, so that it can be integrated in LyX later.
* 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.
  Example:
  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
  constructs, instead
  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."

* If it isn't too complex already - document the software well too. :-)

Helge Hafting

Reply via email to