On Mon, 25 Sep 2000, Angus Leeming wrote:
> Attached is a patch containing the replacement for InsetInfo, InsetNote. It
> also contains the new files insetnote.[Ch]. Please remove insetinfo.[Ch] as
> they are now redundant.
It would be nice if Painter could be extended to support the drawing of 3d
buttons with different coloured backgrounds so we could keep the bright
yellow of Notes. This should simply involve passing one colour and the
colour of the bevels is calculated from this (hue+saturation
interpolation for example or use the features of a given toolkit).
> In view of the on-going discussion and the fact that (almost) nobody was
> aware of the existing comment layout (thanks, Lars!),
Gosh, I didn't realize I'd changed my name ;-)
> the new inset is nothing but a collapsable replacement for the
> existing one. No output to LaTeX and no Context Sensitive Menus.
> Nonetheless, this is an improvement as the new inset is
> GUI-independent.
>
> The patch also contains a rearrangement of Buffer::readInset() that reduces
> all of those instances of
> par->InsertInset(pos, inset, font);
> ++pos;
> to one only.
Okay so far.
> Finally, I have made the xforms implementation of FormCopyright a derived
> class of FormBase and demonstrated that none of these FormXXX classes need be
> dependent on Dialogs.h if they are passed pointers to the relevant show, hide
> and update signals directly by Dialogs.C. As before, I have also modified the
> kde version of Dialogs.C to suit, but not gnome's.
I don't like the looks of this much at all. If you are going to
#include <sigc++/signal_system.h>
into a forms header you should use a reference instead of a pointer for
the Signal0<void>'s. If you really want a pointer then you should use a
forward declaration of Signal0 instead and remove the #include above:
template <class x> class Signal0;
Avoiding Dialogs.h isn't going to buy us that much. Dialogs.h shouldn't
need changing unless there are a few missing signals and there aren't that
many of those. Separating out the signals looks more confusing to me.
If I want to set which signals a given dialog responds to it has to be
done in Dialogs.C now but it also means every single signal a dialog wants
to connect to has to be passed as a parameter. FormTable will need an
extra 3 parameters for example. Anytime someone decides to add an extra
signal for a dialog they have to change Dialogs.C and FormXxxx.[Ch]
instead of just FormXxxx.C (assuming the signal exists or Dialogs.h
also if the signal doesn't).
I don't find this a simpler solution. This will be more confusing for
newcomers than simply naming and making the connections in the respective
forms (and I'm sure I'd find it frustrating).
The addition of FormBase looks quite useful though for consolidating
common code. Although it might be useful to allow forms to define their
own form property mask (or whatever the FL_TRANSIENT | FL_CENTER etc. is
called). You could do this with a default parameter to the FormBase
constructor.
Allan. (ARRae)
