Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » GEF » Focus display and traversing
Focus display and traversing [message #178573] Wed, 20 April 2005 21:02 Go to next message
Eclipse UserFriend
Originally posted by: bo.n0spam.majewski.com

I noticed that the logical example displays focus and allows focus
traversing, using arrow keys. Could some kind soul point me to the code
that does exactly this. I need to enable the same feature in our
application.
Re: Focus display and traversing [message #178590 is a reply to message #178573] Wed, 20 April 2005 21:36 Go to previous messageGo to next message
Pratik Shah is currently offline Pratik ShahFriend
Messages: 1077
Registered: July 2009
Senior Member
In configureGraphicalViewer() method of your Editor, set a
GraphicalViewerKeyHandler as the handler for the graphical viewer.
The specific method in the class GraphicalViewerKeyHandler is
navigateNextSibling().

"Bo Majewski" <bo@n0spam.majewski.com> wrote in message
news:d46g3i$evt$1@news.eclipse.org...
> I noticed that the logical example displays focus and allows focus
> traversing, using arrow keys. Could some kind soul point me to the code
> that does exactly this. I need to enable the same feature in our
> application.
Re: Focus display and traversing [message #178617 is a reply to message #178590] Wed, 20 April 2005 22:10 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: bo.n0spam.majewski.com

Pratik Shah wrote:
> In configureGraphicalViewer() method of your Editor, set a
> GraphicalViewerKeyHandler as the handler for the graphical viewer.
> The specific method in the class GraphicalViewerKeyHandler is
> navigateNextSibling().

Excellent, thanks! Now one more question. How do cause GEF to call the
showFocus method?

I return a NonResizableEditPolicy from the createChildEditPolicy method
of the XYLayoutEditPolicy instance. Yet the showFocus never seems to be
called. I traced it back to the fact that setFocus is always called with
false. I explicitly set in the figure focus flags

this.setRequestFocusEnabled(true);
this.setFocusTraversable(true);

But that does not seem to have any result.
Re: Focus display and traversing [message #178633 is a reply to message #178617] Wed, 20 April 2005 22:32 Go to previous messageGo to next message
Pratik Shah is currently offline Pratik ShahFriend
Messages: 1077
Registered: July 2009
Senior Member
It should be getting called. SelectionEditPolicy (which is what a
NonResizableEditPolicy is) is listening for selection changes on its host
editpart. See SelectionEditPolicy#addSelectionListener(). So, the flow is:
key handler determines the next editpart, and sets it as the focus part on
the viewer; the viewer updates the editpart's selection state, which
notifies the editpolicy, which then shows the focus. It should be simple to
debug and see which step is failing.

"Bo Majewski" <bo@n0spam.majewski.com> wrote in message
news:d46k2k$j7d$1@news.eclipse.org...
> Pratik Shah wrote:
> > In configureGraphicalViewer() method of your Editor, set a
> > GraphicalViewerKeyHandler as the handler for the graphical viewer.
> > The specific method in the class GraphicalViewerKeyHandler is
> > navigateNextSibling().
>
> Excellent, thanks! Now one more question. How do cause GEF to call the
> showFocus method?
>
> I return a NonResizableEditPolicy from the createChildEditPolicy method
> of the XYLayoutEditPolicy instance. Yet the showFocus never seems to be
> called. I traced it back to the fact that setFocus is always called with
> false. I explicitly set in the figure focus flags
>
> this.setRequestFocusEnabled(true);
> this.setFocusTraversable(true);
>
> But that does not seem to have any result.
Re: Focus display and traversing [message #178640 is a reply to message #178633] Wed, 20 April 2005 23:20 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: bo.n0spam.majewski.com

Pratik Shah wrote:
> editpart. See SelectionEditPolicy#addSelectionListener(). So, the flow is:
> key handler determines the next editpart, and sets it as the focus part on
> the viewer; the viewer updates the editpart's selection state, which
> notifies the editpolicy, which then shows the focus. It should be simple to
> debug and see which step is failing.

I see the following:

1. GraphicalViewerKeyHandler.navigateTo calls getViewer().select(part).
The part is correctly set to the part managing selected object

2. ScrollingGraphicalViewer.select calls appendSelection(editpart) with
the selected part. The selected part is still valid.

3. ScrollingGraphicalViewer.appendSelection(EditPart editpart) compares
the editpart with the focusPart. The latter is null. As a result, it
sets the focus to null (setFocus(null)).

Later, the part.hasFocus() returns false consistently, as it is never
given focus.

The focusPart, defined in the AbstractEditPartViewer class remains
stubbornly null throughout the life of the program. It seems that the
only way to set it is via setFocus method. However, this one is called
with null, as the non-null value in appendSelection causes a call to
setFocus with null as the parameter.

I guess I don't understand why the appendSelection method uses the
following code:

if (editpart != focusPart)
setFocus(null);

I re-implemented the createGraphicalViewer method as follows, and it
gives me the selection rectangle:

protected void createGraphicalViewer(Composite parent) {
GraphicalViewer viewer = new ScrollingGraphicalViewer() {
public void appendSelection(EditPart editpart) {
super.appendSelection(editpart);
if (editpart != focusPart) {
setFocus(editpart);
}
}
};
viewer.createControl(parent);
setGraphicalViewer(viewer);
configureGraphicalViewer();
hookGraphicalViewer();
initializeGraphicalViewer();
}

I am using GEF 3.0.1 ... maybe this has been changed in subsequent
releases ...
Re: Focus display and traversing [message #178777 is a reply to message #178640] Thu, 21 April 2005 21:07 Go to previous messageGo to next message
Pratik Shah is currently offline Pratik ShahFriend
Messages: 1077
Registered: July 2009
Senior Member
Okay, I am a little confused...are you talking about focus or selection?
GEF doesn't show focus when a part is selected (since it's already showing
selection handles feedback, and focus feedback is just annoying). However,
if you hit Ctrl + arrow key in the logic example, it will show focus (since
the part now has focus, but no selection). Only when you do this will
showFocus() be called.

"Bo Majewski" <bo@n0spam.majewski.com> wrote in message
news:d46o6j$mmu$1@news.eclipse.org...
> Pratik Shah wrote:
> > editpart. See SelectionEditPolicy#addSelectionListener(). So, the flow
is:
> > key handler determines the next editpart, and sets it as the focus part
on
> > the viewer; the viewer updates the editpart's selection state, which
> > notifies the editpolicy, which then shows the focus. It should be
simple to
> > debug and see which step is failing.
>
> I see the following:
>
> 1. GraphicalViewerKeyHandler.navigateTo calls getViewer().select(part).
> The part is correctly set to the part managing selected object
>
> 2. ScrollingGraphicalViewer.select calls appendSelection(editpart) with
> the selected part. The selected part is still valid.
>
> 3. ScrollingGraphicalViewer.appendSelection(EditPart editpart) compares
> the editpart with the focusPart. The latter is null. As a result, it
> sets the focus to null (setFocus(null)).
>
> Later, the part.hasFocus() returns false consistently, as it is never
> given focus.
>
> The focusPart, defined in the AbstractEditPartViewer class remains
> stubbornly null throughout the life of the program. It seems that the
> only way to set it is via setFocus method. However, this one is called
> with null, as the non-null value in appendSelection causes a call to
> setFocus with null as the parameter.
>
> I guess I don't understand why the appendSelection method uses the
> following code:
>
> if (editpart != focusPart)
> setFocus(null);
>
> I re-implemented the createGraphicalViewer method as follows, and it
> gives me the selection rectangle:
>
> protected void createGraphicalViewer(Composite parent) {
> GraphicalViewer viewer = new ScrollingGraphicalViewer() {
> public void appendSelection(EditPart editpart) {
> super.appendSelection(editpart);
> if (editpart != focusPart) {
> setFocus(editpart);
> }
> }
> };
> viewer.createControl(parent);
> setGraphicalViewer(viewer);
> configureGraphicalViewer();
> hookGraphicalViewer();
> initializeGraphicalViewer();
> }
>
> I am using GEF 3.0.1 ... maybe this has been changed in subsequent
> releases ...
Re: Focus display and traversing [message #178793 is a reply to message #178777] Thu, 21 April 2005 22:37 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: bo.n0spam.majewski.com

Pratik Shah wrote:
> Okay, I am a little confused...are you talking about focus or selection?
> GEF doesn't show focus when a part is selected (since it's already showing
> selection handles feedback, and focus feedback is just annoying). However,
> if you hit Ctrl + arrow key in the logic example, it will show focus (since
> the part now has focus, but no selection). Only when you do this will
> showFocus() be called.

Ah, so ... :-) OK, it works with Ctlr+Arrow without overriding the
appendSelection method.

The primary reason for having focus AND selection are the Match Width
and Match Height actions. I thought that I can show with focus what is
the primary selection. This then indicates to the user which object is
going to used as the template for height or width operations. Now I
noticed that primary selection is indicated with filled handles and
non-primary with empty ones.

Any-who, thanks for your help!
Re: Focus display and traversing [message #178869 is a reply to message #178793] Fri, 22 April 2005 20:06 Go to previous message
Eclipse UserFriend
Originally posted by: none.us.ibm.com

The alignment/match actions are indicated by the handles which are black.
All the other handles should be white.

Focus also appears if you are on a selected editpart, and press CTRL+SPACE,
to deselect it.

"Bo Majewski" <bo@n0spam.majewski.com> wrote in message
news:d49a2f$gqs$1@news.eclipse.org...
> Pratik Shah wrote:
>> Okay, I am a little confused...are you talking about focus or selection?
>> GEF doesn't show focus when a part is selected (since it's already
>> showing
>> selection handles feedback, and focus feedback is just annoying).
>> However,
>> if you hit Ctrl + arrow key in the logic example, it will show focus
>> (since
>> the part now has focus, but no selection). Only when you do this will
>> showFocus() be called.
>
> Ah, so ... :-) OK, it works with Ctlr+Arrow without overriding the
> appendSelection method.
>
> The primary reason for having focus AND selection are the Match Width and
> Match Height actions. I thought that I can show with focus what is the
> primary selection. This then indicates to the user which object is going
> to used as the template for height or width operations. Now I noticed that
> primary selection is indicated with filled handles and non-primary with
> empty ones.
>
> Any-who, thanks for your help!
Previous Topic:Initializing the viewport scroll to location in a scrollable compartment
Next Topic:Header for a GEF editor
Goto Forum:
  


Current Time: Sun Feb 05 15:23:19 GMT 2023

Powered by FUDForum. Page generated in 8.16223 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top