I haven't time to look at this straight away. I'll look tonight and give
you some feedback on the patches tomorrow. I have a few comments for you
at the bottom of this email also.
I'll make a few general comments at this point regarding rules for
gui-indep of dialogs. These are not directed at you specifically, Angus,
just laying some ground rules for anyone who's interested.
1. Anyone who wants to help is welcome too.
2. To avoid several people trying to port the same code ask me if anyone
is working on that dialog or at least post to this list.
I will add a table of dialogs with some comments to my web pages so
it'll be easier to see who's working on what and how difficult a
particular dialog is likely to be.
3. If anyone wants to dip their toe in the water I strongly recommend
they get the lyx module from cvs and see what Jürgen and I did
with dialogs there. There are a large number of dialogs already
gui-indep there. The differences between that scheme and the current
more refined one are quite small (apart from the swapping of
Communicator for a LyXFunc entry and using xtl -- coming soon).
4. I have an almost complete script for converting all the work Jürgen
and I did in the old lyx module to fit the new scheme. The only bits
I still have to add are converting the Communicator calls into
lyxfunc::dispatch() calls instead. These won't necessarily compile
but they will be pretty close to complete.
As such, I'd like to get this script finished and do one or two
dialogs of different types by myself first. Most inset-related
dialogs are very similar in the way they interact with their related
inset for example. That way newbie developers can have something to
work from and pass further comment on. Then either they do dialogs
not already converted and I just run through the ones that've already
been converted in the old module or vice versa.
With this script most of the work will involve cutting out the
code from the rest of the lyx codebase whilst checking that any
bug-fixes or enhancements are incorporated into the old code. Most of
this can be done via cut-and-paste. It should also mean we get a
dialog done in 2 hours or so instead of every three days.
5. Make all patches against the rae branch. This should be obvious now
but once gui-indep is merged into the main trunk I'll probably make a
new branch called "dialogs" or something like that. That'll only be
updated from the main trunk once a week/fortnight and will be used for
testing/cleaning your submitted patch before it gets merged into the
main trunk. This also means you have a fairly stable target to work
against and if you time your submission right I'll do the merging
instead of you.
6. All dialogs should have a corresponding .fd file in xforms/forms/.
One dialog per file. Dialogs with multiple tabs also count as a
single dialog. Then follow the instructions in the Makefile/README in
the same directory to generate the corresponding FormXXXX::build().
Plug this into your new form class. This makes maintenance much
easier. Also pay attention to the naming scheme for _all_ buttons and
inputs and the naming of all callbacks.
7. Patches may be committed to the rae branch by any of the developers if
they are bug fixes such as JMarcs configure fixes were. If you have
to fix something in sigc++/ then check to make sure the bug wasn't a
result of the development/tools/makeLyXsigc.sh script. If the bug
really is a problem in libsigc++ send a patch to the libsigc++ mailing
list:
[EMAIL PROTECTED]
That was longer than I expected... I better put a copy in xforms/forms/.
On Wed, 8 Mar 2000, Angus Leeming wrote:
> i thought I'd follow in Allan Rae's footsteps and try and port a
> pop-up to frontends. Thinking, "let's keep this simple", I chose the
> Help->Credits pop-up. I now have a FormCredits.[Ch] in the
> src/frontends/xforms/ directory and... it all works!
Credits was indeed the second dialog that I converted in the lyx module so
you certainly are following closely.
[description of modifications req'd]
Sounds good so far. Although as I implied above I'd rather not lose all
the previous work. Credits, however, is one dialog I was going to
implement differently this time around. See below.
> The close similarity between FormCredits.[Ch] and FormCopyright.[Ch]
> (see attachments), suggests that I should proceed by creating a base
> class with virtual build() and two derived classes FormCredits, and
> FormCopyright implementing the build() function. Is this a Good Idea?
> (I ask because C++ is new to me and I'm learing as I go ;-).)
If you look at the lyx module in cvs you'll see a browserbase class and
then notice that the filebrowser for latex errors and one other (can't
remember the class) are derived from it. Credits is much closer to those
classes than it is to Copyright. This is a change I was going to make
this time around.
Get the lyx module if you haven't already and see what I mean:
cvs checkout lyx
Allan. (ARRae)
