From: James Henstridge (james@daa.com.au)
Date: Tue Jul 10 2001 - 22:15:27 EDT
On Tue, 10 Jul 2001, Dermot Musgrove wrote:
> Chema Celorio wrote:
>
> [About file changes ...]
> There will obviously be a great many changes in the way that the Glade2
> file be read and interpreted when it comes to widgets. I'm sure that
> the changes are for the better - is there an example/reference file
> somewhere that I can have go at using?
>
> > I suggest that you take a look at the XML format that James has been
> > working on and review it. Send any comments you have on the new format
> > so that we make sure we get it right.
> I had a look at the sample/DTD that James posted 5 May 2001 and that
> is certainly very elegant and an improvement over the present format.
> 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.
>
> [...]
> > > I guess that you have
> > > considered making Glade2 an object that would supply services so that
> > > IDEs, editors or even generators can use Glade2 functionality rather than
> > > the present way round.
> >
> > I don't think genereators want to use glade2 functionality, but I have
> > not given thought to this idea. What funcitonality do you want glade2 to
> > provide to generators ?
> I guess that it depends on the direction that Glade2 goes. At the moment
> the new format is suitable for libglade but does not hold any information
> that the generators need.
>
> If there is no <project> element with directory information and so on, the
> generators will have to hold that information in a separate project file.
> Glade-Perl already does this to control the generation and also as a small
> history of the last generation run (for project.glade it is called
> project.glade2perl.xml and there may also be a project.glade2perl.log)
> 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.
> > Glade2 should actually simplify code-generators a lot, since it will
> > use GParams to get & set properties of widgets.
> >
> > So if GParams have a decent binding in Perl, you should be able to set
> > all widget properties in a generic way, even those of widgets that
> > Glade-Perl knows nothing about.
> I don't think that GParams is bound at all :( I will have to find out
> what they are all about. James Henstridge talked in a similar way so
> I suppose that he was describing this too.
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 have to say, though, that I think people are moving away from code
> > generation and more towards dynamic loading, using libglade or a wrapper.
> > It means less code and is easier to handle for large projects.
> You are probably right - I have no idea. Glade-Perl is still being
> downloaded so I guess that there are still people who want to 'fiddle'
> with the source. If Glade2 is going to ignore code generation I will
> have to write a Glade::Helper app to do the job that Glade does now
>
> 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.
James.
-- Email: james@daa.com.au WWW: http://www.daa.com.au/~james/_______________________________________________ Glade-devel maillist - Glade-devel@ximian.com http://lists.ximian.com/mailman/listinfo/glade-devel
This archive was generated by hypermail 2b29 : Wed Jul 11 2001 - 00:55:17 EDT