From: Dermot Musgrove (dermot@glade.perl.connectfree.co.uk)
Date: Thu Jul 12 2001 - 19:19:55 EDT
James Henstridge wrote:
>
> On Tue, 10 Jul 2001, Dermot Musgrove wrote:
>
[...]
> > My only suggestion at the moment is to set the encoding property eg:
> > <?xml version="1.0" standalone="no" encoding="ISO-8859-1"?>
> > or whatever is used.
>
> Well, with gtk 2.0, all user visible strings are expected to be in UTF-8,
> so it makes sense to use UTF-8 in the file format. However, if the glade
> file gives a different encoding, then the code generator should reencode
> the strings in UTF-8.
Great.
[...]
> > This could be extended and used to control the generation phase.
>
> The reason for not having project specific information in the glade file
> was to make the glade files purely interface descriptions. Having project
> information inside the glade file doesn't always make sense -- there are
> many projects where there isn't a one to one correspondence between glade
> files and projects (gnumeric has lots of glade files for instance).
>
> I don't know what the best balance would be.
Do I understand that a Glade2 project could reuse existing form/dialogs
by referencing them somehow? I can imagine a lot of uses for this
approach - the first off the top of my head is a common file dilaog.
I haven't yet thought how to implement this in a generator but I have
always meant to package up some dialog/handlers to achieve something
like this. Perhaps a common repository for glade files is needed?
[...]
> GParams/properties are the new name for gtk 1.2's GtkArgs. I think the
> simple.pl example (I think it is Gtk/samples/simple.pl) in gnome-perl
> demonstrates using GtkArgs to construct an object. I am sure lupus will
> provide a similar interface in his 2.0 bindings.
I can't find any actual use of them in the latest package - do you have
a URL describing GParams at all?
[...]
> > Glade2 will need IPC of some sort unless it is to be a libglade-only UI
> > builder or the generators are all CLI apps supplied with args and/or
> > text-edited project files.
>
> It will probably call code generators as command line apps. I would think
> that most people would put the code generation stage into their makefiles
> rather than having to remember to press a "build" button in glade every
> time they make a change to their interface file.
Right - my problem here is that the project information has to be
entered by the developer somehow and it would be a shame to force them
back to hand-editing project files. As I implied before, each generator
would really need to provide a UI to work with this data and it would
not be possible to simply click a radio button to generate code in a
different language.
Maybe it is desirable for IDE/editor/generator/helper apps to ask Glade2
to save any UI changes before they build the project.
I can understand why James is not interested in having any information in
the Glade file except that needed by libglade but I can imagine plenty of
problems if there is not sufficient certainty that project and UI files
are in step.
As I asked before, is Glade2 giving up on maintaining the project
information completely? if not, can it be extended to maintain all
the necessary information - perhaps using generic fields (GParams? :)
Also I would love to see the latest XML format - is there a URL?
My questions come because I don't really understand what the Glade2
project goals are and also that I would not like to see Glade lose
functionality or impose working methods on developers unnecessarily or
replication of the 'Options' dialogs for each generator (unless someone
builds a fairly generic glade_helper of course).
I am sure that when I understand more I will stop bugging you all -
thanks anyway for the time you have spent responding :)
Regards, Dermot
_______________________________________________
Glade-devel maillist - Glade-devel@ximian.com
http://lists.ximian.com/mailman/listinfo/glade-devel
This archive was generated by hypermail 2b29 : Thu Jul 12 2001 - 20:55:01 EDT