[Geany-devel] About disabling GTK+/GLib deprecated symbols

Enrico Tröger enrico.troeger at xxxxx
Thu Oct 23 16:57:09 UTC 2008


On Wed, 15 Oct 2008 18:30:42 +0200, Enrico Tröger
<enrico.troeger at uvena.de> wrote:

>On Wed, 15 Oct 2008 17:07:08 +0100, Nick Treleaven
><nick.treleaven at btinternet.com> wrote:
>
>>On Wed, 15 Oct 2008 15:32:24 +0200
>>Enrico Tröger <enrico.troeger at 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

-- 
Get my GPG key from http://www.uvena.de/pub.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: strcasetest.c
Type: text/x-csrc
Size: 3359 bytes
Desc: not available
URL: <http://lists.geany.org/pipermail/devel/attachments/20081023/d5a6d397/attachment.c>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://lists.geany.org/pipermail/devel/attachments/20081023/d5a6d397/attachment.pgp>


More information about the Devel mailing list