[Glade-users] custom properties stored in glade xml file

[Neil Zanella <nzanella gmail com> (Neil Zanella)]

> I suggested this before, but it has some problems. (you can't set pointers to
> data via your method, only strings and integers (but not enumerations from
> within the code either)
>
> I use a method that has a config file in .ini file format ([section] key=value)
>  after the glade tab is loaded a recursive funcion is called "bind_data" that
> rccurses down through the widget tree and looks for keys/values to load from
> the conf file and loads them.  It's not very pretty, but it works extremely
> well for my application.

Yeah,so we can have another XML file sitting around with other
configuration data.
But that is precisely what I don't want. The whole point is, the
developer shouldn't
have to key in widget names in the source code when it could be avoided by
storing custom properties in the glade file via the glade gui builder.

I don't understand your complaint regarding pointers that can't be stored that
way. Why would you want to do so? Keep a hash table with the pointers you
need on the RHS and property strings on the LHS and the custom properties
solution will apply to you in this way.

Plus, everyone knows renaming variables and matching them is so tedious.
Sometimes I would even like to have a property called retrieveme="true",
process the glade file with my own python script to gerate source code to
retrieve only those widget I care about, automatically. Would be so much
better.

Plus, while I am at it, anyone know of ways of integrating glade files
with eclipse?
Has anyone done this? What would it take to write an eclipse plugin?
So that, when
I want to rename a variable in the glade file, all corresponding
variables are automatically
renamed in the corresponding C file.

Also, is glade pluggable into eclipse? For instance, can I write yet
another plugin, so that,
when I click on an XML file line, property editor comes up with the
widget of interest
where the cursor is located? Just wondering. Could be handy.

Regards,

Neil