Well here we are again with another issue. Still in the growing stages of a news and editorial page as I find my feet (or should that be fingers) putting this collection together. We've a bit more variety and a bit more length this time also.
Lars posted a link to a project last week that got my head spinning with possibilities. "RBook" is a REBOL dialect for writing documents by Karl Robillard. Karl says that RBook "was inspired by the LyX document processor" and it follows our WYSIWYM philosophy. RBook is mainly setup for producing HTML documentation although it also produces LyX files and plain ascii text. The exciting part is that the document is itself a REBOL program.
This brought to mind a number of threads of discussion over the last two years about adding scripting languages, smart layout files and even the already operational Literate Programming support. Forget document macros make the standard file format a program and export to any document format you want! A glimpse of the future? Perhaps. An alternative future involves making an XML DTD and using that as the document format. There have been many discussions on this issue as well. André Pönitz has been doing some work on this topic. While you're reading about RBook and imagining the possibilities I'll try to find some links to those discussions I mentioned.
Although LyX isn't a wordprocessor, it was the thing I was happy to find recently when I thought I was searching for a wordprocessor. :-)
LyX is, of course, a document processor.
Insets are document objects. Examples include any of the things that appear as buttons (table-of-contents, citations, labels, URLs and so on) and most of the glyphs like equations, quotation marks and accented characters. Lars Gullik Bjønnes and Jürgen Vigna are busily transforming all document objects including paragraphs into insets. Jürgen was able to tear himself away from the work long enough to provide the following overview (slightly edited):
Insets will help to clean up a lot of source and remove a lot of hacks we actually have in the code (footnotes, tabulars and other floats, minipages, ...) and they should be easier to work with and also give a better visual feedback. Minipages and tabulars will particularly benefit from being made into insets. A scrolling tabular inset is in the works although not currently in the repository.
We have reached the maximum amount of hacks we can tolerate in the core to support the features we want and now it's time to clean up, removing some of the hacks and coding the stuff the right way.
There may also be stuff like the ERT inset which hides the Evil Red Text (say LaTeX) from the speed-reading eye. You can make templates with LaTeX in them without scaring people when they see all that command syntax at the first look they take when they load the template.
Most large insets will be collapsible or you may prefer the term foldable -- just like fan-fold paper or the folding mode of some editors like Brief. This property could then be used to implement a better form of the outline mode offered by some word processors. Better, because we already have folding footnotes, tables and figures.
A long time ago Larry Marso asked about the possibility of hiding the raw LaTeX he was using in an inset.
Larry ended up leading a one man crusade to convince the core developers of the importance of LyX useability for newbies to LaTeX and for people like secretaries that just want to get a job done with a minimum of fuss using templates for letters and so on. One point was that the average user doesn't need to know about these commands and might either be scared off by all the strange red text in their document or worse yet accidentally change it and not know how to get it working again.
The raw LaTeX commands are displayed as red text on screen and allow you to enter any LaTeX you want into your LyX document. The beauty of this is that even if LyX doesn't support a particular TeX package (.sty file) you can still use it within your document. Larry suggested that for new users the raw LaTeX was more like "Evil Red Text".
Everybody agreed with Larry that it would be a good idea to have a collapsible inset, but he didn't let us forget about it even after being told it was not an easy thing to implement. Some of these threads were very long and were sometimes heated. The upshot was, that due to Larry's persistence, the ERT thing became an icon and thus worthy of attack. Hats off to Jürgen Vigna and Alejandro Aguilar Sierra who did this work the first time at the Mexican LyX Developers Meeting and hats off also to Larry for continuing his crusade to improve LyX's useability. Jürgen has incorporated the "Encapsulated Raw LaTeX" inset into LyX and is now fine-tuning it.
I may have missed a few threads either because the archive search mechanisms don't work or I used the wrong keywords or the threads I know took place are not archived. I'm sure there is more than enough reading material for anyone with too much spare time on their hands. It's been a long time coming but ERT insets are finally a part of LyX.
I never realized before how long it took for collapsible ERT insets to become a reality. The LyX timeline for me started in April of 1997 although I didn't really pay much attention to the list until about June or July of 1997. By then the ERT concept was already a year old and wasn't implemented until the following year. Followed by a further delay of about 12 months. It's only become possible to incorporate ERT insets and the other interesting and wonderful developments from the archived development strand into the current transitional series in the last few weeks.
What else have we overlooked or forgotten about?
How to report bugs effectively provides a glimpse of how bug reports look from a developer's perspective and provides some tips for making your next bug report useful.
The most common question asked by developers after a bug report has been sent in is: "What version are you using?". With a new release, prerelease or fix-patch out every two or three weeks it's very important that you include the version number of the release or the date of the cvs snapshot you are using when filing a bug report. Included in the distribution is a "Known Bugs" document, available from the Help menu, that includes a description of what the developers expect you to provide in a bug report. That file also lists most of the difficult-to-fix bugs in LyX and many have descriptions of simple workarounds. Remember that everyone loves reproducible bugs because they're easier to fix. So if you find a bug and can create a small example file to demonstrate the problem you'll speed up the debugging process a lot. The next best thing is a set of instructions to follow to trigger the bug.
A simple tip for anyone wanting to file a report with a backtrace of LyX is to
capture the output of gdb using the tee command.
sh or bash : gdb lyx 2>&1 | tee gdb_dump.txt
csh or tcsh : gdb lyx |& tee gdb_dump.txt
You can read all about tee and gdb in their respective man or info pages. An impromptu tutorial on filing useful backtraces appears in this thread on the developers mailing list.
Get it here. This is a small patch against LyX 1.1.4fix1 which fixes various bugs. Note that you must first apply the 1.1.4fix1 patch to 1.1.4 yourself or fetch an RPM from Kayvan Sylvan's site. Jean-Marc Lasgouttes has been hard at work preparing this patch. His job hasn't been easy given the large number of internal changes since 1.1.4 was released. Expect a 1.1.5pre in a couple of days.
CVS stands for "Concurrent Versions System". CVS is a version control system that maintains a central source-code repository and allows multiple developers to edit their own copies of this source-code. CVS provides automated facilities for merging each developers changes into the central repository (when they "commit" their changes) or merging changes made by other developers into their locally modified sources (when they "update" their sources).
Multiple different projects can be stored in the same repository. Each of these
areas of the repository is called a "cvs module". LyX has several cvs modules
ranging from the web-site you're now reading (www-user) to the current
source-tree (lyx-devel). Not all modules are active. The code for the
1.0.x series of LyX is archived in lyx-1_0_x and the previous development
effort is archived in lyx.
There is a web interface for CVS that allows you to follow the changes made to individual files and to view the message accompanying each "commit". You can't beat having your own copy of the sources though. Instructions for doing just that provided here.
This week Lars added a \show_banner keyword to lyxrc so you can stop the splash screen or banner image from appearing on startup. Doesn't sound like much but it was one of the most requested features.
Garst R. Reese's hollywood document class got some attention in the mailing list this week when he contacted the GNU Free Film project to let them know that LyX has been supporting screenplay writers for over a year now. Hollywood first shipped with LyX-1.0.0.
Hollywood allows you to write spec scripts in the format demanded by the US film industry. Garst has also written a document class to support playwrights. That class is naturally enough called broadway and it has been a part of LyX since version 1.0.2.
A discussion a few weeks ago about the problems of extending the existing Hebrew support to also handle Arabic has resulted in Dekel Tsur posting a patch. He then had to post it again after discovering that Lars had just committed a lot of changes to most of the files in the repository in the short time since he'd created the patch.
LyX is still in a transitional phase and while it might still look much the same on the outside there have been some massive changes under the hood over the last few months. While we are still trying to progress step-by-step toward our goal Lars likes to do a little dancing from time to time. The good news is that Dekel's patch is now in the source tree and LyX is another step closer to becoming a truly international application.
The next major step in this direction will be the incorporation of CJK-LyX which will finally see an official LyX with support for Asian languages. This should also make ChangGil Han's life a lot easier.
A tornado named Angus Leeming struck
the GUI-independent dialogs subproject this week. Angus found a number of ways we could
improve the inheritance hierarchy in the xforms implementation. Once the details are ironed
out there we'll have a terrific reference implementation for other ports to learn from.
A set of guidelines for working
on the xforms dialogs has been drawn up as has an action plan.
In the meantime we have a sed script
to convert the code from the lyx cvs module to match closely with the current implementation.
This should allow us to rapidly shift about 80% of the dialogs into gui-independent form.
The actual plan for using libsigc++ and xtl still remains unchanged although there have been a few teething problems in adopting xtl mostly related to conflicts between LyX's internal std::string implementation and the way that gcc implements its exceptions header file. A solution is expected within the next couple of days that will allow the use of LyX's std::string if desired by the user.
Last issue's crystal ball gazing wasn't very accurate which is about the same as most clairvoyants. So I'll have another go this time:
Many thanks to Asger Alstrup Nielsen, Jürgen Vigna and Amir Karger for their contributions to this issue. Thanks also to Timm Danker for your words of encouragement -- its nice to know LDN has a readership of at least one person who isn't a core developer ;-)