- Forum
- General C++ Programming
- GUI Design
GUI Design
Dear forum folks,
I'm making a GUI library for SFML and thus I'll have some design decisions to make. The most important one:
To make, or not to make a base widget class.
If I'd make one (most probable!) I have two choices:
1. Declare a whole set of virtual functions that will be overwritten every time (eg. setPosition() etc)
2. Declare non-virtual functions which do some basic work and than call a callback which is provided by the derived class. This seems unnatural to me, but I've yet to see another design be used for GUI frameworks.
What's your input?
I'm making a GUI library for SFML and thus I'll have some design decisions to make. The most important one:
To make, or not to make a base widget class.
If I'd make one (most probable!) I have two choices:
1. Declare a whole set of virtual functions that will be overwritten every time (eg. setPosition() etc)
2. Declare non-virtual functions which do some basic work and than call a callback which is provided by the derived class. This seems unnatural to me, but I've yet to see another design be used for GUI frameworks.
What's your input?
Why would the virtual functions need to be overwritten every time? Every widget is going to have a position and size, right? So why not write that code once and keep it in the base class. No need to rewrite the same thing for every derived class.
@Disch: Yes, but teh size allocations wille have to be handled differently for all the widgets. For example a pushbutton will need to set it's text to the correct position again and that stuff.
I'd have to allocate the size and position the text correctly every single time I draw??
Also, should I protect the user from resizing too small (eg. text comes out of the button)?
Also, should I protect the user from resizing too small (eg. text comes out of the button)?
Maybe I'm misunderstanding. Why do you need to allocate anything?
I wouldn't. Rather, I would prevent drawing from happening outside the designated box.
Another option would be to do something like this:
1) Have the widget keep an offscreen surface/texture which has the drawn widget on it
2) Whenever you resize, the parent class can resize the control, and call a virtual internal draw function that draws to the offscreen surface (not to the screen)
3) The parent class's Draw function can simply draw the widget to the screen by drawing that offscreen surface.
Having a secondary texture/surface will prevent drawing outside the designated box. It also might speed up drawing because items are only redrawn when they need to be. On the flip side it uses more textures so it will consume more memory.
| Also, should I protect the user from resizing too small (eg. text comes out of the button)? |
I wouldn't. Rather, I would prevent drawing from happening outside the designated box.
Another option would be to do something like this:
1) Have the widget keep an offscreen surface/texture which has the drawn widget on it
2) Whenever you resize, the parent class can resize the control, and call a virtual internal draw function that draws to the offscreen surface (not to the screen)
3) The parent class's Draw function can simply draw the widget to the screen by drawing that offscreen surface.
Having a secondary texture/surface will prevent drawing outside the designated box. It also might speed up drawing because items are only redrawn when they need to be. On the flip side it uses more textures so it will consume more memory.
In my opinion, you should do the opposite.
Instead of making a gui library for SFML, i think it could be more appropriate to take an existing GUI library, and eventually link the SFML drawing functions to a child of the 'Canvas' or 'DC' (draw context) class of the GUI library (the widget in which you can draw).
That way you will have a working GUI library with the possibility to add SFML graphics.
And once that is done, you can eventually overload the base widgets of the GUI library to give them an other appearance thanks to SFML drawing functions
I'm planning to do something like that to use Cairo in Fox Toolkit for example (when i have some free time :P )
Instead of making a gui library for SFML, i think it could be more appropriate to take an existing GUI library, and eventually link the SFML drawing functions to a child of the 'Canvas' or 'DC' (draw context) class of the GUI library (the widget in which you can draw).
That way you will have a working GUI library with the possibility to add SFML graphics.
And once that is done, you can eventually overload the base widgets of the GUI library to give them an other appearance thanks to SFML drawing functions
I'm planning to do something like that to use Cairo in Fox Toolkit for example (when i have some free time :P )
I'm making this for the purpose of learning, so I'd rather do as much as possible myself :)
@Disch:
Each widget has a rectangle which defines it's boundaries. I draw sf::Shape::Rectangle with said boundaries and inside it I position my text. But that is already positioned correctly before I draw.
Thus, when the user calls setPosition() and stuff, the text needs to move with it.
@Disch:
Each widget has a rectangle which defines it's boundaries. I draw sf::Shape::Rectangle with said boundaries and inside it I position my text. But that is already positioned correctly before I draw.
Thus, when the user calls setPosition() and stuff, the text needs to move with it.
For inspiration, some documentation about FOX Toolkit :
The base window class and the methods it needs: http://www.fox-toolkit.org/window.html
How layout works : http://www.fox-toolkit.org/layout.html
How FoX and other libs exchange message between widgets : http://www.fox-toolkit.org/messages.html
Something to consider, do you plan to make a GUI library where you place everything at an absolute position and size? Or a library where widget positions and sizes are function of their order in their containing window and their layout style?
The base window class and the methods it needs: http://www.fox-toolkit.org/window.html
How layout works : http://www.fox-toolkit.org/layout.html
How FoX and other libs exchange message between widgets : http://www.fox-toolkit.org/messages.html
Something to consider, do you plan to make a GUI library where you place everything at an absolute position and size? Or a library where widget positions and sizes are function of their order in their containing window and their layout style?
Topic archived. No new replies allowed.