From: Dermot Musgrove (dermot@glade.perl.connectfree.co.uk)
Date: Tue Jul 10 2001 - 13:06:41 EDT
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.
[...]
> > 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.
If there is no <project> element there can be no 'Build' button/menuitem
in Glade2 and the control must pass to a generator/helper app. If there
is no <project> data held there is no need to coordinate the apps
and there is little need for IPC as far as I can see.
However, if Glade2 holds <project> data it is most likely that the
generator/helper will need to ask Glade2 to reload at least the <project>
data fairly often and to notify the helper when the UI definition has been
updated. I would also have plenty of suggestions for what should be
included in a glade2perl page in the options dialog :)
[...]
> the two versions are diverging already. glade2 is mostly a rewrite of
> glade.
I guess that the best solution is to fork parts of my generator and
supply eg. Glade::PerlGenerate and also Glade::PerlGenerate2 etc. This
would probably be fairly easy to achieve - if a bit of work. Perhaps
this should be combined with the gtk2 changes
[...]
> I don't understand what you mean by glade2 developers taking generator
> authors for granted. I am contributing to the community, so are the code
> generators authors.
Please don't think that I am flaming, it's just that if the <project>
data disappears or changes, generators will have much more to do and there
has not been much discussion so far about them.
[...]
> I started writing glade2 because i wanted to add undo to the current
> glade and i (stupidly) thought that it was more work to add undo to the
> current codebase than to rewrite it from scratch and add undo. I was
> wrong ;-). But glade2 is comming along nicelly.
I know the feeling :) Glade-Perl also started as a weekend project.
[...]
> I have been told a couple of times "why didn't you inform us ?", "who
> made this desition that is affecting my code", "you can't be taking
> GNOME desitions on your own and not talking about it with the rest of
> the parties". well the answer is simple, this was just an accident. It
> just happened. I wrote code because i wanted to do something fun for a
> weekend, next time i look back glade2 is now a project that is moving
> along.
I guess that is bound to happen when you take such a popular and well
used app with a known interface (XML file), change it and then _release_
it without consulting the interested parties. Still perhaps nothing would
change unless someone jumps in at the deep end :)
Damon Chaplin wrote
> 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.
> 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.
I know that this all sounds like complaints so I would like to thank
all the clever people who have done so much in the past and also now for
their generous work to make Glade the best UI builder available. I
will follow Glade2 with enormous interest - does it have a website?
Regards, Dermot
_______________________________________________
Glade-devel maillist - Glade-devel@ximian.com
http://lists.ximian.com/mailman/listinfo/glade-devel
This archive was generated by hypermail 2b29 : Tue Jul 10 2001 - 16:53:38 EDT