There is a problem as I understand it with checking for the SC_MARK_AVAILABLE marker to see if a marker is available...
Markers seem by default to be set to 0 (SC_MARK_CIRCLE) by scintilla. So there is no way to tell if a marker is being used with the default marker icon (SC_MARK_CIRCLE), or is not being used. The following code dropped in anywhere that it will get run (I placed it in the DefineMarkers function of geanynummberedbookmarks) will demonstrate:
GtkWidget *dialog; gchar temp[10000]; gint m[32]; for(i=0;i<32;i++) m[i]=scintilla_send_message(sci,SCI_MARKERSYMBOLDEFINED,i,0); sprintf(temp,"%d %d %d %d %d %d %d %d\n%d %d %d %d %d %d %d %d\n%d %d %d %d %d %d %d %d\n%d %d %d %d %d %d %d %d",m[0],m[1],m[2],m[3],m[4],m[5],m[6],m[7],m[8],m[9],m[10],m[11],m[12],m[13],m[14],m[15],m[16],m[17],m[18],m[19],m[20],m[21],m[22],m[23],m[24],m[25],m[26],m[27],m[28],m[29],m[30],m[31]); dialog=gtk_message_dialog_new(GTK_WINDOW(geany->main_widgets->window), GTK_DIALOG_DESTROY_WITH_PARENT, GTK_MESSAGE_ERROR, GTK_BUTTONS_NONE, "%s",temp); gtk_dialog_add_button(GTK_DIALOG(dialog),_("_Okay"),GTK_RESPONSE_OK); gtk_dialog_run(GTK_DIALOG(dialog)); gtk_widget_destroy(dialog); g_free(temp);
This displays the value of each marker, and those that aren't being used for anything are showing up as 0, and not 28 (SC_MARK_AVAILABLE).
I can see 4 options, and I'd like to see what people think about them, or if they can think of any better solutions: 1) agree between plugin developers which markers they will use and use them staticly (as we are now, but ensuring they don't overlap) 2) change scintilla or geany so that markers are set to SC_MARK_AVAILABLE when it is initialised. 3) Have a plugin that is run before any others or some static code usable by all plugins that sets all editor unused markers to SC_MARK_AVAILABLE ready for the other plugins. 4) Have an option in the preferences for each plugin that uses markers to allow users to define which markers are to be used by that plugin.
There are pros & cons to each of these:
With option 1 we will probably run out of markers for anyone wanting to develop a new plugin. Also would have to change code if editor's use of markers changed. It is easiest to implement here and now.
Option 2 would be the most versatile in the long run, but would require altering someone else's project purely for our own devices, and it would require anyone using a plugin using markers to have to use the latest version of geany.
Option 3 would mean we could handle marker allocation in-house, but would require an extra plugin, and can we ensure that it would be loaded before any other plugin? Or would we agree that any plugin using markers would have to access a shared piece of code that's keeping track of which markers are being used to see what's available?
Option 4 would be simple for us to implement, but would be messy, and complicated for the user (like having to set IRQ numbers in the old day to get your PC to work).
My personal preference would be some shared static function that any plugin using markers could access.
Looking forward to your opinions.
William Fraser
On Sun, 26 Feb 2012 13:08:14 +0000 WILLIAM FRASER william.fraser@virgin.net wrote:
There is a problem as I understand it with checking for the SC_MARK_AVAILABLE marker to see if a marker is available...
Markers seem by default to be set to 0 (SC_MARK_CIRCLE) by scintilla.
"By default, all 32 markers are set to SC_MARK_CIRCLE with a black foreground and a white background."
- change scintilla or geany so that markers are set to SC_MARK_AVAILABLE
when it is initialised.
"Applications may use the marker symbol SC_MARK_AVAILABLE to indicate that plugins may allocate that marker number".
So AVAILABLE is specifically designed for our case, and it's Geany that should be changed, not scintilla.
Option 2 would be the most versatile in the long run, but would require altering someone else's project purely for our own devices, and it would require anyone using a plugin using markers to have to use the latest version of geany.
The old plugins may continue to use their fixed marker numbers, which will show as "allocated" [1] . They won't "deallocate" the numbers on _cleanup, but will "allocate" the same numbers if reloaded.
[1] Unless somebody uses a marker without defining it. White circle with black background, anyone?..
My personal preference would be some shared static function that any plugin using markers could access.
A simple ui_utils function to find and return the first available marker based on SC_MARK_AVAILABLE would suffice.
[...]
My personal preference would be some shared static function that any plugin using markers could access.
A simple ui_utils function to find and return the first available marker based on SC_MARK_AVAILABLE would suffice.
The absolute minimum we need is for Geany to set unused markers to available. Geany has to do this, it is the only thing *guaranteed* to run before all plugins.
It is not clear to me if it has to be done for each scintilla buffer, each view or once only.
Plugins or Geany can then simply search for the next available one. and allocate it by setting it to something other than available. Since every mark using plugin should do it it is probably better to have a common function in Geany. It can then also generate a message to the user suggesting unloading a plugin if it runs out of markers.
Plugins should be re-written to use this scheme as soon as possible, until then those with fixed marker numbers will still stomp all over the others as they do now.
Bookmarks should also be re-written to only use the number of markers as current bookmarks, not grab ten at startup.
Cheers Lex
-- E-gards: Jimmy _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Mon, 27 Feb 2012 08:23:41 +1100 Lex Trotman elextr@gmail.com wrote:
[...]
My personal preference would be some shared static function that any plugin using markers could access.
A simple ui_utils function to find and return the first available marker based on SC_MARK_AVAILABLE would suffice.
The absolute minimum we need is for Geany to set unused markers to available. Geany has to do this, it is the only thing *guaranteed* to run before all plugins.
Fraser #2 states this, but it won't be enough. In fact, it may be useful only for programs with a single SciObj, such as SciTE.
It is not clear to me if it has to be done for each scintilla buffer, each view or once only.
For each buffer (each SciObj), I guarantee...
Plugins or Geany can then simply search for the next available one. and allocate it by setting it to something other than available.
Since a plugin may not need to set [all of] it's markers for each file, and we may even have 0 buffers open, a guint map seems required, and I was probably wrong to suggest AVAILABLE. Can't query/define Scintilla markers without at least 1 SciObj...
Since every mark using plugin should do it it is probably better to have a common function in Geany.
utils_ui_get_marker(), utils_ui_free_marker().
It can then also generate a message to the user suggesting unloading a plugin if it runs out of markers.
Shoudn't the plugin handle this? It may reduce the number of markers used, work without them if non-critical, or do something else.
Bookmarks should also be re-written to only use the number of markers as current bookmarks, not grab ten at startup.
Ten markers? Wow, that's heavy. Different colors or what?
27.02.2012 22:12, Dimitar Zhekov пишет:
have a common function in Geany.
utils_ui_get_marker(), utils_ui_free_marker().
Hi, guys. Is it going with these new functions? I started with SF bug about markers and also came up to that having such functions would be the best way for dealing with plugin's markers.
Best regards, Alex
On Sat, 10 Mar 2012 17:43:16 +0400 Alexander Petukhov devel@apetukhov.ru wrote:
utils_ui_get_marker(), utils_ui_free_marker().
Is it going with these new functions?
Nothing is going on, the thread died.
I started with SF bug about markers and also came up to that having such functions would be the best way for dealing with plugin's markers.
Fellow developers, how about implementing these? I can do it, they are not hard to write.
On 11 March 2012 03:42, Dimitar Zhekov dimitar.zhekov@gmail.com wrote:
On Sat, 10 Mar 2012 17:43:16 +0400 Alexander Petukhov devel@apetukhov.ru wrote:
utils_ui_get_marker(), utils_ui_free_marker().
Is it going with these new functions?
Nothing is going on, the thread died.
I started with SF bug about markers and also came up to that having such functions would be the best way for dealing with plugin's markers.
Fellow developers, how about implementing these? I can do it, they are not hard to write.
Hi Dimitar,
Sorry not to reply sooner, very busy. Offer gratefully received.
I don't think much is needed:
1. Scintilla already provides the special symbol SC_MARK_AVAILABLE to indicate that the mark is available.
2. As I read the Scintilla docs, it isn't the default, so Geany needs to initialise all markers it doesn't use to SC_MARK_AVAILABLE each scintilla object it creates.
3. When a plugin needs a marker for a document it should search for one that is available on that document and use that, and set it back to available when it no longer needs it and on unload. There are only 32 to search so it isn't IMHO worth implementing anything faster.
4. As noted previously in the thread, since plugins know if they can work without the marker it should be left up to the plugin to provide a user error message if no markers are available.
So all we need is the initialisation, and probably a common search routine for the convenience of plugins (although that isn't absolutely needed). The smaller the patch the more likely someone has time to test it and commit it.
Cheers Lex
-- E-gards: Jimmy _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
So all we need is the initialisation, and probably a common search routine for the convenience of plugins (although that isn't absolutely needed). The smaller the patch the more likely someone has time to test it and commit it.
I would vote for having utility functions that manages a list of available markers instead of letting plugins manually find those that are marked with SC_MARK_AVAILABLE.
I can imagine a situation when some plugin set its markers for several documents but didn't do it for others, so when another plugin tries to set it's own markers it came to that markers idenifiers for the same markers are different in different documents that means it's another job to keep track of it.
having such functions as utils_ui_get_marker(), utils_ui_free_marker() seems more clear and robust.
Regards, Alex
On 11 March 2012 17:16, Alexander Petukhov devel@apetukhov.ru wrote:
So all we need is the initialisation, and probably a common search routine for the convenience of plugins (although that isn't absolutely needed). The smaller the patch the more likely someone has time to test it and commit it.
I would vote for having utility functions that manages a list of available markers instead of letting plugins manually find those that are marked with SC_MARK_AVAILABLE.
I can imagine a situation when some plugin set its markers for several documents but didn't do it for others, so when another plugin tries to set it's own markers it came to that markers idenifiers for the same markers are different in different documents that means it's another job to keep track of it.
Well, the plugins are just going to have to do this anyway, why should a C language plugin steal markers froma Python file when the Python plugin also needs them??
Cheers Lex
having such functions as utils_ui_get_marker(), utils_ui_free_marker() seems more clear and robust.
Regards, Alex
Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Am 11.03.2012 07:16, schrieb Alexander Petukhov:
So all we need is the initialisation, and probably a common search routine for the convenience of plugins (although that isn't absolutely needed). The smaller the patch the more likely someone has time to test it and commit it.
I would vote for having utility functions that manages a list of available markers instead of letting plugins manually find those that are marked with SC_MARK_AVAILABLE.
I can imagine a situation when some plugin set its markers for several documents but didn't do it for others, so when another plugin tries to set it's own markers it came to that markers idenifiers for the same markers are different in different documents that means it's another job to keep track of it.
having such functions as utils_ui_get_marker(), utils_ui_free_marker() seems more clear and robust.
I agree. Not because I really expect this going to happen very often, but because of it sounds like a cleaner solution for me with a defined API for plugin codes.
Cheers, Frank
On Sun, 11 Mar 2012 12:33:07 +1100 Lex Trotman elextr@gmail.com wrote:
I don't think much is needed:
- Scintilla already provides the special symbol SC_MARK_AVAILABLE to
indicate that the mark is available.
I already replied to this [1]. Unless we want each plugin to allocate it's markers for each document, possibly receiving different numbers, we should have a bitmap in Geany.
- When a plugin needs a marker for a document it should search for
one that is available on that document and use that, and set it back to available when it no longer needs it and on unload. There are only 32 to search so it isn't IMHO worth implementing anything faster.
Oh, I see. So any plugin with markers must keep track of each document it allocated markers in. This is not going to be fun.
why should a C language plugin steal markers froma Python file when the Python plugin also needs them??
To be able to allocate markers #s in plugin_init(), and free them in plugin_cleanup(). To be able to work without tracking document file type changes.
[1] http://lists.uvena.de/pipermail/geany-devel/2012-February/006629.html
On 12 March 2012 06:25, Dimitar Zhekov dimitar.zhekov@gmail.com wrote:
On Sun, 11 Mar 2012 12:33:07 +1100 Lex Trotman elextr@gmail.com wrote:
I don't think much is needed:
- Scintilla already provides the special symbol SC_MARK_AVAILABLE to
indicate that the mark is available.
I already replied to this [1]. Unless we want each plugin to allocate it's markers for each document, possibly receiving different numbers, we should have a bitmap in Geany.
- When a plugin needs a marker for a document it should search for
one that is available on that document and use that, and set it back to available when it no longer needs it and on unload. There are only 32 to search so it isn't IMHO worth implementing anything faster.
Oh, I see. So any plugin with markers must keep track of each document it allocated markers in. This is not going to be fun.
why should a C language plugin steal markers froma Python file when the Python plugin also needs them??
To be able to allocate markers #s in plugin_init(), and free them in plugin_cleanup(). To be able to work without tracking document file type changes.
Hi Dimitar,
Any plugin that is filetype specific must know which documents are its type.
I wouldn't expect (for example) GeanyLatex to interfere with my C# programming. Similarly I wouldn't expect the debugger plugin to try to work on a language gdb doesn't understand, eg Java.
Maybe you should contact Matthew, during a conversation we had on IRC he revealed a prototype for manageing all such limited resources, not just markers, in a consistent manner.
Since the SC_MARK_AVAILABLE isn't, erm, available, for other recources such as indicators, Matthew uses the suggested boolean map method.
@Frank, this would give a single consistent interface to acquire and release all limited resources, markers, indicators, margins and styles.
Cheers Lex
[1] http://lists.uvena.de/pipermail/geany-devel/2012-February/006629.html
-- E-gards: Jimmy _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Mon, 12 Mar 2012 09:59:45 +1100 Lex Trotman elextr@gmail.com wrote:
Maybe you should contact Matthew, during a conversation we had on IRC he revealed a prototype for manageing all such limited resources, not just markers, in a consistent manner.
This concerns all plugin developers. @Matthew, can you public the prototype or it's short description on the mailing list, or on another shared resource?..
I wouldn't expect (for example) GeanyLatex to interfere with my C# programming. Similarly I wouldn't expect the debugger plugin to try to work on a language gdb doesn't understand, eg Java.
Sounds nice. But for some reason, both Scintilla and Geany use fixed resources, independent of file type. Folding for text files, anyone?..
A per-document allocation, no matter how implemented, also introduces per-document resource exhaustion errors. So we should at least have a policy how such error messages are displayed - they must be both noticable and not too annoying.