Created attachment 71540 [details] [review]
patch

A working demo of what I want.

Created attachment 71541 [details]
sample catalog file

(In reply to comment #0)
> At the moment glade insists on having a module defining the types. It's be much
> better if a type could be defined completely in XML file.
> 
> The use case is really simple: I have an application with FooWidget class. It's
> a subclass of stock BarWidget with couple of extra properties. To use it in
> glade I need to break my build system, learn to make a shared library, learn to
> make a glade module, maintain this extra library. It's overkill, so I want just
> to write an xml file and be happy.

This should be possible without having any support module - you should
be able to point your support module to the actual library containing
the widgets themselves if no support routines are needed.

> Or, imagine a python guy who just will never make a shared library. While a
> real solution should be glade modules written in python, this hack is simple
> and does the job in simple cases (and these are the most cases, and think also
> about perl, ruby, mono, and whatnot).

I would expect this approach to be a last resort - glade doesnt have
to interface with any of the code provided from these modules, just use
the integer type identifier to introspect everything from the object.

There must be a better solution to these other languages than
writing out the class name & properties by hand in the catalog.

> These two are just about what attached patch does - simply subclass a type, and
> use fake properties. I believe it'd be good to make this stuff more powerful,
> e.g.  define param specs in xml too.

Sounds like a good idea, would be nice if we could continue define pspecs 
in a single line in the xml file.

I think it was you that also brought up another idea on irc... to use some
kind of class per widget-class on the catalog side - that sounds also like
a really great idea, that would dramaticly effect the way we see the xml file
etc.

Lets find out where we're going on a big picture scale before we jump the
gun on these features.

(In reply to comment #3)
> (In reply to comment #0)
> > At the moment glade insists on having a module defining the types. It's be much
> > better if a type could be defined completely in XML file.
> > 
> > The use case is really simple: I have an application with FooWidget class. It's
> > a subclass of stock BarWidget with couple of extra properties. To use it in
> > glade I need to break my build system, learn to make a shared library, learn to
> > make a glade module, maintain this extra library. It's overkill, so I want just
> > to write an xml file and be happy.
> 
> This should be possible without having any support module - you should
> be able to point your support module to the actual library containing
> the widgets themselves if no support routines are needed.

Usual people do not write libraires, they write applications, so there is no library to give to glade. So you do have to make a library, and it is overkill. It might not be hard to make a lib once (you need to know how though, think of all the people having troubles with glad autoconnect), but it is hard to maintain it, and you have to maintain it if you want to edit your glade file later again.

> > Or, imagine a python guy who just will never make a shared library. While a
> > real solution should be glade modules written in python, this hack is simple
> > and does the job in simple cases (and these are the most cases, and think also
> > about perl, ruby, mono, and whatnot).
> 
> I would expect this approach to be a last resort - glade doesnt have
> to interface with any of the code provided from these modules, just use
> the integer type identifier to introspect everything from the object.

You can't "just use the integer type identifier", you must run some code to get that integer type, it's not some integer. But type name *is* a human-readable/writable string, as well as properties descriptions.
I'd say it's a nice hack that allows easy solution of a problem. 
Think of it this way: it's not glade business to decide what I want, its business is to help me, e.g. get properties right from the type, but not get in my way if I'm saying red is blue. Just look at gtk catalog, that's not exactly nice introspection stuff.

> There must be a better solution to these other languages than
> writing out the class name & properties by hand in the catalog.

Must be. But I am hundred percents sure that those better solutions will be powerful and complex, just like making a glade module (it is complex).

Oh, and I completely forgot about the case when those properties are not real, and introspection won't give you anything, so you just have to create a GType with right parent, and still write that xml with *same* content...

> Usual people do not write libraires, they write applications, so there is no
> library to give to glade. So you do have to make a library, and it is overkill.
> It might not be hard to make a lib once (you need to know how though, think of
> all the people having troubles with glad autoconnect), but it is hard to
> maintain it, and you have to maintain it if you want to edit your glade file
> later again.

Libraries are not hard to maintain, usual people do create and use them
and they are a great way to reuse your custom widgets in whatever other
projects you might work on.

> You can't "just use the integer type identifier", you must run some code to get
> that integer type, it's not some integer. But type name *is* a
> human-readable/writable string, as well as properties descriptions.
> I'd say it's a nice hack that allows easy solution of a problem. 
> Think of it this way: it's not glade business to decide what I want, its
> business is to help me, e.g. get properties right from the type, but not get in
> my way if I'm saying red is blue. Just look at gtk catalog, that's not exactly
> nice introspection stuff.
> 
> > There must be a better solution to these other languages than
> > writing out the class name & properties by hand in the catalog.
> 
> Must be. But I am hundred percents sure that those better solutions will be
> powerful and complex, just like making a glade module (it is complex).

The complexity should be mostly in the core - it should know how to load
an "any language" backend with little or no participation from the user
that provided the widget code in the first place.

While an ultimate solution to loading widgets written in other languages
and scripts might be impossible, it should still be investigated - the last
thing I want to do is to introduce convenience hacks for things we havent even
tried to get working properly yet.

All I'm saying is that - what you are sugesting is an interesting possible
solution to interfacing with widgets written in other languages - and while
you might just see it as a patch containing a few lines of code, I see it as
a dangerous design decision that risks shaping the future of glade into
something that may or may not be less than perfect, we need to cover all the
angles and implications before jumping right into such a change.

(In reply to comment #6)
> > Usual people do not write libraires, they write applications, so there is no
> > library to give to glade. So you do have to make a library, and it is overkill.
> > It might not be hard to make a lib once (you need to know how though, think of
> > all the people having troubles with glad autoconnect), but it is hard to
> > maintain it, and you have to maintain it if you want to edit your glade file
> > later again.
> 
> Libraries are not hard to maintain, usual people do create and use them
> and they are a great way to reuse your custom widgets in whatever other
> projects you might work on.

It is from libtool manual, isn't it :)
Have you ever gotten misterious "dynamic library won't be created" from libtool when building for win32? (just an example of funny libtool business).

> While an ultimate solution to loading widgets written in other languages
> and scripts might be impossible, it should still be investigated

Of course it is possible (maybe not "ultimate").

> - the last
> thing I want to do is to introduce convenience hacks for things we havent even
> tried to get working properly yet.

But this hack is not for that, this hack is for a thing this hack is for, no more no less. Make glade use non-existing types ("non-existing" means "not created in the glade process by someone else").

> All I'm saying is that - what you are sugesting is an interesting possible
> solution to interfacing with widgets written in other languages - and while
> you might just see it as a patch containing a few lines of code, I see it as
> a dangerous design decision that risks shaping the future of glade into
> something that may or may not be less than perfect, we need to cover all the
> angles and implications before jumping right into such a change.

No, I am not suggesting what you said. This bindings stuff is just an example of real-life situation where user can get a quick nice (or not nice) solution for his problem.
What I am proposing here is: make it possible to define *type* in xml, not only its properties. It would be a logical extension to what's already there: you can create fake properties out of nothing; then, you can specify function which gets you the type.
Language bindings and stuff is really an orthogonal issue.

We're going to go ahead with this - the major reason why we haven't so
far is because we have our attention on other things, I think that this
is a little touchy of an issue and we probably need to discuss and refine
the api a little more before we get a patch in - that goes for the definition
of GParamSpecs in the catalog as well.

I'm putting this on the TODO for now but I cant promise that I'll have
time to give my attention to it soon, definitly want to get it in as
part of the 3.2 release cycle.

Applied !

Applied this feature as is with the same semantics, just refitted the
patch a bit to fit with new sources

Thanks muntyan !