Community
Participate
Working Groups
Orion commands and GCLI commands have similar properties. We should try to unify these... The mapping is something like (Orion->GCLI) name->name callback->exec parameters->params tooltip->description We should also unify the properties of a parameter (name, type, etc.) Some interesting scenarios: - Clients can pass an Orion command or a GCLI command into the editor as an "actionDescription" (see bug 377828). - KeyAssist panels or other help could treat them uniformly - extension points that refer to commands could refer to GCLI commands - we could actually render a toolbar or other help panel for GCLI using the command framework
This would be largely a mechanical change in Orion. Many of the concepts are shared. If we look at piping our commands in support of ideas like bug 344205 then we would definitely want to use their return values, parameter descriptions, etc...why reinvent the same concept.
This makes sense to investigate. The top-level properties seem straight-forward. Looking at the comment 0 comparison, the one top-level property where I think Command should consider a change (as opposed to the Console changing) is "tooltip", because "description" does not commit to a particular means of displaying its content. The other current properties of Command make sense for adoption in both contexts. Parameters don't seem as easy. For "type", Orion commands will take any HTML5 input type, while GCLI will accept string/boolean/number/array/selection (selection == an enumeration). Does this imply that some commands would be usable in both contexts (if their types all fell into the intersection of these supported types), while other commands would not? In theory it would be possible for the Console to provide custom implementations for some of its missing types (it currently defines custom types "directory" and "file"), but I'm not sure that signing it up to implement the others is desirable. Thoughts?
(In reply to comment #2) > This makes sense to investigate. > > The top-level properties seem straight-forward. Looking at the comment 0 > comparison, the one top-level property where I think Command should consider a > change (as opposed to the Console changing) is "tooltip", because "description" > does not commit to a particular means of displaying its content. The other > current properties of Command make sense for adoption in both contexts. Thanks for looking at this. Actually, I was thinking Command would change to use all the console terms, on the assumption that they would be more familiar to the gcli community. We aren't API yet, so it's just a giant mechanical internal change. Agree especially on "tooltip" vs. "description." > Parameters don't seem as easy. For "type", Orion commands will take any HTML5 > input type, while GCLI will accept string/boolean/number/array/selection > (selection == an enumeration). Does this imply that some commands would be > usable in both contexts (if their types all fell into the intersection of these > supported types), while other commands would not? In theory it would be > possible for the Console to provide custom implementations for some of its > missing types (it currently defines custom types "directory" and "file"), but > I'm not sure that signing it up to implement the others is desirable. > > Thoughts? I think the things that GCLI accepts that we don't are things that Command clients want anyway. So at least a GCLI command would be able to be used in the Orion UI. That is what I think could be useful...we could generate toolbars or other popup "run the command" stuff that combined console stuff, key bindings, etc. Going the other way....GCLI commands understanding Orion commands. Not as sure about that one. So I don't see Console implementing the other types necessarily until we find that use case. It might be worthwhile to recognize HTML types as "text" and I could imagine a day when a user might want to invoke a type based content assist for parameters where that type would be helpful information. But this bug was mostly asking if you thought it valuable for Commands to try to adopt GCLI terminology and whether you could imagine any other cool use cases for doing so...
> Thanks for looking at this. Actually, I was thinking Command would change to > use all the console terms, on the assumption that they would be more familiar > to the gcli community. We aren't API yet, so it's just a giant mechanical > internal change. Agree especially on "tooltip" vs. "description." I don't think an effort needs to be made to preserve gcli terminology, the use of gcli is an implementation detail, which plug-ins that contribute commands do not reference directly. I'm inclined to adopt "parameters" and "callback", unless you disagree. "Description" wins over "tooltip". gcli's base parameter types are pretty straight-foward, so having Command support them seems like a reasonable step. As you say, adding support for more types in Console should probably be preceeded by real use cases first.
Closing as part of a mass clean up of inactive bugs. Please reopen if this problem still occurs or is relevant to you. For more details see: https://dev.eclipse.org/mhonarc/lists/orion-dev/msg03444.html
