In another thread http://lists.uvena.de/geany/2012-February/007808.html a couple of things were mentioned about guidelines for plugins to be good citizens. So I thought it worthwhile gathering any suggestions so the docs could be updated in one go.
Items mentioned to date:
1. don't set default keybindings, users will be annoyed if you override their personal bindings. Always let the user tell the plugin what to use. 2. don't spread menu items through the Geany menus, users don't know where to look and if several plugins add things to the same place the menu may become unworkable. You don't know what other plugins the user will enable at the same time.
I add the following for consideration:
3. be aware of the performance, especially if your plugin does something on every keystroke or change or at startup, other plugins are likely to want to as well. Just because the plugin works ok or your computer by itself doesn't mean it will work well when the user combines it with 15 others on their old notebook and they have heaps of files open.
And on the development side, these have been mentioned before ad-nauseum but still need emphasis:
4. make your plugin compile clean with -Wall -Wextra -O2 -Wno-unused-parameter with and without -ansi, and 64bit clean 5. don't use anything not *documented* in the plugin interface, a change in Geany can make your plugin fail if you do. But you are protected against changes in the interface.
Any other thoughts?
Cheers Lex
Am 21.02.2012 05:15, schrieb Lex Trotman:
- don't spread menu items through the Geany menus, users don't know
where to look and if several plugins add things to the same place the menu may become unworkable. You don't know what other plugins the user will enable at the same time.
You don't propose a solution. What would be the correct place for menu items? Also I don't quite get what you're trying to say. You seem to say both, spreading menu items and adding them to the same place is unworkable, but that contradicts.
Best regards.
Am 21.02.2012 11:53, schrieb Thomas Martitz:
Am 21.02.2012 05:15, schrieb Lex Trotman:
- don't spread menu items through the Geany menus, users don't know
where to look and if several plugins add things to the same place the menu may become unworkable. You don't know what other plugins the user will enable at the same time.
You don't propose a solution. What would be the correct place for menu items? Also I don't quite get what you're trying to say. You seem to say both, spreading menu items and adding them to the same place is unworkable, but that contradicts.
Current best practice is to append it into tools-menu and / or adding with good reasons directly into menubar.
Cheers, Frank
Another item just came up, see http://lists.uvena.de/geany/2012-February/007831.html where two plugins don't share resources nicely (in this case the limited number of markers available).
Both plugins use hard coded integer marker numbers.
Looks like all markers are going to have to be marked available by Geany (well except for those we use) and plugins are going to have to test for available ones before defining them, and to reset them available when the plugin is unloaded. This means plugins also have to handle exhaustion of markers.
This convention also needs to be documented.
More generally what other resources does this apply to?
Cheers Lex
On 12-02-21 01:00 PM, Lex Trotman wrote:
Another item just came up, see http://lists.uvena.de/geany/2012-February/007831.html where two plugins don't share resources nicely (in this case the limited number of markers available).
Both plugins use hard coded integer marker numbers.
Looks like all markers are going to have to be marked available by Geany (well except for those we use) and plugins are going to have to test for available ones before defining them, and to reset them available when the plugin is unloaded. This means plugins also have to handle exhaustion of markers.
This convention also needs to be documented.
More generally what other resources does this apply to?
Indicators, GUI elements/widgets/layout (SplitWindow/Devhelp), intents/purposes (GProject/GeanyPrj/Android/Clang), project files (GProject/Others?), scripting plugins (GeanyPy/ZenCoding) and there's probably some more.
It might be neat to have some form of controller in Geany that can dish out resources as needed and prevent conflicting plugin types/intents and resources.
PS, anyone not wanting to conflict with any of my plugins that use indicators, don't use SCI_INDIC_MAX-1 :)
Cheers, Matthew Brush
On 21 February 2012 23:23, Frank Lanitz frank@frank.uvena.de wrote:
Am 21.02.2012 11:53, schrieb Thomas Martitz:
Am 21.02.2012 05:15, schrieb Lex Trotman:
- don't spread menu items through the Geany menus, users don't know
where to look and if several plugins add things to the same place the menu may become unworkable. You don't know what other plugins the user will enable at the same time.
You don't propose a solution. What would be the correct place for menu items? Also I don't quite get what you're trying to say. You seem to say both, spreading menu items and adding them to the same place is unworkable, but that contradicts.
Current best practice is to append it into tools-menu and / or adding with good reasons directly into menubar.
Yes, a single menu item in toolbar (which may have subitems) or for larger menu hierarchies put it in the menubar (like debugger does).
Cheers Lex
Cheers, Frank _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Le 21/02/2012 05:15, Lex Trotman a écrit :
In another thread http://lists.uvena.de/geany/2012-February/007808.html a couple of things were mentioned about guidelines for plugins to be good citizens. So I thought it worthwhile gathering any suggestions so the docs could be updated in one go.
Items mentioned to date:
- don't set default keybindings, users will be annoyed if you
override their personal bindings. Always let the user tell the plugin what to use.
I'm not convinced that saying "not set default" is the best solution to the conflict problem. Couldn't Geany simply not override an already existent keybinding when installing a plugin's one?
- don't spread menu items through the Geany menus, users don't know
where to look and if several plugins add things to the same place the menu may become unworkable. You don't know what other plugins the user will enable at the same time.
I'm not sure about this one either, though I understand that too many items everywhere may become a problem.
But if the plugin provides a feature like, say, uniqueness (ref. thread in the general ml), the menu would better fit in edit->format or something; and e.g. GeanyGenDoc places an item in "editor context menu"->insert. IMO this makes the UI better than fulfilling the tools menu with various stuff, since it's the "appropriate place" for such an item.
I understand that if 10k plugins adds items in various menus it'd start to be annoying, but OTOH, is a tool menu with 10k items really better?
Cheers, Colomban
I add the following for consideration:
- be aware of the performance, especially if your plugin does
something on every keystroke or change or at startup, other plugins are likely to want to as well. Just because the plugin works ok or your computer by itself doesn't mean it will work well when the user combines it with 15 others on their old notebook and they have heaps of files open.
And on the development side, these have been mentioned before ad-nauseum but still need emphasis:
- make your plugin compile clean with -Wall -Wextra -O2
-Wno-unused-parameter with and without -ansi, and 64bit clean 5. don't use anything not *documented* in the plugin interface, a change in Geany can make your plugin fail if you do. But you are protected against changes in the interface.
Any other thoughts?
Cheers Lex _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On 23 February 2012 01:13, Colomban Wendling lists.ban@herbesfolles.org wrote:
Le 21/02/2012 05:15, Lex Trotman a écrit :
In another thread http://lists.uvena.de/geany/2012-February/007808.html a couple of things were mentioned about guidelines for plugins to be good citizens. So I thought it worthwhile gathering any suggestions so the docs could be updated in one go.
Items mentioned to date:
- don't set default keybindings, users will be annoyed if you
override their personal bindings. Always let the user tell the plugin what to use.
I'm not convinced that saying "not set default" is the best solution to the conflict problem. Couldn't Geany simply not override an already existent keybinding when installing a plugin's one?
Thats possible, but does Geany know that it is a plugin setting the keybinding?
If we can do it, might it not also cause user confusion when keybindings are not applied? What about when adding several plugins some of which clash in keybindings?
There would have to be some sort of notification (I guess by plugin manager?) and that in itself is also probably annoying.
And even if the plugin didn't have a default shortcut, I guess if the user set one and the plugin saved it, then the user unloaded the plugin, set the same keybinding somewhere else and then re-loaded the plugin you still get a clash so detecting it and notifying the user is needed in any case.
(Sorry no solutions, just questions)
- don't spread menu items through the Geany menus, users don't know
where to look and if several plugins add things to the same place the menu may become unworkable. You don't know what other plugins the user will enable at the same time.
I'm not sure about this one either, though I understand that too many items everywhere may become a problem.
But if the plugin provides a feature like, say, uniqueness (ref. thread in the general ml), the menu would better fit in edit->format or something; and e.g. GeanyGenDoc places an item in "editor context menu"->insert.
Well, its only the plugin developers idea of where it "belongs", personally I would not want uniqueness in format. Also if we change the Geany menu all the plugins have to scramble to fix themselves.
IMO this makes the UI better than fulfilling the tools menu with various stuff, since it's the "appropriate place" for such an item.
Just try getting agreement on "appropriate", its a bikeshed. Unless the plugin has a preference to choose tools or somewhere else.
I understand that if 10k plugins adds items in various menus it'd start to be annoying, but OTOH, is a tool menu with 10k items really better?
Well, at least its isolated and the usability of the rest of Geany isn't impacted.
I don't think that there is a clear cut solution, but IMHO on balance it is better to keep the mess constrained to one place.
[...]
Cheers Lex
On 12-02-22 04:48 PM, Lex Trotman wrote:
On 23 February 2012 01:13, Colomban Wendlinglists.ban@herbesfolles.org wrote:
Le 21/02/2012 05:15, Lex Trotman a écrit :
[...] 2. don't spread menu items through the Geany menus, users don't know where to look and if several plugins add things to the same place the menu may become unworkable. You don't know what other plugins the user will enable at the same time.
I'm not sure about this one either, though I understand that too many items everywhere may become a problem.
But if the plugin provides a feature like, say, uniqueness (ref. thread in the general ml), the menu would better fit in edit->format or something; and e.g. GeanyGenDoc places an item in "editor context menu"->insert.
Well, its only the plugin developers idea of where it "belongs", personally I would not want uniqueness in format. Also if we change the Geany menu all the plugins have to scramble to fix themselves.
We could use GtkUIManager more, it's precisely what it's used for (ex. in Gedit), AFAIK.
IMO this makes the UI better than fulfilling the tools menu with various stuff, since it's the "appropriate place" for such an item.
Just try getting agreement on "appropriate", its a bikeshed. Unless the plugin has a preference to choose tools or somewhere else.
That's what HIGs are for, and common sense even :)
I understand that if 10k plugins adds items in various menus it'd start to be annoying, but OTOH, is a tool menu with 10k items really better?
Well, at least its isolated and the usability of the rest of Geany isn't impacted.
I don't think that there is a clear cut solution, but IMHO on balance it is better to keep the mess constrained to one place.
IMO, if it's a simple plugin and provides a generic editor feature Geany is missing, it would be fine to put it in the corresponding menu (ex. Edit->Format->Remove Duplicate Lines), but if it's a big plugin with lots of menu items, even if they fit better in the regular menus, they should still be put in a submenu inside the Tools menu. That's my opinion anyway.
Cheers, Matthew Brush
[...]
IMO, if it's a simple plugin and provides a generic editor feature Geany is missing, it would be fine to put it in the corresponding menu (ex. Edit->Format->Remove Duplicate Lines),
Thats the problem, I would never have looked for remove duplicate under "format", for me if it goes in the standard menu it goes in "commands", maybe under "duplicate line" command.
but if it's a big plugin with lots of menu items, even if they fit better in the regular menus, they should still be put in a submenu inside the Tools menu. That's my opinion anyway.
Agree here, one top level one in tools and the rest under it. Except for complete units of functionality like "debug" that should go in the top level.
Maybe there should be a filetype specific top level item too, where all the language specific plugins could put stuff, and over time we could migrate language specific things to it.
Cheers Lex
Cheers, Matthew Brush
Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Am 23.02.2012 05:42, schrieb Lex Trotman:
Maybe there should be a filetype specific top level item too, where all the language specific plugins could put stuff, and over time we could migrate language specific things to it.
I already did start something like this with LaTeX and BibTeX from GeanyLaTeX. So I second this.
Cheers, Frank
On Thu, 23 Feb 2012 11:48:41 +1100 Lex Trotman elextr@gmail.com wrote:
On 23 February 2012 01:13, Colomban Wendling lists.ban@herbesfolles.org wrote:
Le 21/02/2012 05:15, Lex Trotman a écrit :
In another thread http://lists.uvena.de/geany/2012-February/007808.html a couple of things were mentioned about guidelines for plugins to be good citizens. So I thought it worthwhile gathering any suggestions so the docs could be updated in one go.
Items mentioned to date:
- don't set default keybindings, users will be annoyed if you
override their personal bindings. Always let the user tell the plugin what to use.
I'm not convinced that saying "not set default" is the best solution to the conflict problem. Couldn't Geany simply not override an already existent keybinding when installing a plugin's one?
Thats possible, but does Geany know that it is a plugin setting the keybinding?
Not really.
If we can do it, might it not also cause user confusion when keybindings are not applied? What about when adding several plugins some of which clash in keybindings?
Yepp. This is the issue I'm seeing.
There would have to be some sort of notification (I guess by plugin manager?) and that in itself is also probably annoying.
ACK.
And even if the plugin didn't have a default shortcut, I guess if the user set one and the plugin saved it, then the user unloaded the plugin, set the same keybinding somewhere else and then re-loaded the plugin you still get a clash so detecting it and notifying the user is needed in any case.
Agreed.
As a conclusion based on your questions: I'm stronger in my point: Noncore Plugins should not set default keybindings in about 99.9% of cases.
Cheers, Frank