Some basic Ruby issues:
Unlike JavaScript, Ruby does not enforce parenthesis around conditional expressions.
Ie:
if( not file_loaded?("collierstoolbar.rb") )
You can use parenthesis to make complex expressions easier to understand or to force a certain order of evaluation.
But generally simple conditional expressions should omit the parenthesis:
if not file_loaded?("collierstoolbar.rb")
It is always best to use parenthesis around instance method call argument lists.
Only global methods from Kernel, BasicObject, Object, Module and Class, (those that are called without a receiver object and dot notation,) can be called without parenthesis. These kinds of methods are known as having “keyword status” (or “reserved word status”) as if they were interpreter functions.
sbm.add_item("Around Blue") {rotate90 sel, "z"}
… should be:
sbm.add_item("Around Blue") { rotate90(sel, "z") }
Another example:
toolbar.add_item cmd2
… should be:
toolbar.add_item(cmd2)
Indentation is 2 spaces in Ruby. Using more when showing code on the forum can cause readers to have to use horizontal scrolling to read code snippets.
It looks like your indentation is using TAB characters. With most good code editors, you can set TAB to be automatically replaced with a certain number of SPACE characters.
This is best when you post into forums or other posting on the web such as GitHub repository issues.
In Discourse engine forums, TAB characters for code is displayed as 4 wide. In GitHub, I think it may be 8 wide.
The line where a block begins should be aligned with line that closes the block.
Ie:
cmd2 = UI::Command.new("Haut") {
deplacement_y_haut()
}
should be:
cmd2 = UI::Command.new("Haut") {
deplacement_y_haut()
}
… or … a one-liner:
cmd2 = UI::Command.new("Haut") { deplacement_y_haut() }
It looks like you wanted indentation to “group” the definition of your command objects for readability. You can use Ruby core’s #instance_eval to do this if you like. Within the block sent to this method, the command instance object is referenced as the reserved word self .
Ie:
cmd2 = UI::Command.new("Haut") {
deplacement_y_haut()
}
icon2 = File.join(__dir__, 'collierstoolbar', 'images','UP.png')
cmd2.small_icon = icon2
cmd2.large_icon = icon2
cmd2.tooltip = "Haut"
cmd2.status_bar_text = "Pour déplacer d'une trame vers le haut"
toolbar.add_item cmd2
… can become:
cmd2 = UI::Command.new("Haut") {
deplacement_y_haut()
}
cmd2.instance_eval {
icon2 = File.join(__dir__, 'collierstoolbar', 'images','UP.png')
self.small_icon = icon2
self.large_icon = icon2
self.tooltip = "Haut"
self.status_bar_text = "Pour déplacer d'une trame vers le haut"
}
toolbar.add_item(cmd2)
But I notice that in the command defintions, you’re getting the icon paths:
icon2 = File.join(__dir__, 'collierstoolbar', 'images','UP.png')
Your extension’s code file should (and actually must) be placed within your extension’s subfolder.
So the 2nd argument … 'collierstoolbar' would be unneeded as __dir__() alone would return the correct path to your extension’s folder.
You should only have an extension registrar script in the "Plugins" folder that registers the extension and allows it to be switch on and off.
The naming convention for extension registrar files and extension folders is, the name of your top level namespace module, an underscore (_) and then the name of your extension.
Ex:
If your top level unique namespace you chose (for ALL of your extensions) was CollierMangrove and this test extension was wrapped in a submodule identified as ToolbarTest, …
then the extension subfolder in the "Plugins" folder should be "CollierMangrove_ToolbarTest",
and the extension’s registrar file should be "CollierMangrove_ToolbarTest.rb".
All of the extension’s actual running code should be in rb files inside the "CollierMangrove_ToolbarTest" subfolder. The only part in the "Plugins" folder proper should be the registrar file.
So, the code running in your extension most likely would never need to use a 'collierstoolbar' literal string because __dir__() and __FILE__ will return paths to the proper folder. (This means parts of your code can often reuse “generic” snippets that don’t use hardcoded literal extension subfolder name strings.)
