Important Changes

Quite a bit is being changed, and I hope to be able to push the updates out tonight or tomorrow.

  1. A complete rework of the Clipping System.
    — Elements can now contain an infinite number clipping layers
    — Clipping can now contain a defined region within the parent layer.
    — Clipping is self-propagating in most cases. (addChilld, removeChild, addClippingLayer, updateClippingLayer, removeClippingLayer, etc)
    — Final clipping is calculated from the inner most extents of all parent clipping.
    — This allows for complex nesting scenarios that were not possible until this update.

  2. Window has been restructured
    — There is now a content area (use addWindowContent)
    — There is now an optional close button for the drag bar (use setUseCloseButton(true))
    — There is now an optional collapse button for the drag bar (use setUseCollapseButton(true))
    — There is now a sizeWindowToContent() method… this does require that you add Elements to the window via addWindowContent)

  3. Layouts have been added. The available stock Layouts are:
    — MigLayout - A fairly powerful implementation of Swing’s MigLayout (grid based layout)
    — FlowLayout - A horizontal line wrapping layout that allows you to use LayoutHints to control the flow
    — HorizontalLayout - A layout from left to right that wraps to the parent’s bounds
    — VerticalLayout- A layout the wraps after place each component.

Layouts can override element properties and resize functions (if enabled)… thus far the following is supported:

  • cell (row col)
  • span (x y)
  • grow (x y)
  • fill (x y)
  • pad (x w y h)
  • dock (left center right) (top center bottom)
  • wrap
  • min (w h)
  • pref (w h)
  • max (w h)

Layouts themselves have properties and behaviors as well, such as margins, resize (absolute, variable and percentage… or any combination of these depending on the cell definitions), clipping by cell (or cells depending the elements span properties)

With the addition of Layouts, the is also a constructor for every control that just requires screen as a param. The rest of the elements properties are define in LayoutHints, like so:

[java]
MigLayout layout = new MigLayout(screen, “[][60%][][][65][]”, “[][][200][][10%]”,“margins 10 10 10 10”,“clip”);
contentArea = ControlUtil.getContainer();
contentArea.setLayout(layout);

ButtonAdapter ba = new ButtonAdapter(screen);
ba.getLayoutHints().define(“cell 0 1”,“span 1 2”,“pad 2 2 2 4”,“grow true false”,“fill false true”); //etc
contentArea.addControl(ba);

contentArea.layoutChildren();
[/java]

As seen above, there is also a small control utility class for creating some common elements.

Anyways, I’ll post when the plugin has been updated.

3 Likes

Fantastic news :slight_smile: I intend to convert the Table control to use layout instead, I also want to take advantage of the clipping (and of course horizontal scrolling - but this is already mostly done).

I also have a Menu replacement that would work with this if you are interested. I found the existing control very hard to make to look nice, mainly because it is based on a text only ScrollArea. Adding checkboxes larger than text caused alignment problems etc.

So I made one that uses MY MigLayout, but it should be pretty easy to convert to the new code once it is available. This one is based on ScrollPanel and TextElement. It can handle any type of control as menu items, tries to keep itself in the screen bounds (height only at the moment).

Note the bold/italic/underlined doesn’t work yet because AnimText ‘no wrap’ doesn’t work properly.

3 Likes
@rockfire said: I also have a Menu replacement that would work with this if you are interested.

Definitely! The current menu’s were done this way to keep the number of meshes down to 2 + checkboxes and arrows… however this (again) was made long before containers were added. I believe you can also set the textPadding for menus which increases the space between menu items. However… many controls just need to be reworked with the new Layouts and other changes in mind.

EDIT: If you want to just grab the positioning code from the other menu… it should pick the appropriate side and reposition to make sure it stays within the screen bounds.

Yeh I figured that was the reason. In this case I don’t care too much about the number of mesh. The menus don’t stay visible long, so it’s not really a problem. I felt it was worth losing this for the greater flexibility in looks. I’ll get this posted some point this week then :slight_smile:

@rockfire said: Yeh I figured that was the reason. In this case I don't care too much about the number of mesh. The menus don't stay visible long, so it's not really a problem. I felt it was worth losing this for the greater flexibility in looks. I'll get this posted some point this week then :)

