After José Matos's fabulous debut contributions in the last issue I thought LDN might settle into a new groove. Well José is snowed under with other things to do so there will be a bumper issue of tips collected together by José in the next issue (won't there, José ;-) [José: Yes. Scout's word!]
I started writing stuff about version numbering changes and what you can all expect to see in coming releases of LyX. Much to my delight Jean-Marc Lasgouttes started a thread on Updating NEWS for 1.1.6 and I have decided it's about time he and other developers contributed to LDN so I've included what they've written so far. Thanks Jean-Marc, Jürgen Vigna, José and Amir Karger for your contributions to this issue. [I've since learned from Jean-Marc that he got some of the entries from earlier editions of LDN!]
Actually you could almost say Jean-Marc has written half of this issue because I've also included his description of LyX-1.1.5fix2 which should be released by the time you read this.
Another small point is that the mail archive seems to be lagging behind the mailing list by at least a week maybe longer. Either that or it's dropping entire threads so there are a number of places without mail-archive links in this edition. I'll try to fill them in when they become available.
Certainly Path is not intuitive (and the source is not exactly transparent! ;-)
If you had seen how it was done before Path was introduced you would have said it was obvious and intuitive. :-)
I'd be happy to make the changes as it was me who raised the question in the first place. Just say yeah or neah...
— Angus
Hey... that is one of my first babies using that idiom. I have feelings you know. Dammit, why must everything be intuitive...
— Lars
After 1.1.6 we will change the numbering scheme slightly so that hard working system administrators won't have to wonder what the fix suffix stands for. They seem happy enough with something cryptic like the pl suffix used by some projects but complain about fix. Oh well!.
Just like now, all releases without a suffix are stable releases. However, any fixes will just change the 3rd revision digit. We will still have prereleases labeled with a pre suffix and if you checkout a copy of the cvs module the version number will have a cvs suffix. Also remember that since September of 1999 we no longer use the Linux kernel numbering scheme. We use a contiguous numbering scheme where there is no difference between odd or even numbers. For a description of the current numbering scheme and reasons why we have changed our development process see the first edition of LDN.
Here's a diagram to help make all this as clear as mud. While the diagram shows a date it is not drawn to any particular scale. It is simply meant to illustrate the numbering scheme changes.
After missing his Monday release date due to a batch of small fixes Jean-Marc Lasgouttes is now scheduling the release of LyX-1.1.5fix2 for today.
You can always get the latest fixes direct from the LyX CVS repository using:
cvs checkout -d lyx-1_1_5 -r lyx-1_1_5 lyx-devel
See the LyX cvs page for more details.
As for all of the 1.1.x versions of LyX, this release contains a lot of new code. In fact, half of the changes described in the ChangeLog (which dates back to the 1.1.0 release) describe changes in LyX 1.1.6!
Besides the usual under-the-hood changes, LyX 1.1.6 has many new user-visible features. The main visible feature is that the GUI-independent (GUII) branch of development has been merged, as well as code from the older development version:
We're now in a feature freeze for 1.1.6 because we have already been working on this release for much longer than we anticipated. LyX-1.1.5 was released just before the Developers Meeting on the 6th of June so we've been ferreting away for almost 6 months. The list above is by no means exhaustive. Numerous other little features have crept in and as a result we have a lot of testing to do. If you have an interest in any of the above features there should be a prerelease in the next week or two. If you are feeling adventurous you can get a copy from the anonymous cvs server by following the instructions at the LyX cvs page.
The only major change left for the transitional releases (ie. before 1.2.0) is to make all document objects derive from the same base class. In LyX terms this means everything will be an inset of some sort. Most of this is already written and there was a long debate about whether or not we should include this change in 1.1.6. In the end it was decided to leave the everything-is-an-inset change for 1.2.0 because there were already more than enough changes for us to contend with and stabilise.
Another item that was hotly debated was how much GUII work should be done before 1.2.0. Some wanted to get all of LyX GUII including the main window and workarea (a.k.a. canvas) converted before 1.2.0. That would be an awesome amount of work especially considering that we should really be trying to keep our stable releases to no more than about a three month cycle and I'd be so radical as to suggest a one month cycle. Why? Read the stated aims of our new development process in the first edition of LDN. It boils down to keeping the codebase as stable as possible at all times while developing without ever having to resort to a feature freeze in order to get another release completed.
Anyway, what I argued for and think I convinced everyone of, is that we should aim to get all the existing dialogs GUII for 1.2.0. This will be a lot of work, but with a combination of the dialog designs from the old codebase and the experience Angus and I now have, in conjunction with revised XForms dialog class hierarchy we should be able to do this by Christmas. (Famous last words)
Then after 1.2.0 we can try to get the main LyX window GUII. There was a lot of ground work for this done in the old codebase and Lars and Jean-Marc have ported most of this already. However, it is simply a lot safer to work on one target area at a time instead of tripping over one another like we did in the old development branch. Many discussions have already been had on this topic and many more are likely but at least we can thrash out these ideas and implement the best bits over time.
Dekel Tsur, our resident multi-language document guru, has announced his intention to merge the CJK-LyX patch sometime after 1.1.6. This should be excellent news for any of our Asian based readers (and users) and also for those few people who want to mix Chinese, Japanese or Korean (CJK) with languages currently supported by LyX such as German or Hebrew.
Many people still want to see a Curses port done. Another option would be a slang/newt port. Either way, we have had several people asking when they'll be able to run LyX on their PDA. Not yet, is the best answer they can expect till after the GUII work is completed. Unless of course they just want to convert LyX documents to some other format in which case they may be able to do this now if they have enough memory.
There are heaps of other cool things working their way into LyX and something that will make many people happy is to know that Pierre-Olivier Gaillard is working on supporting an XML lyx file format. Actually, it should end up being a reading/writing module that also supports the existing LyX file format. There is already a patch floating around and it seems likely it'll be included during the 1.2.0cvs cycle.
All of the above features are user visible but you can be sure there are a number of under-the-hood changes coming soon to clean up the source or redesign existing subsystems (such as LyXFunc, the function dispatcher) to allow greater flexibility and extensibility of LyX's features.
The last twelve months has seen a huge speed up of LyX's development, a rekindling of core developers interests and the addition of a number of new, talented developers. I put most of this down to our change of development process and the need to keep the codebase as stable as possible that a short development cycle requires. As Asger Alstrup Nielsen so succinctly put it: Small steps. Developers win by having a stable platform to work upon and users win by getting new features sooner. Maybe the Linux kernel developers could learn something from our lesson?
The GNOME and KDE ports are coming along nicely. You can check how far your favourite port has progressed by visiting the GUI-Independence Status page. At the moment they have about 8 completed dialogs each. This looks good in comparison to the XForms port which has 13 completed dialogs. Although both these ports are based on an earlier XForms class structure and will probably find it necessary to either copy the new XForms dialog hierarchy or develop their own. John Levon (KDE porter) and Marko Vendelin (GNOME porter) have also provided a number of good ideas and innovations or just asked the right questions to spur further improvements to the user interface.
Angus Leeming continues to improve the implementation of the XForms port. We now have a hierarchy of classes to support different dialog types -- such as buffer-dependent or independent as well as certain classes of insets. This new hierarchy really cleans up a lot of stuff that had been bugging Angus and had bugged me over the last two years or so that I've been working on GUII. The hierarchy removes all the duplicated code from the various dialogs and centralises it higher up the inheritance chain. As a result, we should be able to build new dialogs for the XForms port much more easily.
This change also reflects the change in attitude to the GUI independence work. When I started working on the dialogs, all those years ago, my main aim was to get the dialogs out of the LyX core as quickly as possible and to concentrate them in a minimum of files per dialog in a single directory instead of having parts of any given dialog's code scattered through 8 or more files.
Nowadays, we have a team of four dedicated GUII developers and the aim is to build the best possible implementation from the start. It now looks like all those years of work I did will be redone from scratch, which isn't such a bad thing. Although there are still a lot of lessons to be learned from the old codebase and some of the old codebase's dialogs have been ported to the new codebase. So all is not lost.
I wrote a button controller class that, in conjunction with a number of button policies, allows us to control the activation of the various OK, Apply, Restore and Cancel buttons as well as handling the disabling of inputs in dialogs if they are affected by a document's read-only status. This goes together nicely with Baruch Even's RadioButtonGroup class to make handling dialog components a breeze. In fact, now that we have Angus's class hierarchy in place and a little callback magic we basically have a button controller running automatically in every XForms dialog!
After struggling with a few problems getting the Preferences dialog working, I sat down and redesigned it so it now uses nested tabbed folders to hold all those different lyxrc variables. Still two or three extra tab folders to add. Why do we need 120+ variables to control LyX?
There has also been some interest in ports to OS/X, GNUstep and BeOS. Although, these have all been user requests and so far no developers have stepped up to start work. Anyone interested in an OS/X port may be able to get onto the Apple Developer Program which is offering a free loan of a Mac for twelve months, some training and tech support to help get applications ported to their new OS. Search the Apple web site for details.
A few weeks ago I got very annoyed and to paraphrase Eric S. Raymond very itchy. I needed to be able to simulate cvs from my development machine at home where I can't get a connection to the LyX cvs servers so I could easily generate patches to transport to Uni to apply to a cvs checkout there. After several frustrating experiments with scripts I decided the only way to get what I wanted was to patch diff. You can read more about what, why and how here where you'll also find a patch against diffutils-2.7 and also a complete pre-patched diffutils tarball.
I mentioned this on the developers mailing list and it got a mixed reaction. I proposed it as a good solution for contributors who need to add new files as part of their patch (since `cvs diff -N` doesn't include new files unless they have been `cvs add`ed to the repository and you can't do that as an anonymous user). I even submitted it to the diffutils maintainer although no reply yet.
Now I have a request to try to add the ChangeLog hack from the linux-kernel mailing list that I saw in "Kernel Threads" to my diffutils patch.