Hi all,
Could someone clue me in as to how the src/interface.c file is generated?
Since its autogenerated, wouldn't it be a good idea to remove it from the repo? Obviously, it should be shipped in the source code tarball, but it is reasonable to expect that anyone working from SVN have whatever tool is required to generate that file.
Cheers, Erik
Hi,
Le 09/09/2010 03:02, Erik de Castro Lopo a écrit :
Hi all,
Could someone clue me in as to how the src/interface.c file is generated?
AFAIK it is generated by Glade 2.x; but I'd think it's mentioned in the HACKING file, isn't it?
Since its autogenerated, wouldn't it be a good idea to remove it from the repo? Obviously, it should be shipped in the source code tarball, but it is reasonable to expect that anyone working from SVN have whatever tool is required to generate that file.
Since Glade 2.x doesn't really exist anymore (its out-of-date and couldn't even be compiled with recent GTK version [1]), I don't think it is reasonable to think that every possible contributor have it. So I think keeping it in the repository is a good thing.
That said, I think it'd be good to find a legacy-free way to generate this file -- but I don't know if a C source generator already exists for Glade 3.x/and or GtkBuilder...
Regards, Colomban
[1] at least it wasn't possible without fixing an issue in GTK 2.20, see https://bugzilla.gnome.org/show_bug.cgi?id=618639
On Thu, 09 Sep 2010 03:15:55 +0200 Colomban Wendling lists.ban@herbesfolles.org wrote:
Hi,
Le 09/09/2010 03:02, Erik de Castro Lopo a écrit :
Hi all,
Could someone clue me in as to how the src/interface.c file is generated?
AFAIK it is generated by Glade 2.x; but I'd think it's mentioned in the HACKING file, isn't it?
It is ;) http://geany.org/manual/hacking.html#glade
Since its autogenerated, wouldn't it be a good idea to remove it from the repo? Obviously, it should be shipped in the source code tarball, but it is reasonable to expect that anyone working from SVN have whatever tool is required to generate that file.
Since Glade 2.x doesn't really exist anymore (its out-of-date and couldn't even be compiled with recent GTK version [1]), I don't think it is reasonable to think that every possible contributor have it. So I think keeping it in the repository is a good thing.
I agree for the same reasons.
Cheers, Frank
On 9 September 2010 11:15, Colomban Wendling lists.ban@herbesfolles.org wrote:
Hi,
Le 09/09/2010 03:02, Erik de Castro Lopo a écrit :
Hi all,
Could someone clue me in as to how the src/interface.c file is generated?
AFAIK it is generated by Glade 2.x; but I'd think it's mentioned in the HACKING file, isn't it?
Since its autogenerated, wouldn't it be a good idea to remove it from the repo? Obviously, it should be shipped in the source code tarball, but it is reasonable to expect that anyone working from SVN have whatever tool is required to generate that file.
Since Glade 2.x doesn't really exist anymore (its out-of-date and couldn't even be compiled with recent GTK version [1]), I don't think it is reasonable to think that every possible contributor have it. So I think keeping it in the repository is a good thing.
That said, I think it'd be good to find a legacy-free way to generate this file -- but I don't know if a C source generator already exists for Glade 3.x/and or GtkBuilder...
Glade 3 doesn't support code generation, it only supports using XML descriptions via libglade or gtkbuilder.
Cheers Lex
Regards, Colomban
[1] at least it wasn't possible without fixing an issue in GTK 2.20, see https://bugzilla.gnome.org/show_bug.cgi?id=618639 _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Colomban Wendling wrote:
Since Glade 2.x doesn't really exist anymore (its out-of-date and couldn't even be compiled with recent GTK version [1]), I don't think it is reasonable to think that every possible contributor have it. So I think keeping it in the repository is a good thing.
Well this current situation has dire consequences for people who have a set of patches they want to apply on top of whatever is current in SVN. If any of the patches I want to apply touch this interface.c file and an SVN commit also touches the file, then the patch breaks (and currently, I don't have the required tool).
The particular patch I'm talking about is one posted to this list by Jiří Techet almost a month ago (ie per document indent sizes). I have attached the version of that patch that was working up until some time in the last week.
Erik
On 9 September 2010 12:40, Erik de Castro Lopo mle+tools@mega-nerd.com wrote:
Colomban Wendling wrote:
Since Glade 2.x doesn't really exist anymore (its out-of-date and couldn't even be compiled with recent GTK version [1]), I don't think it is reasonable to think that every possible contributor have it. So I think keeping it in the repository is a good thing.
Well this current situation has dire consequences for people who have a set of patches they want to apply on top of whatever is current in SVN. If any of the patches I want to apply touch this interface.c file and an SVN commit also touches the file, then the patch breaks (and currently, I don't have the required tool).
And I confirm what Columban reported, that Glade 2.12 won't compile on a current system, so this is a major problem for contributors.
Cheers Lex
The particular patch I'm talking about is one posted to this list by Jiří Techet almost a month ago (ie per document indent sizes). I have attached the version of that patch that was working up until some time in the last week.
Erik
Erik de Castro Lopo http://www.mega-nerd.com/
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Thu, 09 Sep 2010 03:15:55 +0200 Colomban Wendling lists.ban@herbesfolles.org wrote:
Since Glade 2.x doesn't really exist anymore (its out-of-date and couldn't even be compiled with recent GTK version [1]), I don't think it is reasonable to think that every possible contributor have it.
...
[1] at least it wasn't possible without fixing an issue in GTK 2.20, see https://bugzilla.gnome.org/show_bug.cgi?id=618639
So part of GTK 2.x isn't usable? Why won't they fix the bug? Surely deprecated stuff should be supported until 3.x.
I suppose the only workaround for Erik is to install an earlier GTK to build Glade 2.12 with and regenerate the interface.c file.
Glade 2.12.2 is about 2.5 years old so I think it's not too old for GTK to drop support for it.
Regards, Nick
On 9 September 2010 21:01, Nick Treleaven nick.treleaven@btinternet.com wrote:
On Thu, 09 Sep 2010 03:15:55 +0200 Colomban Wendling lists.ban@herbesfolles.org wrote:
Since Glade 2.x doesn't really exist anymore (its out-of-date and couldn't even be compiled with recent GTK version [1]), I don't think it is reasonable to think that every possible contributor have it.
...
[1] at least it wasn't possible without fixing an issue in GTK 2.20, see https://bugzilla.gnome.org/show_bug.cgi?id=618639
So part of GTK 2.x isn't usable? Why won't they fix the bug? Surely deprecated stuff should be supported until 3.x.
With GTK, in general deprecated seems to mean unsupported, so unlikely :-(.
I suppose the only workaround for Erik is to install an earlier GTK to build Glade 2.12 with and regenerate the interface.c file.
Downgrading a GTK version can have major follow-on effects on all the things that depend on it, I for one won't be doing it.
Glade 2.12.2 is about 2.5 years old so I think it's not too old for GTK to drop support for it.
Nobody is interested in it, its even hard to find a download of 2.12 now. In fact Geany probably should have a tarball on the hacking page with the GTK docs.
Note that Glade 3.7 (current) claims to support GTK2.8 but only via libglade loading XML, not code generation like interface.c. That would entail a major change in Geany and another dependency (libglade).
Cheers Lex
Regards, Nick _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Thu, 9 Sep 2010 22:09:18 +1000 Lex Trotman elextr@gmail.com wrote:
[1] at least it wasn't possible without fixing an issue in GTK 2.20, see https://bugzilla.gnome.org/show_bug.cgi?id=618639
So part of GTK 2.x isn't usable? Why won't they fix the bug? Surely deprecated stuff should be supported until 3.x.
With GTK, in general deprecated seems to mean unsupported, so unlikely :-(.
This seems bad for a toolkit as important as GTK.
I suppose the only workaround for Erik is to install an earlier GTK to build Glade 2.12 with and regenerate the interface.c file.
Downgrading a GTK version can have major follow-on effects on all the things that depend on it, I for one won't be doing it.
I wasn't suggesting downgrading, that would be next to impossible on a Gnome system. I meant having a parallel install of GTK. I haven't tried it myself but have heard people say they do that.
Glade 2.12.2 is about 2.5 years old so I think it's not too old for GTK to drop support for it.
Nobody is interested in it, its even hard to find a download of 2.12
Latest Fedora still seems to package it: http://rpmfind.net/linux/rpm2html/search.php?query=glade2&system=fedora
now. In fact Geany probably should have a tarball on the hacking page with the GTK docs.
Good idea.
Note that Glade 3.7 (current) claims to support GTK2.8
Interesting.
but only via libglade loading XML, not code generation like interface.c. That would entail a major change in Geany and another dependency (libglade).
I think the dependency issue isn't too important. We need to have a UI designer IMO and glade2 needs replacing.
Maybe it's time to upgrade (after the next release?).
Regards, Nick
On Thu, 9 Sep 2010 16:10:16 +0100 Nick Treleaven nick.treleaven@btinternet.com wrote:
now. In fact Geany probably should have a tarball on the hacking page with the GTK docs.
Good idea.
http://download.geany.org/glade-2.12.2.tar.gz
Also added a link for HACKING in SVN.
Regards, Nick
On 10 September 2010 01:10, Nick Treleaven nick.treleaven@btinternet.com wrote:
On Thu, 9 Sep 2010 22:09:18 +1000 Lex Trotman elextr@gmail.com wrote:
[1] at least it wasn't possible without fixing an issue in GTK 2.20, see https://bugzilla.gnome.org/show_bug.cgi?id=618639
So part of GTK 2.x isn't usable? Why won't they fix the bug? Surely deprecated stuff should be supported until 3.x.
With GTK, in general deprecated seems to mean unsupported, so unlikely :-(.
This seems bad for a toolkit as important as GTK.
True, but being philosophical this morning, I'd observe its a common problem of volunteer supported software, no one is interested in supporting old stuff, and those in the GTK team paid by companies are of course only interested in things the companies are interested in. It shouldn't be marked resolved though!
An in this specific case CList is a GTK-1 widget (I believe) so its waaaaaay deprecated.
I suppose the only workaround for Erik is to install an earlier GTK to build Glade 2.12 with and regenerate the interface.c file.
Downgrading a GTK version can have major follow-on effects on all the things that depend on it, I for one won't be doing it.
I wasn't suggesting downgrading, that would be next to impossible on a Gnome system. I meant having a parallel install of GTK. I haven't tried it myself but have heard people say they do that.
Or I guess it could be run in a VM.
Glade 2.12.2 is about 2.5 years old so I think it's not too old for GTK to drop support for it.
Nobody is interested in it, its even hard to find a download of 2.12
Latest Fedora still seems to package it: http://rpmfind.net/linux/rpm2html/search.php?query=glade2&system=fedora
Must be using an older GTK or maybe they hacked a fix.
now. In fact Geany probably should have a tarball on the hacking page with the GTK docs.
Good idea.
Note that Glade 3.7 (current) claims to support GTK2.8
Interesting.
but only via libglade loading XML, not code generation like interface.c. That would entail a major change in Geany and another dependency (libglade).
I think the dependency issue isn't too important. We need to have a UI designer IMO and glade2 needs replacing.
Maybe it's time to upgrade (after the next release?).
Indeed, maybe its time to think about the whole UI implementation, eg using UIManager for the menu & toolbar which helps with integration of plugin extensions and allows things like build systems to add to them easily :-).
And maybe (not really important) clean up some of the extraneous 1s in the names.
Cheers Lex
Regards, Nick _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Le 10/09/2010 01:50, Lex Trotman a écrit :
On 10 September 2010 01:10, Nick Treleaven nick.treleaven@btinternet.com wrote:
On Thu, 9 Sep 2010 22:09:18 +1000 Lex Trotman elextr@gmail.com wrote:
[1] at least it wasn't possible without fixing an issue in GTK 2.20, see https://bugzilla.gnome.org/show_bug.cgi?id=618639
So part of GTK 2.x isn't usable? Why won't they fix the bug? Surely deprecated stuff should be supported until 3.x.
With GTK, in general deprecated seems to mean unsupported, so unlikely :-(.
This seems bad for a toolkit as important as GTK.
True, but being philosophical this morning, I'd observe its a common problem of volunteer supported software, no one is interested in supporting old stuff, and those in the GTK team paid by companies are of course only interested in things the companies are interested in. It shouldn't be marked resolved though!
Yeah, I think it's weird especially because the fix is really trivial (see below).
I suppose the only workaround for Erik is to install an earlier GTK to build Glade 2.12 with and regenerate the interface.c file.
Downgrading a GTK version can have major follow-on effects on all the things that depend on it, I for one won't be doing it.
I wasn't suggesting downgrading, that would be next to impossible on a Gnome system. I meant having a parallel install of GTK. I haven't tried it myself but have heard people say they do that.
Yes, it works fine, but needs to be installed in another prefix (say ~/old-gtk), and building and/or running an application against it needs tweaking (pkg-config's path, LD path, etc.). It works, but isn't really convenient though.
Glade 2.12.2 is about 2.5 years old so I think it's not too old for GTK to drop support for it.
Nobody is interested in it, its even hard to find a download of 2.12
Latest Fedora still seems to package it: http://rpmfind.net/linux/rpm2html/search.php?query=glade2&system=fedora
Must be using an older GTK or maybe they hacked a fix.
As said, the only thing that's needed is to move includes outside header guards, and you're done.
That is, good night [1] folks! Colomban
[1] at least for me!
On Fri, 10 Sep 2010 03:48:41 +0200 Colomban Wendling lists.ban@herbesfolles.org wrote:
[1] at least it wasn't possible without fixing an issue in GTK 2.20, see https://bugzilla.gnome.org/show_bug.cgi?id=618639
So part of GTK 2.x isn't usable? Why won't they fix the bug? Surely deprecated stuff should be supported until 3.x.
With GTK, in general deprecated seems to mean unsupported, so unlikely :-(.
This seems bad for a toolkit as important as GTK.
Yeah, I think it's weird especially because the fix is really trivial (see below).
Glade 2.12.2 is about 2.5 years old so I think it's not too old for GTK to drop support for it.
Nobody is interested in it, its even hard to find a download of 2.12
Latest Fedora still seems to package it: http://rpmfind.net/linux/rpm2html/search.php?query=glade2&system=fedora
Must be using an older GTK or maybe they hacked a fix.
As said, the only thing that's needed is to move includes outside header guards, and you're done.
Maybe they would accept a patch?
Regards, Nick
Le 10/09/2010 13:25, Nick Treleaven a écrit :
On Fri, 10 Sep 2010 03:48:41 +0200 Colomban Wendling lists.ban@herbesfolles.org wrote:
> [1] at least it wasn't possible without fixing an issue in GTK 2.20, see > https://bugzilla.gnome.org/show_bug.cgi?id=618639
So part of GTK 2.x isn't usable? Why won't they fix the bug? Surely deprecated stuff should be supported until 3.x.
With GTK, in general deprecated seems to mean unsupported, so unlikely :-(.
This seems bad for a toolkit as important as GTK.
Yeah, I think it's weird especially because the fix is really trivial (see below).
Glade 2.12.2 is about 2.5 years old so I think it's not too old for GTK to drop support for it.
Nobody is interested in it, its even hard to find a download of 2.12
Latest Fedora still seems to package it: http://rpmfind.net/linux/rpm2html/search.php?query=glade2&system=fedora
Must be using an older GTK or maybe they hacked a fix.
As said, the only thing that's needed is to move includes outside header guards, and you're done.
Maybe they would accept a patch?
I've just proposed a patch [1], I'll wait a bit to see if there is some reactions. If no, I'll ask and we'll see.
Anyway, I've just tried to fix the build in the glade side, and the result is a really trivial patch that I attach here -- it may be available for download together with the glade tarball or you could even patch the tarball.
Regards, Colomban
On Sun, 12 Sep 2010 01:24:34 +0200 Colomban Wendling lists.ban@herbesfolles.org wrote:
> Glade 2.12.2 is about 2.5 years old so I think it's not too old for GTK > to drop support for it.
Nobody is interested in it, its even hard to find a download of 2.12
Latest Fedora still seems to package it: http://rpmfind.net/linux/rpm2html/search.php?query=glade2&system=fedora
Must be using an older GTK or maybe they hacked a fix.
As said, the only thing that's needed is to move includes outside header guards, and you're done.
Maybe they would accept a patch?
I've just proposed a patch [1], I'll wait a bit to see if there is some reactions. If no, I'll ask and we'll see.
Anyway, I've just tried to fix the build in the glade side, and the result is a really trivial patch that I attach here -- it may be available for download together with the glade tarball or you could even patch the tarball.
Thanks, the patch is now at: http://download.geany.org/
I was too lazy to patch Glade myself, anyway hopefully GTK will be fixed soon.
Regards, Nick
On Fri, 10 Sep 2010 09:50:51 +1000 Lex Trotman elextr@gmail.com wrote:
Note that Glade 3.7 (current) claims to support GTK2.8
Interesting.
but only via libglade loading XML, not code generation like interface.c. That would entail a major change in Geany and another dependency (libglade).
I think the dependency issue isn't too important. We need to have a UI designer IMO and glade2 needs replacing.
Maybe it's time to upgrade (after the next release?).
Indeed, maybe its time to think about the whole UI implementation, eg using UIManager for the menu & toolbar which helps with integration of plugin extensions and allows things like build systems to add to them easily :-).
Not sure if it's worth rewriting, but I haven't used UIManager.
A similar situation: I think using Stash for prefs everywhere would be much cleaner, but no one really wants to make the change, and it could introduce bugs.
And maybe (not really important) clean up some of the extraneous 1s in the names.
If Glade 3 still puts 1 on the end of widget names by default then every time a widget was added we'd have to remember to edit the name.
Regards, Nick
On 10 September 2010 21:30, Nick Treleaven nick.treleaven@btinternet.com wrote:
On Fri, 10 Sep 2010 09:50:51 +1000 Lex Trotman elextr@gmail.com wrote:
Note that Glade 3.7 (current) claims to support GTK2.8
Interesting.
but only via libglade loading XML, not code generation like interface.c. That would entail a major change in Geany and another dependency (libglade).
I think the dependency issue isn't too important. We need to have a UI designer IMO and glade2 needs replacing.
Maybe it's time to upgrade (after the next release?).
Indeed, maybe its time to think about the whole UI implementation, eg using UIManager for the menu & toolbar which helps with integration of plugin extensions and allows things like build systems to add to them easily :-).
Not sure if it's worth rewriting, but I haven't used UIManager.
Oh, it would only be worth it when making a big change like moving to libglade, but its worth a thought then.
A similar situation: I think using Stash for prefs everywhere would be much cleaner, but no one really wants to make the change, and it could introduce bugs.
Yes, and new contributors don't understand about stash and (gently) I think it could use a bit more documentation, I'm still confused how it relates to the widgets & how it handles non-static things like variable numbers of build commands? (which is why I don't use it)
And maybe (not really important) clean up some of the extraneous 1s in the names.
If Glade 3 still puts 1 on the end of widget names by default then every time a widget was added we'd have to remember to edit the name.
Or remember to put the 1 in all references in the code, six of one half a dozen of the other :-)
Cheers Lex
Regards, Nick _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Sat, 11 Sep 2010 11:31:47 +1000 Lex Trotman elextr@gmail.com wrote:
Indeed, maybe its time to think about the whole UI implementation, eg using UIManager for the menu & toolbar which helps with integration of plugin extensions and allows things like build systems to add to them easily :-).
Not sure if it's worth rewriting, but I haven't used UIManager.
Oh, it would only be worth it when making a big change like moving to libglade, but its worth a thought then.
OK.
And maybe (not really important) clean up some of the extraneous 1s in the names.
If Glade 3 still puts 1 on the end of widget names by default then every time a widget was added we'd have to remember to edit the name.
Or remember to put the 1 in all references in the code, six of one half a dozen of the other :-)
I think Glade increments the 1 for duplicate names, but of course any names with no digit maybe should be changed. The problem is it may break plugin code though.
Regards, Nick
On Sat, 11 Sep 2010 11:31:47 +1000 Lex Trotman elextr@gmail.com wrote:
A similar situation: I think using Stash for prefs everywhere would be much cleaner, but no one really wants to make the change, and it could introduce bugs.
Yes, and new contributors don't understand about stash and (gently) I think it could use a bit more documentation
Maybe. I wrote Stash myself and it could use some feedback.
I'm still confused how it relates to the widgets
Not sure if you've seen the latest docs, but just in case: http://www.geany.org/manual/reference/stash_8h.html#_details
Perhaps it could be clearer, suggestions welcome.
& how it handles non-static things like variable numbers of build commands? (which is why I don't use it)
It doesn't really support that. I didn't mean to suggest you should use it there ;-) For simple prefs, it could be used everywhere though.
Regards, Nick
Nick Treleaven wrote:
I suppose the only workaround for Erik is to install an earlier GTK to build Glade 2.12 with and regenerate the interface.c file.
Actually, I managed to find a way to do this.
I have Ubuntu Hardy running in a chroot and that has glade-2. However, this is a short term solution as Hardy is due to be end-of-lifed some time in the next year and I expect the repos will disappear soon after that.
Erik
On Thu, 9 Sep 2010 11:02:42 +1000 Erik de Castro Lopo mle+tools@mega-nerd.com wrote:
Could someone clue me in as to how the src/interface.c file is generated?
Its created by galde. Please check http://geany.org/manual/hacking.html#glade for some info over here.
Since its autogenerated, wouldn't it be a good idea to remove it from the repo? Obviously, it should be shipped in the source code tarball, but it is reasonable to expect that anyone working from SVN have whatever tool is required to generate that file.
I disagree. Removing this would cause everybody who just wants to have the current svn build to have an ancient version of Glade installed.
Thanks, Frank