> > Is the dialog subclassing really a memory hog? By how much do you think
> > you'd reduce the RSS if the dialog classes were not subclassed? I imagine
> > it would be almost negligible.
>
> It's a binary size bloat.
Sure. I guess it's conceiveable to modify moc and uic ;-)
> > > This is what happens when you compromise. Thankfully normal users do
> > > not need or use ERT.
> >
> > ?! LyX doesn't support some of very basic LaTeX functionality that has
> > been there since ages: siunits package, tableaux package, switching page
> > numbering modes, etc. To do anything non-trivial (as in a thesis with
> > decent page numbering schemes, front page to university specs, etc.) you
> > have to use ERT.
>
> Simply not true. You get your faculty to provide a lyx layout, and you
> just select it.
Okay, there's this \unit{10}{\kilo\hertz} thing. How do I provide a layout for
this? There are *two* parts to this. Similarly, how does one handle
\caption[Short caption]{long caption}? And what LyX layouts have to do with
just putting a short ERT to say change from roman to arabic numbering, etc?
Well, I guess I haven't tried to write one -- I only judge basing on what
they do in different document classes.
> > That's pretty bad for the development. I guess that LyX would be very apt
> > to XP+testsuite approach, where even big things are implemented in
> > relatively small steps that do not break anything.
>
> This is close to impossible given the codebase we have to deal with.
It's a mindset. It gets some using to. It may involve some overhead, but you
end up with having a stable product all the time. And you have to constrain
yourself so that whatever big thing you're doing, you do it in small steps,
they get tested and made to work, and you're done with that small thing then.
Doing a big thing means that even though 90% of the work may be done, nobody
can use it.
> Even simple changes have a tendency to massive ramifications in the old
> crap
It takes some using to to port things from old crap to new crap stepwise. The
benefits of such an approach are real. Even if you have to do big changes to
the old crap to support a minor cleanup, well, I guess you can still do the
cleanups so minor that within a month you'll be done with the cleanup. And
usually you refresh yourself wrt. some other old crap, so you may end up
fixing more that you'd think that you initially need to fix.
> > don't see a valid reason why LyX shouldn't be developed in one month
> > cycles (having a release each month).
>
> That would be very nice but not yet poossible.
With a proper tool to manage it, and without prejudice, it actually works.
It's actually best suited for small developer teams, so that there needs to
be no split between maintainership and "active development", no need to
backport things, etc. You just go about your job, maybe slightly slower, but
things work all the time and nothing is supposed to get worse (at least from
the user's perspective). That's the whole framework that Aegis tries to
enforce.
Cheers, Kuba Ober
