Hi Martijn,
Martijn van Beers wrote:
>
> here goes:
>
> 1) The <project> tag and it's children. I've said this before, this
> shouldn't be in the xml file. None of the information is useful
> for applications that want to work with the interface described in
> the xml file. They are all project settings belonging in some
> .ini like file, along with a line
>
> project_xml_file=nameofxmlfile.glade
>
> Putting it in the xml file is like putting the source in that file
> too, so we don't have too many files. It describes a totally
> different sort of information, it should not be there.
You are wrong here. When my app that generates source code needs to know
where to put the generated source I use the Glade <project> value. When I
need to find pixmaps I use the Glade <project> value. When I need to know
if the user has asked for Gnome support I use the Glade <project> value.
And I bet that libglade uses some of the values on the libglade page :)
> 2) The <child> tag. This has several problems.
> a) It's being used for different things. A child of a GtkBox is
> not the same as a child of a GtkTable. These should have
> different names, so you don't have the same tag containing
> different attributes/elements
> b) It's in completely the wrong place. the data in <child>
> is not a part of the child widget, it's a part of the
> container.
You are right here, it would be great to know whether to construct the
widget and add it to the UI (somehow?) or to get a ref to a subwidget that
has already been constructed (although it is possible to work it out).
> 3) Labels in buttons. Creating a button, and just filling in a label
> generates a different result than creating a button, removing
> the original label, and putting a label of your own in its
> place. This is wrong. You can't change the properties of the
> former label, and they don't even get stored.
I reckon that this reflects the Gtk approach which gives you new() and
new_with_label() and is understandable. In perl, they are new() or
new('label') so it's not a great problem :)
if there is a decision to be made about how to represent GtkButtons in the
XML structure, I vote to treat the button as a container, for consistency.
However I think that buttons should be GtkButton _or_ GnomeStockButton so
that they can be seen to be different widgets (as they are).
> 4) CLists. Apart from not being completely controllable from within
> glade, they have the following problems
> a) It's children are currently the row title widgets. The way
> it should be is clist->colums->titlewidget. A column has
> several properties currently not settable and
> b) the column-width is part of a column, not something that
> should be a property of the clist widget as a comma seperated
> list.
This is a problem that I haven't come across yet, now I am worried. At the
moment I allow the label width to determine the column widths but I can
see that it might be good to set_column_width() for each column instead.
> This list is probably far from complete, but I think it clearly
> shows how the current structure ('simple' indeed!) is wrong, thus
> warranting a rewrite. And, again, if we're going to rewrite it
> anyway, why not pick up the advantages of attributes as we go.
You know what I think about this :)
Regards, Dermot
+---------------------------------------------------------------------+
To unsubscribe from this list, send a message to [EMAIL PROTECTED]
with the line "unsubscribe glade-devel" in the body of the message.
