>>>>> "Allan" == Allan Rae <[EMAIL PROTECTED]> writes:
Allan> Two weeks ago I was at the Conference of Australian Linux Users
Allan> and I wrote "LyX Developer" on the bottom of my name badge to
Allan> see what responses I got.
Great idea! When I read about CALU, I wondered whether you would be
there...
Allan> * LyX is cool * Users love
Allan> our philosophy of enforcing styles and concentrating on content
I think this second point is important and that we should always keep
it in mind when adding so-called 'user friendly' features.
Allan> * File transfer/interchange of documents with pictures - The
Allan> difficulty of sharing documents with others. In particular
Allan> ensuring that all the relevent files are bundled together. All
Allan> the people with this complaint resorted to storing each new
Allan> document in its own subdirectory to ease the bundling process.
Allan> Some of these people suggested embedding the images into the
Allan> .lyx file while others would be happy with an automated tarring
Allan> and untarring facility.
Yes, handling tar.gz files transparently would be great...
[interesting things snipped]
Allan> * .layout file creation/management tools - a LaTeX-to-layout
Allan> parser would be ideal - otherwise a GUI tool for maintaining
Allan> layout files. The description of this tool was essentially a
Allan> generalised version of Martins Tcl/tk tool for use with his
Allan> neoprene.cls
In the latest LaTeX release, the News file says:
--------
\section{Coming soon}
Major work on a new class file structure to support flexible
designs is well under way; some of this work will be presented at the
TUG'99 conference in Vancouver, Canada. With a bit of luck much of
this work could be ready for integration into the next release---so
watch this space!
----------
This is probably what we are looking for, instead of hacking our own
class...
Allan> * Multipart document [MPD] support should ensure correct use of
Allan> \input and \include. TOC support for MPDs with the same
Allan> hypertext style traversal across file boundaries. - there were
Allan> also calls for some semi-automated way to split an existing
Allan> document into multiple parts. An automated
Allan> "split-document-into-one-file-per-chapter" facility would be a
Allan> good first step. Many thought this facility should be driven
Allan> from the TOC popup (doesn't kLyX do something like this?)
Do people really want one file per chapter or just a way of editing it
as if it were one file per chapter. There were thought about having
tabs presenting partial views of documents according to some criteria,
a long time ago.
Allan> * SGML/XML output using jade as an alternative to sgmltools
I think the DocBook support in 1.0.4 is a good step in this
direction.
Allan> * Be able to handle documents of 300-400 pages or more in a
Allan> single file without crashing like Word does
Aren't we already doing that? What are the problems?
Allan> * XML file format to replace .lyx format. Some people
Allan> suggested using libxml for this. I'd suggest we could move
Allan> lyxrc to XML as a first test because with a lyxrc DTD we'd have
Allan> config file validity testing for free using any validating
Allan> parser. It could also make creating the Preferences popup and
Allan> handling easier. libxml is very low level and is still
Allan> evolving.
I do not see the interest of using xml for something as simple as
lyxrc...
Allan> * The idea of a scripting language received reasonable support
Allan> although quite a few were worried about the possibility of
Allan> macro-viruses.
I am too. I'm not really for scripts in documents.
Allan> I've been thinking a bit about the applications
Allan> of scripting languages in LyX while writing this up and can see
Allan> the greatest benefit in things like version control
Allan> independence and spell-checker independence since we can have a
Allan> generalised manager class that uses scripts to implement the
Allan> different services. Many felt that scripts weren't needed in
Allan> documents but the option of extending LyX arbitrarily without
Allan> having to recompile and reinstall was a very good future
Allan> direction.
Yes, we need that, but I think it should be post-1.2. We just have too
many things to do right now.
JMarc