[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [platform-swt-dev] Mouse selections in StyledText and TextViewer
|
I'd like to understand why copy/cut doesn't work in your case.
Are you implementing your own copy/cut behavior or are you just calling
StyledText.copy? If you invoke StyledText.copy and have previously changed
the selection using StyledText API the selection should be copied to the
clipboard. You should not have to call notifyListener. Anything else is a
bug and you should open a bug report (please include the code that fails).
Selection API never sends selection events. This is standard SWT behavior.
Fine grained navigation customization like you and Alan suggest was not a
requirement before. That is why customization is limited to remapping of
existing actions to other key strokes. We (SWT) don't like to add features
and functions that are not needed. It just adds to maintenance effort and
bloats the API. If we find that better customization is in fact needed we
are open to adding it (especially if we don't have to implement it <g>).
We envision the callback we mention below to be issued during each
navigation action (keyboard and mouse). It could have the default
navigation result computed by StyledText(caret offset), doit flag to
suppress the navigation entirely and select flag to enable/disable
selection. A listener could change the caret offset and the flags. The
navigation would execute all the code and sideeffects that normally run as
part of navigation, just with the user provided caret offset. This would
allow you to change any navigation action, not just word navigation.
Other than the keyboard word navigation what else did you override? Any
mouse navigation? Does the proposed API/callback seem like it would
sufficiently support what you are trying to do?
Knut
"Bob Foster" <bob@xxxxxxxxxx>
Sent by: platform-swt-dev-admin@xxxxxxxxxxx
09/18/2002 02:57 PM
Please respond to platform-swt-dev
To: <platform-swt-dev@xxxxxxxxxxx>
cc:
Subject: Re: [platform-swt-dev] Mouse selections in StyledText and TextViewer
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 -----
From: Lynne Kues
To: platform-swt-dev@xxxxxxxxxxx
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
