Common UI API
-
I'd be up for adding to that where I can. I think getting the right level of standardization is important - not too brittle or rigid - from pov of adoption. And not using language features for their own sake too.. But in the same breath I'd suggest that in a language as dynamic as Ruby, protocols over classes is the best bet. eg I really like the fact that the Tools are just objects that implement a known protocol and not some class derivation.
I also like TBD's idea of knowledge base for SU ruby. However, from a fair amount of experience I know its very hard to keep these things from drifting off into the long grass - its completely possible, but it requires work, regular work and perhaps more work than any of us are realistically going to be able to offer. But having somewhere to capture that - "I just wasted an afternoon rediscovering the same bug/glitch/oversight I wasted an afternoon from N years back and this is what it was" - could be a valuable resource. Catchy title too.
Adam
-
Well, let's say I wrote this great plugin; if there already existed some Menu&Toolbar library, what would it look like for the end-user? Is it good to define the interface, then create the library to fit the specification?
def hello UI.messagebox("Hi!") end # Typical menu item example; if( !file_loaded?("hello.rb") ) UI.menu("Plugins").add_item("Say Hello") { hello } file_loaded("hello.rb") end
-
Seeing as both Menus and Toolbars use Commands, it would make sense for the plugin to provide an array of available commands on request. Then the UI controller would just have to ask the plugin for it's commands.
module HelloPlugin def self.hello UI.messagebox("Hi!") end def self.commands cmd = UI;;Command.new("Say Hello") { HelloPlugin.hello } return [cmd] end end
Of course, it would be good to allow a plugin to suggest, or request a menu or toolbar to be placed in. Maybe a new Command class is in order; one that would include methods to provide these menus. Something like this incomplete (and incorrect) example:
class Command attr_accessor ;menu, ;toolbar def initialize(menu_name, block) @cmd = UI;;Command.new(menu_name) { block } end def large_icon(path) @cmd.large_icon = path end end
And so our hello plugin becomes:
require "command.rb" module HelloPlugin def self.hello UI.messagebox("Hi!") end def self.commands cmd = Command.new("Say Hello") { HelloPlugin.hello } cmd.menu = "Plugins/Nonsense" return [cmd] end end
-
Jim,
I guess you've lost me a little already! What exactly is the problem that we want to solve? I know there are few rules wrt plug-in integration, but it would be useful to articulate the precise issue that would be solved by any additional APIs.
Having a reflection system / protocol is all neat but how exactly does that help the end-user?
Secondly, IMHO if you are going to provide some infrastructure then you have to provide the developers a compelling reason to use it. It has to give them something that they would otherwise not have. If you don't, then most developers will take the view that its quicker and easier to 'do their own thing'.
So I'm a developer, what do I gain for my Tool/Plugin by implementing some standard reflection methods?
Adam
-
Just thinking out loud about standardizing menus and toolbars. It will make the life of the developer easier because the idea is to shift the burden of deciding where to install a menu item or toolbar command to the end-user.
I don't want to entirely take away control from the developer - many plugins need and deserve their own toolbars and menus. But for the hundreds (or so) single-purpose plugins, and the hundreds more yet to be written, it would be nice to be able to organize them.
I see a drag-and-drop, perhaps a tree-view, menu editor as optimal for the end-user.
Perhaps just a folder structure as used by Rick's organizer plugin is all that is needed.
-
OK, got it. [And this is all thinking out loud ]
So the idea is that if developers implement some well-known reflection methods, their plug-in will be able to work in the new whizzy plug-in management GUI that gives users a better experience, right?
What happens if they don't implement those methods? I guess the plug-in is ignored wrt the PluginManager?
You mentioned some ideas for what features could be offered which sound cool - might be good to have the notion of 'Favorites' to avoid searching through dozens of icons each time. Perhaps even some gesture pop-up (radial layout of icons?)
One thing I don't understand (and its probably lack of coffee!) is how this PluginManager discovers the plugins. ??
Lastly, I'd like to encourage more people to contribute to this discussion. If you've got suggestions and ideas, then post them; the worse that can happen is they're shot down in flames and. ^h^h^h.. Just kidding! No, really SketchUp users out there, lets have your ideas as to how you'd like to manage lots of little plugins.
Adam
-
maybe redirecting SU plugins related methods for non common api (capi?) and creating a database of running plugins ? I will go for a keyboard search interface
-
@adamb said:
OK, got it. [And this is all thinking out loud ]
So the idea is that if developers implement some well-known reflection methods, their plug-in will be able to work in the new whizzy plug-in management GUI that gives users a better experience, right?
I am not familiar with the term reflection in this context, but better user experience is a big part of it.
@unknownuser said:
What happens if they don't implement those methods? I guess the plug-in is ignored wrt the PluginManager?
Not necessarily, but if a plugin messes up someone's meticulously organized menus then the author is likely to hear about it and (hopefully) decide to conform. Or put them under an "Unfiled" menu.
@unknownuser said:
You mentioned some ideas for what features could be offered which sound cool - might be good to have the notion of 'Favorites' to avoid searching through dozens of icons each time. Perhaps even some gesture pop-up (radial layout of icons?)
Favorites is a good idea. I'm not sure where a radial menu would be useful, could you exlpain?
@unknownuser said:
One thing I don't understand (and its probably lack of coffee!) is how this PluginManager discovers the plugins. ??
There's a couple ways to do it. 1) Have plugins register themselves. 2) Have PluginsManager ask each plugin if it responds_to? "menus" (or similar.)
I think this is leading to moving all .rb file out of the Plugins folder.
@unknownuser said:
Lastly, I'd like to encourage more people to contribute to this discussion. If you've got suggestions and ideas, then post them; the worse that can happen is they're shot down in flames and. ^h^h^h.. Just kidding! No, really SketchUp users out there, lets have your ideas as to how you'd like to manage lots of little plugins.
Adam
Thanks Adam, these things are important to discuss.
-
this is only indirectly related to the topic:
is it possible to "sub-shortcut-keys"?
what I mean is: if you have a lot of rubies and you would like to use shortcut keys for them, you will soon run out of keys on your keyboard. to prevent this it would be great, if you could apply shortcuts to a tool that are only active, when this specific toolset (like the "on surface tools") is in use. if it is inactive the same keys are linked to different (standart) tools.
that would bring the great advantage of script writers being able to set up default shortcuts for their rubies without interfering with user specific ones.to develope this idea even further you could enter a toolset by pressing a shortcut and then using the toolset specific ones ("sub-shortcuts). press escape to return back to the "home screen" (I recently came around such a way of using key ins in microstation).
by the way, my shortcuts would be:
"Space Bar" (for entering the rubies-collection-window, followed by...) >
"1" for Joint Push Pull
"2" for On Surface Tools (here I use my standart keys again for Line, Offset,...)
"3" for .....did that make any sense? and is it possible to achieve this without completely rewriting SketchUp?
-
plot-paris: possible. is what Adam referred with radial menu
Advertisement