This one looks like the easiest to fit with our code. Our GNOME
classes can simply inherit from the GTK classes. You will
probably need to make some functions virtual in the GTK classes,
but should be very easy.
> like this:
> .../wp/ap/unix/gtk/[files with the gtk+ code]
> .../wp/ap/unix/gnome/[files with the gnome code]
I think this introduces a problem with inheritence. I haven't
looked through all the GNOME front-end code, but I _think_ there
are probably situations where the GNOME libraries do not provide
a special service we already use. That way we can code that
"special feature" once and have it work on GTK and GNOME.
That's why I like the first layout better.
> or like this:
> An another question, the gnome code must be inherited of the gtk+ one?
> or the gnome branch has to be treated like a yet another port?
It could be treated like another port, but I would like it to be
inherited. One of the reasons I wanted to inherit was to have all
features working for the GNOME front-end, even if someone hadn't
implemented the GNOME library's version. For example, if GNOME
menus hadn't been added, the GTK menus would still work.
Since you've shown some exceptional effort in hooking up the GNOME
parts, this isn't much of a concern. :) But for the future, we're
using dialogs constructed from raw GTK widgets. Our dialogs
are pretty complex things, and sometimes their widgets might
map to GNOME widgets, but I think we'll have some native ones for
quite a while.
> I think that if you give me some ideas about the abisource plans for the
> GNOME port, I can make this port a reality really soon (at least
Really, my suggestions are just that. If you find one way remarkably
better than another, feel free to do it your way. I think the code
will deal with itself pretty well, but the Makefiles will require
a test (in abi/src/config/require" to switch on the GNOME front-end
classes (for compilation and linking) and the right gnome-config
CFLAGS (for compilation and linking).
-- Shaw Terwilliger