[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [platform-ui-dev] Canadian Idol - or - follow your role-model: Contexts, Commands, Actions
|
Things cast in stone are hard to break (even without considering
downstream dependents, such as WebSphere Studio and the
likes). I am talking from my luxurious ivory tower, speaking in
ideal terms, trying to think out of the box, and blurting out random
rants. Just use what you can from my arguments. It is my intuition
that speaks out: trying to fix something broken in eclipse by
adding new bloat to it is the only measure we have now, I'm afraid.
I'd rather start over with all the lessons we learned sofar.
Chris
|---------+--------------------------------->
| | Chris |
| | McLaren/Ottawa/IBM@IBM|
| | CA |
| | Sent by: |
| | platform-ui-dev-admin@|
| | eclipse.org |
| | |
| | |
| | 09/11/2003 11:56 AM |
| | Please respond to |
| | platform-ui-dev |
| | |
|---------+--------------------------------->
>---------------------------------------------------------------------------------------------------------------------------------------------|
| |
| To: platform-ui-dev@xxxxxxxxxxx |
| cc: |
| Subject: Re: [platform-ui-dev] Canadian Idol - or - follow your role-model: Contexts, Commands, Actions |
| |
>---------------------------------------------------------------------------------------------------------------------------------------------|
there is certainly two different definitions in use (at least) for the
word "command".
whether one definition is more "real" than another is subjective.
i'm personally not tied to any particular terminology right now, but i
think eclipse might be:
the org.eclipse.ui.commands extension point has been api in eclipse since
2.1,
where as a formal 'undo/redo' stack for eclipse is still a deferred item.
it is expected (within the ui team currently) that 'command' as currently
defined in eclipse will quickly become the dominate notion of a user's
request - it will be the command that appears on menus and toolbars, and
it is the command that already has the key bindings, as you pointed out.
it will supercede actions in terms of functionality, and actions are
expected to be not much more than the command's handler - the
'retargetable' part of a command that provides a run() method
and,optionally, some name/description overrides. this is happening as art
of the "[plan item] improve action contributions." my point is that use of
the term command in this sense will be become more and more common.
would you propose we should break some existing eclipse api now to get
some terminology changed?
(and i'm not trying to be facetious - breaking api is a *possible* option
still...)
chris.
Randy Hudson <hudsonr@xxxxxxxxxx>
Sent by: platform-ui-dev-admin@xxxxxxxxxxx
09/11/2003 10:56 AM
Please respond to platform-ui-dev
To: platform-ui-dev@xxxxxxxxxxx
cc:
Subject: Re: [platform-ui-dev] Canadian Idol - or - follow
your role-model:
Contexts, Commands, Actions
I had a previous question about what was meant by Command. A "Command" is
a class of actions that are all similar. A command is basically the
descriptorID that identifies an action, and causes it to inherit the
keybinding associated with that Command.
Don't get this concept confused with the "real" command pattern, used for
undo and redo.
-Randy
Chris Laffra <Chris_Laffra@xxxxxxxxxx>
Sent by: platform-ui-dev-admin@xxxxxxxxxxx
09/11/2003 09:37 AM
Please respond to platform-ui-dev
To: platform-ui-dev@xxxxxxxxxxx
cc:
Subject: [platform-ui-dev] Canadian Idol - or - follow your
role-model: Contexts, Commands, Actions
With interest, I read the Context proposal at
http://dev.eclipse.org/viewcvs/index.cgi/~checkout~/platform-ui-home/contexts/contexts.html
I have some questions/remarks.
1. Why the digression in layout style. Where is the familiar (boring)
Eclipse header?
2. The proposal makes excellent points on Command vs. Actions, and
made me think of Intentional Programming. Contexts are suggested as
a solution and an extension point in org.eclipse.ui is proposed. Fine.
3. The article does consider hierarchies of contexts, see "parentId".
However, the poor sole who has to define the hierarchy of
contexts for even something as small as Eclipse itself - I pitty him/her.
I think contexts are context-free (how's that for a cool meta-statement).
In other words, a context is not bound to a parent, but a parent defines
what contexts it manages. This modification generates a sort of
multiple inheritance hierarchy (multiple contexts can claim a given
context as child and promote/demote them). From the ground up,
the implementation for Contexts should have excellent
introspection, tracing and debugging capabilities. Just image the
newsgroups: "Why doesn't my Print button show?", "Does one of
the gazillion plugins perhaps promote the "Printer Toner Low"
context?
We should promote that the hierarchy of Contexts stays
shallow. No deep, redundant hierarchies, please.
4. I propose to add the concept of "Role" - a metalevel Context.
Many discussions I have seen in this area describe users of
Eclipse playing different "roles" (architect, developer, tester,
manager, etc). If the userr role is made explicit (in the UI) menu
options that appear/disappear would not surprise the user as much.
5. Contexts will be abused for controlling the entire UI. Someone
will add a nifty small extension and make them Turing complete.
All hell will break loose then. Spaghetti code written in XML.
People will use Contexts as global boolean switches:
if (Context.isPromoted("Debugging Java")) {
new MessageDialog("Quit Fooling Around!").open();
}
6. I suggest a language change:
promote a Context -> enable a Context
demote a Context -> disable a Context
This is more palleable to non-native speakers (like me)
7. The most fundemental gripe: Command, Context, and Role
should not be defined in org.eclipse.ui, but in org.eclipse.core.
Everything in the platform is driven by what role a user plays.
Based on their role, certain plugins are loaded and shown.
Heck, the entire loading mechanism may be different. Based
on what context is enabled, help is affected (certain help
categories shown, other hidden). Nothing you don't need for
your Role is loaded at all. Has to be in core for this reason.
Many technologies have the notion of Command. Should
therefore be in a generally available place (also for
headless Eclipse incarnations).
Action is something that belongs in org.eclipse.ui.
Command is something that belongs in org.eclipse.core.actions
Chris Laffra
_______________________________________________
platform-ui-dev mailing list
platform-ui-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-ui-dev
