Eclipse Community Forums: Riena » [MacOSX/Cocoa] Ridget<->Widget binding not working when inside splash screen

Home » Eclipse Projects » Riena » [MacOSX/Cocoa] Ridget<->Widget binding not working when inside splash screen(This problem seems to be SWT-specific, but still...)

Show: Today's Messages :: Show Polls :: Message Navigator

[MacOSX/Cocoa] Ridget<->Widget binding not working when inside splash screen [message #542409]

Thu, 24 June 2010 18:06

Christian Kesselheim

Messages: 59
Registered: June 2010

Member

I found a strange problem with Riena resp. Eclipse/SWT on MacOSX/Cocoa/x86_64 that I can't really explain.

It all started when I came across the phenomena that the log-in-enabled splash screen as demonstrated by e.g. org.eclipse.riena.example.client would not work on my MacOSX/Cocoa machine (anymore?).

Digging deeper, I found that this was due to SWT not raising its focusLost()/focusGained() events when the user moves his cursor from one input field to another. On the other hand, simply setting the ridgets "direct writing" property to true or merely hitting the enter key while residing within the field still did the trick. Also, I wasn't able to reproduce this particular flaw outside the Eclipse splash screen so far.

So I wonder: Is this a known issue on MacOSX? Or is there perhaps something special about focus handling on Cocoa/SWT or the way that the Eclipse splash screen is rendered that I'm not getting yet?

Again, sorry for these dumb questions and thanks in advance Smile

.

Chris

Report message to a moderator

Re: [MacOSX/Cocoa] Ridget<->Widget binding not working when inside splash screen [message #542629 is a reply to message #542409]

Fri, 25 June 2010 13:35

Christian Campo

Messages: 597
Registered: July 2009

Senior Member

Am 24.06.10 20:06, schrieb Christian Kesselheim:
> I found a strange problem with Riena resp. Eclipse/SWT on
> MacOSX/Cocoa/x86_64 that I can't really explain.
>
> It all started when I came across the phenomena that the log-in-enabled
> splash screen as demonstrated by e.g. org.eclipse.riena.example.client
> would not work on my MacOSX/Cocoa machine (anymore?).
> Digging deeper, I found that this was due to SWT not raising its
> focusLost()/focusGained() events when the user moves his cursor from one
> input field to another. On the other hand, simply setting the ridgets
> "direct writing" property to true or merely hitting the enter key while
> residing within the field still did the trick. Also, I wasn't able to
> reproduce this particular flaw outside the Eclipse splash screen so far.
>
> So I wonder: Is this a known issue on MacOSX? Or is there perhaps
> something special about focus handling on Cocoa/SWT or the way that the
> Eclipse splash screen is rendered that I'm not getting yet?
>
> Again, sorry for these dumb questions and thanks in advance :).
>
> Chris
I am not sure what you mean by "splash screen ..... would not work".....

Maybe you wonna try to simply generate a hello world RCP example (non-Riena) and then add a splash handler with login to
it. (That a RCP functionality). Then you can tell whether thats a SWT, RCP problem or a Riena problem

christian

Report message to a moderator

Re: [MacOSX/Cocoa] Ridget<->Widget binding not working when inside splash screen [message #542679 is a reply to message #542409]

Fri, 25 June 2010 15:32

Christian Kesselheim

Messages: 59
Registered: June 2010

Member

// View.java
Text userWidget = UIControlsFactory.createText(inputArea);
addUIControl(userWidget, LoginController.RIDGET_ID_USER);

// Controller.java
ITextRidget userRidget = (ITextRidget) getRidget(RIDGET_ID_USER);
String ridgetText = userRidget.getText();
String widgetText = ((Text)userRidget.getUIControl()).getText(); // Don't do this in production code

On my Windows machine, the strings ridgetText and widgetText will be identical as soon as change propagation from widget to ridget has been properly triggered (e.g. the user has pressed enter or simply left the text field in question).

On my MacOSX, I found that this would only work for "standard" views displayed somewhere with the main shell. For views displayed from inside a splash handler though, changes are never propagated from widget to ridget unless the user really hits enter or "direct writing" has previously been set to true.

userRidget.setDirectWriting(true); // Now it works!

Wondering where this deviation in behavior between MacOSX and Windows originates from, I fired up the debugger and stepped through the code. What I found was that - on MacOSX/Cocoa and for views displayed form within a splash handler - the focusLost/focusGained events of the SWT Text widget where never raised reliably at the appropriate places (which is bad, because e.g. TextRidget relies on them to know when its internal textValue field should be updated):

// View.java
Text userWidget = UIControlsFactory.createText(inputArea);
addUIControl(userWidget, LoginController.RIDGET_ID_USER);
userWidget.addFocusListener(new FocusListener() {
	@Override
	public void focusGained(FocusEvent e) {
		System.out.println("The focus has been gained!");
	}
	
	@Override
	public void focusLost(FocusEvent e) {
		System.out.println("The focus has been lost!");
	}
});

Starting up the application, then using the keyboard or mouse to continuously move in and out of the text box created above, here's what's being displayed on Windows Vista 32bit:

... (the application starts, displaying the splash screen) ...
The focus has been gained!
The focus has been lost!
... (I start moving in and out of the field) ...
The focus has been gained!
The focus has been lost!
The focus has been gained!
The focus has been lost!
...

On MacOSX, only a singly focusGained()/focusLost() event gets raised when the splash screen is initially displayed (but NOT when I move the cursor in and out of the field after that):

... (the application starts, displaying the splash screen) ...
The focus has been gained!
The focus has been lost!
... (I start moving in and out of the field) ...

I have some ideas why this may be, all untested/nothing more than me taking a wild guess:

* Perhaps there's some special combination of SWT style bits or parent/child relationships that can trigger this behavior?
* I've seen (while digging deeper into Eclipse) that there's some special and especially nasty SWT Shell handling implemented for SWT widgets that are being displayed from within an Eclipse splash handler (e.g. see org.eclipse.ui.internal.WorkbenchPlugin.getSplashShell(displ ay)). For example, they seem to directly call Shell.internal_new(..) instead of going via the public constructor.
* Perhaps Cocoa itself is not reliably raising the focus events at times it should do so?

So far, I'm using the setDirectWriting work-around explained above, since the problem seems to only manifest itself within a splash handler. I just wanted to check with you if this was a "known issue" with Riena on MacOSX/Cocoa and whether or not there's a better work-around than mine.

Thanks again,

Chris

Report message to a moderator

Re: [MacOSX/Cocoa] Ridget<->Widget binding not working when inside splash screen [message #542756 is a reply to message #542679]

Fri, 25 June 2010 21:12

Christian Campo

Messages: 597
Registered: July 2009

Senior Member

Am 25.06.10 17:32, schrieb Christian Kesselheim:
> Sorry for not making myself clear. The problem's that - on my particular
> MacOSX/Cocoa machine at least - the Widget-to-Ridget binding (e.g.
> Text.getText() <-> ITextRidget.getText()) does not seem to work for
> views implemented as a sub-class of
> org.eclipse.riena.navigation.ui.swt.login.AbstractLoginSplas hView.
> Example:
>
>
> // View.java
> Text userWidget = UIControlsFactory.createText(inputArea);
> addUIControl(userWidget, LoginController.RIDGET_ID_USER);
>
>
>
> // Controller.java
> ITextRidget userRidget = (ITextRidget) getRidget(RIDGET_ID_USER);
> String ridgetText = userRidget.getText();
> String widgetText = ((Text)userRidget.getUIControl()).getText(); //
> Don't do this in production code
>
>
> On my Windows machine, the strings ridgetText and widgetText will be
> identical as soon as change propagation from widget to ridget has been
> properly triggered (e.g. the user has pressed enter or simply left the
> text field in question).
>
> On my MacOSX, I found that this would only work for "standard" views
> displayed somewhere with the main shell. For views displayed from inside
> a splash handler though, changes are never propagated from widget to
> ridget unless the user really hits enter or "direct writing" has
> previously been set to true.
>
> userRidget.setDirectWriting(true); // Now it works!
>
> Wondering where this deviation in behavior between MacOSX and Windows
> originates from, I fired up the debugger and stepped through the code.
> What I found was that - on MacOSX/Cocoa and for views displayed form
> within a splash handler - the focusLost/focusGained events of the SWT
> Text widget where never raised reliably at the appropriate places (which
> is bad, because e.g. TextRidget relies on them to know when its internal
> textValue field should be updated):
>
>
> // View.java
> Text userWidget = UIControlsFactory.createText(inputArea);
> addUIControl(userWidget, LoginController.RIDGET_ID_USER);
> userWidget.addFocusListener(new FocusListener() {
> @Override
> public void focusGained(FocusEvent e) {
> System.out.println("The focus has been gained!");
> }
>
> @Override
> public void focusLost(FocusEvent e) {
> System.out.println("The focus has been lost!");
> }
> });
>
>
> Starting up the application, then using the keyboard or mouse to
> continuously move in and out of the text box created above, here's
> what's being displayed on Windows Vista 32bit:
>
>
> .. (the application starts, displaying the splash screen) ...
> The focus has been gained!
> The focus has been lost!
> .. (I start moving in and out of the field) ...
> The focus has been gained!
> The focus has been lost!
> The focus has been gained!
> The focus has been lost!
> ..
>
>
> On MacOSX, only a singly focusGained()/focusLost() event gets raised
> when the splash screen is initially displayed (but NOT when I move the
> cursor in and out of the field after that):
>
>
> .. (the application starts, displaying the splash screen) ...
> The focus has been gained!
> The focus has been lost!
> .. (I start moving in and out of the field) ...
>
>
> I have some ideas why this may be, all untested/nothing more than me
> taking a wild guess:
>
> * Perhaps there's some special combination of SWT style bits or
> parent/child relationships that can trigger this behavior?
> * I've seen (while digging deeper into Eclipse) that there's some
> special and especially nasty SWT Shell handling implemented for SWT
> widgets that are being displayed from within an Eclipse splash handler
> (e.g. see org.eclipse.ui.internal.WorkbenchPlugin.getSplashShell(displ
> ay)). For example, they seem to directly call Shell.internal_new(..)
> instead of going via the public constructor.
> * Perhaps Cocoa itself is not reliably raising the focus events at times
> it should do so?
>
> So far, I'm using the setDirectWriting work-around explained above,
> since the problem seems to only manifest itself within a splash handler.
> I just wanted to check with you if this was a "known issue" with Riena
> on MacOSX/Cocoa and whether or not there's a better work-around than mine.
>
> Thanks again,
>
> Chris
>
I had Elias, one of our committers, have a look at your mail and he is quit confident that this is a SWT problem. There
is nothing in Riena about it. You are observing a different behaviour on 2 platformss in SWT. That should not be so.

So we recommend that you create an SWT bug and attach an example that does not use Riena but just plain SWT. It should
have the same problem and its easier this way for the SWT team to reproduce the problem.....

christian

Report message to a moderator

Re: [MacOSX/Cocoa] Ridget<->Widget binding not working when inside splash screen [message #586042 is a reply to message #542409]

Fri, 25 June 2010 13:35

Christian Campo

Messages: 597
Registered: July 2009

Senior Member

Report message to a moderator

Re: [MacOSX/Cocoa] Ridget<->Widget binding not working when inside splash screen [message #586057 is a reply to message #542409]

Fri, 25 June 2010 15:32

Christian Kesselheim

Messages: 59
Registered: June 2010

Member

Sorry for not making myself clear. The problem's that - on my particular MacOSX/Cocoa machine at least - the Widget-to-Ridget binding (e.g. Text.getText() <-> ITextRidget.getText()) does not seem to work for views implemented as a sub-class of org.eclipse.riena.navigation.ui.swt.login.AbstractLoginSplas hView.

Example:

// View.java
Text userWidget = UIControlsFactory.createText(inputArea);
addUIControl(userWidget, LoginController.RIDGET_ID_USER);

// Controller.java
ITextRidget userRidget = (ITextRidget) getRidget(RIDGET_ID_USER);
String ridgetText = userRidget.getText();
String widgetText = ((Text)userRidget.getUIControl()).getText(); // Don't do this in production code

On my Windows machine, the strings ridgetText and widgetText will be identical as soon as change propagation from widget to ridget has been properly triggered (e.g. the user has pressed enter or simply left the text field in question).

On my MacOSX, I found that this would only work for "standard" views displayed somewhere with the main shell. For views displayed from inside a splash handler though, changes are never propagated from widget to ridget unless the user really hits enter or "direct writing" has previously been set to true.

userRidget.setDirectWriting(true); // Now it works!

Wondering where this deviation in behavior between MacOSX and Windows originates from, I fired up the debugger and stepped through the code. What I found was that - on MacOSX/Cocoa and for views displayed form within a splash handler - the focusLost/focusGained events of the SWT Text widget where never raised reliably at the appropriate places (which is bad, because e.g. TextRidget relies on them to know when its internal textValue field should be updated):

// View.java
Text userWidget = UIControlsFactory.createText(inputArea);
addUIControl(userWidget, LoginController.RIDGET_ID_USER);
userWidget.addFocusListener(new FocusListener() {
@Override
public void focusGained(FocusEvent e) {
System.out.println("The focus has been gained!");
}

@Override
public void focusLost(FocusEvent e) {
System.out.println("The focus has been lost!");
}
});

Starting up the application, then using the keyboard or mouse to continuously move in and out of the text box created above, here's what's being displayed on Windows Vista 32bit:

... (the application starts, displaying the splash screen) ...
The focus has been gained!
The focus has been lost!
... (I start moving in and out of the field) ...
The focus has been gained!
The focus has been lost!
The focus has been gained!
The focus has been lost!
...

On MacOSX, only a singly focusGained()/focusLost() event gets raised when the splash screen is initially displayed (but NOT when I move the cursor in and out of the field after that):

... (the application starts, displaying the splash screen) ...
The focus has been gained!
The focus has been lost!
... (I start moving in and out of the field) ...

I have some ideas why this may be, all untested/nothing more than me taking a wild guess:

* Perhaps there's some special combination of SWT style bits or parent/child relationships that can trigger this behavior?
* I've seen (while digging deeper into Eclipse) that there's some special and especially nasty SWT Shell handling implemented for SWT widgets that are being displayed from within an Eclipse splash handler (e.g. see org.eclipse.ui.internal.WorkbenchPlugin.getSplashShell(displ ay)). For example, they seem to directly call Shell.internal_new(..) instead of going via the public constructor.
* Perhaps Cocoa itself is not reliably raising the focus events at times it should do so?

So far, I'm using the setDirectWriting work-around explained above, since the problem seems to only manifest itself within a splash handler. I just wanted to check with you if this was a "known issue" with Riena on MacOSX/Cocoa and whether or not there's a better work-around than mine.

Thanks again,

Chris

Report message to a moderator

Re: [MacOSX/Cocoa] Ridget<->Widget binding not working when inside splash screen [message #586068 is a reply to message #542679]

Fri, 25 June 2010 21:12

Christian Campo

Messages: 597
Registered: July 2009

Senior Member

Report message to a moderator

Previous Topic:	[MacOSX/Cocoa] Ridget<->Widget binding not working when inside splash screen
Next Topic:	Riena and Spring

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Sat Apr 20 01:53:18 GMT 2024

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter