Designing a GUI system that's easily skinnable

This one interests me as well. I was thinking about the first method you described, but since the user would have to handle to many draw cases (enabled/disabled, highlighted/non-highlighted, pushed, keyboard-focus, default-button) this would be to tough (I guess). But if you do it for yourself and don't want to release it, I would do it.

If you split up the render to the stuff I mentioned, this may make the stuff easier.
Or you could state the GUI texture's layout, so you know, that a particular widget will always use given texture coordinates, so you can make more textures and use your custom skin. That requires some editor for your texture. Or use separate textures for every widgets (so it will be easy to modify without knowing the precise dimensions) and put them into the atlas texture at startup/load.

If you combine the two (custom texture, but with fixed layout; and enabling overriding the draw method), that would be pretty flexible, but still relatively easy to use (I think).

Just some quick ideas, I'm sure there's a common way to do it.

writing your own system is a lot of work and more than likely its been done better so please check qt on how they achieved this and build up on that knowledge.

(couldn't resist, but seriously, one advantage of FLOSS is that you can study sourcecodes)

Quote:

Original post by rofseek Should window's be able to draw themselves and simply allow the user to override a virtual draw function?

That's not what I would call 'easily skinnable'. Being able to set a (9-patch) background image and color would be much easier. Less flexible than being able to provide your own drawing routines, but you could ask yourself how often a user really needs that kind of power.

Quote:

Perhaps, windows should only exist logically and visibility should be delegate to a renderer of some sorts? Both techniques would achieve the desired results but the second requires a considerably larger amount of glue to achieve the same results with what possible benefits?

You could set up a draw callback, and link each GUI element to a function that knows how to draw that specific GUI element type. This allows you to swap the default rendering functions for custom ones. Callbacks could even be swapped at run-time, on a per-object base (or, if that's not necessary, use one callback per type rather than per instance).

Pseudo-code:

A proper implementation will obviously take some more thought, depending on the actual requirements (for example, what platforms and graphics systems/libraries need to be supported) but I hope this gives you some inspiration.