On Thu, 4 May 2000, Angus Leeming wrote:
> Hello, Allan. I think I'll be back on board real soon now. It must feel like
> the Marie Celeste at present!
Yes, I'm not even there!
[...XTL.. I know I'm on the list...]
> I've been looking at the stuff in the "rae" branch.
>
> Point 1
> =====
> You could clean up the code enormously with a single statement
> #ifndef MB
> typedef auto_mem_buffer lyx_mem_buffer;
> #else
> typedef mem_buffer lyx_mem_buffer;
> #endif
> whether or not auto_mem_buffer becomes the standard.
No. That's what I did at first. The result being you have to include all
the xtl headers in every header file that mentions mem_buffer. The
existing choice of mem buffer type is temporary only -- mainly to show how
different the code looks and why I wrote the auto_mem_buffer in the first
place. So the mem_buffer choice will be gone RSN.
> Point 2
> =====
> I think PrinterParams is made ridiculously convoluted by insisting
> that "from_page", "to_page" and "count_copies" are strings not ints.
> Moreover, it seems to defy C++'s principles of encapsulation. Perhaps
> xforms does return character strings, but that's why this sort of
> thing should be hidden "North of the Border" in the frontends/xforms
> classes. The rest of the code shouldn't know about such things.
>
> Make them ints and you loose the need for testInvariant() which does no more
> than check they're unsigned ints anyway.
>
> I know, you're going to talk about other (hypothetical) frontends messing
> things up. I think that if you make the interface clear, you minimise the
> chances of this happening.
The code I removed by using strings instead of ints was even uglier than
the use of strings. testInvariant, isn't really necessary anyway, it's
part of my plan to push self testing into everything.
They could be switched back to ints at some stage. Right now I wanted it
working. Strings provided the cleanest way of doing that fix for the time
being.
> Point 3
> =====
> I've read and re-read your mail explaining why we need the Connection
> data in frontends/xforms/FormFoo.[Ch] and I still don't get it. I
> guess I need a concrete example to show thick old me. The fact is, the
> code as it stands works perfectly without them; they're nothing but
> code bloat and, as such, should be culled ruthlessly ;-)
Look at the code in UpdateAllVisibleBufferDependentPopups() and
HideAllBufferDependentPopups() in lyx_gui_misc.C.
That code is replaced by dynamic lists of Connections. The dialogs
disconnect themselves when they are not visible -- the only way they can
do that is to keep their half of the Connection in a local variable.
If a dialog connects and then never removes itself from the global
hideAll() signal it will always be called -- much like what happens now in
HideAllBufferDependentPopups() -- even though it's already hidden.
Same arguements for the update connections.
> Apart from that, I'm pretty happy (big grin). I would note, however,
> that I think that introducing derived classes in frontends/xforms NOW
> would make things much, much easier. You've been testing xtl/sigc++
> proof of concept using two dialogs; I think that this should be
> continued with the derived classes.
Well we could at least add the derived classes as we bring in new dialogs
into the gui-indep code. However,...
Trying to update my branch again is proving to be as big a hassle as it
did last time (see the archive, msg09017, I think). The 15 files with
conflicts I mentioned this time last week also removed _all_ the new files
in my tree. I've once again been experimenting with different forms of
cvs update calls to try to keep the new code around with not much success.
I'll have another go over the weekend or next week.
I'm now convinced that cvs was never meant to allow you to merge changes
from the main trunk into a branch -- only the other way, and only for
short term branches. With the main trunk changing rapidly as it is at the
moment the merging process is totally ugly.
Allan. (ARRae)
