Slices are meant to be able to compute the positions of their children efficiently, since they recompute them every frame. I think radial layout or anything else not likely to be needed for creating slice collections should be instead implemented as a script. That would work much better; then it doesn't matter how slow it is to position the slices.
I don't think a packing layout slice is useful for an inventory system where you manually manage space and placement, because it doesn't allow you to customise placement, aside from the order in which the slices are placed. I would really like to let you assign graphics to items, then you can have a graphical inventory. Grid and layout would both be reasonable ways to display them.
Aside: it would be nice to just have a set of simple options for how the inventory should be displayed, eg grid/layout and image/image+text/text without needing to know how to edit slice collections. But how can we have such options while also letting you customise the inventory slice collection directly? Maybe it's still possible for those options to work by manipulating the slice collection using lookup codes. Like, toggling the visibilty of the slice marked 'item name', if it exists.
Bob the Hamster wrote:As for layout slice and thing browser, hopefully it will be possible to use it for some browsers that it makes sense for (like Sprite browser after variable Sprite sizes are implemented) while leaving most other browsers grid slice based.
I doubt there's any good reason to use a grid in some and a layout in others. If all the children of a layout slice are same size, then it'll lay them out in a grid (you'll probably want to set it to justify, then it'll behave very much like a grid slice), without needing to manually calculate the rows/columns of the grid.