Re: Tablelayout

[Nate]

I added a Table constructor that takes name (though I don't think you'll need it for your dialog).

Fixed nested layouts, both laying out children and some positioning problems.

Fixed debug lines, see Table.drawDebug static method.

To fix actors being added twice, use the new "add(actor)" method or use "setName". The latter is a bit redundant though.

I added a "name" table property and use it in NinePatchTest.

See NinePatchTest. It uses a nested table for the content, then manually adds an image to the nested table, sized to fill the area. Note you must layout to size the nested table so you will know how large to set the background image. This manual stuff isn't quite ideal. I tried some other approaches, but scene2d isn't made for UIs and is limited in how it supports actor sizes. It has no notion of preferred size, which is problematic when an actor's size depends on its contents (eg, a nested table). Also, this means you are really limited to a one shot layout with scene2d. After the initial layout, subsequent layouts of the same table may not work right, since the widgets don't differentiate between current size and preferred size.

Thanks for reporting the issues! Hopefully soon you'll be productive without running into more problems. TableLayout is really useful, but still young. It has been evolving rapidly as I use it to implement complex Android UIs. The nice part is, some of that evolution and some of the problems you've reported apply to the core of TableLayout, so all the supported toolkits benefit. :)

Can you post future issues to the mailing list? It is good for others with similar problems, and helps show that the project is active.

Thanks!
-Nate

On Mon, Apr 4, 2011 at 2:33 PM, Moritz Post <morit...@gmail.com> wrote:

Hi Nate

Got more time to experiment with the tables. I have update my code and am now having a proper nine patch. (Btw with the proper texture filter the corners align nicely with the stretched sides).

I noticed that every actor i insert into the Layout (aka the Group) is added a second time when calling parse("..."). that is probably not the wanted behavior. The adding happens in GdxToolkit.addChild().

Now i am trying to fill the content area of the 9-patch. Since i can not have overlapping layouts (i think) i have created a new Layout class for the content which has itself one image which holds the background content which it stretches to fill its own dimensions. Additionally that second Layout has its own layout where it tries to layout content widgets.

This does not work however.

First of i needed to make two changes to the tablelayout code (no patch included because you would complain about formatting ;) ). The two places:

1. A new constructor in Layout to provide the name of the group so that the top layout (the 9-patch) is able to pick up the my content layout. Here are the existing constructors:

public Table() {

this((String) null);

}

public Table(final TableLayout parent) {

layout = new GdxTableLayout(parent);

layout.table = this;

}

public Table(final String name) {

super(name);

layout = new GdxTableLayout();

layout.table = this;

}

2. Since i am now dealing with a nested Layout i have added a call to propaget the .layout() to all children. The following addtion is in GdxTableLayout.layout()

for (int i = 0, n = cells.size(); i < n; i++) {

                        ...

if (actor instanceof Table) {

((Table) actor).layout();

}

}

So i am able to find my childs Layout and am able to lay it out. Here comes the problem. The layout does not look as expected. First of here is my code to layout the second layout.

public class BackgroundTable extends Table {

private final FastImage bgImage;

public BackgroundTable(final String name, final Sprite background) {

super(name);

bgImage = new FastImage("bgImage", background); //$NON-NLS-1$

addActor(bgImage);

createContent();

}

protected void createContent() {

addActor(new FastImage("header", AtlasManager.getInstance().getSprite(

AtlasManager.DIALOG_HEADER)));

addActor(new FastImage("footer", AtlasManager.getInstance().getSprite(

AtlasManager.DIALOG_FOOTER)));

layout.parse("* fill:x expand:x" //

+ "[footer]"//

+ "---" //

+ "'Content' fill" //

+ "---" //

+ "[header] "//

);

}

@Override

public void layout() {

super.layout();

bgImage.width = width;

bgImage.height = height;

}

@Override

protected void act(final float delta) {

super.act(delta);

update();

}

}

Attached you find some screenshots of the current results and what i am actually trying to implement when finished. Also attached are the header and footer slices.

I hope you understand what i am trying to achieve. Maybe there is a better way for nesting stuff. Any input is appreciated.

Regards

Moritz

On Sun, Apr 3, 2011 at 12:31 PM, Nate <na...@n4te.com> wrote:

I sent the discussion group email from the wrong address so it was rejected. Oh well. :p

I sort of rewrite all of TableLayout. Supporting new toolkits is now very clean, there are some javadocs, etc. The API changed for the better. You now create a Table which is an Actor, which has a TableLayout, which has a Toolkit. The toolkit is the GUI toolkit specific stuff, like how to create a label. The TableLayout is mostly for code reuse of the layout algorithm. There is a little glue code between the Table and TableLayout. Table has delegate methods for a handful of the most common TableLayout methods, for convenience.

TLDR: shit has changed, see tests in SVN, should be pretty straightforward. :)

