RE: [boost] Re: GUI library - another one

From: Powell, Gary (powellg_at_[hidden])
Date: 2004-03-03 13:02:31

>>> 9. (really 0 in my view) It should use an extensive resource 
>>> description schema or language (for widget properties, 
>>> layouts and relations) that is either interpreted at run time 
>>> or (though I like it less) compiled into code transparently 
>>> to the user. This resource description should probably be XML-based.
>>
>> I agree, and would definitely go with a XUL-like approach for any new GUI
>> library, i.e., have the GUI defined completely in an XML file. Maybe even
>> handling Microsoft's future XML descriptors for GUIs (XAML?)

>Well, I'd hope there would be a user-readable/writable format that
>could be used as a front-end.  You can go a long way in plain text:

>  +--------+
>  | button |
>  +--------+

>  * radio
>  * buttons

>  [ ] checkbox

> you get the idea, I hope.

>-- 
>Dave Abrahams

While a human readable front end is nice, a machine parsable file is key. I've written I think 3 or 4 of these data format file GUI's and it always starts out as some simple GUI and rapidly becomes an embedded control language. Why because programmers don't want to spend time doing layout and button control! It is just a huge time suck. And every manager has a different opinion. What you want is out of that loop. Let the art director and the manager haggle over what the buttons look like and do.

Ideally you create a flexible file format, and XML comes to mind, and then write a GUI tool to let the artists create button art, and tell it how where and how its connected. Then programmers write code which is event based. Then no matter the button is, or how its pressed, the program still runs. Last minute art is no problem. Last minute GUI changes, easy. The button "Quit" still sends a "quit" message. And no recompile, or new binary is necessary.

I also despair of a multi platform GUI, it always seemed that each platform had its own look and feel and that users hated anything that reminded them of the other platform. Hence if you can abstract the "message" from the "button" you can have a dropdown menu in one platform and a radio button on another and the program should not care. So if you are selling software, do everything you can to get the "button" logic out of the program and into the art/menu/GUI control system.

Layout. Its really nice if you can attach one piece of art to another so that they always line up. But that usually means "pixel" coordinates. Ever look at a game and see that the title is in flames and wonder what's going on? It's like 12 pieces of flame art all designed to run in a cycle. A good GUI can handle that easily. It's enter 12 pieces of art file names, and a sleep time between each in milli seconds and a set of coordinates for each art file that is exactly the same. It's one thing to have layout art such that no matter what size the window is, the art moves to fit, its another to have that same art "burn". Those positions are relative but "exact".

A rollover button that highlights as you drag your mouse over it? 2 pieces of art at the same position with another sleep so it doesn't "flash". Depress it and there is a depress "on" followed by a undepressed "on". rollover that and its "highlighted on" art. It looks very 3D but is just wads of art.

My recommendation is write a "control from the menu" library. A drawing library, a parse the dang Art file library. Make it send 'text' messages to the control library. Yes this is a bit heavyweight but all the light weight libraries I ever wrote became heavyweight in about 30 seconds due to changed requirements. So start with a resource file that can grow, write a quick text to resource file parser and then an artist GUI to resource file tool.

I bet if you look at the game developer sites you'll find some of these already written (But not as well as you'd like.)

  Yours,
  -Gary-