Architecture for a C++ Widget Library

Started by
0 comments, last by Amr0 7 years, 11 months ago

Can I have some advice regarding architecture please?

I'm making an open-source widget library in C++. It is intended to be used alongside DirectX or OpenGL to make UI creation faster and easier. However it has no dependencies itself, not even Boost. It will consist of a basic set of widgets which can nest inside each other, have mostly automatic layout and respond to click / drag events.

The library does not handle drawing by itself. It produces 2D geometry in the form of vertex + index arrays which can be passed by the user to OpenGL or DirectX.

The current design is as follows (see attached UML diagram):

class WL_GeometrySet: Contains a vector of floats (vertices) and a vector of ints (indices). These are to be passed by the user into their API's vertex buffer and index buffer or the equivalents. Also stores a primitive type, for example lines or triangles.

class WL_IDrawable: This is an abstract class and the base class for all widgets. This is done on the assumption that every widget is at least sometimes visible (or it wouldn't be a widget). WL_IDrawable contains geometryData which is a vector of WL_GeometrySet. It has a virtual function UpdateGeometry() which populates geometryData, but the specifics are left to the subclass to implement. WL_IDrawable also contains bufferObjData which is a pointer to void. The user can fill this with what they want (GLuint buffer IDs for instance) and use it to render the widget using their chosen API.

class WL_IContainer: You get the idea, it can contain any other widget via polymorphism.

class WL_Button, WL_Checkbox, WL_Panel etc. These are the widgets.

So my questions are:

1) Am I using inheritance in the right way?
2) Is there a better approach to using a pointer to void for the buffer data?
3) Is it a bad thing that the library doesn't handle drawing the controls itself?
4) Would this library be difficult to use, and if so why? Can you see any obvious pitfalls / naïveties / usability issues with the approach I'm taking? Any general criticisms?

If anyone is interested in downloading the library along with an example project (though these are very incomplete at the moment), go to https://sourceforge.net/projects/open-cpp-widget-library-ocwl/

Advertisement

The library does not handle drawing by itself. It produces 2D geometry in the form of vertex + index arrays which can be passed by the user to OpenGL or DirectX.

That the library doesn't handle drawing itself is not a bad thing. But instead of being geometry based, why not texture based? Why not asking the client to implement a simple rendering interface, or an entire platform interface for gui event handling/triggering as well as drawing:


class GuiPlatform
{
	public:
	// rendering
	virtual void RenderItem( Rectangle rect, TextureId texture, Rectangle texturePortion ) = 0;
	virtual TextureId LoadTexture( const char* fileName ) = 0;
	
	// system interaction
	virtual point GetCursorPos() = 0;
	virtual size GetWindowSzie() = 0;
	virtual int HanleEvent( EventType, EventData ) = 0;
};


bool InitGuiLibrary( GuiPlatform* myGuiPlatform );

Then in your SDK provide sample implementations for DX11, OpenGL, Win32, or whatever.

Edit: Personally I'd name it Open Widget Library (OWL), but that's just me... owls are cool [@v@]

This topic is closed to new replies.

Advertisement