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