GUI Programming Sucks
Kind of. I’m just not a fan of it. I like the math side of programming more. Getting pixels in all the right places just isn’t as fun!
Anyways. Why am I GUI programming in the first place? Well, the GUI toolkit I was using started producing memory allocation errors at run time. I got an updated version at some point, and it went kaput.
It’s okay though, I didn’t really like the library all that much in the first place. Plus, it made work on my own GUI library, which, for better or worse, is useful! In probably a total of 3 hours or so of working on it (including design and such, not just coding), I’ve got working buttons with mouse-over feedback and mouse click feedback. As buttons tend to be the most used GUI widget (I think, don’t quote me on that), I decided to implement them first. Also, they’re easy.
It’s following what I’d call a fairly strict OOP method. The parent->child path is pretty easy to follow. I’m using SFML for the drawing and events and all, it was just easier as I’ve been working with it for so long.
Anyway, here’s a basic outline of the planned/semi-implemented architecture (forgive me for the formatting):
GUI Window – It is essentially a glorified container of Widgets. It can have (theoretically) any number of children, which can be a type of Widget. It handles events (mouse movement, mouse clicks, etc) for its children, asks specific children to do their things based on those events, and asks the children to draw. That’s about it. To create and use a (basic) Window, you need to know all of 3 or 4 lines of code.
sgui::Window win(sf::Window, bool); // constructor(SFML window to listen to events and draw to, whether the GUI is active or not (receives events and draws or not)) win.addChild(sgui::Widget*) win.update(sf::Event) sf::Window.draw(win) // draw the Window
Fairly simple I’d like to think. Oh, right, outline.
Widget – This is what makes the GUI actually useful. Anything meant to be part of a GUI is a Widget (inherits from it). It has a basic constructor that gets the position, dimensions, the function to call when run, and a sf::Texture* for how the Widget looks. Each child may or may not have their own constructor for its needs. A Button (for example) asks for a string for its text, a font, and a color of the font. It has functions to tell if the Widget has been moused over or not, and to check if the mouse is on it. It has two pure virtual functions that need to be implemented by any children for them to work properly. These are clickFeedback() and mouseOverFeedback(). The names kinda give it away, they each are called to give the user a visual (and/or audial) feedback to a button press/mouse-over. I want to document this well, because anyone that may use the library (pretty much just me at the moment, but I have plans to put it up on Github or Bitbucket) may want their Widgets to act differently. Gives room for more customization! Maybe in the future I’ll add a simple Lua binding that lets you write Lua functions for those, to make things a bit easier and dynamic. I may not though, my goal for this library is to be simple and light. If a user of the library wants to make Widgets setup via xml files, they can write the file input code for themselves. Via a script? Write the code yourself for that. I’ve seen a lot of GUI libraries get, well, massive with lots of features and they end up having a steep learning curve. Keep tools simple and specific!
Then, that’s about it honestly. I have future plans for automated organization of buttons so you don’t have to care so much about getting all the coordinates right, but, that’s the future. I want stuff working nice and well first.
Filed under: C++, Computers, Programming Tagged: C++, computers, game engine, gui, GUI library, GUI toolkit, GUI widget, Lua, Programming, Scripting language via WordPress http://ift.tt/1cXHgIt
January 08, 2014 at 12:31AM
Thanks to IFTTT