next »

[jeffhoye]

Does anyone have an example of a resizable HUD Frame?  I saw the "WidgetManipulator" but it doesn't work with a Frame -- and the behavior is a bit different because it should just be the border that is resizable on the Frame.

Thanks!
-Jeff

[Marvin Fröhlich]

I'm sorry. Resizable frames are a missing feature. But you're free to add it .

[jeffhoye]

Will do!

[Marvin Fröhlich]

Cool . tbh. I almost didn't expect that answer . Please send me your sourceforge account name, so that I can grant you dev access to SVN.

[jeffhoye]

Hi Marvin,
  I'll send you the dev info later... 

  I'm trying to use Frame.onMouseMoved() to determine when the mouse is on the border.  Currently when the mouse is over the border, onMouseMoved() doesn't get called.  But when you go over the internal panel, onMouseMoved() is called and the first 2 arguments are offset by the border width/height.  So, for example, when the border width is 3, I can't ever get onMouseMoved() to be called with x == 0, it is only called with x >= 3.  -- Because onMouseMoved() isn't called on the border.  I'm digging into the HUD code, but I can't figure out how to modify pick() to return a value when the mouse is over the border.  I may try to return a HUDPickResult with negative values if it is within the border size, however, I'm not sure this will work properly.  Any thoughts or hints? 

Thanks!
-Jeff

[Marvin Fröhlich]

If the mouse is over the right or bottom border, these values wouldn't be negative. So I suggest to introduce a boolean field to HUDPickResult, which denotes, whether the mouse is over the border. Then I suggest to add a protected method to the Widget class, that tells, whether to react on picks on the border. It would return false by default to reflect the current behavior. The Window would override this method and return true.

Well, just a thought. But it might work.

[jeffhoye]

I believe it was a bug in Window because onMouseMove() was being fired even when the cursor was a bit to the right of the frame.  I fixed it by overriding getContentLeftPX() and getContentTopPX() on Window to not include the border. 

I saw the Cursor and CursorSet classes make reference to these cursor types.

        INHERIT,
        POINTER1,
        POINTER2,
        CROSSHAIR,
        TEXT,
        WAIT,
        HELP,

However, for resizable windows, I'm going to need a lot of the standard cursors in Java. 
    public static final int SW_RESIZE_CURSOR = 4;
    public static final int SE_RESIZE_CURSOR = 5;
    public static final int NW_RESIZE_CURSOR = 6;
    public static final int NE_RESIZE_CURSOR = 7;
    public static final int N_RESIZE_CURSOR = 8;
    public static final int S_RESIZE_CURSOR = 9;
    public static final int W_RESIZE_CURSOR = 10;
    public static final int E_RESIZE_CURSOR = 11;
    public static final int MOVE_CURSOR = 13;

What is the plan for this?  Is there a way to use the standard system cursors?  The AWT way would be to call setCursor() on the AWT element, but we can't assume they are using an AWT frame.  Should I add these cursor types into CursorSet.Type?  Is there a way to use the system defaults if they don't load a cursor from an image?

Thanks!
-Jeff

[Marvin Fröhlich]

No, there is intention to load the system default cursor. And yes, you'd have to add them to the CursorSet type.

Very good work so far. Keep it up. Thanks a lot.

[jeffhoye]

Hi Marvin,
  I just checked in the first pass at the ResizableFrame.  It extends Frame. 

You can test it in org.xith3d.test.ui.HUDResizableFrameTest.

To properly display the correct move/resize cursors, I added several types to Cursor.Type and also made CursorSet more extensible by changing it to a HashMap.  I hope I didn't overstep my developer bounds.  Let me know if you prefer for it to work differently.

ResizableFrame extends Frame.  Do you think I should just integrate the resize functionality into Frame and make the resize capability an option?

I believe I followed all of the code formatting standards and such.  However, you may want to take a look at my changes/check-in comments to see if they are all Kosher.

There is still a bug redrawing the border and the Header Widget.  I believe this is outside of what I've changed, but I'll spend some time tracking it down.  Any idea where it may be?  To reproduce the problem, run the test and try resizing the frame a bit, and you'll see the Header Widget disappear, and some weird artifacts on the drop shadow border.

Thanks!
-Jeff

[Marvin Fröhlich]

  I just checked in the first pass at the ResizableFrame.  It extends Frame. 

You can test it in org.xith3d.test.ui.HUDResizableFrameTest.

Very great job and good work. Nice and clean commit.

To properly display the correct move/resize cursors, I added several types to Cursor.Type and also made CursorSet more extensible by changing it to a HashMap.  I hope I didn't overstep my developer bounds.  Let me know if you prefer for it to work differently.

It's good just like that.

ResizableFrame extends Frame.  Do you think I should just integrate the resize functionality into Frame and make the resize capability an option?

Yes, please.

