Hi Allan,
me again and I've got it to work and had a closer look at how things work.
> Allan Rae wrote:
>
[...]
> > You should use "cvs update -dP" to get new directories and have stuff that
> > has been removed in the repository removed from your local working area.
Thanks, I could have rtfm....
> >
> > > I have found that you created a container class that is supposed to
> > > hold all Dialogs. I would suggest to name that class DialogContainer
> > > or something appropriate but not Dialogs, I find this confusing (I
> > > think of multiple Dialogs which is not what that class is) but that is
> > > ultimatively up to you.
> >
> > Perhaps. While it is a container from one point of view (looking at the
> > private part) it also represents an almost complete abstraction of the
> > interface to all the dialogs. Hence the name Dialogs.
> >
After having a look how things work when a menu button is pressed (the
FormCopyright example) I start to understand what the actual problems are.
A LyXView object knows a LyXFunc object of which the method Dispatch() is
called when the menu button is pressed.
LyXFunc::Dispatch() is a monster if I ever saw one :-) It handles everything
and looking at it. I really wonder why bother with SIgnals at all. At least I
can not see how Signals will simplify anything. Basically LyXFunc::Dispatch() is
the core method to connect events to functions and methods. This is probably
because the goal is to make the entire functionality available in LyX shall be
made available through the LyXServer.
Now LyXFunC emits a signal to show the Copyright form with
owner->getDialogs()->showCopyright();
the Signal is contained and stored in the Dialogs class, that is all Signals
are stored here. The connection between Signal and Slot is made in the
FormDialog constructor which not only needs to know the current LyXFunc but
also the Dialogs object. At least this connection could have been made on the
base class level, the it wouldnt have to be repeated in each derived class.
Still the reason why there is an interims layer (LyXFunc) for each and every
call to a function or method is not quite clear to me.
Yes - I see know why Dialogs is necessary though. But somehow I cant stop the
feeling that something is wrong with this design.
[...]
> > Any given dialog still needs to connect to its associated show Signal
> > (showCopyright for example) and whatever other hide Signals or update
> > signals are appropriate. How do you intend to hide all this from the gui
> > developers? How do you intend to make it easy to maintain LyXView? How
> > do you know which dialog is which so you can connect them up or at least
> > call the right one?
I admit I was wrong here, I was essentially assuming a different model where
events are directly connected to functions via Signal/Slot. At that point each
object representing an event, e.g. a pressed menu button is an
Sigc::Object and directly connected to one ore more corresponding Slots. That
requires a different design, I was assuming that LyX has a truly OO design,
but it is far from that. If LyXFunc was instead of what it is now, a virtual
base class for events and the actual events were derived from that the design
would be much clearer but the rewrite would be tedious. Still the main
advantage of OO program design is lost with the current LyXFunc.
Yes in the model I was thinking of a LyXFunc object would also be derived from
SigC::Object and have a Signal to call the method. You can then even chain the
calling sequence like in one of Karls examples.
Maybe this is planned in the future and I just dont know it, then your design
is intermediate and certainly the right step in the right direction.
[...]
> > Somewhere along the line something has to get more complex (be it LyXView
> > or the gui-specific code) if we follow your idea. This is the simplest
> > scheme I've been able to find. There may be better ones but I think your
> > plan will in fact require us to write more code, make LyXView aware of a
> > lot more stuff and complicate the various lyxfuncs.
Yes, LyXView should not be made more complicated.
[...]
I think I understand now how things are supposed to work.
I dont know how much I can do tomorrow but I'll get back to you.
Thanks for your patience.
Roland
PS: I've got it to compile and run both on NT and Linux.
> >
> > Allan. (ARRae)
>
