What would you like in a GUI library?

Started by
6 comments, last by DrEvil 16 years, 3 months ago
Hello everyone, and a happy new year. As far as I know, there is no decent, easy to use, high-performance, good looking, customizable (skinnable), and free GUI library for use with DirectX. So I've decided to make one, but before that, I thought it would be a good idea to consult with you guys on how you would like it to be. Please, advise on all aspects (API design, underlying technology, skinning format... anything). Here is the design I currently have in mind (all subect to change depending on your input): The library will be very similar to the Win32 GUI library; every control is a window, a window has a parent and children, a client area and a non-client area, a message processor... etc. Later, thin C++ wrappers can be written for those who love classes. The library will use the same messages used in the Win32 API (WM_MOUSEMOVE, WM_CLOSE... etc) with the same semantics. There will be three main components in the library. The first is an entity (class) that the application will interact with (let's call it the GUI core). The application notifies the GUI core about the major input messages (mouse movement and keyboard strokes). The GUI core does the necessary processing to send the appropriate messages to the appropriate "windows", like sending a WM_SETFOCUS to the window under the mouse when the mouse button is clicked. Of course, internally, the GUI core will keep track of all windows created. Also, the "windows" will use methods of this core that are replacements to Win32 API functions, like GetCursorPos(), GetWindowRect(), MoveWindow(), SetTimer()... etc. This is required since the windows of the library will not be actually Win32 windows, and it also has the advantage of facilitating the process of porting the library to another platform in the future. This approach has the advantage that users of the library will not have to learn anything new - if they can program GUI stuff under Win32, they will be able to use the library right away. So, for example, when a button is pressed, it will send a WM_COMMAND message to its parent, just like a regular Windows' button would. The second main component in the library will be a drawing component - a class which encapsulates the basic drawing functions which can be used by windows to draw themselves. This class will have methods like FillRect(), DrawEdge(), DrawText(), DrawTexturedRectangle(), DrawGradient()... etc. This class will facilitate porting to another graphics API (the main API that will be used at first will be Direct3D 9). The third component is of course the windows themselves, keeping track of their parents and children, rectangles and client-area rectangles.. etc. As for skinning, I'm thinking of starting with using native Windows' visual styles, using uxtheme. With some digging, it should be possible to even use a visual style other than the one the user is using (directly from an msstyles file). Obviously this has the advantage that there are already hundres of cool themes out there, but the disadvantage that it's a Windows' only thing. Phew... ok.. what do you think?
Advertisement
I think that thousands of programmers (myself included) have fallen into the "write my own GUI library" trap. It's a fun project...at first. It's fairly easy to get a simple framework and some easy widgets implemented. But a full-blown GUI library as you've described could easily take 500 solid hours of design, programming, testing, and debugging. Some things are surprisingly involved too (e.g., scaling/resizing). Most programmers (including me) lose interest before getting anywhere close to finishing. Still I think it's a useful learning experience to design a GUI library since you have to solve a few interesting design challenges. But after you solve those, it's a whole lot of unpaid and uninteresting grunt work to actually implement and test and debug a complete GUI library on your own.
Thanks for the fair warning, but I guess I will at least try anyway. I realize it might take a lot of time, but hey, time I've got all the time in the world - I'm a recluse! I leave the house an average of once every couple of months. Thanks for your input anyway.
Quote:Original post by Wade Steel
I think that thousands of programmers (myself included) have fallen into the "write my own GUI library" trap. It's a fun project...at first. It's fairly easy to get a simple framework and some easy widgets implemented. But a full-blown GUI library as you've described could easily take 500 solid hours of design, programming, testing, and debugging. Some things are surprisingly involved too (e.g., scaling/resizing). Most programmers (including me) lose interest before getting anywhere close to finishing. Still I think it's a useful learning experience to design a GUI library since you have to solve a few interesting design challenges. But after you solve those, it's a whole lot of unpaid and uninteresting grunt work to actually implement and test and debug a complete GUI library on your own.

Really? Mine does resizing relatively simply-- I have a series of four floats akin to a RECT that I pass into a vertex shader that transforms vertices. I then do a pretty painless test to see if the mouse has been clicked within a certain radius of the window borders when I update cursor and button press states. If an edge is clicked, just monitor the change in mouse position and adjust the values for my window size structure as needed, until the mouse is released. I'm not sure if that's your idea of 'hard' or you're thinking of another method. *shrug*
clb: At the end of 2012, the positions of jupiter, saturn, mercury, and deimos are aligned so as to cause a denormalized flush-to-zero bug when computing earth's gravitational force, slinging it to the sun.
Sorry I wasn't clear. I meant handling the various ways widgets can scale (or not) with the resizing of their parent container. You can't simply scale a GUI since you usually want some things to stay the same size but others to scale. For example, one approach to this problem is the various "sizer" classes of wxWidgets.
I'd really like to see an .Net/Mono GUI system that makes use of Tao.OpenGL.
I know a fellow who has worked on a DirectX based GUI system before, he called it View GUI. However it's a plugin for Dark Basic Professional (But it uses the pure Direct3D calls), so I'll see if he'll port it or not. Here's a link to it: http://forum.thegamecreators.com/?m=forum_view&t=120273&b=8


Cheers,

-naota
Madness never stops..... It takes a breather every once in a while, but then it grabs it's inhaler and chases you down the street with a cane.
I'd like to see an open source Scaleform competitor. Flash based GUIs are practically the norm these days in games, and is unbeatable in terms of flexibility of an attractive GUI in their look and animation capability, and on top of that being flash gives you a big pool of talent to pull UI artists from. There's really no GUI that can compete with scaleform/flash for game UIs, but the price tag is well out of range of indy/hobby devs.

This topic is closed to new replies.

Advertisement