On 6 April 2013 00:02, William Fraser william.fraser@virgin.net wrote:
I attached an int to each scintilla object to keep track of what's been assigned in my markers plugin. The only problem was that some markers are used by scintilla, so any plugin would have to make note of which ones were being used by the editor (with the problem that you would have to update plugins if editor changed) or, you would have to submit code to scintilla so that it also used the uniform resource allocation.
Hi William,
Which plugin is that? And how do you know that say the bookmarks plugin isn't using that marker already? Thats the sort of problem this is to solve.
Cheers Lex
-------- Original Message --------
Lex Trotman elextr@gmail.com wrote:
Update:
Matthew has pointed out on IRC that the markers and indicators are per scintilla object, not global. He has a suggested alternative API which he will post after its tested.
Cheers Lex
On 5 April 2013 13:09, Lex Trotman elextr@gmail.com wrote:
There are several plugins that share limited resources, such as scintilla markers and indicators.
At the moment there is no coordination for using those resources so plugins can interfere with one another and possibly with Geany.
The only common thing between plugins and Geany is Geany, so this is a proposal to add a resources management interface to Geany.
The proposed interface is below, I have tried to make it so it is easy to expand to resources that are not integers (markers and indicators are all integers)
enum resource_type { GEANY_RESOURCE_MARKER, GEANY_RESOURCE_INDICATOR }; gboolean alloc_int_resource( enum resource_type, int* resource_num ); void free_int_resource( int resource_num );
This allows extra resources to be added without ABI changes (so long as they are added to the end of the enum).
If (when) other types of resource need managing then extra functions can be added again without breaking the ABI.
Automatic release is not suggested because that prevents use of RAII and similar management schemes in C++ or GC for other plugin languages. For plain C plugins just call free_int_resource in the plugin_cleanup function.
Any simpler, more flexible suggestions?
Cheers Lex
Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
On 06/04/2013, Lex Trotman elextr@gmail.com wrote:
On 6 April 2013 00:02, William Fraser william.fraser@virgin.net wrote:
I attached an int to each scintilla object to keep track of what's been assigned in my markers plugin. The only problem was that some markers are used by scintilla, so any plugin would have to make note of which ones were being used by the editor (with the problem that you would have to update plugins if editor changed) or, you would have to submit code to scintilla so that it also used the uniform resource allocation.
Hi William,
Which plugin is that? And how do you know that say the bookmarks plugin isn't using that marker already? Thats the sort of problem this is to solve.
Cheers Lex
Hello Lex,
It is the GeanyNumberedBookmarks plugin that has to manage sharing markers with other plugins and the editor. I had to re-write it as some of the markers were clashing with another plugin (I forget which one).
The functions that handle keeping track of markers are GetMarkersUsed(), NextFreeMarker(), SetMarker(), and DeleteMarker().
To get around the problem of different scintilla editor instances, each of which could have more than one document open in them, I used the g_object_set_data() and g_object_get_data() functions to attach a pointer to an allocated piece of memory holding data on which markers I'm using per Scintilla editor object (I see if there is one allocated already and if not add one, thus ensuring only one per editor instance). As there are 32 markers I used a 32 bit int to hold which markers were being used.
Unfortunately it's a little more complex as other pluggins can also use the markers, as can the editor (some are documented as being in use:0 &1 for bookmarks & errors, 25 onwards for folds). So the NextFreeMarker() function in GeanyNumberedBookmarks thus only checks between 2 and 24 for free markers. I have assumed that anyone using a marker will likely set it to something other than the default of SC_MARK_CIRCLE, or at least followed documented good practice of resetting it to SC_MARK_AVAILABLE if they no longer need it. This is how I find unused markers.
However there are potential problems with this due to the assumptions. Problems that could arise include: Markers being used by another plugin (or the editor if it's use of markers changes) after GeanyNumberedBookmarks has started using them without checking to see if they are already in use, and not setting the marker to something other than SC_MARK_CIRCLE.
To get round these problem I can see only 3 options: 1) Each plugin manually setting their own markers as we do at the moment but with better co-ordination to avoid clashes, or to enable the user to set them manually in the pluggin settings. This is sort of what we have at the moment and is messy, and makes it difficult to maintain plugins, or develop new ones without clashing with existing plugins. It also has the downside of needing to check all pluggins if scintilla changes which markers it uses.
2) Submit a patch to Scintilla that adds functions similar to GetMarkersUsed(), NextFreeMarker(), SetMarker(), and DeleteMarker() that the editor, and any plugins would use. The downside of this is that they might not accept the patch, and that it would then mean that plugins using markers would only work with the version of Scintilla where the patch was accepted or later versions. It would be the neatest, and most robust solution.
3) Have plugin functions similar to GetMarkersUsed(), NextFreeMarker(), SetMarker(), and DeleteMarker() that any plugin has to call to use markers as part of the geany-plugins standard function calls. We would have to monitor Scintilla for changes to markers but would then mean that our plugins would play nicely with each other, and we could update/modify these functions independent of Scintilla. Also we would only have to changed the geany-plugins standard function if Scintilla's use of markers changed rather than having to re-write all the plugins. We also would not have to wait for any changes to Scintilla to propogate through the versions. This would probably be the fastest way of doing things.
There is no reason why we could not use a combined approach: submit a patch to Scintilla and in the meantime have our own functions until the changes to Scintilla were adopted.
Any plugins wide, or editor marker management functions would have to be thread safe to avoid clashes between plugins or the editor.
What do people think about these options? Does anyone have any other ideas?
William
P.S. sorry for delay in getting back, and for not doing much with my pluggins of late, but life is beyond busy at the moment & for the foreseeable future.
On 13-04-09 03:20 PM, WILLIAM FRASER wrote:
On 06/04/2013, Lex Trotman elextr@gmail.com wrote:
On 6 April 2013 00:02, William Fraser william.fraser@virgin.net wrote:
I attached an int to each scintilla object to keep track of what's been assigned in my markers plugin. The only problem was that some markers are used by scintilla, so any plugin would have to make note of which ones were being used by the editor (with the problem that you would have to update plugins if editor changed) or, you would have to submit code to scintilla so that it also used the uniform resource allocation.
Hi William,
Which plugin is that? And how do you know that say the bookmarks plugin isn't using that marker already? Thats the sort of problem this is to solve.
Cheers Lex
Hello Lex,
It is the GeanyNumberedBookmarks plugin that has to manage sharing markers with other plugins and the editor. I had to re-write it as some of the markers were clashing with another plugin (I forget which one).
The functions that handle keeping track of markers are GetMarkersUsed(), NextFreeMarker(), SetMarker(), and DeleteMarker().
To get around the problem of different scintilla editor instances, each of which could have more than one document open in them, I used the g_object_set_data() and g_object_get_data() functions to attach a pointer to an allocated piece of memory holding data on which markers I'm using per Scintilla editor object (I see if there is one allocated already and if not add one, thus ensuring only one per editor instance). As there are 32 markers I used a 32 bit int to hold which markers were being used.
Unfortunately it's a little more complex as other pluggins can also use the markers, as can the editor (some are documented as being in use:0 &1 for bookmarks & errors, 25 onwards for folds). So the NextFreeMarker() function in GeanyNumberedBookmarks thus only checks between 2 and 24 for free markers. I have assumed that anyone using a marker will likely set it to something other than the default of SC_MARK_CIRCLE, or at least followed documented good practice of resetting it to SC_MARK_AVAILABLE if they no longer need it. This is how I find unused markers.
However there are potential problems with this due to the assumptions. Problems that could arise include: Markers being used by another plugin (or the editor if it's use of markers changes) after GeanyNumberedBookmarks has started using them without checking to see if they are already in use, and not setting the marker to something other than SC_MARK_CIRCLE.
To get round these problem I can see only 3 options:
- Each plugin manually setting their own markers as we do at the
moment but with better co-ordination to avoid clashes, or to enable the user to set them manually in the pluggin settings. This is sort of what we have at the moment and is messy, and makes it difficult to maintain plugins, or develop new ones without clashing with existing plugins. It also has the downside of needing to check all pluggins if scintilla changes which markers it uses.
- Submit a patch to Scintilla that adds functions similar to
GetMarkersUsed(), NextFreeMarker(), SetMarker(), and DeleteMarker() that the editor, and any plugins would use. The downside of this is that they might not accept the patch, and that it would then mean that plugins using markers would only work with the version of Scintilla where the patch was accepted or later versions. It would be the neatest, and most robust solution.
- Have plugin functions similar to GetMarkersUsed(),
NextFreeMarker(), SetMarker(), and DeleteMarker() that any plugin has to call to use markers as part of the geany-plugins standard function calls. We would have to monitor Scintilla for changes to markers but would then mean that our plugins would play nicely with each other, and we could update/modify these functions independent of Scintilla. Also we would only have to changed the geany-plugins standard function if Scintilla's use of markers changed rather than having to re-write all the plugins. We also would not have to wait for any changes to Scintilla to propogate through the versions. This would probably be the fastest way of doing things.
There is no reason why we could not use a combined approach: submit a patch to Scintilla and in the meantime have our own functions until the changes to Scintilla were adopted.
Any plugins wide, or editor marker management functions would have to be thread safe to avoid clashes between plugins or the editor.
I don't think they'd need to be thread-safe, nothing else in Geany or the plugin API is.
What do people think about these options? Does anyone have any other ideas?
Here's the ideas I was working on: https://gist.github.com/codebrainz/a72b0c18669649ee7939
I still haven't tested it too much but I think the idea is pretty sound and flexible. It's quite like your #3 but a bit more generic and includes also a signal plugins can connect to in order to notify them when resources become available.
If you don't want to get bored reading the code, just jump to the /** doc-comments for descriptions of the functions.
P.S. The patch unnecessarily bumps the plugin ABI by mistake.
Cheers, Matthew Brush
William
P.S. sorry for delay in getting back, and for not doing much with my pluggins of late, but life is beyond busy at the moment & for the foreseeable future. _______________________________________________ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel