This is the second issue of LDN. The first issue was released two weeks ago on the 17th of February. With a little luck and encouragement I'll be publishing future editions fortnightly as well. Thanks go to the staff of the Linux Weekly News for carrying the first LDN which I mailed to them at what must have been only minutes before their deadline.
The format is a bit different this time around. One area of development is featured followed by a couple of short editorials followed by some recent feature additions that haven't been trumpeted yet. This is likely to be the format for future editions. There are plenty more short news items on our news ticker.
Also known as: "What's happening? Are you ever going to do anything? I reckon XForms sucks and you should use blah-tk instead!"
As mentioned in the first issue of LDN the previous development series has been put on ice. During that series quite a few advances were made including having about 80% of the dialogs GUI-independent. All that work isn't lost though. A revised scheme for the dialogs is currently being trialled in the "rae" branch of the lyx-devel cvs module. We currently have the Copyright dialog as a proof-of-concept implemented in both xforms and KDE. Once the new scheme is finalized we should be able to very rapidly backport the archived work -- I'm working on a script to convert those files to the new scheme although some manual intervention will still be required.
The new scheme utilises Libsigc++ instead of the now defunct gtk-- signalling system. In addition, we will be using the XTL (externalization template library) to handle communications between the dialogs and the LyX core. This will also eventually allow scripting languages and LyXServer-aware applications to change anything that a dialog can. XTL will be included into the new scheme in the next week. If all goes well the new scheme will then be merged into lyx-devel and the floodgates can open. Allan Rae will be coordinating the dialog work.
If you are an OS/2, Windows, KDE, Gnome or Berlin (or any of the other myriad of desktops and GUI toolkits) developer now is a good time to checkout what we're doing and make sure your favourite "blah-tk" can be used with this scheme.
setenv CVSROOT ":pserver:firstname.lastname@example.org:/usr/local/lyx/cvsroot" cvs co -r rae -d rae_lyx_devel lyx-devel
The GUI-Independence: The LyX Way document on the LyX web site and included in the archived lyx module of the cvs repository describes how the previous scheme worked. Most of its content is still valid for the new scheme and is recommended reading for anyone considering contributing. I'll eventually update this document -- hopefully before all the gui-indepence work is completed...
Both the old and new schemes abstract the user interface at the dialog level and are based on the notion that the LyX core only needs to know how to tell particular dialogs to show, hide or update themselves. This is all achieved using signals and slots. Most dialogs only need a single show signal. Common hide and update signals are used to inform visible dialogs when a major change occurs. Such changes include when a user changes to a different buffer or closes all open buffers.
Different toolkits will be able to use this high-level abstraction of the interface in different ways. For example, someone may decide they want to merge the character, paragraph and document level dialogs into a single super-dialog using a tabbed widget. They will be able to use the three different show signals to decide which tab should be focussed. A different toolkit-port may use toolbars for some of the dialogs while another toolkit-port may offer a choice of toolbars or dialogs.
The technical details of the new scheme involve each dialog inheriting from an abstract base class: DialogsBase. Another class, Dialogs, contains all the signals required to trigger the dialogs. Eventually LyX will support multiple frames (main windows, LyXViews) and each of these will have their own set of dialogs.
Abstracting at the level of the dialogs results in each toolkit port being implemented completely within the confines of its own subdirectory making maintenance easier since they will be self-contained modules. Common code is kept in a function dispatcher, LyXFunc, where it is also available to LyXServer-enabled applications or scripts.
A number of mini-project areas have been discussed on the developers list over the last few years. Most recently, discussion has focussed on PDF generation and support for other bibliography style (natbib, harvard). The core developers are already heavily over-committed and seek volunteers to tackle these projects. The design discussion is archived in the mailing list archives and the first volunteer we'd like is someone to gather these threads together into design documents so that all the design issues thrashed out at the time can be used by new developers.
The beauty of this position is that anyone can do it. You don't have to be a coding genius to be able to put together the design docs. Contact the LyX developers' list if you are interested in helping.
We've had a number of reports of problems with version 0.89 of XForms on various platforms. We recommend against using this development version of the library. Please continue to use 0.88 at least until 0.90 is released. A couple of developers are testing LyX with 0.89 to ensure we keep abreast of any changes there.
On a related note if you are installing on a glibc-2.1 based Linux system you must use the version of xforms compiled for that library. If you use an xforms library compiled for glibc-2.0 LyX will almost certainly segfault on startup. For XForms RPMs see below.
Kayvan A. Sylvan provides RPMs of both the stable
releases of LyX and snapshots of the cvs repository of LyX. Find them at
In the HTML subdirectory
of that site, you can also find both binary and source RPMs of TTH.
If you also get the XForms RPM you should have all you need in
order to try out this new feature in LyX.
Kayvan's site also holds RPMs for RH5.1 created by Jacek M. Holeczek.
ChangGil Han contributed a new patch against LyX 1.1.4 allowing to write documents in Chinese, Japanese and Korean languages. Find more about it at the bottom of the download page.
We have finally attracted one developer from outside the left-to-right community and have now applied a right-to-left hebrew patch from Dekel Tsur. This patch is likely to grow into more general support for right-to-left languages shortly.
The development version of LyX has been extended with an HTML export feature based on TTH which is free for non-commercial use.
Looking in the crystal ball I see the following items appearing in the next issue: