Why not just make panels a sprite?

[zoombapup]

I'm curious about something.

Normally in UI's, you'd have a "panel" object which is basically a box. It usually outlines things, giving a rectangular area to work within. Most UI's I've worked with have things based off rectangle areas, such that objects can anchor within the parent area, position themselves relative to it etc.

NGUI in this respect seems entirely weird to me, in that panels by default have no rectangle. What's weirder still is that they CAN have a rectangle, but then that rectangle isn't sizable like the sprite is. Having grab handles for rectangle areas like panels seems to me to be a no brainer. Its there for sprite but not for panel and I can't for the life of me think why?

Having to have an anchor script also seems weird, given most UI's simply have an anchor property that anchors a child in relation to a parent rect (which means of course parents must HAVE a rect).

Can I ask about the design thinking for NGUI? I mean why not follow the conventions of 100's of other UI libraries? Is there some advantage to this method of layout I'm missing? because trying to do things like scrollable lists seems needlessly vague to me this way, or even relatively simple controls seem complex (i.e. I create a button, usually the button would be the rectangle the button covers, rendered with different states, yet with NGUI the "button" is simply a collection that isn't really even loosely connected, so trying to create a button of a certain size means editing colliders and sprites and labels separately).

Perhaps there's an advantage I'm not encountering?

Genuinely curious.

[Waurelius]

Simplicity of implementation, and emergent flexibility from simple, powerful low-level constructs.  There's a lot to be said for that, especially in a game coding context.  I've only been messing around with NGUI for a few days, but I like it that way.

[Nicki]

I suppose the name "Panel" isn't really a good name, since many people think it's an actual widget or a window like in other UI solutions.

The panel here is a "meta" object that exists as a convenience for the user to be able to control the number of draw calls and order of UI elements.

The anchoring is an inherent problem in the structure that unity has - children inherit the scale of the parent. If we want to work in pixels, then we have to set up rules such as no non-widget object in the hierarchy can be any other scale than 1,1,x because then the scale and position of the widget does not fit anymore.

NGUI gives you the options to do it more freely that for instance a pre-made "UIButton". You can make your own prefabs that trigger their own effects based on the difference interactions with the collider; that's harder to do in native iOS.

In the end there's always a tradeoff between ease of use and available features and NGUI tends to lean to the latter.