Hello, Allan. I think I'll be back on board real soon now. It must feel like
the Marie Celeste at present!
Relevant news:
* José (Orlando Pereira --- XTL) seems to like my changes, suggesting
that an official xtl release working on 64-bit machines will be available soon...
* I've submitted a bunch of patches to the head branch of CVS that allow
me to compile with DEC cxx and with DEC's std::string. They too appear to have
been accepted. Once they're in (don't worry, I'll tell you when!), can you
update the "rae" branch so that we're working from a common (working) code
base?
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.
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.
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 ;-)
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.
Just my 2c-worth.
Angus
