JFace aside, some changes are needed in StyledText.
I have overridden the navigation key behaviors in an editor, using addVerifyKeyListener() from SWT. My first thought, like
Alan's I guess, was to look for the hook to replace the definition of
a 'word'. I was very surprised to see the definition hard-coded in StyledText -
talk about low-level decision-making! - with no way to override it.
addVerifyKeyListener() requires you to change all of the behavior of the key or
none. As Alan says, this is requires you to duplicate internal StyledText
functionality, which may not be obvious.
For example, changing the behavior of
CONTROL+SHIFT+ARROW_left-or-right requires setting the selection. However, none
of the public selection setting methods notify selection listeners, so, e.g., a
subsequent Copy or Cut doesn't work. To work around this I had to explicitly
call text.notifyListeners(SWT.Selection, event), which assumes way
more internal behavior than I would have liked.
Even if there is such a method that I missed,
implementing this required way too much code reading. ;-}
My $.02.
Bob
----- Original Message -----
Sent: Wednesday, September 18, 2002 12:03
PM
Subject: RE: [platform-swt-dev] Mouse
selections in StyledText and TextViewer
Alan, thanks for
your comments and ideas. We have added our two cents and you may not
agree with everything we say, but lets keep talking...
You seem like you are interested in changing
the basic Eclipse editor behavior. As we indicate below, the way to do
this is in JFace Text. The StyledText widget is a low-level widget,
designed not only for Eclipse editors. Some of the abstractions you
would like ** do ** make sense, but from an SWT standpoint these abstractions
would better exist in JFace - not SWT. We elaborate on this more
below...
Lynne &
Knut
----- Forwarded
by Lynne Kues/RAL/OTI on 09/17/2002 09:23 AM -----
| "Alan Oursland"
<alan@xxxxxxxxxxxx> Sent by: platform-swt-dev-admin@xxxxxxxxxxx
09/16/2002 05:42 PM Please respond to platform-swt-dev
| To:
<platform-swt-dev@xxxxxxxxxxx> cc:
Subject: RE: [platform-swt-dev]
Mouse selections in StyledText and
TextViewer |
I went through the plug-in development tutorials on eclipse.org when
I started looking at 2.0. It would probably be helpful to revisit
them.
I am not really interested in just extending the behavior of the
Java editor. I want the same basic functionality for my editor regardless
of the type of file I am editing. And, like most people, I want that
functionality to work like the editor to which I am accustomed.
When
editing a generic text file, double-clicking to select words did
not operate the way I expected (try opening a text file, double click,
and drag). Since eclipse is open source, I thought I would figure out how
to fix it instead of filing a bug report and waiting for a fix. What I
found in the code was that some of the UI handling was being done in
StyledText and some of it in TextViewer. The code in StyledText looked like
it operated correctly, but the functionality was overridden TextViewer with
an implementation that didn't work correctly, seemed overly specific,
and lacked customization ability. Some of the overly specialized code seems
to have leaked into StyledText as well (setDoubleClickEnabled?). I am not
sure why TextViewer developers felt the need to reimplement functionality.
I suspect they wanted to do something that StyledText didn't let them
easily change.
I'm
not sure why TextViewer changed the double click behavior either - would be a
good question for the newsgroup. Even so, if you want to customize the
StyledText's double click behavior, the way to do this is to
setDoubleClickEnabled(false) and then provide your own behavior. This is
what the TextViewer does. The way to change the behavior for all of your
Eclipse editors would be to supply your own double click strategy for
TextViewers.
I probably don't
have a good enough model of the purpose of StyledText, but it seemed to me
that making StyledText more customizable would be a good step towards
getting the UI features that I want.
The StyledText widget is a generic text widget. It does
not exist solely to support the Eclipse editors. When you think of
Eclipse editor behavior, you should be thinking of JFace Text, not the
StyledText widget. The StyledText is just a building block and its goal
is to provide a customizable text widget. Its default behavior is based
on the lowest common denominator (think Notepad).
StyledText has bidi (which I find phenomenally
impressive) and single-line modes which introduce navigation subtleties.
Overriding the navigation capabilities of StyledText seems like a bad idea.
Classes overriding this behavior would need to reimplement that subtle
behavior. If a bug is fixed in StyledText, or a new feature is added, the
changes would need to propagated to several pieces of code. Overall it
sounds like a maintenance nightmare for developers and a bug nightmare for
users. If I am correct that the navigation functionality shouldn't be
overridden, then StyledText should provide ways to customize navigation.
Currently, CTRL-ARROW_RIGHT navigates across words where a word is defined
by the method getWordEnd(). If I want to change the definition of a word
according to a specific language, I either need to override the class and
method (which isn't how TextViewer works), or reimplement the navigation
(and introduce subtle bugs).
The changes I proposed in the previous message were really just a
first step of an effort to try to generalize navigation and selection in
StyledText so that other classes can customize the behavior better. These
changes include: - abstraction of navigation.
- addition of a selection mode. - customization of
navigation steps
Support for customizing selection (both
mouse and keyboard) is a valid request. Handling this would entail
something like setSelectionEnabled(boolean) or providing a callback like the
VerifyKeyEvent in which we would pass what we're about to select and one could
set the doit flag to false if they didn't want the default select to occur.
Then the StyledText user could provide the selection behavior they
wanted. This approach maintains the SWT-way.
Currently, selection and navigation are handled separately.
Accessibility design discourages the use of frequent multiple key commands.
It should be possible to perform actions like SHIFT-ARROW_RIGHT using
single keys. One way I have seen this done is to do this is to make
selection a mode. If I turn selection on and press ARROW_RIGHT, it does the
same thing that SHIFT-ARROW_RIGHT does. For example, the code mapped to
ARROW_RIGHT might look like: doCursorNext(); The code
mapped to SHIFT-ARROW_RIGHT might look like:
setSelectionMode(true); doCursorNext();
setSelectionMode(false);
setSelectionMode has the following
behavior: - If set to true and there is currently a selection, just set the
selection mode to true. - If set to true and there is not currently a
selection, record the current caret position and set selection mode to
true - If set to false, set the select mode flag to
false.
This behavior
(setSelectionMode) could currently be implemented with the StyledText API.
You could keep track of the "single keystroke select mode" and map
cursorNext to selectCursorNext, etc.
when in this
mode.
Depending on the language
I am using, a 'word' might be defined differently. I may always want
CTRL-ARROW_RIGHT to the next word, but I want the word definition to change
based on the type of document I am editing. If StyledText should be
handling all navigation, then it should provide a way to change navigation
blocks. Again, for accessibility reasons, it would be good to have a
navigation mode. For example, the code mapped to ARROW_RIGHT might look
like: doCursorNext(); The code mapped to CTRL-SHIFT-RIGHT
might look like: setNavigationMode(wordLexar);
setSelectionMode(true); doCursorNext();
setSelectionMode(false);
setNavigationMode(defaultLexar);
IDocument has the interface IDocumentPartitioner, but it seems to
be designed to maintain a lot of state about a specific document.
Because navigation generally deals with partition boundaries adjacent to a
single point, runtime lexing is probably sufficient (which is what the code
does now anyway). An IContentPartitioner with methods "int
nextPartition(int, StyledTextContent)" and "int prevPartition(int,
StyledTextContent)" is probably sufficient.
doCursorNext() would be generalized to perform all
of the "next" navigation and would look something like: int
newOffset; int newLine; if( isSelectionOn() ==
false && selection.y - selection.x > 0 ) {
caretOffset = selection.y; caretLine =
content.getLineAtOffset(caretOffset);
showCaret(); } else {
newOffset = partitioner.nextOffset( caretOffset, content );
newLine = content.getLineAtOffset(newOffset);
// only go to next line if not in single line mode. fixes
5673 if( !isSingleLine() || newLine == caretLine
) { // Remember the last
direction. Always update lastCaretDirection,
// even though it's not used in non-bidi mode in order to
avoid // extra methods.
lastCaretDirection =
ST.COLUMN_NEXT; caretOffset =
newOffset; caretLine =
newLine; showCaret();
} }
To recap, what you would like to do is have a way to define
what a word/line/etc. is and to be able to use this definitions for your
specific navigation and selection purposes. Right? Currently, the
StyledText widget will let you remap your navigation keys and you could
override selection behavior (if we add the support for this or you can try
doing it via hooking MouseEvents), but even so, you feel this is not
sufficient because of the "what is a word/line/etc" concept?
We're not sure how this
should be handled. However, leaking JFace Text into the StyledText
widget is not acceptable. Concepts of partitions, etc. are
JFace-related. If we wanted to support this "word/line/etc" concept in
the StyledText widget, we would have to do something much more
basic/low-level. For example, providing a callback during keyboard
navigation in which one could provide a different caret offset.
What do these changes buy? - they
make sure that navigation in editors using StyledText happen correctly
regardless of the settings in StyledText - they allow editors based on
StyledText to customize functionality without reinventing the wheel. -
better code reuse. It combines similar function and pulls other
generic functionality into new classes (like finding the next word).
Smaller class files are generally easier to understand and maintain. -
better accessibility support
Could this be done with a plug-in? Maybe,
but the intent of the proposed changes is to improve the generality of the
library so the jface editor doesn't have to try to reimplement
functionality.
The
place to do this is in a plugin or JFace Text. We can provide low-level
support in the StyledText widget, but the majority of the "smarts" will have
to be in JFace or a plugin. How to do this from a JFace standpoint
should be posted to the newsgroup. We really think you should introduce
your own plugin. If it turns out that you cannot do what you want easily
(once we give you the low-level SWT support you would need) with the existing
API, extension points, etc., then you should post to the platform.ui.dev
mailing list.
I am also willing
to write this myself if you guys are too busy. I want to make sure it will
get used before I work on it though. If you have junit tests for StyledText
it should be pretty easy to make the changes transparent to the rest of the
system.
Okay, we would
need to first decide upon SWT-like API. Then you could submit the
changes. The changes would have to be reviewed. Note that
StyledText junit tests exist, but these do not address keyboard navigation.
You could add these as part of any changes you submit (you would have to
code something based on invokeAction and there would be a lot of variations).
The junit tests are in the org.eclipse.swt.tests project.
Alan Oursland
-----Original
Message----- From: Lynne Kues [mailto:Lynne_Kues@xxxxxxx] Sent: Friday,
September 13, 2002 2:25 PM To: alan@xxxxxxxxxxxx Cc:
knut_radloff@xxxxxxx Subject: Re: [platform-swt-dev] Mouse selections in
StyledText and TextViewer
"Alan Oursland"
<alan@xxxxxxxxxxxx> Sent by:
platform-swt-dev-admin@xxxxxxxxxxx 09/12/2002 04:06 PM Please respond to
platform-swt-dev
To:
<platform-swt-dev@xxxxxxxxxxx>
cc: Subject:
[platform-swt-dev] Mouse selections in StyledText and
TextViewer
I have been looking at the code for selecting text with
the mouse in the text editor. It looks like StyledText implements most of
it and then TextViewer implements it again.
I have also noticed that
selection actions are pretty much hardcoded to the mouse events.
I
would like to rewrite the mouse selection code so that: a) it works like
the editor in MS Visual Studio by default b) it is customizable
My
main reservation with this endeavor is that I have zero understanding
of how changes will affect plug-ins that other people have written.
Could someone provide any information on this and how I can avoid
impact.
Have you looked at the Platform Plug-in Developer and the JDT
Plug-in Development Guides? These guides discuss how to plug-in to
the workbench in order to extend the existing behavior. There is also
an example of creating a customized Java Editor.
The
JavaSourceViewerConfiguration is intended to be used for customizing
the JavaEditor, but it doesn't look like it gives you what you need.
This is really a JDT issue (vs. an SWT issue). The question
being "How do I extend the Java Editor selection behavior?" The
JavaSourceViewerConfiguration class references a text editor and if you
could access this variable you could hook the mouse events and provide
special processing (see discussion below), but there is not API for doing
this, nor is the class intended to be subclassed.
The changed I
would like to make are: I. get rid of IDoubleClickStrategy and all support
(affects ITextViewer, TextViewer, and SourceViewerConfiguration)
Why
not just introduce a DoubleClickStrategy that does nothing/what you want?
As I understand it, this is the intended use
of SourceViewerConfiguration (i.e., you can customize the given
behavior).
II. introduce a new more general model for customizing mouse
selection in StyledText where:
a) A mouse down event (including multi-clicks):
- clears the current selection unless shift is pressed
(shift always extends selections)
-
records a selection start position.
-
uses modifiers (ctrl, alt, click-count) to find a content
partitioning object.
- sets the
selection to the left and right bounds of the partition in which the
mouse was pressed.
- begins
autoscrolling b) A
mouse move event
- makes sure a mouse
drag selection is taking
place
- gets the correct content
partitioning based on modifiers
-
extends the selection to the left and right bounds of the
partitions that the start position and current mouse position
span. c) A mouse up
event
- ends autoscrolling
I think
you could do this by hooking the MouseEvents on the StyledText widget for
the editors in which you want this behavior. Have you tried this at
all (hooking the events on a StyledText widget and supplying the additional
selection behavior)? The content partitioning is supported via JFace
Text. See below. You shouldn't change StyledText, but either
extend the existing editors or introduce your own editor.
Content
Partitioning objects define partitions within content. I am pretty sure I
remember seeing something like this in Eclipse already, but it doesn't seem
to be associated with StyledTextContent. You might have different
partitioning objects for words, lines, programming scopes, or whatever.
Each editor would be able to map mouse modifiers to their own custom
partitioning object. A default, or null, partitioning object would indicate
single character partitioning.
The org.eclipse.jface.text.* packages
have this support.
Note that there is no functional difference between
MouseClick and MouseDoubleClick events. Ideally, this should also be able
to handle triple clicks, if the event model were to support it.
What
this does not support is block selection. To do that, I think
that selection state would need to be encapsulated inside an object, or
multiple selections would need to be supported in the widget (which doesn't
make a lot of sense to me).
I would appreciate any comments on
this.
Alan
Oursland
_______________________________________________ platform-swt-dev
mailing
list platform-swt-dev@xxxxxxxxxxx http://dev.eclipse.org/mailman/listinfo/platform-swt-dev
_______________________________________________ platform-swt-dev
mailing
list platform-swt-dev@xxxxxxxxxxx http://dev.eclipse.org/mailman/listinfo/platform-swt-dev
|