Is there another method somewhere to use @pspeed ?
Same for this?
What is it that you are trying to do?
Originally, these methods were for trying to deal with the stuff in mouse events. When CursorEvents were added, they include all of the relevant collision information so the old hacky methods weren’t necessary.
The MigLayout port does this,
@Override
public int getScreenLocationX()
{
return (int) GuiGlobals.getInstance().getScreenCoordinates(component, component.getLocalTranslation()).x;
}
@Override
public int getScreenLocationY()
{
return (int) GuiGlobals.getInstance().getScreenCoordinates(component, component.getLocalTranslation()).y;
}
@Override
public int getScreenWidth()
{
return GuiGlobals.getInstance().getCollisionViewPort(component).getCamera().getWidth();
}
@Override
public int getScreenHeight()
{
return GuiGlobals.getInstance().getCollisionViewPort(component).getCamera().getHeight();
}
Ugh… neither of which will be doing what the author intended in some cases, I guess.
It makes a lot of assumptions about the relationship between “screen” and “this is the viewport Lemur will deliver mouse events on for this spatial”.
I dont see anything that allows a componet to know its viewport. Not sure it even should know that.
I would think the best way is to use jme method.
getCamera().getScreenCoordinates(component.getLocalTranslation());
Looking at GuiGlobals, I see the camera but its just used in the constructor.
Plus, even if you can get that camera, what if the there is more than one viewport?
Any suggestion on the best approach to allow the implementations for these?
/** Returns the screen x-coordinate for the upper left coordinate of the component layout-able bounds.
* @return The screen x-coordinate for the upper left coordinate of the component layout-able bounds.
*/
public abstract int getScreenLocationX();
/** Returns the screen y-coordinate for the upper left coordinate of the component layout-able bounds.
* @return The screen y-coordinate for the upper left coordinate of the component layout-able bounds.
*/
public abstract int getScreenLocationY();
/** Returns the pixel size of the screen that the component is currently in or for the default
* screen if the component is not visible or <code>null</code>.
* <p>
* If in headless mode <code>1024</code> is returned.
* @return The screen size. E.g. <code>1280</code>.
*/
public abstract int getScreenWidth();
/** Returns the pixel size of the screen that the component is currently in or for the default
* screen if the component is not visible or <code>null</code>.
* <p>
* If in headless mode <code>768</code> is returned.
* @return The screen size. E.g. <code>1024</code>.
*/
public abstract int getScreenHeight();
Exactly.
If you want to know “screen coordinates” in some context then you have to provide the context… usually the ViewPort would be enough. So if the layout wants to provide “screen coordinates” then it will need to be passed a ViewPort.
The original (now deprecated) GuiGlobals methods were used to provide information for dragging. So the fact that the event was probably received on one of the managed picking viewports was a little better of an assumption. It was unnecessary after I added CursorEvents because the ViewPort is part of the event.
Right. The only way to really do that would be to pass it as part of the layout as a new parameter?
Everytime the layout is used?
Like
new MigLayout(viewport, layoutConstraints, colConstraints, rowConstraints)
Yeah, I don’t know how often MigLayout uses screen-related stuff (I don’t use it and never really looked at the code)… so I can’t say whether it should be a hard-requirement or not.
…but if it wants to accurately answer those questions then it needs to know which ViewPort it applies to.
I guess if you want to use outside stuff you gotta make sacrifices. Thats one heck of a constructor for a layout.
Got it running but not sure whats going to happen for every situation yet.
I am curious though. Should the viewports still work using that deprecated code though?
If you look at the lemur demo for second viewports its passing it to the pick state where its added to the list of viewports.
I think so. What is it that you believe makes them not work?
Keep in mind that mouseState and touchState are both PickState implementations.
Was wondering what cases it may not work as intended?
A Spatial can be in multiple viewports… just because you’re displaying the Spatial in one, doesn’t mean that’s the one you receive events on.
I see, like if in the minicam the same node shows in main and minicam so this only works properly if theres a single view.
And only if you’ve registered to receive events in that view.
You could also have display-only spatials that never receive events… in which case the GuiGlobals methods will not work.