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

[Enrico Tröger]

On Tue, 14 Oct 2008 15:38:27 +0100, Nick Treleaven
<nick.treleaven at 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

-- 
Get my GPG key from http://www.uvena.de/pub.asc

-------------- 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/20081015/2324f6c7/attachment.pgp>