See #952 for a version based on @codebrainz suggestion, which I like best.
It's non-intrusive, does the job and makes sense (as the plugin *has* to
support deprecated APIs so long as they work)
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly
I don't see a good solution for this. The gtk people keep on deprecating stuff.
At the moment I will not continue work on this - I more tend to wait until gtk2
support is dropped and only one version needs to be supported.
--
You are receiving this because you are subscribed to this thread.
I really don't like this PR: too much code, too much copy, and all this for
getting rid of deprecation warnings -- where this code actually has to support
the deprecated API.
> **Edit:** I also just noticed the `G_GNUC_*_IGNORE_DEPRECATIONS` macro, maybe
> tricky stuff could be wrapped
> Also a little question regarding the plugin API: as the utils lib is not a
> registered plugin - how can I get a callback on closing of geany to free the
> memory allocated for the utils lib?
If this library was statically compiled into each plugin (don't think it is),
you could probably use
Probably this PR isn't the place for the resource management design discussion,
maybe create a separate issue for it.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
I have never used Openssl, but for libxml, as far as I remember either it
returns the memory (the document tree) to the caller, or the caller has to do
new/free calls like for newcontext paired with freecontext.
To share some resource between plugins reference count it and have plugins free
> You probably shouldn't keep memory in any library, not just yours
I am not sure if that is generally done. I didn't check the internals of the
libs but I guess libs like OpenSSL and LibXML2 (which have init functions) will
reserve memory for themselves. Also I do not want to create the
On the library memory issue. You probably shouldn't keep memory in any
library, not just yours, libraries should always return allocated memory to the
caller to dispose of, you never know if the library is going to ever be entered
again.
--
You are receiving this because you are subscribed
I would really like to fix it for geany-plugins at least. Sometimes there is
just a warning and you can run geany and the plugins - but that doesn't mean
that the GUI works as it should under gtk3.
--
You are receiving this because you are subscribed to this thread.
Reply to this email
> All over the place, its only deprecated, not removed in GTK3 so it still
> works.
And Geany itself is compiled with deprecation warnings off so you don't see it.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
> All over the place, its only deprecated, not removed in GTK3 so it still
> works.
Ok, that's why I see the stock-id's being returned as labels on GTK3. Then the
function I wrote is maybe the only solution to have some interworking with code
that uses the gtk2-stock-items and code that
> Is the geany core still using them on GTK3?
All over the place, its only deprecated, not removed in GTK3 so it still works.
Probably won't with GTK4 but its also probably not the only thing that will
break.
--
You are receiving this because you are subscribed to this thread.
Reply to this
> Also a little question regarding the plugin API: as the utils lib is not a
> registered plugin - how can I get a callback on closing of geany to free the
> memory allocated for the utils lib?
There is a "geany-startup-complete" signal, but I don't think there is an
equivalent
13 matches
Mail list logo
