Re: gtk3

On 2013/01/28, at 21:50, Maxence Guesdon <[email protected]> wrote:

> Hello,
> 
> I had a look at the gtk3 branch. (by the way, the branch is out of sync
> with all the changes since we use findlib. Since the src directory was
> copied in a src3 directory, files from src may have changed
> indepedently.

This is not a problem: currently its goal is to generate automatically
as much code as possible, dumping almost all of lablgtk2.
That's why only a tiny part had to be copied in src3.
At some point we will need to merge, but there is no need to
sync the src directory now.

> I propose to do the following:
> - start a new branch, gt3x or whatever,
> - create a /tools directory where to put the stub generator actually in
>  src3/introspection

I'm afraid it's a bit too early yet.
But I agree that the configuration in src3/introspection is not very intuitive.

> - make it use xmlm rather than xml-light, which stops when encountering
>  "/" in a XML attribute in GLib-2.0.gir

I have no opinion on that. I've never used xmlm, but if you can adapt the
sources easily it's ok.

> - add a target in src/Makefile to generate stubs,

As you've seen, it is already done, but lots of work to do yet.

> - use these stubs in src/ files

That's indeed the ultimate idea.
But the question is how far we can go using automation.
In particular it would be nice to add labels automatically.
But generating optional arguments seems to be harder.

Writing only the OO files by hand would be safe, but it would still
be lots of work.

> The question whether the release should already contain stubs or not
> was raised. What do you think ? Personnaly, I think the generated stubs
> should be included in the release, so that the person which compiles do
> not have to regenerate them, depending on more installed libraries.
> The separate "stubs" target in src/Makefile would be available, anyway.

Yes, the end user is not supposed to regenerate the stubs every time.
For instance, some gir files might be broken in some installation.

> Well, I think we should remove xml_lexer too and use Xmlm, so that we
> concentrate on gtk bindings. :-)

I don't know. Sometimes, adding more dependencies creates more work :-)
Anyway, we should move from libglade to gtkBuilder, so lablgladecc will
have to change for sure.

(the xml_lexer was really one of the easy parts of lablgtk, it was only intended
for reading glade…)

	Jacques