Asger,
"Asger K. Alstrup Nielsen" wrote:
> > LyXFunc::Dispatch() is a monster if I ever saw one :-)
> ...
> > Yes - I see know why Dialogs is necessary though. But somehow I cant stop the
> > feeling that something is wrong with this design.
>
> What we have chosen to do is to split LyXFunc::Dispatch into separate
> dispatchers. We'll have one in BufferView, and one in LyXView, IIRC.
> I think this approach was originally proposed by André (please
> correct me if I'm wrong), and this is a good way to proceed.
Well, the question is then how this will work with the proposed integration of
Signal/Slot for GUII.
Much of what I wrote earlier was to help me understanding how things work in LyX. I
realize that LyXFunc plays a central role in LyX because everything runs through
its dispatch. So when the user presses a button in the menu, the menu calls LyXFunc
and LyXFunc makes the connection to the appropriate method. Realizing this
structure I was most astonished and asking myself what Signal/Slot is then needed
for, since calling a virtual method of some dialog base class could be done
directly from LyXFunc. Then I realized that LyXFunc needs to be called also. Anyway
I will keep searching since this all doesnt make too much sense to me yet, but it
got me curious.
> You are right that lyxfunc::dispatch is too big for it's own good, and
> you are also right that it would be too much to take it apart completely
> and replace it might something else.
>
> This is why André's proposal is so good: It's a partial, but much needed,
> clean-up. And most importantly, it's feasiable.
> Over time, the program will be better. Each time a function is moved to
> it's correct place, the program will be more modular and more object
> oriented.
>
> It's old hat by now, but let me reiterate it again just to be a pain:
>
> We have to take small steps.
I understand and I agree with you. Each release version should be as stable as
possible but if a release version
should have a bug another one can be made quickly. Users that need stability over
features are still encouraged to try 1.0.4 first or?
[...]
> And now, I think I'm ready for the main point: We should not fall into
> the trap of speeding up development because we have some success now!
>
> That will not help. We have to realize that this pace is the best pace
> to move in, even if it seems counter-intuitive that you have to move
> slow to be most efficient.
No but if too many development branches exist, things may be more difficult than
necessary.
GUII and nonGUI LyX are relatively close targets now. Since there is interest in
both and code being written maybe these things should get testing soon.
> Remember that we still have the LyX developers meetings to give the
> program the huge bursts that any open source project needs from time
> to time. At those meetings we suddenly have the resources to make huge
> steps and succeed with them. But let us save the big ammo to those
> meetings.
Hmmm, I was not aware that you guys did actual work at this meetings :-)
He he wish I could participate - maybe if you'd all come to the US.
Roland
