> I think we've agreed on an integrated IDE via Corba & Bonobo.
> Of course this won't be available in the GTK+ version, but we can't do
> everything.
Any work been done as to the interfaces between elements of the IDE?
> We can try to use the GtkArg/GParam stuff in GTK+/GLib, and also the
> BonoboPropertyBag stuff which we partially support now.
>
> An extra customization API may be useful. I'm not sure if Bonobo has that.
I'm assuming that this discussion related only to GTK2.0, right? And
when you
say customization API, do you mean a general API to be applied to custom
widgets, or an API specifically for Glade?
> > 3. Should the XML format be overhauled? (As a code generation author, I
> > can tell you first hand that it needs work).
>
> Maybe, once we know exactly what the final format should be.
> (But there are many other things to do and this is a religious issue, so
> forget you even mentioned it!)
Never! :)
Something you mentioned hit me a while ago. The idea of using small
Glade XML
files for dialogs (as in Evolution) can be extrapolated.
Consider each top-level widget having its own XML file, and one XML file
for
the project itself. Widget XML files have no project-specific info,
just
widget structures and property tags. The project XML file has flags for
gnome support, directory locations, etc.
This would go a long way to creating a component development environment
with
GUI tools like Glade. Right now, if you develop a dialog box under
Glade,
and you want to use it in another project, you have to either a) load
the other
project's glade file using libglade, then request the dialog, or b) do a
copy/
paste from the old glade file to the new glade file. It would be much
nicer
to keep the glade files in the gnome share directories, then load it
using
libglade on demand, or add it to a project as a read-only widget. I
suppose
bonobo will also fix that problem, however.
As for the Glade XML files, I'm not looking for a massive overhaul. It
would
make my life easier, though, if labels for attributes in glade's XML
matched
up with the GtkArg name. Examples would be shadow_type (shadow) and
columns
(n_columns). The <child> tag causes a few complications as well. Most
importantly, though, I would make widget attributes XML attributes.
That
way I know immediately if I'm dealing with a subwidget or an attribute.
I understand that a small change in glade's XML can cause a lot of
rework for
for code generator authors, so if this change is to be made, I would
suggest
making the change at the same time as the switch to GTK2.0. When it
rains
it pours, something like that :)
> > 4. Should glade be a tool for entry-level programmers, exposing only the
> > most basic features of Gtk/Gnome, or should it be a power-user tool,
> > allowing endless customizability and flexibility?
>
> It should be the best that we can make it, with our limited time.
Thats pretty vague... if we truly have limited time, it would only make
sense
that we should have a better game plan. Knowing what type of tool Glade
should be would help focus the developers who still work on Glade.
> I'm mainly only doing bug fixes at present. Michael Meeks occasionally works
> on the Bonobo stuff. Federico said he may try to add Undo support, though he
> also has tons of other things to do.
>
> I don't know of anyone else doing any development.
> Glade doesn't seem to attract many developers. I'm not sure why.
Don't know either. I think developers might shy away because it looks
intimidating. Writing GUI development tools has traditionally been a
rather
difficult task.
John
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
_______________________________________________
Glade-devel maillist - [EMAIL PROTECTED]
http://lists.helixcode.com/mailman/listinfo/glade-devel