I believe I followed all of the code formatting standards and such.  However, you may want to take a look at my changes/check-in comments to see if they are all Kosher.

Yes, almost. I know, my coding style is a bit uncommon here and there. Though it should be pretty well readable. At least I hope so and it is the goal behind my rules.

The only thing, that differs, is, 1) that I always write the return argument in braces like this.

return ( someValue );

2) I use to put the constructors to the bottom and follow the "define first, then use" paradigm, which almost forces the constructors to the bottom. Well, I know, this might be pretty confusing at first. And if you don't want to use that, feel free to pu them to the top in new classes. Just try to keep them at the bottom in classes, where they're at the bottom.

3) no-modifier is not private. So never use no-modifier, if you actually mean private. One of the little advantages is, that the compiler and the IDE will be able to help you track down unused private fields.

4) Make fields final where ever you can. I use this to help myself not accidentally manipulate fields, that are meant to be constant.

Apart from that you did a very good job adapting my style. Thanks a lot.

There is still a bug redrawing the border and the Header Widget.  I believe this is outside of what I've changed, but I'll spend some time tracking it down.  Any idea where it may be?  To reproduce the problem, run the test and try resizing the frame a bit, and you'll see the Header Widget disappear, and some weird artifacts on the drop shadow border.

Yeah, I saw that. If I had to guess, I would say, the clear() method gets outdated coordinates when resizing the frame. About the header widget I have no idea.

Thanks for your great work.

[jeffhoye]

Hi Marvin,
  I fixed 3 artifacts that showed up when resizing:

A) The title bar wasn't drawing:
  This was a bug in TextureImage2D, it wasn't setting the limit when scaling down and useBuffer
 
B) The drop shadow had ugliness:
  TextureImage2D.drawPixelLine() should overwrite on the call to pixelCombine().  For reverse compatability, I added the parameter and called a helper function, though the only place in the library it is called is from DefaultDropShadowFactory.  Should I just make this the default and remove the helper?  When you look at TextureImage2D.drawPixelLine() it will be obvious what I did.
C) Due to the getMaxRedrawFrequency() rule, there are artifacts when resizing.  I fixed this by stepping up the redraw frequency to 1000f while resizing and overriding WidgetAssembler to only draw the headerWidget.  This required a small change to WidgetAssembler.draw() to allow me to override which widgets were drawn.

Let me know if you want me to do any of this differently.

Next step is to integrate all these features into Frame.

-Jeff

[Marvin Fröhlich]

Should I just make this the default and remove the helper?

Hmm... Since TextureImage2D is a pretty general class, I would say we should stick to what you did now to keep this open for any kind of need.

C) Due to the getMaxRedrawFrequency() rule, there are artifacts when resizing.  I fixed this by stepping up the redraw frequency to 1000f while resizing and overriding WidgetAssembler to only draw the headerWidget.  This required a small change to WidgetAssembler.draw() to allow me to override which widgets were drawn.

Let me know if you want me to do any of this differently.

If it works, well, then it's ok. Otherwise the max redraw frequency is there for a reason. And it really shouldn't be cranked up to 1000. Shouldn't it work to compute the chenge delta since the last redraw and tell the redraw algorithmus about is? I haven't thought this through though.

[jeffhoye]

C) Due to the getMaxRedrawFrequency() rule, there are artifacts when resizing.  I fixed this by stepping up the redraw frequency to 1000f while resizing and overriding WidgetAssembler to only draw the headerWidget.  This required a small change to WidgetAssembler.draw() to allow me to override which widgets were drawn.

Let me know if you want me to do any of this differently.

If it works, well, then it's ok. Otherwise the max redraw frequency is there for a reason. And it really shouldn't be cranked up to 1000. Shouldn't it work to compute the chenge delta since the last redraw and tell the redraw algorithmus about is? I haven't thought this through though.

I tried, but the problem is that Texture2DCanvas doesn't call render at all if the timeout hasn't occurred.  However, resizing happens on each loop, so the texture ends up full of artifacts while resizing.  I guess the best approach would be to find a way to only resize if the timeout is good.  I'll think about it. 

[Marvin Fröhlich]

I guess the best approach would be to find a way to only resize if the timeout is good.  I'll think about it. 

Yes, this should work under the same approach as the other HUD rendering: Resize virtually and only redraw the resized Widget when the rest of the Widget is drawn.

[jeffhoye]

Sorry for the delay, my new graphics card had to be sent back, and my old one won't run Xith3D for some strange reason I was never able to determine.  I'm back online again.

I didn't realize that setMaxRedrawFrequency() was static.  That was clearly going to be a big problem.  As suggested, I now call setSize() in drawAndUpdateWidget(). 

I saw that you had to clean up my code because I didn't precisely follow the formatting rules.  Old habits die hard.  I think I did better in this checkin. 

Next step is to integrate the changes into Frame and delete ResizeableFrame.

-Jeff