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.
> Is there any way of setting the style for widgets of a certain type within a widget
> tree i.e. all buttons in this window's widget tree? If there is then that would be a
> good use of ".*." in the rc files. I can't remember seeing this feature though -
> another one for the list perhaps :-).
I'm not sure you can do that with rc files. You can either use widget names as paths
or class names, but I don't think you can mix them like "mywindow1.*.GtkButton".
But of course Glade could handle this itself, generating all the rc lines.
> First though, can rc files be used for anything other than styles? If they can then
> this entire section can be iignored!
I've heard rumours about this for GTK+ 2.0, but I'm not sure it has been done.
> 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.
It might be nice for Glade users to set their own default values for particular
properties. 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?
Damon
_______________________________________________
Glade-devel maillist - [EMAIL PROTECTED]
http://lists.helixcode.com/mailman/listinfo/glade-devel