Hah… when menu’s were first written… the library wasn’t actually handling removing elements from the rendered scene… I guess old habits die hard, because I still start new mini-projects with this mind-set. Now that hide/show works in this way… I really need to get over the idea of minimal meshes…

I probably show have mentioned that I’ll need peoples help reporting issues as they arise with the new clipping system. I haven’t seen any issues here (all my tests run fine… new test run fine… FX Builder runs fine, the new test app does as well. But… I tend to build things iin the same way, so propbably won’t see the issues others might.

Long story short: Report stuff as you find it… now that I finally took the plunge over the clipping update, I can start looking at more the outstanding issues I knew were going to be effected by this change.

Aaaaand… This is the post to say the plugin has been updated.

And this is a post to say thanks. Will reply with any issues here.

1 Like

Another worthy mention…

ScrollPanel:
— reshape() now sizes the scrollableArea properly for added content.
— text and textPadding is now accounted for properly.

I’m having a hard time getting MigLayout to work at all. This may be preconceptions I have because of my own stuff though :wink: … A couple of questions …

  1. If I don’t set any size at all, either in the constructor or in layout hints (except on say a top level Panel), what size should child components get? From what I am seeing it is 0x0? My own layout stuff uses a size the component calculates itself (e.g. text size + icon size + borders in the case of button, preferred size of contained components if a container). In user code, i very very very rarely set any specific size (percentage or otherwise).

  2. How do I wrap to the next line. wrap was mentioned in the other post, but I can see no wrap hint at all in the current SVN.

  3. Do you have a complete example? I was considering having a go a creating a tonegod version of the MigLayout webstart demo. Do you think that is possible currently?

@rockfire said: I'm having a hard time getting MigLayout to work at all. This may be preconceptions I have because of my own stuff though ;) .. A couple of questions ..
  1. If I don’t set any size at all, either in the constructor or in layout hints (except on say a top level Panel), what size should child components get? From what I am seeing it is 0x0? My own layout stuff uses a size the component calculates itself (e.g. text size + icon size + borders in the case of button, preferred size of contained components if a container). In user code, i very very very rarely set any specific size (percentage or otherwise).

  2. How do I wrap to the next line. wrap was mentioned in the other post, but I can see no wrap hint at all in the current SVN.

  3. Do you have a complete example? I was considering having a go a creating a tonegod version of the MigLayout webstart demo. Do you think that is possible currently?

  • Components use their default size if nothing is specified… this will be updated. I just haven’t gotten their yet.

  • Wrap isn’t currently implemented in MigLayout… this will also be updated.

  • I’ll put something together today and post it here.

  • Yep… not extremely helpful reply… need… coffee… hack… cough cough…

    Actually, might as well go into specifics about things that aren’t complete yet:

    • Wrap is currently only used in FlowLayout
    • Pref & max sizes are ignored atm… they’re stubbed for future use
    • Mig expects it’s owner element to have dimensions (for now at least). It’s how variable size is calculated… i.e. as apposed to [120] or [20%]. This will either change to setting min, pref, max size in the layout constraints or… ??
    • Cell placement is 0-based

    For now… assume that layouts are ignorant of self-sizing (outer bounds that is) and set the owner’s dimensions. I’m still floundering on how to handle variable width/height with setting this. From what I read in MigLayout, it expects an outer dimensions as well.

    Anyways… I’ll post a full example here in a bit!

    @t0neg0d said: 1. Components use their default size if nothing is specified... this will be updated. I just haven't gotten their yet. 2. Wrap isn't currently implemented in MigLayout... this will also be updated. 3. I'll put something together today and post it here.

    Yep… not extremely helpful reply… need… coffee… hack… cough cough…

    Actually, might as well go into specifics about things that aren’t complete yet:

    • Wrap is currently only used in FlowLayout
    • Pref & max sizes are ignored atm… they’re stubbed for future use
    • Mig expects it’s owner element to have dimensions (for now at least). It’s how variable size is calculated… i.e. as apposed to [120] or [20%]. This will either change to setting min, pref, max size in the layout constraints or… ??
    • Cell placement is 0-based

    For now… assume that layouts are ignorant of self-sizing (outer bounds that is) and set the owner’s dimensions. I’m still floundering on how to handle variable width/height with setting this. From what I read in MigLayout, it expects an outer dimensions as well.

    Anyways… I’ll post a full example here in a bit!

    Heh, naww, helpful enough. I very much look forward to the example though, that’s going to help a lot

    hi @t0neg0d,

    @rockfire said: Heh, naww, helpful enough. I very much look forward to the example though, that's going to help a lot
    As he say, i'm not against some exemple too, i've tryed to use the new layout but without no real usefull/success output u_U Btw, does passing string as argument will be the only way to do ? [java]MigLayout layout = new MigLayout(screen, "[][60%][][][65][]", "[][][200][][10%]","margins 10 10 10 10","clip");[/java] It look realy complex, having wrong a string argument is far easyer than a Float/Integer/Enum, having a layout parameter could be more usefull, at last for someone like me who don't always remember the order to pass argument in or what they mean. Thx for all.
    @kobRoah said: Btw, does passing string as argument will be the only way to do ? [java]MigLayout layout = new MigLayout(screen, "[][60%][][][65][]", "[][][200][][10%]","margins 10 10 10 10","clip");[/java] It look realy complex, having wrong a string argument is far easyer than a Float/Integer/Enum, having a layout parameter could be more usefull, at last for someone like me who don't always remember the order to pass argument in or what they mean. Thx for all.

    No… each layout will add it’s own chained methods for setting properties.
    Layout hints will as well.

    This is just an initial push to get the code out. It has a ways to go still.

    Here is an example… however! The was an issue with how margins were being parsed, so they are not working correctly (and won’t be unit either tonight or if you grab the latest commits for the layout classes). The example will not look right because of the default margins of 10, 10, 10, 10 atm.

    I also think I will likely add single tag support for enabling things like movable, resizable, etc

    NOTE: I was lazy about my use of components and opt’d for buttons and panels were I could in the example.

    [java]
    Panel p = new Panel(screen, Vector2f.ZERO, new Vector2f(300,250));
    MigLayout ml1 = new MigLayout(screen,"[120][0][120]","[45][][50]",“margins 5 5 5 5”,"pad 0 0 0 0 ");
    p.setMinDimensions(new Vector2f(220,45));
    p.setIsMovable(false);
    p.setClipPadding(5);
    p.setLayout(ml1);

    Panel p2 = new Panel(screen, Vector2f.ZERO, new Vector2f(300,55));
    p2.getLayoutHints().define("cell 0 0","span 3 1","fill true true", "grow true true");
    p2.setIsResizable(false);
    MigLayout ml2 = new MigLayout(screen,"[][35][35]","[35]","margins 0 0 0 0","pad 0 0 0 0 ");
    p2.setLayout(ml2);
    p.addChild(p2);
    
    ButtonAdapter ba1 = new ButtonAdapter(screen);
    ba1.getLayoutHints().define("cell 0 0","span 3 1","fill true true","grow true false");
    ba1.setIsMovable(true);
    ba1.setEffectAbsoluteParent(true);
    ba1.setEffectZOrder(false);
    p2.addChild(ba1);
    
    ba1 = new ButtonAdapter(screen);
    ba1.getLayoutHints().define("cell 0 1","span 1 1","fill true true","grow false false","pad 5 5 5 5");
    p2.addChild(ba1);
    
    ba1 = new ButtonAdapter(screen);
    ba1.getLayoutHints().define("cell 0 2","span 1 1","fill true true","grow false false","pad 5 5 5 5");
    p2.addChild(ba1);
    
    p.addChild(p2);
    
    Panel p3 = new Panel(screen, Vector2f.ZERO, new Vector2f(300,55));
    p3.getLayoutHints().define("cell 1 0","span 3 1","fill true true", "grow true true","pad 5 5 5 0","min 0 0");
    p3.setIsResizable(false);
    p3.addClippingLayer(p3);
    MigLayout ml3 = new MigLayout(screen,"[120][][45]","[35][35][35][]","margins 10 10 5 10","pad 0 0 0 0 ");
    p3.setLayout(ml3);
    p3.setIsMovable(false);
    p3.setIsResizable(false);
    
    Label l = new Label(screen, Vector2f.ZERO);
    l.getLayoutHints().define("cell 0 0","span 1 1","fill true true","grow true false","pad 0 5 0 0");
    l.setText("First Name:");
    l.setTextAlign(BitmapFont.Align.Right);
    p3.addChild(l);
    
    TextField tf = new TextField(screen);
    tf.getLayoutHints().define("cell 0 1","span 1 1","fill true true","grow true false","min 120 25");
    p3.addChild(tf);
    p3.addClippingLayer(p3);
    
    l = new Label(screen, Vector2f.ZERO);
    l.getLayoutHints().define("cell 1 0","span 1 1","fill true true","grow true false","pad 0 5 0 0");
    l.setText("Middle Initial:");
    l.setTextAlign(BitmapFont.Align.Right);
    p3.addChild(l);
    
    tf = new TextField(screen);
    tf.getLayoutHints().define("cell 1 1","span 1 1","fill false true","grow false false");
    p3.addChild(tf);
    p3.addClippingLayer(p3);
    p.addChild(p3);
    
    l = new Label(screen, Vector2f.ZERO);
    l.getLayoutHints().define("cell 2 0","span 1 1","fill true true","grow true false","pad 0 5 0 0");
    l.setText("Last Name:");
    l.setTextAlign(BitmapFont.Align.Right);
    p3.addChild(l);
    
    tf = new TextField(screen);
    tf.getLayoutHints().define("cell 2 1","span 1 1","fill true true","grow true false","min 120 25");
    p3.addChild(tf);
    
    ba1 = new ButtonAdapter(screen);
    ba1.getLayoutHints().define("cell 2 0","span 1 1","fill true true","grow false false","pad 5 5 5 5");
    p.addChild(ba1);
    
    ba1 = new ButtonAdapter(screen);
    ba1.getLayoutHints().define("cell 2 2","span 1 1","fill true true","grow false false","pad 5 5 5 5");
    p.addChild(ba1);
    
    p.layoutChildren();
    p.addClippingLayer(p);
    
    screen.addElement(p);
    

    [/java]

    Oh… the results of the above create a window that sizes/positions everything properly with resizing…

    Nice :slight_smile: That just worked with my own my style too, thought you might like to see it.

    However, you might be able to make out i’m seeing blurring of the text here. It’s probably somewhere that needs to needs to round off an x or y position (the new ScrollPanel has this problem too I’ve just noticed).

    1 Like
    @rockfire said: Nice :) That just worked with my own my style too, thought you might like to see it.

    However, you might be able to make out i’m seeing blurring of the text here. It’s probably somewhere that needs to needs to round off an x or y position (the new ScrollPanel has this problem too I’ve just noticed).

    Yeah… definitely will make sure I do this. I noticed this as well.

    Also, I should mention… the other 3 layouts still need a ton of work before they will be (what I would consider) useful. I’ll be working on updating those and hopefully be able to push them out tonight with the updates. Hopefully, I’ll be able to get pref and max size into mig as well. Will make it a ton easier to determine the entire layout size once these are actually being used.

    @t0neg0d said: Hopefully, I'll be able to get pref and max size into mig as well. Will make it a ton easier to determine the entire layout size once these are actually being used.

    Hi, please don’t spend too much time on pref and max size :))

    As I mentioned, I personally against the idea of pref and max size. Or at least, pref size should not be implemented, maxsize still got few reasons to be implemented.

    The idea of pref size can be intepreted as some Elements, some Attributes should have more “awareness” or “piority” than other in layouting. So eventually in the end of the Layouting, if other constraints can not be satisfied, the pref size take over the re-trigger the layouting of other elements. This can cause a lot of headaches, because we (in the past) are lazy and didn’t do layouting the right way.

    In the past, for the designer who do the layouts, in Swing for example, they did assume that an universal layout and unit can work in every display, resolution and style. Which is totally untrue (make it complex, ugly, or both…).

    What we may learn in the Web world, we reponsive layout are implemented with another idea called Threshold, which only collapse to be fit for specific device. Beside of that are absolute layout for general device and pixel exact layout for specific device.

    So even if you gonna support pref size, consider not making it dominance to other attributes… (Swing has some issues and this one is quite bad IMO… )

    @atomix said: Hi, please don't spend too much time on pref and max size :))

    As I mentioned, I personally against the idea of pref and max size. Or at least, pref size should not be implemented, maxsize still got few reasons to be implemented.

    These will be completely optional… if you don’t set them, they are not used.

    Personally, I’m not a big fan either as I would rather use defined sizes for default… maybe a minimum size for resizing… and then just set the fill and grow property to define the rest of the resize process.

    The one benefit is, it will allow me to provide the option of letting the content define the size of the parent.