Thanks for setting me straight, Allan. (I hope that these
questions aren't TOO irritating!) Anyway, I have some more.
The first two are general LyX questions, not
specially targetted at Allan's GUI-indepence stuff although
that is how I came to consider them.
First point (simple statement, not a question). I inserted
lots of cerr statements to show which methods in FormPrint
(and FormCopyright) are called and when. One interesting
point. The destructors are NOT called when lyx is exited,
which means that the Dialogs::~Dialogs() is not called
either. Since the dialogs are deleted in
LyXView::~LyxView(), this means that the LyXView is not
deleted... I feel a bit like Sherlock Holmes!
Second point.
LyXFunc contains:
LyXView * owner;
LyXView contains:
LyXFunc * lyxfunc;
isn't this a bit recursive! Is this related to the First
point?
Third point. Rae branch specific. What is the point of the
SigC::Connections in FormPrint.{Ch], FormCopyright.{Ch] etc
ad infinitum?
/// Update the connection.
Connection u_;
/// Hide the connection.
Connection h_;
Thet are connected in show() and disconnected in hide(),
but NOTHING calls them and commenting them out makes no
difference to the code. (At least, lots of cerr statements
show that the FormPrint methods are called in identical
fashion when popping up the dialog several times.) I must
be missing something obvious, but why not just cut them out
of the code?
Furthermore, (assuming that these things do have a
function!) what is the rationale behind having three
signals hideAll, hideBufferDependent and
updateBufferDependent. Again, since these are never
actually used, its hard to see what they're meant to do.
IF we can do without them...
Then we can also do without
Dialogs * d_;
and simply pass a signal when creating the new dialog. Ie:
Dialogs::Dialogs(LyXFunc * lf)
{
dialogs_.push_back( new FormCopyright(lf, this->showCopyright) );
dialogs_.push_back( new FormCredits(lf, this->showCredits) );
dialogs_.push_back( new FormVersion(lf, this->showVersion) );
dialogs_.push_back( new FormPrint(lf, this->showPrint) );
// reduce the number of connections needed in
// dialogs by a simple connection here.
hideAll.connect( hideBufferDependent.slot() );
}
By the same token, I don't understand what this last line
(hideAll()...) is doing.
Just trying to get to grips with it all...
Angus
ps. I have ported FormCredits and FormVersion so don't
waste your time. I'll send a patch whenever you want.
pps I have two xforms directories, xforms1 and xforms2 and
connect whichever with a symbolic link
ln -s xforms1 xforms
The first is yours, the second is the results of my
delving. That way, I can continue to play with a new design
that is functionally identical as far as the rest of the
code is concerned. The beauty is that all this signal/slot
stuff is isolated in two base classes so people like me (ie
thick) can get to grips with it. Perhaps you'd like a look
at this too? Maybe even shove them into the rae branch for
wider discussion?
ppps. Regards to Beelzebub.
Angus
> > It also contains changes needed to remove the old
> > form_print from the sources. This code will use the NEW
> > print dialog.
> >
> > This dialog does not yet work properly.
> > 1. The file name is appended to an incorrect path.
> > 2. There are some unaligned error traps.
>
> I'll try to look at this tonight.
>
> > Could I suggest, Allan, that now is a good time to merge in
> > all the changes that have been happening in the head branch
> > of CVS as well. Things are diverging rapidly I feel.
>
> I've been wanting to do this for a while however every time I try either
> the nameserver is offline or baywatch is unplugged or I see ssh1 running
> instead of ssh2 (and so wonder if we are still in a security breach
> situation) or just waiting for the major segfaults in lyx-devel to be
> fixed. I should also actually have time to do this on Friday or at least
> over the weekend.
>
> > FormPrint::apply() calls
> > LyXFunc::Dispatch(LFUN_BUFFER_PRINT, size, buf);
> >
> > which in turn calls
> > Buffer::Dispatch(LFUN_BUFFER_PRINT, size, buf);
>
>
> FormPrint::apply should/could call Buffer::Dispatch. I just added the
> extra entry in LyXFunc because I thought it would probably be needed for
> the LyXServer and because I didn't have much time before I left for the
> weekend (when I wrote it).
>
> > Noting the comment in lyxfunc.C immediately above
> > LyXFunc::Dispatch():
> >
> > /*========================================================================
> > Below here doesn't really belong in LyXFunc and should be either
> > removed or reworked so they aren't needed. Sooner the better otherwise
> > LyXFunc will end up a dumping ground for miscellaneous functions.
> > ==========================================================================*/
>
> This comment refers to the need to have another overloaded version of
> Dispatch and the need for isAvailable() to be somewhere. But where is the
> the best place for it and do we really need it?
>
> > Can I just say PLEASE!
> > This (ridiculously convoluted) code would surely be better served if
> > FormPrint::apply() and FormPrint::update() called a
> > PrinterParams::Dispatch() function directly. Why do LyXFunc or Buffer
> > need to know anything?
>
> Because PrinterParams is a data container used to pass data between
> different parts of LyX and external apps/scripts via XTL. I didn't get
> around to it but we could have an instance of PrinterParams on either a
> per-buffer and/or global basis although it is easy to build on demand.
>
> If we had a global PrinterParams (and only a global-one -- no per-buffer
> or per-LyXView settings) then we could access the global direct from the
> GUI _but_ then how do scripts/LyXServer apps get to access it? Only via a
> lyxfunc. So the GUI should use the same mechanism -- and this also
> limits the number global variables and the interdependencies between
> frontend and backend.
>
> > Before I try and hack something together, I thought I'd ask
> > someone who knows why things are the way they are!
>
> A PrinterParams.Dispatch() wouldn't work because there is no global
> instance of PrinterParams and we don't want one or really need one.
> Secondly, what would this achieve? I'm trying to test if XTL can satisfy
> our needs and allow us to maintain a single entry point for all of the
> non-core interactions (GUI, scripts, LyXServer). If we can support all
> these different areas from a single point (LyXFunc and/or it's sibling
> dispatchers) we have fewer dependencies. Sure Dispatch gets bigger but we
> can short cut to Buffer::Dispatch in the GUI to cut one call if we really
> think it's going to make any significant difference.
>
> In time we will need an XTL format that can be easily read/written by the
> external scripts etc. (probably looking like xml or similar) but switching
> formats involves changing _one_ line in lxtl.h (the gui_format).
>
> > Time to do some paid work!
>
> Yes, it is. As my old foreman used to say "Back on your heads!"
>
> Allan. (ARRae)
