[whistles, streamers, party balloons and loud music]
Yay! We've made it to double figures!
Now that LDN is established I can let a few secrets out. The very first LDN was written as a press release to announce our change of development process. That announcement was made about five months after the change. I emailed the press release to about a dozen different Linux news sites and used LDN as the subject since that was what it was. Little did I know what I had let myself in for.
Linux Weekly News was the only news service to carry our press release. They reported it like this (complete with lowercase X's in LyX and LaTeX):
Lyx Development News. Lyx Development News came in for the first time this week. Lyx is an advanced open-source document processor based on LaTex. "It is called a "document processor" because, unlike standard word processors, LyX encourages an approach to writing based on the structure of your documents not their appearance." The news this week indicates that they are in the process of changing their development model and plan on releasing frequent, stable releases in the future, rather than maintaining a separate development and stable tree.
That mention of came in for the first time and some encouraging emails from Liz at LWN led me to comment to Amir Karger in a private email:
All this stuff to write now that someone was foolish enough to try to get the worlds attention with a little email with a poorly chosen title that was misinterpreted by the good people at LWN to mean they'd be getting a regular publication. Oh whoa is me.
Of course, it's ironic that I called it "LyX Development News" as a result of an email announcing to the world we'd be "advancing" LyX in future not "developing" it. :-)
After an enthusiastic start, publishing every fortnight for three issues I got burned out. Mostly because the A Brief History of ERT story went through three or four revisions in about 14hours of work trawling through the old mail archive -- the search facility was broken. The story kept getting revised as I went back earlier and earlier in the archive and I found my attitude toward Larry Marso changed when I realized he'd been arguing for a way to hide raw TeX for at least a year before I joined the LyX Team in 1996. Since then I've learned of the importance of eating, drinking and resting while writing -- much better idea than having a bowl of breakfast cereal at 1am as the evening meal after having had no lunch either.
I didn't manage to get the History of GUII story prepared for this issue. We do however feature a very important discussion on the developers list that argued about whether we should ditch GUII in favour of supporting a single toolkit at least until such time as LyX has been converted to a modern toolkit or application framework.
Finally, thank you everyone who has offered encouragement, links or other useful stuff during these first early stages of LDN's existance. Special thanks to Elizabeth Coolbaugh and the team at Linux Weekly News for being the best open-source news service around -- without you LDN may never have happened. Thanks also to Amir Karger and José Matos for their contributions.
Got it. Many thanks, Dekel, Lars, JMarc. The penny, centime, agora, kroner has finally dropped
(maskulin)
sing. (en) krone
plur. kroner
(the) kronen (evt. krona)but you really want:
(neutrum)
sing. (et) øre (100 øre = 1 krone)
plur. øre
(the) øret
Thanks. I was wracking my brains there. I guess that in my times in Norway, I've never seen øre, just handed over large bills of many kroner!
— Angus
Actually the agora was dropped quite some time ago, the minimum coin is 5 agorot. Though if you bill or get billed by credit card, they still count by a single agora.
Apparently manufacturing the agora costs more then an agora (I believe it was 1.3 agorot to manufacture 1 agora), so it was dropped.
Now if this doesn't get into the LDN as the most ridiculous series of entertaining trivia then I think we should all complain to the editor!
— Angus
As a special 10th issue of LDN treat I asked Matthias Ettrich, founder of LyX and KDE, a few questions. One of them was about the origin of LyX's name.
LyX was supposed to be a program to write "beautiful documents", just like poems are beautiful texts. And it was an X11 application, so it needed an X in there. So I ended up with LyriX (after lots of thinking ;).
The name was changed, when I learned about a commercial wordprocessor from SCO that was using the same name. The idea to simply strip the name down to LyX came from David Johnson. It fit very well with the filenames: those I called *.lyx in good-old DOS fashion from the very beginning (I had to use an MS-DOS floppy disk at this time to transport LyX and LyX-Files from the university computers to my home).
Jean-Marc Lasgouttes offered the following observations while reviewing this issue before publication:
Note that the history of the name "LyX" seems to be only partial, since the CREDITS file says:
Carmen Kauffmann
original name that is now two characters shorterNow, maybe Matthias wants to forget about Carmen :)
I also remember an old thread on usenet where matthias asked for help in selecting the new name (I failed to find it on deja). All I can remember is somebody making a case for the name "inky". I really think LyX is a much better name, and that would probably have changed the program future. For example, I am sure inky would have a paperclip wizard by now :)
— Jean-Marc
Around the middle of November John Levon spotted a KLyX2 project in the MandrakeSoft cvs repository and contacted Lars privately about this. Lars in turn contacted Matthias Ettrich to find out what was happening and Matthias's response was forwarded to the developers list at his request. All this discussion took place in a different thread with the subject: "Re: Fwd: Re: Mandrake and KDe frontend".
There was short exchange between John Levon and Matthias in which Matthias argued that we should switch to a single toolkit because he believes:
Restricting LyX to one toolkit is not a restriction in terms of software engineering, but a design decision that leads to more flexibility - and thus to faster and more innovative software development.
...
John, wake up! See how long you guys have been working on that and see how far you came until now. Of course what you describe *can* be done. But it's even more effort in terms of development hours than doing two forks and let one use Gtk and one Qt. In practice, it simply will be a low common denominator. Maybe not the lowest, but pretty low.
...
IMO you picked the worst possible choice. By trying to make everybody happy, you make nobody happy.
Keep in mind: a complete KDE port that replaces all the xforms stuff with Qt/KDE code can be done in two weeks work if you have at least two people fulltime. With the abstraction layers in there, it might be more complicated now than it was with LyX1, but one could simply drop some of those and replace them with the ones Qt already provides.
This is why I'm so angry about the whole issue. Can you imagine what a powerful killerapplikation LyX would be today if you had continued working on the KLyX code base two years ago?
Matthias didn't take part in the arguement after this, possibly because Asger (who loves to debate) took up where Matthias left off. At this point several developers joined in the arguement. Angus pointed out that the GUII dialogs are progressing very rapidly and cast doubt on Matthias's claim that a port to Qt2 could be done in two weeks. Several developers commented on the KLyX claims. An important point to note is that the old development tree was abandoned after the newfound freedom of switching to CVS for source control resulted in our creating a monster and IMSHO we would have done the same things with the KLyX code base -- only it would have taken longer because we would have spent six months doing a four way merge between LyX-0.12, KLyX and the LyX development and stable trees existing at the time.
I posted a huge rebuttal detailing the technical merits of GUII including a description of how different frontends can provide very different implementations using the same high level abstractions. Asger then provided a short summary of my arguements:
1) Being independent is better, since you'll potentially last longer in a changing environment
2) Different GUI frontends creates competition, and thus more innovation
3) Different frontends attract different developers, that might otherwise not be there
4) GUII is a better design
5) GUII gives better code, because it's reviewed by all front-ends
6) GUII makes everybody happy because everybody can choose the frontend they prefer, and they don't have to install libraries they don't want
7) Then you spent some time to explain why it's not technically restraining to do a GUII application.
8) GUII (or some separation) allows core developers to concentrate on the application while others (possibly intermittent) take care of the GUI's.
— Allan
and posed a few more questions of his own including:
Would you be still be enthusiastic to participate in LyX development if GUII was dropped and focus was on Qt as the main toolkit?
To which several core developers replied "No.", although some were a bit more verbose than that.
Asger then fought a long arguement about the technical complexities of developing GUII instead of a simpler single toolkit system using the Model/View/Controller paradigm. After a long series of emails from Jean-Marc Lasgouttes, Lars Gullik Bjønnes and others that describe the current abstractions for the dialogs and the toolbars Asger came to these conclusions:
At this point, you have a clean separation of Model/View/Control in a GUII fashion for the dialogs. You have a clean separation of Model/ViewController for the menus. This framework is suboptimally implemented for XForms only.
What you don't have:
1) A separation of view and control for the menus
2) A separation of M/VC for the toolbar
2b) A separation of V/C for the toolbar
3) A separation of M/VC for the canvas
3b) A separation of V/C for the canvas1) is what I argue is hard. Therefore, you probably won't do it, and just leave each frontend as an integrated VC pair.
2) is relatively easy. You are already discussing it on the list at the moment.
2b) is hard. Therefore you probably won't do it, but just leave each front-end as an integrated VC pair.
3) is hard. Some work has been started to get a View abstraction (the painter).
3b) is also hard, and will probably never be done in a GUII setting.If you focused on one front-end only, the tasks of 1), 2b) and 3b) would be easier.
So in conclusion, you have been making great progression in the GUII job. In particular, you have demonstrated that it is possible to develop the model components without dumbing them down.
But there still is a long way to go, and by chosing this direction, you more or less deliberately decide that the view/controller separation is not necessary for the first round.
That certainly is a viable path, and I encourage you to continue on it, given that there is no interest in focusing on a one front-end solution which arguably could progress faster.
— Asger
There are many more emails in this long thread and it is well worth reading if you are a developer contemplating moving an application to KDE, GNOME or some other toolkit. There is also a lot of history covering the creation of KLyX, developers argueing to protect their "baby": Matthias and his baby LyX, me and my baby GUII; and even a little Qt versus Gtk flamebait.
And I've already said I once argued we could do it in a week but nobody had a week to spare. Besides it's better to do it right and have fun while you are doing it than to do it fast for instant gratification. That applies to more than just coding ;-)
...
We're not targeting cross platform (at least I'm not). We're targeting native apps on multiple systems using a common core. GUII may only be an interim step to something much better but at the moment it serves the purpose of focussing attention on separating core from frontend and system independence is a logical and small next step. Having multiple active ports helps ensure that we are actually achieving independence.
— Allan
And there is certainly many benefits you get by sticking to one toolkit that can not be achieved as easily with GUII. So you have to weigh the pros and cons on a weight. I think Matthias might be right that at this point in time, the weight is in the favour of dropping GUII if the goal is to achieve maximum merit for the effort.
— Asger
Follow Lars' instructional email about CVS branch operations and create a BRANCH_KLyX2 branch. Work there. Merge from the HEAD to the branch every so often to get things in sync with LyX development (ie. Lars and Jürgen running amok with insets). Only work within src/frontends apart from removal of xforms specific code. Then when you're done in two weeks time we can make KDE2 the main base and xforms can either be dropped or continue as a secondary port (or replaced by fltk). The other ports can also continue, although using KDE2 instead of xforms for the rest of their dialogs and frontend.
Then when Matthias and Kalle return to their regular work and we take over the maintenance GUII can continue.
Everybody's happy.
When you've stopped laughing think about it seriously.
The main reason xforms is the main port is because that's what the guts of LyX is and IMO it makes sense to keep the same GUI toolkit as the main target until such time as all the gui-specific code is out of the core. So who wants to do the work of rapidly switching default toolkit? But must remain within the bounds of the Dialogs GUII work and mustn't change anything other than gui-specific code in the core of lyx.
— Allan
If you by infrastructure mean the model abstraction, yes, this will be easy. But once again, you basically just shove complexity into the front-ends: Each front-end has to implement the rest.
— Asger
No, because, except for xforms, the other toolkits have all that is needed to implement multiple toolbars, I guess.
That's right -- but not only for toolbars. The difficult part is that some toolkits (XForms, curses and some other C/C++ toolkits) aren't as full featured as some frameworks (KDE, GNOME or probably MFC). So we draw an abstraction as high as possible so that each framework is free to use whatever powerful components it may have (reuse of the toolkit/framework) while less extensive toolkits will use some proportion of the support code provided by LyX (reuse of LyX framework). The good part is that most of the LyX framework code already exists. It just isn't collected together into a nice support library yet (reuse of existing LyX internals -- which has some GUI specific code mixed in at present).
— Allan
Here are the remainder of the questions I asked Matthias. These came up during the great GUII debate while I was trying to do some research for the History of GUII article.
The very first version did not use Motif, but xviews. I liked the xviews look and feel better and the library was available everywhere. I never released that to the public, though.
But then I read in a book that Motif was going to be the standard in future versions of Linux and I wanted to be prepared to use the standard.
I had access to the Motif libraries at the university, so the switch was no problem.
— Matthias
There was no lesstiff back then, and no OpenMotif either. Only very few people had access to Motif libraries, so the pool for potential co-developers was too small. Most emails I got were requests to send them a statically linked binary.
Somebody (can't remember who) sent me an email suggesting XForms and I fell in love with the API and the GUI-designer (what a relief after Motif!).
— Matthias
(I remember some discussion in late'96 IIRC about a possible switch to Qt
but you had handed over LyX to Lars before then (you had handed over to
Lars before I joined up). I still have to go through the old archive
but since its glimpse engine is stuffed it means going through by hand
-- an answer to this might help me find some links sooner)
LDN
IIRC there was talk to switch to Qt, which I considered the natural choice after xforms development almost stagnated for years. Lars started working on that and I believed it was going to happen. I was extremely busy with KDE, so I didn't pay too much attention. Later I was quite dissappointed when I noticed that this port was cancelled in favour for yet another xforms-based release.
— Matthias
The tips that are here are only some of all those that appeared in the LyX Users Mailing list. If you have a tip that you think is worth including, please post it to the LyX users' list, with a note, and I will post it in the next edition.
Keep note of Herbert Voß's site, the tips are presented by subject, and the site is updated often with new tips. Thanks Herbert.
As LDN has progressed I have gradually shortened the name Graphical User Interface Independence to just GUII which is how it's referred to in the developers list. Newcomers to LDN might be a bit confused by this acronym so if I define it here I can refer to it in future issues.
GUII is the process of separating out and cleaning up the support for the user interface in LyX. The next step after GUI independence is system independence. Then LyX will be able to be ported to run natively on any platform. The best part is that each port gets to use the same core application while competing to produce the best interface. Good ideas move across to other ports then and LyX benefits from having developers it may not have had otherwise.
We have a GUII status page that shows which toolkits or application frameworks LyX is currently being ported to and the status of each one.
RTL is one of the most significant new features to appear in LyX this year and possibly in the whole lifetime of the project. LyX supports Right-To-Left languages such as Hebrew and Arabic. Dekel Tsur is the developer who implemented this support. The introduction of RTL support is a step toward language independence. Dekel is working on improving Arabic support and plans to merge in the Chinese, Japanese and Korean support patch in the coming year.
Here is a screenshot teaser from Dekel to show what he's currently working on. It shows Hebrew, Arabic and Russian text in the same document using Unicode fonts.
On Wednesday the 9th of October 2000 I presented a 25 minute seminar/tutorial about LyX at the Conference on Computational Physics at the Hyatt Regency, Sanctuary Cove on Queensland's Gold Coast. This went really well. About 80 people attended on what was almost a rest day for the conference. There was quite a lot of interest from the maths and physics community. This advocacy was really needed as only half a dozen people there had heard of LyX before the seminar while about half to two-thirds of the audience were regular users of LaTeX.
You can get the PDF (72kB) version of the slides and I have also made up a tarball (82kB) containing everything that was used to create the slides.
The tarball also contains a copy of the one-page abstract that will appear in the conference proceedings and a copy of the scary equations that Walter Landry made available for using in demonstrating LyX's math editor. Most of the demonstration time was spent showing off the User Guide since it contains a good cross section of paragraph styles, tables, references and so forth.
Anyone who's read a couple of issues of LDN will know that there isn't much in common between the issues. The only regular items are the Quote of the Month, an introductory editorial, José's collection of tips and short updates on the status of GUII. Do you like this? Do you really want an itemized account of what everyone has been doing in the last month like in the July issue? What things would you prefer to see in future LDN issues?
Please send in your suggestions to the LyX developers' list.