On Sun, 30 Jan 2000, Dr. Ing. Roland Krause wrote:
> Tataaaahhh..
>
> Allan,
> great absolutely, good job.
> I was able to roll my version over to the sigc-1 branch, although a simple
sigc-1 is just a revision tag on the "rae" branch.
> cvs up -r sigc-1 wouldnt checkout the new directories. I had to checkout from
> scratch. What cvs version is the server running?
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.
> 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.
> Second, I noticed that you put all the signals in this class. Why?
> They really do not belong there, in fact you dont need them there at
> all.
They belong somewhere. Without them the house of cards falls down.
> The Signals belong in the DialogBase class. They shall connect to the
> virtual methods of the base class: show() hide() and update(). That
> way you do not have to update Dialogs whenever a new Dialog is
> introduced.
Take another look at how it all fits together:
LyXView---1----Dialogs---*---DialogBase
if we do as you suggest:
LyXView---*---DialogBase
If we stick every Signal that a LyXView has to use to talk to the
individual dialogs into DialogBase, how does LyXView know which
DialogBase to access to trigger a specific Signal? It can't know which
one to use unless we make the system even more complicated or even uglier
by shifting all the Signals into LyXView.
> Otherwise you have to constantly update Dialogs and keep
> track when a new Dialog is introduced.
There are about a dozen dialogs not mentioned in the Signals in Dialogs.
There won't be any constant updating. Just: constant ie. fixed in stone.
> The person who makes a new Dialog does not need to know about the
> calling mechanism, this can safely be encapsulated from him.
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?
> Dialogs only needs to povide a way to store these Dialogs (do you see
> what I mean when I suggest renaming the class?). The question is,
> whether this class is necessary at all. You could make it - as you did
> - into a vector of Dialogs, then just store the vector where you've
> got the class now. One class less and a leaner and clearer design.
See my comment above about LyXView becoming uglier.
> The only method of this class is a hideAll Signal which can be
> implemented through a loop, that calls hide for all elements of the
> vector (generic programming).
The hideAll, updateBufferDependent and other Signals do the looping for
us. And they make it much simpler to ignore how each frontend is
developed or even what the names of the files and classes are in the
gui-specific subdirectories.
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.
> Last but not least I believe that instead the Signals you can use
> Slots in the DialogBase class to connect to the virtual methods.
I'm not sure I see how we could get this idea to work. Something has to
connect everything together. Either the dialogs do it or LyXView (or some
other entity does it). I don't know enough about Slots to be sure either
way (Signals I know plenty about but Slots are unchartered territory).
It could perhaps lead to an easier job for gui-developers if we can get
LyXView connecting things but I think that will end up putting
restrictions on the names of classes etc. in the gui code. How would
LyXView know which dialog was which in order to connect it all up? Hmmm,
now I'm getting myself confused. I'll think about it. But at the moment I
think we'd end up having to do like Dialogs.C does and #include"" every
dialogs header file just so we can add it to the container and connect the
right signals/slots together. This would be really bad because the gui
would no longer be a black box (we don't even there is a box with this
design it's so black) but a grey one instead.
> Maybe I havent fully understood this system and I'll have to play
> around with it a bit so bear with me if I am making a fool out of
> myself here.
Me too for your system.
> I will try to compile your code and send a modified version in tomorrow.
Okay, that might be easier to understand.
Allan. (ARRae)
