On 10/04/2013 22:49, Lex Trotman wrote:
It makes sense when the resource is only available per sci.
There is no "global" set of markers, just that Geany always set up the same set for its own use in each sci.
Even if a plugin uses the same markers in each sci, regardless of language or other settings, it still has to set them up and release them on each sci. It is more likely though that a plugin will only use markers on a few sci.
So the plugin will have to be allocating the resource per sci anyway, and it will need to track it, yes.
This is the way I have done it in numberedbookmarks. I use the g_object_set_data() and g_object_get_data() functions passing G_OBJECT(sci) as the first argument, thus attaching a pointer to a structure that can be used to keep track of resource use on a per sci object basis. Other than having to watch out for memory leaks of the structures when shutting down, I think that this is best option to track resource use. What's more, I'm no GTK expert and have not tried it, but but using g_object_set_data_full() would probably be an easy way to prevent memory leaks.
- If they are above the limit, check how much per-sci will improve
the things. If it's less than, say, 15%, per-sci makes no sense.
- If per-sci still seems reasonable, provide some logical to physical
mapping, so that the plugins woudn't need to remember each allocated resource separately for each sci.
Unless they are set and forget uses, the plugin still has to remember them to be able to use them.
If a you're going to create a structure holding handles to the resources used on a per sci object basis to ensure no clashes in resource use anyway, then it would be a simple matter to write a function returning the handle of a numbered resource. A plugin would not then have to remember which ones were allocated, but could simple call the function with the resource number and sci object, with the knowlage that if null were returned then the resource was not in use.
However I feel that this slightly goes against the ethos of geany and geany-plugins being as light-weight as possible by adding another function to the geany-plugins api that is not essential. A plugin writer would have insight into if a plugin needed to keep track of resource use or not (geany-plugins would be keeping track of which resources were in use or not anyway, so there is no need to replicate this if a plugin didn't need to remember this information once a resource had been established), and it would be a relatively simple matter of adding a simple way of keeping track of which resources a plugin uses. On the other hand, having such a simple function would keep plugins simpler, and thus less likely to contain any bugs.
William