#92 Wonderland Java client default action on successful login should be avatar in focus

[Anonymous]

Originally created by: davekoelmeyer@gmail.com
Originally owned by: josmasfl...@gmail.com

Describe your enhancement request in detail. Explain the benefits, and
suggest possible avenues for implementation.

As soon as a user has successfully logged into a Wonderland world, the address bar ("Location") of the client is in focus. I believe that the first action a user in a 3D environment would want to take is to move around, and not in this case to enter an alternate location to the location just logged in to.

With the default behaviour, this results in characters inadvertently entered into the address bar (see attached), followed by the user having to click on the in-world display to bring it into focus - which itself is unclear for new users.

The benefit here would be reducing one IMO unnecessary set of actions for a (new) user, and allow (new) users to interact instantly with a newly logged into world.

[Anonymous]

Originally posted by: jonathan...@gmail.com

Updated milestone

Labels: Type-Defect Priority-Medium Milestone-0.5-preview5 Component-Client

[Anonymous]

Originally posted by: josmasfl...@gmail.com

Done a bit of digging here: The problem is the call to loadServer() in line 401 of JmeClientMain.java at line 513:
frame.setServerURL(serverURL);
This calls a serverField.setText(serverURL) on line 709 of MainFrameImpl.java so the focus remains there.

Adding a call to:
frame.getCanvas3DPanel().requestFocusInWindow();
after the setServerURL (513 in JmeClientMain.java) gets rid of the focus on the Location bar (although I don't think it is the solution needed here).
I cannot completely test the effects cause I'm in a Mac (focus policies are different), but at least it avoids inputing text in the location bar, but not sure how it will behave under other platforms.
Having a look at the input system, but it's going to take a while!

[Anonymous]

Originally posted by: josmasfl...@gmail.com

the following seems to work better and allow to move straight away (if the frame does not lose focus altogether!):

frame.getCanvas().requestFocusInWindow();

Attaching a patch for revision.

cheers,
José

[Anonymous]

Originally posted by: josmasfl...@gmail.com

Hey Jon, been messing about with this again but I don't think the patch was applied.

The patch actually fixes this issue in all platforms; the issue being that when you start walking, the focus is in the location bar and you get the result as in the screenshot (wwwwwwww in the bar).

The problem with Mac is that the whole window loses the focus (and the SipCommunicator gets the focus on load) but if you change to the client window with cmd+tab, you can start walking without the problems in the Location bar.
In both linux and windows lose of focus does not happen and you can start walking straight away with the patch.

I have no idea about how to steal back the focus from the SIPC on mac, and it does not seem easy.
Would you consider applying the patch? the issues are different in my opinion.

Cheers,
José

[Anonymous]

Originally posted by: jonathan...@gmail.com

I didn't realize the patch fixed the issue on other platforms -- we can definitely integrate it.

[Anonymous]

Originally posted by: josmasfl...@gmail.com

the patch fixes the issue but we are looking for a way to keep the focus on the main window on macs (it does not happen in other platforms).

Look for a way of making the SipCommunicator window go away or at least stop it from stealing focus.

Owner: josmasfl...@gmail.com
Status: Started

[Anonymous]

Originally posted by: josmasfl...@gmail.com

Hey Jon, I found this but not sure how the SIP is started... any chance of adding the flag:
java -Djava.awt.headless=true

source (with further link to more elaborate info): http://zzamboni.org/brt/2007/12/07/disable-dock-icon-for-java-programs-in-mac-osx-howto/index.html

[Anonymous]

Originally posted by: jonathan...@gmail.com

The code to start the softphone is here:

https://code.google.com/p/openwonderland/source/browse/trunk/core/src/classes/org/jdesktop/wonderland/client/softphone/SoftphoneControlImpl.java#271

Feel free to add the java.awt.headless property and see if it works. My only concern is whether you can turn off the headless option, for example when we use tools->audio->show softphone.  If not, it looks like startSoftphone() waits until the softphone process is started. So presumably you could find where that is called (probably in audio-manager), and after it returns, grab focus back to the main screen.

[Anonymous]

Originally posted by: josmasfl...@gmail.com

No luck with the flag. It crashes the softphone on startup. and it seems that making it headless friendly is somehow rather involved. http://java.sun.com/developer/technicalArticles/J2SE/Desktop/headless/

Will have a look at the other option. Thanks for the pointer!

[Anonymous]

Originally posted by: josmasfl...@gmail.com

Another quick question. The thing is that the problem here is that another 'window' takes control, so even if I can catch the latest call (or return) it will still NOT be possible to grab the focus again cause we are talking about two independent applications running in the machine... is that correct?

If the focus was somewhere else within the same application (as it used to happen with the Location bar) then it would just be a matter of asking for the focus, but this problem is different... can one app hijack the focus from a different app? would that be an OS call of some sort?

[Anonymous]

Originally posted by: josmasfl...@gmail.com

closing down this issue. The outstanding mac behaviour deserved issue 201 on its own :)

Status: Done

[Anonymous]

Originally posted by: jonathan...@gmail.com

This issue was closed by revision [r4731].

Status: Fixed

[Carlos Rafael Ramírez Castillo]

The issue happens again. But now the Text Chat window is which grab the focus