Damon Chaplin wrote:
> Matt Goodall wrote:
>
> > Wouldn't it be better to use the full name of a widget, i.e.
> > mywindow1.this.that.mybutton1, in the rc files? That way there will never be name
> > clashes.
>
> The problem there is that some widgets insert extra children which you rarely notice
> (e.g. GnomeApp has GnomeDockBands which you never see in Glade.)
> Though maybe it would work OK if you walked up the hierarchy and used the widget name
> or the widget class if the name isn't set.
Ah, good point.
> > I think I need to explain my idea more so here goes ...
> >
> > If the values are put in a shared data file then "overriding" the values using
>data in
> > $HOME could use pretty much the same loading code.
> >
> > Each value definition could be stored in a map as a structure containing id,
> > default_value and user_value. The shared data would fill in the id and
>default_value
> > and set the user_value to the default_value at the same time. The $HOME data would
> > then simply replace the user_data value.
> >
> > I can see this sort of thing being useful for putting something like this in the
>$HOME
> > data:
> >
> > GtkWindow.GtkContainer.border_width: 10
> > *.GtkButtonBox.layout: Spread
> > *.GtkTable.row_spacing: 5
> > *.GtkTable.cell_spacing: 5
> >
> > All the code generators have to do is:
> >
> > if user_data != default_data
> > write code
> >
> > Unfortunately, this sort of change would affect all the code generators. If this is
> > seen as a good idea then it would probably be nice if glade supplied the parsing
>and
> > map building code as a separate, shared library to avoid duplication. I suppose
>that
> > libraries like libglade would also have to support this stuff which could be
>tricky.
> > More thought needed on that bit. Heh, this idea should panic some of the code
> > generator maintainers :-).
> >
> > The other argument for this sort of info being supplied in a data file is that
>there
> > really shouldn't be stuff like this hard-coded anyway.
> >
> > Yet another vaguely related thought is that Glade could even be distributed as
>glade
> > and glade-data packages to make changes/bug fixes to this sort of thing have less
>of
> > an impact on users.
>
> I'm not sure I understand the idea completely. Are the data files just used for Glade
> development? I don't see why the real default values are not determined automatically
> by Glade. It can probably do that.
You're right, after all Glade creates the widget so the defaults could be determined at
that point. No need for the shared data file.
> It might be nice for Glade users to set their own default values for particular
> properties.
It could potentially save a lot of time developing the UI. Most widgets, especially the
containers, are set up in a very similar way i.e. spacing, alignment, packing etc.
> Glade would then only save properties if they are different from the
> real default values, and code generators wouldn't need to be changed, would they?
You're quite right - it's fairly straightforward and if the info gets written to the
Glade
project file then code generators would still work. Oops, I think I over engineered it
a
bit :-).
Cheers, Matt.
--
Matt Goodall, Software Engineer | Isotek Electronics Ltd
mailto:[EMAIL PROTECTED] | Claro House, Servia Road
http://www.isotek.co.uk | Leeds, LS7 1NL
Tel: +44 113 234320 | England
_______________________________________________
Glade-devel maillist - [EMAIL PROTECTED]
http://lists.helixcode.com/mailman/listinfo/glade-devel
