[tuhopuu-devel] GUI skins

[Daniel Fairhead]

Hi Matt,

> I've been doing some stuff along a similar topic recently (have a look here:
> http://www.blender.org/modules.php?op=modload&name=phpBB2&file=viewtopic&t=1516&start=15
> and on the next page). It would be neat if I could get it working within
> your system. I've done it by creating a new 'emboss' type for each type of
> button, and in the draw_but_XXX() functions overridden the emboss type
> manually. I don't know if that's a good way to approach it in code, but the
> general consensus is (that I firmly agree with) is that the look of the
> buttons need to be differentiated according to their function. I've made

Looks very good!

About code stuff... Here is something I've been thinking about for a while,
as I've been doing code all over the place for ui stuff, and such. I really
dislike some parts of the current interface API, as used in blender. Some
parts are seriously ugly (IMHO). For instance, the way of defining buttons:

uiDefBut(block, BUT,B_DORENDER,"RENDER", 369,142,192,47, 0, 0, 0, 0, 0, "Start the rendering");

for example. *all* buttons are created using the same function "uiDefBut". The 
uiDefButF uiDefButS etc are just wrappers, and not even terribly useful ones
at that. If one has to define buttons this way, having one extra flag (FLO,INT,etc)
is no big deal, and it just adds to the code-bloat.

I have started work on a proper proposal for a new version of the API, which 
would have more sensible (again IMHO) functions:

uiBut *uiButton(uiBlock *block, int type, int eventname, char *str,
	 short x1, short y1, short x2, short y2, char *tip);

for example. The API would be defined from interface widget type, rather
than from data type. So we would have uiLabel, uiToggle, uiSlider, etc.

These could, of course, just be wrappers as the current ones are. The
only advantage here would be making the code outside of interface.c
nicer to read. Button creation and Label creation would look different
from each other, and there would be no need to send silly arguments
like "max" and "min" to a label, of course! :-)

However, thinking of this new api as not just wrappers, there are
many other advantages too. We could re-make the way buttons
are drawn in interface.c itself, so each button type would run its
own draw-function (similar to how each runs its own embossfunc
currently).

Again, half-way through writing this proposal, and thinking it out,
I've had more ideas (heh). Actually, partly from a suggestion of
my dads. Couldn't buttons and interface code be object-oriented?
No need for all these silly "case TOG: draw_tog_but;break;" or whatever,
just send widget->draw(); for all widgets in the list. This is already
partly done already, with the embossfunc, but C is not designed for
OO coding, and as blender mixes C and C++ anyway, why not have
the interface split off to be more modular (as the gameengine and
python are), and done in C++? Wasn't one of the design points of
blender to have the data and the interface not interdependant?

Anyway... Um... Yeah. :-) All of my thinking here is slightly too big
a change to be done over night, and is probably a 2.5 or even 3.0
proposal. 2.5, I hope. Anyway, doing over-rides is probably the easiest
way to do things at the moment... aside from a full interface.c re-code,
that is.

> those modifications to a bf-blender CVS, mainly in interface.c. It's my
> first time ever messing with OpenGL so I'm sure the code could use some

Me too actually! :-)

> optimisation too. I haven't made any updates recently though - right now I'm
> horribly sick with pneumonia :(

:-( I'll pray you get well soon!

> Anyway I can probably make up a patch tomorrow if people are interested to
> take a look.

Sure!

Dan