next »

[horati]

Has anybody implemented any LayoutManagers?  I don't see any implementations in xith3d or xith-tk.  And I guess most importantly, will a LayoutManager implementation do anything or is this the start of something that never got integrated?

[Marvin Fröhlich]

Has anybody implemented any LayoutManagers?  I don't see any implementations in xith3d or xith-tk.  And I guess most importantly, will a LayoutManager implementation do anything or is this the start of something that never got integrated?

No, a LayoutManager was never needed before. What kind of LM do you need?

Marvin

[horati]

As you know, I'm the first user to seriously use a resizeable HUD.  When the outside world resizes my canvas, it simply makes all X3D stuff bigger or smaller.  This is great for the perspective graph but not great for the HUD.  To deal with my resolution issues that you and I discussed Saturday, I am simply setting both my canvas and the HUD to the resolution of the user's screen.  X3D is smart enough to scale this down to the appropriate size and everything about that works great when I resize through a variety of methods.

My screen is set to 1680x1050 but all the text is extremely squished when I resize the HUD to 1198 x 410.  I can calculate sizes using

Code:

        org.eclipse.swt.widgets.Canvas foo = ( org.eclipse.swt.widgets.Canvas ) scene.getCanvas().get3DPeer().getComponent();
        foo.getDisplay().getDPI();

if I have to.  As a user I would like the following features:

• Text always displays at a reasonable size
• Scrollbars appear as needed (always on is an acceptable version 1 alternative)
• WidgetContainers can have a min/max/preferred visual size

It appears that resolution is a way to get at least some of these features, perhaps all of them.

When I constructed MyHud extends HUD and called

Code:

        super( width, height, width, height, scene.getOperationScheduler() );

and inspected what was happening using

Code:

    @Override
    public void setSize( int canvasWidth, int canvasHeight, float resX, float resY )
    {
        super.setSize( canvasWidth, canvasHeight, resX, resY );
        if( DebugHelper.DEBUG )
        {
            System.out.printf( "Hud resize=%d x %d  (%f x %f)\n", canvasWidth, canvasHeight, resX, resY );
        }
    }

I received resolution of 1.0 x 1.0.  Does that mean that HUD resolution is simply a ratio of HUD coordinates / Canvas coordinates?  Based on the HUD documentation, I was very unclear exactly what value was expected.

Since I'm just now creating my HUD, I don't know exactly what LMs I need.  I'm used to Swing or JGoodies LMs and will be happy to write one or two if the framework is there to use them.

[Marvin Fröhlich]

The HUD's resolution is a logical resolution, that is internally converted to SceneGraph's resolution to get the coordinates for a Widget. It's quite strange, that you get 1.0x1.0. It should be 1680x1050 (fixed) when you set it to a certain resolution. Try to dump not these resX and resY parameters, but getResx() and getResY(). I guess, the values you got are actually -1.0x-1.0, but not positive. It is a special value for the setSize() method, that is used to not manipulate the current resolution. getResX() and getResY() will return the actual values.

The Font sizes are a problem, that I know of. when all other problems, that occurred here on the board recently are fixed I will proceed with the Text2D speedup, that I was working on. In the same time I can try to fix the HUD Font size problem when the HUD is resized.

The Canvas3D's size should be returned by Canvas3D.getWidth() and .getHeight(). If it is not, there's a bug, that must be fixed.

I didn't exactly understant, what the problem with the scrollbars is. Could you maybe explain a little more?

There is a framework for LMs. Any WidgetContainer instance can get its own LM through the setLayoutManager() method. But as you can imagine, it has never been tested, since there are no LM implementation yet . Though these min/max/preferred sizes are not available yet.

If I would implement LMs I wouldn't write them exactly like known from AWT/Swing. AWT's LMs suck a little bit. Many of them don't behave the way I would expect. So I would write them more "convenient". E.g. The GridLayout is useless for very most cases and the GridBagLayout is bloated. I would write a GridLayout a way, that allows to define column widths and row heights... just an example.

Marvin

[horati]

Reviewing my trace statements

Rectangle {0, 0, 1680, 1050}
Hud resize=1680 x 1050  (1680.000000 x 1050.000000)
WARNING: Theme "GTK" could not be loaded. Using Fallback-Theme
Hud resize=1680 x 1050  (-1.000000 x -1.000000)
Hud resize=1198 x 577  (-1.000000 x -1.000000)
Hud resize=1198 x 410  (-1.000000 x -1.000000)

it appears that resolution was set the first time.  If I understand correctly, the Canvas3D coordinate size remains the same and scales when its parent component resizes.  This seems to work great so let's keep that.

I tried replacing setSize() with the following

Code:

   @Override
    public void setSize( int canvasWidth, int canvasHeight, float resX, float resY )
    {
        super.setSize( canvasWidth, canvasHeight, canvasWidth, canvasHeight );
        if( DebugHelper.DEBUG )
        {
            System.out.printf( "Hud resize=%d x %d  (%f x %f)\n", canvasWidth, canvasHeight, resX, resY );
        }
    }

