Hi all,
I've tried to compile Geany with the --disable-deprecated configure option, but I used… GTK+ 2.12 and GLib 2.16. Of course, it hasn't worked (mostly because of the new tooltip API and GObject generalization), but it's not really the reason of my mail.
In src/utils.c, g_strcasecmp() is used, but it is deprecated since 2.2. I dunno if the reason why it was deprecated have any incidence on what it is used here (I think not), but it breaks build without deprecated symbols even with 2.6. An easy fix is to copy the function (with another name or so) in the Geany's source code.
Another think I've noticed is that the tagmanager use GMemChunks for allocating memory, but the new GSlice API seems to be really faster (and simpler). What do you think about using it when compiling with GLib >= 2.10? It is easy to set up, just two macros to update. (patch attached - geany_r3060_tagmanager_gslice.patch)
Last thing: about marshal closures. I dunno if g_cclosure_marshal*() are present in GLib 2.6, but gtk_marshal*() are deprecated now, and I think glib-genmarshal is not a really recent tool. Then, it can be nice to move gtk_marshal*() to corresponding g_cclosure_marshal*() and/or to define which are needed in geany-marshal.[ch] files or so. (another patch attached - geany_r3060_no_gtk_marshal.patch). Patch for this is not really good because I'm not really knowing about automake & friends, and a make rule should be created to automatically create geany-marshal.[ch] from geany-marshal.list using glib-genmarshal at compile-time.
I attach a last patch, the global modifications I made do compile with --disable-deprecated with GTK+ 2.12 and GLib 2.16, if this is useful for anyone. Anything works but Scintilla, I've not understood the exact goal of calls using deprecated functions, and it haven't found an easy way to make it use newer functions.
Cheers, Colomban W.
PS: all three patches applies to r3083 too :)
Hi,
On Tue, 14 Oct 2008 03:59:26 +0200 Colomban Wendling ban-ubuntu@club-internet.fr wrote:
Hi all,
I've tried to compile Geany with the --disable-deprecated configure option, but I used… GTK+ 2.12 and GLib 2.16. Of course, it hasn't worked (mostly because of the new tooltip API and GObject generalization), but it's not really the reason of my mail.
That option is to disable deprecated elements in Geany's plugin API.
In src/utils.c, g_strcasecmp() is used, but it is deprecated since 2.2. I dunno if the reason why it was deprecated have any incidence on what it is used here (I think not), but it breaks build without deprecated symbols even with 2.6.
But using deprecated functions isn't really a problem until GTK 3.0, no? Anyway thanks for looking at it ;-)
An easy fix is to copy the function (with another name or so) in the Geany's source code.
Either that, or use a replacement GLib function for it. I probably wrote that code, but using the global tags autocompletion I didn't realize it was deprecated (maybe we could use GTK_DISABLE_DEPRECATED etc for tag file generation).
Another think I've noticed is that the tagmanager use GMemChunks for allocating memory, but the new GSlice API seems to be really faster (and simpler). What do you think about using it when compiling with GLib >= 2.10? It is easy to set up, just two macros to update. (patch attached - geany_r3060_tagmanager_gslice.patch)
Probably we could apply this after the 0.15 release.
Last thing: about marshal closures. I dunno if g_cclosure_marshal*() are present in GLib 2.6, but gtk_marshal*() are deprecated now, and I think glib-genmarshal is not a really recent tool. Then, it can be nice to move gtk_marshal*() to corresponding g_cclosure_marshal*() and/or to define which are needed in geany-marshal.[ch] files or so. (another patch attached - geany_r3060_no_gtk_marshal.patch).
No idea about this - but I guess we should apply it to fix deprecation problems.
(I really don't like GObject code in C, maybe we could use Vala for GeanyObject??)
Patch for this is not really good because I'm not really knowing about automake & friends, and a make rule should be created to automatically create geany-marshal.[ch] from geany-marshal.list using glib-genmarshal at compile-time.
Probably a normal Make rule could be put in src/Makefile.am to do that.
I attach a last patch, the global modifications I made do compile with --disable-deprecated with GTK+ 2.12 and GLib 2.16, if this is useful for anyone. Anything works but Scintilla, I've not understood the exact goal of calls using deprecated functions, and it haven't found an easy way to make it use newer functions.
gtk_widget_set_tooltip_text() was only added in GTK+ 2.12, we still support 2.6 (see HACKING). Maybe that function could be mimiced for GTK < 2.12 with something like ui_widget_set_tooltip_text().
To sum up, we can probably apply all these after the 0.15 release, but with some changes. Thanks for submitting them.
Regards, Nick
Hi,
Nick Treleaven a écrit :
That option is to disable deprecated elements in Geany's plugin API.
Why disable GTK+/GLib deprecated symbols when disabling Geany's ones? Anyway, an update of the configure help should be nice in this case, because the current message is "--disable-deprecated Disable deprecated GTK functions". It's not that clear at all, is it? But I think it is nice to be able to disable GTK+/GLib deprecated symbols too :)
But using deprecated functions isn't really a problem until GTK 3.0, no?
Yes, it's true. But I think there is nothing to loose to remove deprecated symbols; and having a clean code for now eases upgrading for the future, don't you think?
gtk_widget_set_tooltip_text() was only added in GTK+ 2.12, we still support 2.6 (see HACKING).
This is the reason why I've not proposed the full patch as a good fix. (offtopic: BTW, 2.6 compatibility is for Debian Sarge?)
Maybe that function could be mimiced for GTK < 2.12 with something like ui_widget_set_tooltip_text().
Hum, yes, it seems easy to write a function like this, but how to make Glade use it? An automatic replacement is not hard to set up (even though…), but can be a pain… a new step in UI updating. No?
Regards, Colomban
On Tue, 14 Oct 2008 18:08:10 +0200 Colomban Wendling ban-ubuntu@club-internet.fr wrote:
Hi,
Nick Treleaven a écrit :
That option is to disable deprecated elements in Geany's plugin API.
Why disable GTK+/GLib deprecated symbols when disabling Geany's ones? Anyway, an update of the configure help should be nice in this case, because the current message is "--disable-deprecated Disable deprecated GTK functions". It's not that clear at all, is it? But I think it is nice to be able to disable GTK+/GLib deprecated symbols too :)
Oops, sorry I hadn't checked it ;-) Enrico - shouldn't they be separate?
But using deprecated functions isn't really a problem until GTK 3.0, no?
Yes, it's true. But I think there is nothing to loose to remove deprecated symbols; and having a clean code for now eases upgrading for the future, don't you think?
Yes I agree, just wanted to check.
gtk_widget_set_tooltip_text() was only added in GTK+ 2.12, we still support 2.6 (see HACKING).
This is the reason why I've not proposed the full patch as a good fix. (offtopic: BTW, 2.6 compatibility is for Debian Sarge?)
Well, usually there's not much reason to raise the minimum requirements. Maybe they could be raised, but not up to 2.12 IMO.
Maybe that function could be mimiced for GTK < 2.12 with something like ui_widget_set_tooltip_text().
Hum, yes, it seems easy to write a function like this, but how to make Glade use it? An automatic replacement is not hard to set up (even though…), but can be a pain… a new step in UI updating. No?
Oh I hadn't thought about that ;-(
I could still apply the non-glade parts though.
Regards, Nick
On Tue, 14 Oct 2008 17:52:53 +0100 Nick Treleaven nick.treleaven@btinternet.com wrote:
That option is to disable deprecated elements in Geany's plugin API.
Why disable GTK+/GLib deprecated symbols when disabling Geany's ones? Anyway, an update of the configure help should be nice in this case, because the current message is "--disable-deprecated Disable deprecated GTK functions". It's not that clear at all, is it? But I think it is nice to be able to disable GTK+/GLib deprecated symbols too :)
Oops, sorry I hadn't checked it ;-) Enrico - shouldn't they be separate?
Actually I'm just completely wrong, this has nothing to do with the plugin API - sorry ;-/
Regards, Nick
On Tue, 14 Oct 2008 17:54:41 +0100, Nick Treleaven nick.treleaven@btinternet.com wrote:
On Tue, 14 Oct 2008 17:52:53 +0100 Nick Treleaven nick.treleaven@btinternet.com wrote:
That option is to disable deprecated elements in Geany's plugin API.
Why disable GTK+/GLib deprecated symbols when disabling Geany's ones? Anyway, an update of the configure help should be nice in this case, because the current message is "--disable-deprecated Disable deprecated GTK functions". It's not that clear at all, is it? But I think it is nice to be able to disable GTK+/GLib deprecated symbols too :)
Oops, sorry I hadn't checked it ;-) Enrico - shouldn't they be separate?
Actually I'm just completely wrong, this has nothing to do with the plugin API - sorry ;-/
Yeah :). The help text for this option is completely correct and IIRC this option is older than Geany's plugin API. I added it long time ago more or less just out of curiosity to check what and how Geany compile with these flags set.
We could discuss about the relevance of this option but well, there are more important things to talk about. It just doesn't harm as long as nobody uses it :). If you want to remove it, feel free to do so.
Regards, Enrico
On Wed, 15 Oct 2008 14:57:01 +0200 Enrico Tröger enrico.troeger@uvena.de wrote:
We could discuss about the relevance of this option but well, there are more important things to talk about. It just doesn't harm as long as nobody uses it :). If you want to remove it, feel free to do so.
No need to remove it, I have no idea why I got it wrong. Sorry for all the trouble.
It should be more useful soon because of the GTK 3.0 release.
Regards, Nick
On Wed, 15 Oct 2008 16:56:44 +0100, Nick Treleaven nick.treleaven@btinternet.com wrote:
On Wed, 15 Oct 2008 14:57:01 +0200 Enrico Tröger enrico.troeger@uvena.de wrote:
We could discuss about the relevance of this option but well, there are more important things to talk about. It just doesn't harm as long as nobody uses it :). If you want to remove it, feel free to do so.
No need to remove it, I have no idea why I got it wrong. Sorry for all the trouble.
No problem here :)
It should be more useful soon because of the GTK 3.0 release.
Soon? Almost about 11 months...:)
Regards, Enrico
On Tue, 14 Oct 2008 18:08:10 +0200, Colomban Wendling ban-ubuntu@club-internet.fr wrote:
But using deprecated functions isn't really a problem until GTK 3.0, no?
Yes, it's true. But I think there is nothing to loose to remove deprecated symbols; and having a clean code for now eases upgrading for the future, don't you think?
gtk_widget_set_tooltip_text() was only added in GTK+ 2.12, we still support 2.6 (see HACKING).
This is the reason why I've not proposed the full patch as a good fix. (offtopic: BTW, 2.6 compatibility is for Debian Sarge?)
Not necessarily, just in case someone can't use a newer GTK version for whatever reason. For instance, a week ago I got an email from an user who tried to cross-compile Geany with ScratchBox, AFAIK it's a toolchain for an eBook or anything. Anyway, this toolchain has GTK 2.6 and the guy was happy that he sucessfully could build Geany with it.
Maybe that function could be mimiced for GTK < 2.12 with something like ui_widget_set_tooltip_text().
Hum, yes, it seems easy to write a function like this, but how to make Glade use it? An automatic replacement is not hard to set up (even though…), but can be a pain… a new step in UI updating. No?
'automatic replacement' of automatically generated code? No, thanks.
Regards, Enrico
On Tue, 14 Oct 2008 15:38:27 +0100, Nick Treleaven nick.treleaven@btinternet.com wrote:
In src/utils.c, g_strcasecmp() is used, but it is deprecated since 2.2. I dunno if the reason why it was deprecated have any incidence on what it is used here (I think not), but it breaks build without deprecated symbols even with 2.6.
But using deprecated functions isn't really a problem until GTK 3.0, no? Anyway thanks for looking at it ;-)
Yeah, Colomban thanks for your efforts!
Another think I've noticed is that the tagmanager use GMemChunks for allocating memory, but the new GSlice API seems to be really faster (and simpler). What do you think about using it when compiling with GLib >= 2.10? It is easy to set up, just two macros to update. (patch attached - geany_r3060_tagmanager_gslice.patch)
Probably we could apply this after the 0.15 release.
Yes, this is the only thing we really should take as it doesn't change too much and probably gives a small performance boost.
Last thing: about marshal closures. I dunno if g_cclosure_marshal*() are present in GLib 2.6, but gtk_marshal*() are deprecated now, and I think glib-genmarshal is not a really recent tool. Then, it can be nice to move gtk_marshal*() to corresponding g_cclosure_marshal*() and/or to define which are needed in geany-marshal.[ch] files or so. (another patch attached - geany_r3060_no_gtk_marshal.patch).
No idea about this - but I guess we should apply it to fix deprecation problems.
(I really don't like GObject code in C, maybe we could use Vala for GeanyObject??)
I really don't like using anything other than C to write C (except for Glade :D). Seriously, before I state that I don't like Vala, Nick, could you give some details about it? Just an obvious disadvantage: vala would cause another build dependency (for developers, in any case for me :D). But we all have 'glib-genmarshal' already installed.
But I doubt glib-genmarshal isn't a 'recent tool'. What is this statement based on?At least it's the common way to generate marshallers files in a couple of projects I've seen. I guess at some point we need to write or generate marshallers as GTK only provides a few signatures and when we add more signals to GeanyObject we might need own ones. Generating them sould be done with glib-genmarshal IMO but we also could them by hand as they don't need to be updated once they are written.
I attach a last patch, the global modifications I made do compile with --disable-deprecated with GTK+ 2.12 and GLib 2.16, if this is useful for anyone. Anything works but Scintilla, I've not understood the exact goal of calls using deprecated functions, and it haven't found an easy way to make it use newer functions.
gtk_widget_set_tooltip_text() was only added in GTK+ 2.12, we still support 2.6 (see HACKING). Maybe that function could be mimiced for GTK < 2.12 with something like ui_widget_set_tooltip_text().
Why? GTK 2.12+ also supports the old, deprecated tooltips API. What is the advantage in adding more code, more #ifdefs just to get the same behaviour? In another post of this thread you told something like 'removing deprecated API results in cleaner code'. This is basically true and a good idea. BUT it more or less only results in more #ifdefs and duplicate code for old and new API.
We already have a bunch of #ifdefs related to different GTK features from versions above 2.6 and IMO we don't need more. Especially for the tooltips API thing, changing it only causes more code, more work, not to mention the code generated from Glade. But there would be no real benefit, tooltips will work in any way.
I think the "real" solution to this topic would be to increase the minimum GTK requirement and so drop old API. But I would like to keep the minimum requirements as low as possible as long it wouldn't cause other problems like breakge of anything. But this won't happen until GTK 3.2 (even GTK 3.0 will be compatible with 2.x series). And GTK 3.0 is not very near, 2.16 is planned for September 2009, AFAIK.
To sum up, we can probably apply all these after the 0.15 release, but with some changes. Thanks for submitting them.
I don't think so, at least I don't see a need for this except for the tagmanager patch.
Regards, Enrico
On Wed, 15 Oct 2008 15:32:24 +0200 Enrico Tröger enrico.troeger@uvena.de wrote:
(I really don't like GObject code in C, maybe we could use Vala for GeanyObject??)
I really don't like using anything other than C to write C (except for Glade :D). Seriously, before I state that I don't like Vala, Nick, could you give some details about it? Just an obvious disadvantage: vala would cause another build dependency (for developers, in any case for me :D). But we all have 'glib-genmarshal' already installed.
Well, I haven't had time to investigate using Vala yet, but:
* Using Vala for GeanyObject would mean we wouldn't need to touch the geanyobject.[hc] files, which are ugly to maintain. It supports GObject signals in the language AFAIR.
* Developers would only need to install Vala if they were going to add a GeanyObject signal, an uncommon occurrence. The geanyobject.[hc] files can stay in SVN.
But as I said, I don't know if it would work yet.
Regards, Nick
On Wed, 15 Oct 2008 17:03:08 +0100, Nick Treleaven nick.treleaven@btinternet.com wrote:
On Wed, 15 Oct 2008 15:32:24 +0200 Enrico Tröger enrico.troeger@uvena.de wrote:
(I really don't like GObject code in C, maybe we could use Vala for GeanyObject??)
I really don't like using anything other than C to write C (except for Glade :D). Seriously, before I state that I don't like Vala, Nick, could you give some details about it? Just an obvious disadvantage: vala would cause another build dependency (for developers, in any case for me :D). But we all have 'glib-genmarshal' already installed.
Well, I haven't had time to investigate using Vala yet, but:
- Using Vala for GeanyObject would mean we wouldn't need to touch the
geanyobject.[hc] files, which are ugly to maintain. It supports GObject signals in the language AFAIR.
I don't think these files are ugly to maintain. The GObject system is pretty straightforward once you got familiar with it. Yes, it's not "real" OOP but it's ok for C and without it we couldn't use GTK at all :).
- Developers would only need to install Vala if they were going to add
a GeanyObject signal, an uncommon occurrence. The geanyobject.[hc] files can stay in SVN.
Yes, I know this but this still affects me at some point :). I just don't like to install another compiler, learn another language and use it to generate code we could write by hand (or let generate by glib-genmarschal). OTOH, if it's easy to use and really has some advantages over glib-genmarschal, I'm willing to change my opinion :).
Regards, Enrico
On Wed, 15 Oct 2008 18:35:07 +0200 Enrico Tröger enrico.troeger@uvena.de wrote:
OTOH, if it's easy to use and really has some advantages over glib-genmarschal, I'm willing to change my opinion :).
OK, well first I'll try writing some Vala to get an idea about it. Maybe I'll try writing a plugin with it.
Regards, Nick
Enrico Tröger a écrit :
- Developers would only need to install Vala if they were going to add
a GeanyObject signal, an uncommon occurrence. The geanyobject.[hc] files can stay in SVN.
Yes, I know this but this still affects me at some point :). I just don't like to install another compiler, learn another language and use it to generate code we could write by hand (or let generate by glib-genmarschal). OTOH, if it's easy to use and really has some advantages over glib-genmarschal, I'm willing to change my opinion :).
I agree with Enrico.
But if Vala has some real advantages, take care it generates 2.6 compatible code ;)
Regards, Colomban
On Wed, 15 Oct 2008 19:23:27 +0200 Colomban Wendling ban-ubuntu@club-internet.fr wrote:
But if Vala has some real advantages, take care it generates 2.6 compatible code ;)
Vala is very recent, so it's unlikely they would make it generate deprecated GObject code.
Anyway it was just an idea, as I'm sure a geanyobject.vala file would be about 10 lines and very elegant too. But maybe it's not suitable for Geany, not sure yet.
BTW, I'm sure the geanyobject.[hc] generated by Vala would be no better than existing code or code from the patch (in fact probably worse), but we wouldn't have to read it so who cares.
Regards, Nick
On Wed, 15 Oct 2008 15:32:24 +0200, Enrico Tröger enrico.troeger@uvena.de wrote:
this won't happen until GTK 3.2 (even GTK 3.0 will be compatible with 2.x series). And GTK 3.0 is not very near, 2.16 is planned for
This is not true. GTK 3.0 will break API compatibility, obviously. Sorry.
Regards, Enrico
On Wed, 15 Oct 2008 15:32:24 +0200 Enrico Tröger enrico.troeger@uvena.de wrote:
gtk_widget_set_tooltip_text() was only added in GTK+ 2.12, we still support 2.6 (see HACKING). Maybe that function could be mimiced for GTK < 2.12 with something like ui_widget_set_tooltip_text().
Why? GTK 2.12+ also supports the old, deprecated tooltips API. What is the advantage in adding more code, more #ifdefs just to get the same behaviour?
So that users with GTK >= 2.12 don't build with the deprecated tooltip function we currently use.
I don't see any harm in switching the non-Glade code to use ui_widget_set_tooltip_text(), as this is actually neater as the caller doesn't need to get the GtkTooltips object.
I think the "real" solution to this topic would be to increase the minimum GTK requirement and so drop old API. But I would like to keep the minimum requirements as low as possible as long it wouldn't cause other problems like breakge of anything. But this won't happen until GTK 3.2 (even GTK 3.0 will be compatible with 2.x series). And GTK 3.0 is not very near, 2.16 is planned for September 2009, AFAIK.
Well, we can still use some of the work Columban's done so far IMO.
Regards, Nick
On Wed, 15 Oct 2008 17:07:08 +0100, Nick Treleaven nick.treleaven@btinternet.com wrote:
On Wed, 15 Oct 2008 15:32:24 +0200 Enrico Tröger enrico.troeger@uvena.de wrote:
gtk_widget_set_tooltip_text() was only added in GTK+ 2.12, we still support 2.6 (see HACKING). Maybe that function could be mimiced for GTK < 2.12 with something like ui_widget_set_tooltip_text().
Why? GTK 2.12+ also supports the old, deprecated tooltips API. What is the advantage in adding more code, more #ifdefs just to get the same behaviour?
So that users with GTK >= 2.12 don't build with the deprecated tooltip function we currently use.
I don't see any harm in switching the non-Glade code to use ui_widget_set_tooltip_text(), as this is actually neater as the caller doesn't need to get the GtkTooltips object.
But it doesn't hurt to build the old API and AFAIK there is no noticeable (dis)advantage. The only change is more code, ok and a little nicer code for the existing non-Glade tooltips. If you really want, do it. It's probably not that worse as I told but still not strictly necessary.
I think the "real" solution to this topic would be to increase the minimum GTK requirement and so drop old API. But I would like to keep the minimum requirements as low as possible as long it wouldn't cause other problems like breakge of anything. But this won't happen until GTK 3.2 (even GTK 3.0 will be compatible with 2.x series). And GTK 3.0 is not very near, 2.16 is planned for September 2009, AFAIK.
Well, we can still use some of the work Columban's done so far IMO.
As I told, the tagmanager patch is cool.
About the g_strcasecmp() problem: I don't think the right solution is to copy the old, broken code from GLib into Geany. As the docs mention, there is a reason why this function is deprecated and should not used. IMO we should rewrite the code which uses this function with the alternative functions mentioned in the docs.
gtk_widget_ref() vs g_object_ref() is ok, obviously. These are from copy&paste code from Glade :).
Regards, Enrico
On Wed, 15 Oct 2008 18:30:42 +0200 Enrico Tröger enrico.troeger@uvena.de wrote:
On Wed, 15 Oct 2008 17:07:08 +0100, Nick Treleaven nick.treleaven@btinternet.com wrote:
On Wed, 15 Oct 2008 15:32:24 +0200 Enrico Tröger enrico.troeger@uvena.de wrote:
gtk_widget_set_tooltip_text() was only added in GTK+ 2.12, we still support 2.6 (see HACKING). Maybe that function could be mimiced for GTK < 2.12 with something like ui_widget_set_tooltip_text().
Why? GTK 2.12+ also supports the old, deprecated tooltips API. What is the advantage in adding more code, more #ifdefs just to get the same behaviour?
So that users with GTK >= 2.12 don't build with the deprecated tooltip function we currently use.
I don't see any harm in switching the non-Glade code to use ui_widget_set_tooltip_text(), as this is actually neater as the caller doesn't need to get the GtkTooltips object.
But it doesn't hurt to build the old API and AFAIK there is no noticeable (dis)advantage. The only change is more code, ok and a little nicer code for the existing non-Glade tooltips.
Well, at some point we'll need to change the code, whether we raise the required GTK version or not.
(It would actually be less code because of all the calls to get the GtkTooltips object.)
About the g_strcasecmp() problem: I don't think the right solution is to copy the old, broken code from GLib into Geany. As the docs mention, there is a reason why this function is deprecated and should not used. IMO we should rewrite the code which uses this function with the alternative functions mentioned in the docs.
I agree.
Regards, Nick
On Wed, 15 Oct 2008 18:30:42 +0200, Enrico Tröger enrico.troeger@uvena.de wrote:
On Wed, 15 Oct 2008 17:07:08 +0100, Nick Treleaven nick.treleaven@btinternet.com wrote:
On Wed, 15 Oct 2008 15:32:24 +0200 Enrico Tröger enrico.troeger@uvena.de wrote:
gtk_widget_set_tooltip_text() was only added in GTK+ 2.12, we still support 2.6 (see HACKING). Maybe that function could be mimiced for GTK < 2.12 with something like ui_widget_set_tooltip_text().
Why? GTK 2.12+ also supports the old, deprecated tooltips API. What is the advantage in adding more code, more #ifdefs just to get the same behaviour?
So that users with GTK >= 2.12 don't build with the deprecated tooltip function we currently use.
I don't see any harm in switching the non-Glade code to use ui_widget_set_tooltip_text(), as this is actually neater as the caller doesn't need to get the GtkTooltips object.
But it doesn't hurt to build the old API and AFAIK there is no noticeable (dis)advantage. The only change is more code, ok and a little nicer code for the existing non-Glade tooltips. If you really want, do it. It's probably not that worse as I told but still not strictly necessary.
I think the "real" solution to this topic would be to increase the minimum GTK requirement and so drop old API. But I would like to keep the minimum requirements as low as possible as long it wouldn't cause other problems like breakge of anything. But this won't happen until GTK 3.2 (even GTK 3.0 will be compatible with 2.x series). And GTK 3.0 is not very near, 2.16 is planned for September 2009, AFAIK.
Well, we can still use some of the work Columban's done so far IMO.
As I told, the tagmanager patch is cool.
Committed, thanks.
gtk_widget_ref() vs g_object_ref() is ok, obviously. These are from copy&paste code from Glade :).
Done.
I also added some code to handle PATH_MAX if it's not defined and so Geany builds (again?) with gcc -ansi.
About the g_strcasecmp() problem: I don't think the right solution is to copy the old, broken code from GLib into Geany. As the docs mention, there is a reason why this function is deprecated and should not used. IMO we should rewrite the code which uses this function with the alternative functions mentioned in the docs.
Update: Yesterday, I did some work on this and wrote utils_str_casecmp() which uses g_utf8_casefold() and g_utf8_collate() as suggested in the GLib API docs. It seems to work, for simple examples actually better than g_strcasecmp(). But the new code is noticeably slower, about factor 100 (!).
When starting Geany with a fresh configuration and opening about 30 files with different filetypes, we almost have 1000 calls to this function (by only counting calls which actually pass g_utf8_collate()). (we could eliminate many of these calls by changing utils_atob() to be case-sensitive or something smarter, this is used when reading the filetype definition files to evaluate false/true strings into booleans, maybe it's enough to check for true and TRUE, and treat anything else as false.)
I've attached a testcase with some simple test strings to test the correctness of both implementations. These show the new code works better but please note that the code uses only simple example strings, without more complex unicode characters).
The testcase additionally does some speed comparisons of both functions, so you can easily see the big difference in execution time. Simply change the value of the CALLS macro to change the amount of calls of both functions. Note: the gap in execution time of both implementations might be even bigger if the test strings are not encoded in UTF-8 but any other encoding and so have to be passed through g_locale_to_utf8().
Conclusion: I'm not sure anymore if it's worth to use this code because of the execution time. Assuming (read: hoping) that most users will use Ascii-only characters in filenames (for which the code is mostly used) it maybe isn't worth. OTOH utils_str_casecmp() can surely be still improved to get it run faster.
Any ideas?
Regards, Enrico
On Thu, 23 Oct 2008 18:57:09 +0200, Enrico Tröger enrico.troeger@uvena.de wrote:
About the g_strcasecmp() problem: I don't think the right solution is to copy the old, broken code from GLib into Geany. As the docs mention, there is a reason why this function is deprecated and should not used. IMO we should rewrite the code which uses this function with the alternative functions mentioned in the docs.
Update: Yesterday, I did some work on this and wrote utils_str_casecmp() which uses g_utf8_casefold() and g_utf8_collate() as suggested in the GLib API docs. It seems to work, for simple examples actually better than g_strcasecmp(). But the new code is noticeably slower, about factor 100 (!).
When starting Geany with a fresh configuration and opening about 30 files with different filetypes, we almost have 1000 calls to this function (by only counting calls which actually pass g_utf8_collate()). (we could eliminate many of these calls by changing utils_atob() to be case-sensitive or something smarter, this is used when reading the filetype definition files to evaluate false/true strings into booleans, maybe it's enough to check for true and TRUE, and treat anything else as false.)
I've attached a testcase with some simple test strings to test the correctness of both implementations. These show the new code works better but please note that the code uses only simple example strings, without more complex unicode characters).
The testcase additionally does some speed comparisons of both functions, so you can easily see the big difference in execution time. Simply change the value of the CALLS macro to change the amount of calls of both functions. Note: the gap in execution time of both implementations might be even bigger if the test strings are not encoded in UTF-8 but any other encoding and so have to be passed through g_locale_to_utf8().
Conclusion: I'm not sure anymore if it's worth to use this code because of the execution time. Assuming (read: hoping) that most users will use Ascii-only characters in filenames (for which the code is mostly used) it maybe isn't worth. OTOH utils_str_casecmp() can surely be still improved to get it run faster.
There is another possibility :
see the attached testcase, an updated version of the first one. It has an additional variant of the code, utils_str_casecmp_easy() which simply converts the strings to compare into lowercase using g_utf8_strdown() and then compare them with strcmp(). This is to some extend also 'broken' because it doesn't take different locale-specific case sorting rules into account. But therefore it is noticeable faster than the full variant. It's only about ten times slower than g_strcasecmp() which is IMO not that bad and so I'm thinking this could go in.
Regards, Enrico
Enrico Tröger a écrit :
On Thu, 23 Oct 2008 18:57:09 +0200, Enrico Tröger enrico.troeger@uvena.de wrote:
About the g_strcasecmp() problem: I don't think the right solution is to copy the old, broken code from GLib into Geany. As the docs mention, there is a reason why this function is deprecated and should not used. IMO we should rewrite the code which uses this function with the alternative functions mentioned in the docs.
Update: Yesterday, I did some work on this and wrote utils_str_casecmp() which uses g_utf8_casefold() and g_utf8_collate() as suggested in the GLib API docs. It seems to work, for simple examples actually better than g_strcasecmp(). But the new code is noticeably slower, about factor 100 (!).
When starting Geany with a fresh configuration and opening about 30 files with different filetypes, we almost have 1000 calls to this function (by only counting calls which actually pass g_utf8_collate()). (we could eliminate many of these calls by changing utils_atob() to be case-sensitive or something smarter, this is used when reading the filetype definition files to evaluate false/true strings into booleans, maybe it's enough to check for true and TRUE, and treat anything else as false.)
I've attached a testcase with some simple test strings to test the correctness of both implementations. These show the new code works better but please note that the code uses only simple example strings, without more complex unicode characters).
The testcase additionally does some speed comparisons of both functions, so you can easily see the big difference in execution time. Simply change the value of the CALLS macro to change the amount of calls of both functions. Note: the gap in execution time of both implementations might be even bigger if the test strings are not encoded in UTF-8 but any other encoding and so have to be passed through g_locale_to_utf8().
Conclusion: I'm not sure anymore if it's worth to use this code because of the execution time. Assuming (read: hoping) that most users will use Ascii-only characters in filenames (for which the code is mostly used) it maybe isn't worth. OTOH utils_str_casecmp() can surely be still improved to get it run faster.
There is another possibility :
see the attached testcase, an updated version of the first one. It has an additional variant of the code, utils_str_casecmp_easy() which simply converts the strings to compare into lowercase using g_utf8_strdown() and then compare them with strcmp(). This is to some extend also 'broken' because it doesn't take different locale-specific case sorting rules into account. But therefore it is noticeable faster than the full variant. It's only about ten times slower than g_strcasecmp() which is IMO not that bad and so I'm thinking this could go in.
Regards, Enrico
Hi,
I think this is a good compromise, and I think most people using Geany will not be annoyed by the approximation since most programmers just use full ASCII filenames. And even with non-ASCII filenames, the approximation is IMO very acceptable.
Regards, Colomban
Enrico Tröger a écrit :
Yeah, Colomban thanks for your efforts!
It's nothing, I thank you of always improving this wonderful tool that Geany is! ;)
I really don't like using anything other than C to write C (except for Glade :D). Seriously, before I state that I don't like Vala, Nick, could you give some details about it? Just an obvious disadvantage: vala would cause another build dependency (for developers, in any case for me :D). But we all have 'glib-genmarshal' already installed.
But I doubt glib-genmarshal isn't a 'recent tool'. What is this statement based on?At least it's the common way to generate marshallers files in a couple of projects I've seen. I guess at some point we need to write or generate marshallers as GTK only provides a few signatures and when we add more signals to GeanyObject we might need own ones. Generating them sould be done with glib-genmarshal IMO but we also could them by hand as they don't need to be updated once they are written.
glib-genmarshal exists at least since 2.6, I dunno for older versions. I think I don't really understand what you would mean: I understand you think using specific marshallers for Genay is a good idea (and will probably be needed a day or another), but that you don't want use it before you need one not provided by GTK? Anyway, I think it is better to always generate it at compile time, then if generated files changes through different versions of the GLib, it will be done transparently.
I don't think so, at least I don't see a need for this except for the tagmanager patch.
For the marshallers, IMHO it is not a need, but a clean way to make the code highly portable through GTK versions.
Regards, Colomban
On Wed, 15 Oct 2008 19:15:28 +0200, Colomban Wendling ban-ubuntu@club-internet.fr wrote:
Enrico Tröger a écrit :
Yeah, Colomban thanks for your efforts!
It's nothing, I thank you of always improving this wonderful tool that Geany is! ;)
I really don't like using anything other than C to write C (except for Glade :D). Seriously, before I state that I don't like Vala, Nick, could you give some details about it? Just an obvious disadvantage: vala would cause another build dependency (for developers, in any case for me :D). But we all have 'glib-genmarshal' already installed.
But I doubt glib-genmarshal isn't a 'recent tool'. What is this statement based on?At least it's the common way to generate marshallers files in a couple of projects I've seen. I guess at some point we need to write or generate marshallers as GTK only provides a few signatures and when we add more signals to GeanyObject we might need own ones. Generating them sould be done with glib-genmarshal IMO but we also could them by hand as they don't need to be updated once they are written.
glib-genmarshal exists at least since 2.6, I dunno for older versions. I think I don't really understand what you would mean: I understand you think using specific marshallers for Genay is a good idea (and will probably be needed a day or another), but that you don't want use it before you need one not provided by GTK?
No, there is no question that we should create own marshallers *now* and not sometime in the future. Sorry if I was unclear.
The question is just how do we create them. - generate them with glib-genmarshal - generate them with vala - write them by hand - something else :)
Let's see what Nick experiences with Vala and then continue discussing.
Regards, Enrico
On Wed, 15 Oct 2008 19:15:28 +0200, Colomban Wendling ban-ubuntu@club-internet.fr wrote:
Enrico Tröger a écrit :
Yeah, Colomban thanks for your efforts!
It's nothing, I thank you of always improving this wonderful tool that Geany is! ;)
I really don't like using anything other than C to write C (except for Glade :D). Seriously, before I state that I don't like Vala, Nick, could you give some details about it? Just an obvious disadvantage: vala would cause another build dependency (for developers, in any case for me :D). But we all have 'glib-genmarshal' already installed.
But I doubt glib-genmarshal isn't a 'recent tool'. What is this statement based on?At least it's the common way to generate marshallers files in a couple of projects I've seen. I guess at some point we need to write or generate marshallers as GTK only provides a few signatures and when we add more signals to GeanyObject we might need own ones. Generating them sould be done with glib-genmarshal IMO but we also could them by hand as they don't need to be updated once they are written.
glib-genmarshal exists at least since 2.6, I dunno for older versions. I think I don't really understand what you would mean: I understand you think using specific marshallers for Genay is a good idea (and will probably be needed a day or another), but that you don't want use it before you need one not provided by GTK? Anyway, I think it is better to always generate it at compile time, then if generated files changes through different versions of the GLib, it will be done transparently.
I don't think so, at least I don't see a need for this except for the tagmanager patch.
For the marshallers, IMHO it is not a need, but a clean way to make the code highly portable through GTK versions.
As a solution for the middle term, I replaced the gtk_marshal_* calls with appropriate g_cclosure_marshal_* calls which are present in GLib 2.6 according to [1].
For the "update-editor-menu" signal I added a hand-crafted geany_cclosure_marshal_VOID__STRING_INT_POINTER type. This does the trick for now and keeps us from adding glib-genmarschal code to the build system.
But of course, if/when we add more signals with non-standard callback signatures it's better to let the marshalers be generated instead of writing the code for each by hand. If it's easily possible with Vala, ok, as long as it is maintainer-only, so no user, not even SVN users, should need to generate them (similar to how we handle the generated HTML docs).
[1] http://svn.gnome.org/viewvc/glib/tags/GLIB_2_6_0/gobject/gmarshal.list?revis...
Regards, Enrico