On Fri, 10 Mar 2000, Angus Leeming wrote:
> This is where templates come in, IMO. _IF_ we need
> different FD_forms then create a templatised version of
> FormBase I.e.:
> template <class FD_form> class FormBase
> {
> FD_form * dialog_;
> }
>
> However, I have a few questions about FD_form. The current
> FD_form, declared in class FormBase is:
> struct FD_form
> {
> FL_FORM *form;
> void *vdata;
> char *cdata;
> long ldata;
> };
>
> What are vdata, cdata and ldata? They aren't used in the
> code. Are they just historical baggage?
They are xforms baggage. XForms wants them. It just happens to expose
some of its internals in the generated code.
> Furthermore, to quote forms/README:
> "Name all buttons and other form components that
> are likely to cause a callback. The names should
> be of the form: button_ok, radio_group_item and so on"
> Why?
> They all get connected as a linked list (or something) by xfoms anyway
> (fl_add_text) and xforms deals with their destruction. They are
> mentioned only in build(). Nothing else needs to know about them.
> Obviously, you know a LOT more than me, but is this not true for all
> the pop-ups: all that matters to the rest of the code is the callback
> which is tied to a particular button etc in build(). It's the callback
> that is important, not the button itself.
IIRC there were a couple of cases where we needed to identify the button
in the callback. I can't remember why we didn't just use the callback
value. Anyway, it is also a lot easier to read the code when we can see a
button name. I remember now. If you want to disable a button -- such as
when the document is read-only -- you have to name that button in order to
be able to disable it. Likewise for inputs.
In addition in the old tree I had the dialogs setup so that the Ok and
Apply buttons were disabled until something on the form
changed. Several of the dialogs also changed the name of the Cancel
button to Close once Apply had been pushed since we couldn't unapply a
change calling it Cancel was misleading.
[Me(Allan) griping about people who wanted to port to blah-tk but didn't
want to help get LyX ready for them to port ]
> Don't get despondent! I know very little about GUIs and care less
> about other peoples' hang-ups. If they aren't prepared to get their
> hands dirty then they aren't worth listening to.
>
> I do know, however, that the xforms interface works NOW and that
> modifying it to use signals/slots is the simplest (and therefore most
> likely to work) way of proceeding. Does this sound like someone
> quoting you back at yourself? Let's do xforms first. We can iron out a
> nice, elegant set of derived classes that will subsequently make
> porting to other GUIs a doddle.
Sounds good.
[ xforms/forms and why we want it ]
> Yes, I looked at fdfix.sh. It seems to ensure that all text is
> internationalised, etc. I don't want to appear difficult, but I still
> don't get it. form_copyright.fd just seems to replicate
> FormCopyright::build() in a different (less obvious to me) syntax. Do
> we have to maintain both bits of code or are you saying that running
> fdesign(?) on form_copyright.fd will generate FormCopyright::build()
> automatically. Either way, I still fail to see the point. Why not just
> write build() correctly in the first place? Especially since I've
> modified the source a little so that FormCopyright.C needs only
> #include "FormCopyright.h" and FormCopyright.h needs only #include
> "FormBase.h" all other headers are #include-d in FormBase.h
fdesign == GUI designer.
build() = fdesign + fdfix.sh
If need be a patch can be kept in xforms/forms that fdfix.sh will apply to
the files generated by fdesign. Alternately, I'd prefer to just wrap the
create_form_form_xxxx as build_form() and use a separate method build()
for the code we add -- the stuff you shifted into build() from show().
> xforms certainly doesn't need this stuff to compile and run...
No, but we need it make life easier for ourselves. Maintenance and
feature addition are a lot easier with fdesign than frigging around with
hand written code. Also fdesign files can be used by "fluid" the gui
designer for fltk.
> ps, I've tidied up the code I sent you before and attach this tidied
> up version. If the remaining port produces derived classes similar to
> these (I don't know the requirements of other dialogs!), then
> maintenance will be very easy.
Take a look at the lyx cvs module. There you'll see that all the inset
related dialogs have a number of similarities and could probably use the
same base class. There are at least three browser-type dialogs that
should all be derived from a common browserbase. A sample browserbase
(done by Lars who I forget to mention as doing a couple of dialogs) can be
found in the lyx cvs module. Last time though the credits dialog wasn't
derived from browserbase.
Please say you'll look at the code from the old tree then I'll stop
haranguing you about it. You might get some good ideas by looking at this
code and you'll also find it a lot easier to notice the similarities
between the various dialogs.
> pps, I've declared all text as strings in a separate class Label that
> should, ultimately, be accessible to all GUIs.
While it might be nice to share common strings between gui implementations
I'm not sure how many we can really expect to share. Certainly the
Copyright notice is common but you have to remember that most gui-designer
programs are easier to use if you actually have the labels and strings in
the dialog as you build it -- sizing and placement for example. Also if
you look at any of the po/*.po files you see that gettext does a very good
job of finding identical strings already. Sure we may have a couple of
places to change the copyright years but that isn't too much hassle.
Also by making every gui-implementation use the same strings we may be
restricting the interface/porters-imagination more than necessary.
I don't think we need to worry about whether strings are common or not. At
least not at this stage anyway. Certainly we will be applying something
like that to our configurable menues (to support different standards for
different platforms -- MSWord or WordPerfect menues for example).
> I would have liked to declare all these strings as static, so that I
> didn't have to create a fresh instance of Label each time I used one,
> but the gettext function _() created lots of wierd error messages.
> (Interetsingly, ONLY _() produced these errors, the other functions
> called in the production of the strings were fine ...) Any
> suggestions?
N_() might be the appropriate function to use instead of _() for that
case. Don't worry about it yet.
Allan. (ARRae)