and this moved everything around pretty much as expected and everything seems to have a stable visual size.  I need to play some more (tried a dozen passes that I didn't comment on LOL) to see what works best, but this change helps a lot.

The HUD's resolution is a logical resolution, that is internally converted to SceneGraph's resolution to get the coordinates for a Widget. It's quite strange, that you get 1.0x1.0. It should be 1680x1050 (fixed) when you set it to a certain resolution. Try to dump not these resX and resY parameters, but getResx() and getResY(). I guess, the values you got are actually -1.0x-1.0, but not positive. It is a special value for the setSize() method, that is used to not manipulate the current resolution. getResX() and getResY() will return the actual values.

Code:

            System.out.printf( "Hud resize=%d x %d  (%f x %f)\n", canvasWidth, canvasHeight, getResX(), getResY() );

produced

Rectangle {0, 0, 1680, 1050}
Hud resize=1680 x 1050  (1680.000000 x 1050.000000)
WARNING: Theme "GTK" could not be loaded. Using Fallback-Theme
Hud resize=1680 x 1050  (1680.000000 x 1050.000000)
Hud resize=1664 x 539  (1664.000000 x 539.000000)
Hud resize=1664 x 674  (1664.000000 x 674.000000)
Hud resize=1664 x 343  (1664.000000 x 343.000000)

The Font sizes are a problem, that I know of. when all other problems, that occurred here on the board recently are fixed I will proceed with the Text2D speedup, that I was working on. In the same time I can try to fix the HUD Font size problem when the HUD is resized.

Oh cool, that means I don't need to fix it

The Canvas3D's size should be returned by Canvas3D.getWidth() and .getHeight(). If it is not, there's a bug, that must be fixed.

It is.

I didn't exactly understant, what the problem with the scrollbars is. Could you maybe explain a little more?

If I shrink the screen to half its height, I would like lists and other things capable of being scrolled to get scrollbars rather than shrinking to illegibly small.

There is a framework for LMs. Any WidgetContainer instance can get its own LM through the setLayoutManager() method. But as you can imagine, it has never been tested, since there are no LM implementation yet . Though these min/max/preferred sizes are not available yet.

It would certainly be possible to pass min/max/preferred as parameters on the addWidget() method as a layout constraint.  I never did like Swing's implementation putting layout artifacts into the objects themselves.

If I would implement LMs I wouldn't write them exactly like known from AWT/Swing. AWT's LMs suck a little bit. Many of them don't behave the way I would expect. So I would write them more "convenient". E.g. The GridLayout is useless for very most cases and the GridBagLayout is bloated. I would write a GridLayout a way, that allows to define column widths and row heights... just an example.

No doubt lots of LMs suck.  I'm just a pragmatist who makes stuff work in preference to rewriting it   JGoodies has a very usable layout system.

Commercial version: http://www.jgoodies.com/
  -  has a really nice WebStart demo that you might find useful for analyzing your disk space
Forms screen shots: http://www.jgoodies.com/freeware/forms/index.html
Open source version: https://jgoodies.dev.java.net/
  -  by far, I think the best piece is their forms (their name for LMs)
  -  not sure if their license is compatible with BSD

[horati]

Ok, found something out.  Guess I was in too much of a hurry to post that last post because responses were coming so far LOL

This is the default behavior that keeps everything on screen but shrinks the HUD along with everything else.  No good for my purposes.

Code:

        super.setSize( canvasWidth, canvasHeight, resX, resY );

This keeps everything the same size although it breaks the addWidgetCentered method.

Code:

        super.setSize( canvasWidth, canvasHeight, canvasWidth, canvasHeight );

Taking a very quick look at HUD.setSize(), it appears the aspect is not being recalculated every time?  That makes a completely game-oriented assumption that resizing only happens when I change the full screen resolution mode.  In my case, the aspect ratio will change frequently and to very strange values.  For instance 100 x 200, 300 x 300, and 1000 x 300 are all perfectly reasonable values for the size of a HUD in the same user session.

[Marvin Fröhlich]

The aspect is not recalculated at setSize(). It's calculated dynamically (because of its cheapness).

A short rush over the differenct resolution-"layers":

• At default settings the SceneGraph-resolution in parallel projection is [-1.0, -1.0] for x and the same for y, but devided by the aspect ratio. (0.0, 0.0) is always center.
• The Canavs3D resolution is clear.
• A WidgetContainer's resolution (the HUD is a WidgetContainer itself) is either the same as its size, if the user doesn't define differently or always the user defined resolution, no matter which size it has. A Widget's size is always measured in parent WidgetContainer (WC) resolution coordinates.

So if a WC has a virtual resolution, that differes from the size, children's coordinates are calculated by first calculating physical HUD coordines through the parents up to the HUD.
There are getSizeHUD2SG(), etc. methods in WidgetContainer, that you can have a look at for further understanding.

Marvin