[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [platform-ui-dev] Proposal for CommandStack in JFace
|
Scott,
Since it's not functionally complete for us, the Swing classes can't just
replace what GEF and EMF use. We would need to subclass the Swing
interfaces/classes and provide the complete function we need somewhere
anyway. So it doesn't really solve our problem (find a package for the
common function needed by EMF and GEF). We'd still need to do that, but
your proposal would introduce a new (different) API for a part of it.
Basically this amounts to pain with no significant gain. The only argument
for doing it is that we would be using the standard Swing API, but since
Eclipse didn't do that for anything else, I don't see any good reason why
we would want to use just this one little piece (and have to deal with all
the backward compatibility issues).
Randy,
> 1)Are arguing that they need to be in Core or some plugin higher-up?
Yes, but it's a little more complicated yet. The WebSphere Runtime folks
also want to use the common commands standalone, so they will need to be
in a separate jar.
> 2)What is missing in the proposed API that cannot be achieved in
subclasses?
Command.getAffectedObjects() is the big one, but I doubt that any
significant API breakage will be acceptable at this point. Subclassing
will involve messy instanceof checks ... not acceptable.
Frank.
Scott Stanchfield
<scott@xxxxxxxxxxxx> To: platform-ui-dev@xxxxxxxxxxx
Sent by: cc:
platform-ui-dev-admin@ Subject: RE: [platform-ui-dev] Proposal for CommandStack in JFace
eclipse.org
01/05/2003 10:19 PM
Please respond to
platform-ui-dev
You're correct in that Swing's implementation only requires undo/redo
methods and not an execute method. That could be overcome by subclassing to
add an execute. Alternatively, because the "redo" is quite often the exact
same code as the execute, the convention could be to just use the redo when
executing, and if the command needed to do something different for a "real"
redo, it could keep track of whether it is being "done" or "redone".
From what I can see, the Swing edit classes/interfaces aren't specific to
text editing; there are some implementations/subclasses that add specific
support, as that's pretty much the only area that Swing uses the command
pattern.
RE changes performed by the widget; what you're seeing is poor
implementation of the undo support interfaces being used by the text
widgets. I totally agree that the command itself should make the model
changes. However, I don't see anything in the interfaces that require this
approach. I think they could be used in exactly the same way as the GEF/EMF
commands...
Check out the javax.swing.undo.UndoManager class too -- you should be able
to add commands to the undo manager that indicate when the user saved, and
you can undo/redo to that point, as well as check if the last significant
edit (command) was a Save, which would indicate the editor is clean as
well.
So...
Based on what I'm hearing/seeing so far, I'd stand by my suggestion.
I'd definitely like to hear if I missed something else though, and I'd like
to hear from some of the EMF folks as well...
-- Scott
==============================================================
Scott Stanchfield scott@xxxxxxxxxxxx http://javadude.com
Lead author of "Effective VisualAge for Java, Version 3"
http://javadude.com/evaj
VisualAge for Java Tips and Tricks http://javadude.com/vaj
AWT & Swing FAQ Manager, jGuru.com
Visit for Java Enlightenment! http://www.jguru.com
==============================================================
-----Original Message-----
From: platform-ui-dev-admin@xxxxxxxxxxx
[mailto:platform-ui-dev-admin@xxxxxxxxxxx]On Behalf Of Randy Hudson
Sent: Sunday, January 05, 2003 8:37 PM
To: platform-ui-dev@xxxxxxxxxxx
Subject: RE: [platform-ui-dev] Proposal for CommandStack in JFace
Scott--
I'll start off by answering your first response. I knew about Swing's undo
support but have never looked at it until now. I think the main difference
between our approach and the Swing approach is that Swing is missing the
execute portion of the command. Swing's UndoableEdit is designed for a
text widget, where the change to the "model" is handled internally by the
widget, and the change is simply *documented* on the undo stack.
UndoableEdit does NOT make the change itself.
Our command has a .execute(). It is intended that the model be changed
only by the command. However, there are still cases like the ones Swing
designed for (for example, continuous typing). Editors like Page Designer
(an HTML editor) can still achieve the Swing behavior by making execute()
a no-op.
Our CommandStack offers a little more. It now contains a mechanism for
marking the save point, and then detecting when the User has undone the
stack to the save point, indicating the Editor is "clean".
Finally, Swing lets you label (and therfore translate) the command in both
directions. I recommended this at one point, but none of our translators
have identified situations where this is necessary.
Swing's classes are not a suitable alternative.
Frank--
I don't think this is something unique to Graphical or EMF-based editors,
so I don't think you are arguing that they should stay in GEF/EMF.
1)Are arguing that they need to be in Core or some plugin higher-up?
2)What is missing in the proposed API that cannot be achieved in
subclasses?
UI Team--
The TextEditor could benefit from better undo support. Lots of cool stuff
has been added to AutoIndentStrategies, but some of these features result
in two or more "edits" to the StyledText widget. The result is that a
single keystroke requires multiple undos. For an example, type a Javadoc
header '/**' in front of a method and press ENTER, then undo the change.
-Randy
Scott Stanchfield
<scott@xxxxxxxxxxxx> To:
Sent by: platform-ui-dev@xxxxxxxxxxx
platform-ui-dev-admin@eclips cc:
e.org platform-ui-dev-admin@xxxxxxxxxxx
Subject: RE:
[platform-ui-dev] Proposal for
01/04/2003 02:18 PM CommandStack in JFace
Please respond to
platform-ui-dev
This is the type of thing that would make me suggest switching both
implementations to the Swing undo framework. It's very similar (from what
I
see so far), and doesn't have any dependency on UI code (despite being
under
javax.swing.undo).
Because it's in the Java core, both EMF and GEF (as well as anything else
that wants undo support) could use it without depending on other plugins.
Thoughts?
-- Scott
==============================================================
Scott Stanchfield scott@xxxxxxxxxxxx http://javadude.com
Lead author of "Effective VisualAge for Java, Version 3"
http://javadude.com/evaj
VisualAge for Java Tips and Tricks http://javadude.com/vaj
Visit for Java Enlightenment! http://www.jguru.com
==============================================================
> -----Original Message-----
> From: platform-ui-dev-admin@xxxxxxxxxxx
> [mailto:platform-ui-dev-admin@xxxxxxxxxxx]On Behalf Of frankb@xxxxxxxxxx
> Sent: Saturday, January 04, 2003 2:12 PM
> To: platform-ui-dev@xxxxxxxxxxx
> Cc: platform-ui-dev@xxxxxxxxxxx; platform-ui-dev-admin@xxxxxxxxxxx
> Subject: Re: [platform-ui-dev] Proposal for CommandStack in JFace
>
>
> This proposal isn't acceptable for EMF. EMF's common commands are UI
> independent - they can't have a dependency on JFace. The proposed API is
> also not sufficient.
>
> Frank.
>
>
>
>
>
>
> Randy
>
> Hudson/Raleigh/IBM@IBM To:
> platform-ui-dev@xxxxxxxxxxx
>
> US cc:
>
> Sent by: Subject:
> [platform-ui-dev] Proposal for CommandStack in JFace
>
> platform-ui-dev-admin@
>
> eclipse.org
>
>
>
>
>
> 01/03/2003 06:11 PM
>
> Please respond to
>
> platform-ui-dev
>
>
>
>
>
>
>
>
>
>
> GEF provides a Command and CommandStack implementation. This should be
> moved into JFace (which was proposed _too_ late during the 2.0
> developement
> cycle).
>
> Other technologies such as EMF [Edit] also require their own Command and
> CommandStack. We have both invented the wheel. When plugins
> combine GEF and
> EMF, it becomes difficult to deal with multiple definitions of the same
> concept/classes.
>
> Attached is a proposal for a Command and CommandStack implementation.
> Moving them into JFace will simplify future WSAD releases as well as the
> work of others who are combining the "Tools" plugins mentioned above.
>
> We are considering one more feature for the CommandStack (the ability to
> append to an executing command), but the code itself it pretty simple
and
> stable ;-)
>
> -Randy
>
>
>
>
> #### JFaceCommands.jar has been removed from this note on January 04
2003
> by Frank Budinsky
>
>
> _______________________________________________
> platform-ui-dev mailing list
> platform-ui-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/platform-ui-dev
>
_______________________________________________
platform-ui-dev mailing list
platform-ui-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-ui-dev
