"Andre' Poenitz" <[EMAIL PROTECTED]> writes:
| But I think improving LyX *is* difficult, not because it is already perfect
| but because of all built-in legacies. I think the now defunct branch is
| *the* proof that structural improvements to LyX are impossible. Without
| structural improvements I can't see it survive.
This is where I think you are absolutely wrong. The problem with
low-level LyX code today is special cases. There are tens of special
cases in the low-level code that really obfuscates how things really
work. Most of these low-level special cases can be removed by:
- remove support for them (mono, fastselect)
- or made into higher level constructs.
- tabular suport -> tabular inset
- footnotes and floats into approp. insets.
When you get these special cases out of the low-level code it is
easier to make huger structural changes too.
| > We tried to make a giant leap forward with the previous development branch
| > but with only six or so in the team we couldn't get the momentum to get
| > airborne.
|
| You did not start from scratch. You took an important part out of LyX,
| rewrote it and tried to fit it in again. I did not fit.
No excactly how it was done...
The problem with doing something like this, as we have realised, is
that you need to stay stable all the time. Without being stable you
loose users and if you loose users you loose testers. And without
testers you loose bug reports.
| > Hence the demise of the old branch and the change of plan to a
| > softly softly approach. Lots of little safe steps. At least we can
| > backport the major changes from the old development strand and LyX will
| > evolve over time into the glorious wonder we all want it to become.
|
| Does anybody actually work on that? I just diffed the 'old' and
| > 'new'
What old an new files?
lyx -> lyx-devel ?
| files in the main src dir. 69000 lines. Even if you take into account
| that 'diff' does not work optimally, it's a safe guess to say there are
| 10000 lines of changes *excluding* all the kernel stuff.
Note that there are a _lot_ of whitespace changes, name changes and
the like. also in previous devel there were a working tabular inset
and some code to begin a footnote inset.
| Even if we had backported those 10000 lines we would have a nice kernel,
| but to achieve GUI independence etc, more work would be needed. A lot of
| it, I'd say...
Actually much of the gui code is just drop in. F.ex. the port of the
LyXAction in previous devel to current cvs was basically just a cp.
| On the other hand: Writing 10000 lines *from scratch* (I do mean an
| empty directory here!) is not *that* hard. Especially when all the ideas
| are already there.
|
| > We didn't. Maybe some more noise and hype might have gotton more people
| > to help out.
|
| I don't think so. I tried a couple of times to get involved with LyX
| development and I always gave up because it was too difficult for me to
| understand what's going on. Things need to be simple for people to start
| work. LyX is not simple and won't be for quite a while, so there won't
| be many new developers. And so on ;-|
That depends on what areas in LyX you want to work on.
One thing f.ex. that would be nice is a footnoteinset, this should be
developed without handling the current kernel code at all, when it is
finished and works, we can just remove the footnot handling from the
low-level code.
Lgb
