[
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 knew you would figure out your copy.cut problem! In general, when
dealing with JFace I believe it is better to use high level API instead of
immediately going down to the SWT widget level. JFace just adds a lot of
abstractions that you probably want to use in the context of Eclipse
plugins. Setting the selection is the best example because it sends the
general JFace selection events in addition to doing some documenty things
that I haven't bothered to understand...
About the callback: Yes, inside the callback (listener method) you would
still be able to query the old selection using StyledText API. Only when
the listener returns to StyledText would the selection be updated.
After some more thought, we probably want to treat the customizable
navigation and the customizable selection as separate issues. The
SelectionEvent already has one user (Sash) that allows modifying the x, y
and doit fields. Instead of creating a NavigationEvent (or whatever) with
an odd, new select field (after all, different == bad) it's better to just
have the regular x, y and doit field and leave selection customization to
the SelectionEvent.
You would still be able to have any key trigger a selection using the key
binding API. Keys mapped to a navigation action (e.g., WORD_NEXT) would
just send the NavigationEvent and keys mapped to a selection action (e.g.,
SELECT_WORD_NEXT) would first send a navigation event and then a selection
event (which we already do of course but we ignore any changes to x, y,
doit). Of course, by the time someone actually tries to implement this it
may still turn out to be a bad idea.
Knut
"Bob Foster" <bob@xxxxxxxxxx>
Sent by: platform-swt-dev-admin@xxxxxxxxxxx
09/19/2002 02:54 PM
Please respond to platform-swt-dev
To: <platform-swt-dev@xxxxxxxxxxx>
cc:
Subject: Re: [platform-swt-dev] Mouse selections in StyledText and TextViewer
From: "Knut Radloff" <knut_radloff@xxxxxxx>
> 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.
Well, it turns out that looking at StyledText was just confusing me, but
here's the story. All of the internal actions in StyledText that affect
the
selection end with clearSelection(true) or doSelection(direction), both of
which send selection events and neither of which are public, nor is there
any public way to reach these methods. Far as I can tell, if you use
StyledText public API you can't get a selection event sent, and this
meant,
in my case, Cut/Copy were not enabled. So I hacked around it.
What I should have done was ask, who is enabling Cut/Copy? Anyway, you
made
me look. ;-} My editor, like many others, is a subclass of
AbstractTextEditor which adds a selectionChangedListener to its
SourceViewer
which, in turn, adds a selectionListener to StyledText. AbstractTextEditor
enables/disables Cut, Copy, Paste, Delete, Shift Right and Shift Left
based
on this listener. Lo and behold, TextViewer has its own selection api that
uses the StyledText api and then sends out its own style of selection
event,
just as it does for events StyledText originates. If I had used the viewer
api instead of StyledText I would have been fine.
So there is already a way to work around the "standard SWT behavior". Case
closed. I expect the answers to a lot of questions about why the viewer
seemingly duplicates API already found in the widget are found in details
like this.
> 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>).
I'm happy you're proposing to address it.
> 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.
Sounds pretty good. I assume a callback can get the information about the
state just prior to the navigation event through the standard api.
> 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?
Mouse navigaton? You mean like how mouse selection works, auto-scrolling?
I
would never touch that.
Bob
>
> "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
>
>
>
>
> _______________________________________________
> 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