-Nate

On Sat, Apr 2, 2011 at 7:13 PM, Nate <na...@n4te.com> wrote:

Hi Moritz,

Thanks for the detailed report. :) You're the first TableLayout user AFAIK, besides myself. Sweet! I hope you don't mind that I included the TableLayout mailing list in my response.

Yeah, the project setup is a little weird. I've rearranged it to make more sense. It is easiest if you delete the tablelayout projects from your Eclipse, update SVN, then import them again.

The editor may help you get comfortable with the syntax:
http://table-layout.googlecode.com/svn/wiki/jws/editor.jnlp
However, you may want to run it from SVN, as TableLayout is under active development.

Eg, paste this in:
debug
* fill
[nw] [n] [ne]
--- [w] [center] expand [e]
--- [sw] [s] [se]

The TableLayout markup you had in your email is also correct. Here I use the asterisk to apply "fill" to all cells. Since the center expands, it forces the corners to be their minimum size, so fill has no effect on them. You can try debug:widget with and without fill to better see what is going on.

So, now that we're sure the markup is correct, let's see what is going on with libgdx...

First, yeah Stage#projection isn't accessible. Just make it public for now. Mario is supposed to be adding camera support for the scene2d stuff, which will fix this properly. I access the projection matrix to use a y-down coordinate system, which is the only thing that makes sense to me. :p

TableLayout uses the actor's width and height to determine the actor's minimum size. When you rotate an actor, the actor's width and height don't change. This leads to the actor taking up its unrotated space in the table, but being drawn rotated. You can't just rotate 90 degrees and also swap the width and height because the Image actor internally uses the width and height to draw the image the right size. The workaround is to only flip the texture regions, but don't rotate, which means you need one additional image (east or west).

Next, there was an issue with the Image actor, see here:
http://tinyurl.com/3keo6r4
When a region is flipped, the region width can be negative, which isn't what Image wants.

I have been working on TableLayout last night and this morning (mostly on the Android UI stuff). With the above changes and latest in SVN, your layout now works as expected. I added your images (resized slightly) and a NinePatchTest class to SVN:
http://code.google.com/p/table-layout/source/browse/trunk/tablelayout-libgdx/test/com/esotericsoftware/tablelayout/libgdx/NinePatchTest.java
Let me know if you'd rather I not share your images with the world and I can use different images. :) Note the gradient in your images isn't perfectly horizontal near the edges. When stretched, this causes it to not quite match up with the gradient on the corner images.

-Nate

On Sat, Apr 2, 2011 at 9:53 AM, Moritz Post <morit...@gmail.com> wrote:

Hi Nate

Some remarks about the tablelayout.

1. It is a little strange to checkout the tablelayout project and than to checkout the toolkit which exist within this project again.

2. The LibgdxTest accesses the Scene.projection which is not available anymore. When removing the call the entire scene is upsidedown.

I am also having difficulties getting my layout together for a libgdx based project. Attached you find a file dialog_bg.png. It shows a graphic sliced to a 9-patch scheme. So the corners (1,3,7,9) are supposed to maintain there aspect ratio where as 2 and 8 scale only on the x-axis and 4 and 6 scale on the y-axis only. The center field 5 scales on x and y. So a very common pattern.

In my code i am only loading slice 1, 2 and 5. For each corner i use an actor based on slice 1 and rotate the actor according to the corner. The same applies to the sides. The group in which the tablelayout is applies does have the same size as the the window.

Here is the layout that is supposed to do the trick:

layout.parse("debug:all" //

+ "[bg7] "//

+ "[bg8] fill:x"//

+ "[bg9] "//

+ "---" //

+ "[bg4] fill:y" //

+ "[bgContent] expand fill" //

+ "[bg6] fill:y" //

+ "---" //

+ "[bg1] " //

+ "[bg2] fill:x" //

+ "[bg3] " //

);

You might see that the rows of the layout are actually upside down. That happens due to the rotation issue. Is their anything one can do about it? Beside that... The layout created by this scenario looks like the screenshot in layout1.png

Changing the layout a little by replacing the strange behaving bg4 and bg6 with some text:

layout.parse("debug:all" //

+ "[bg7] "//

+ "[bg8] fill:x"//

+ "[bg9] "//

+ "---" //

+ "'bg4'" //

+ "[bgContent] expand fill" //

+ "'bg6'" //

+ "---" //

+ "[bg1] " //

+ "[bg2] fill:x" //

+ "[bg3] " //

);

Results in the layout seen in layout2.png

Also not exactly what i was expecting but closer to the final result. the slice bg8 (remember it is upside down) misbehaves a little.

Attached you find the Dialog.java code encapsulating the tablelayout and the actual textures used. I hope you can make sense of it all and i am awaiting your reply.

Regards

Moritz