A Blender-like/WIP/C++ GUI toolkit, is anyone interested and could give comment?

Hello Everyone,

I’m not sure how many guys here would like to discuss the Blender user interface.

 I started to learn how to use Blender 2 years ago. At the first time I opened the application, I was attracted by the simple, fast user interface.
 When I read the source code, I was surprised that all the UI elements were drawn in OpenGL directly, and until now Blender is still using OpenGL APIs prior to 2.1. (Which is called legacy APIs now and they are removed from OpenGL 3.3).

 Besides, the user interface is written in C and embedded in Blender editor, it's hard for a beginner to reuse the code, there're only Python APIs to extend the UI.

 From my experience with some GUI toolkits such as Qt,Gtkmm, I think it's better to use an object-oriented language (e.g. C++) for user interface.

 So 1 year ago I started to try to develop a Blender-like GUI toolkit in my spare time, just for fun!

 Here're some highlight features I plan to complete:

I use C++ to develop this toolkit, and some concepts from Qt and Gtkmm, so every UI element is an object: a button, a slider, an imageview, a listview etc.

For example, a button can be created by just 1 line:

Button* btn = new Button("Hello World!);

There’s container to hold a sub widget or sub container, for example, a button can be added in a Expander:

Expander* expander = new Expander;

You can use a smart pointer which support reference counting, so that you don’t need to release an object manually:

RefPtr<Button> btn(new Button("Hello World"));

And an sub widget which is set managed, can be release automatically when its container destroyed:

Button* btn = Manage(new Button);
Expander* expander = new Expander;
delete expander;      // this will delete btn too.

I use modern OpenGL (OpenGL 3.3+), there’re predefined and simple shaders to draw a widget and you can use your own in your subclasses.

For example, I use a geometry shader to generate the effect of jitter, which makes the outline of a widget looks anti-aliased.

I use CppEvent to provide a fast Event/Delegate (signal/slot) mechanism. For example, if you need to do something when a button click:

events()->connect(btn->clicked(), this, &ClassName::OnButtonClick);

and disconnect when you don’t need it:

btn->clicked().disconnect(this, &ClassName::OnButtonClick);

A GUI toolkit should never waste resources to redraw widgets each time.
With OpenGL 3.3+, you could use Framebuffer Object for off-screen rendering. In this toolkit, partial redraws can be done by overriding some virtual functions and draw some regions only once when needed.

 So, put all together, you could reuse preset widgets, for example, a FileSelector:<img src="/uploads/default/original/4X/9/8/9/989034c36525a992b5de1145cb4e1c9ee3ec36b2.png" width="654" height="500"><br/>

 , and build your own Blend-like application quickly,<img src="/uploads/default/original/4X/7/8/9/7890b4e9b6e134552ac893cf742ed520f0138c91.png" width="690" height="446"><br/>

 The weakness of such C++ toolkit is that it cause difficulty to write python binding, I'm learning SWIG (http://www.swig.org) to figure it out. 

 Finally, please notice this toolkit is not finished, it's still under development, very very buggy, not fine-tuned. Above all, this toolkit actually has nothing to do with Blender.

 I just want feedback from you if it's worth to continue to develop such toolkit. The progress is not as fast as I expected, and sometimes I doubt what I've done is useless.

 I'd appreciate any comments.

The source code is hosted on https://bitbucket.org/zhanggyb/blendint

Hi, interesting project… a few things that came up while reading your post.

  • Would this be compatible with existing .blend files? (which store window layout)
  • Would this be compatible with existing addons? which define their own UI.
  • How much of Blender’s code would have to be converted to C++? (and which areas)
  • How would this integrate with the RNA API? (You mention SWIG bindings…)
  • How would this fit with Blender’s existing Layout engine? (uiLayout).
  • Would there be some fallback for hardware that doesn’t support OpenGL 3.3 (some users have older Intel cards which don’t do FBO’s, though this is becoming less and less of a problem as time passes)
  • Replacing one UI system with another is a big task, did you consider a way to do this incrementally?
  • Are you proposing to integrate this into Blender? or would this be a task for others.


  • What would benefit’s would an average user expect to see?
  • What might be possible with such a toolkit that is currently impossible/impractical.

Hi ideasman42,

Your questions let me become enlightened.

At first I just wanted to develop a lightweight, standalone GUI toolkit. It's too superficial without considering if it can improve and compatible with Blender.

I need time (maybe several months) to read Blender's code carefully, and think about your questions.

Thank you so much!

If you’re developing this as a toolkit to eventually replace the GUI code in Blender (PLEASE, YES, DO IT!) then I’d say push forward. This is one of the biggest headaches when coding for Blender.

If you’re developing this as a general graphics framework, you’ll have to consider what this offers over something like Qt. I completely agree that there is room to improve on these frameworks in general. It would be exciting to see this project be the beginnings of the “next big thing”, and I absolutely love the simplicity of the examples you’ve posted so far.

Some other points regarding your proposal…

You’re making quite a few architectural/technology changes at once.

  • Move to new C++ API.
  • Move Python from RNA API to Swig.
  • Move to new OpenGL API.
  • Move from C to C++.

We could do any of these or none of them, but making a lot of changes at once seems quite risky.

Also, the existing API has cobwebs (years of incremental updates on old codebase), but there is a case to be made for updating that instead of a rewrite.

We could for example…

  • Refactor C API to make UI code less complicated.
  • Rewrite OpenGL drawing to make use of more modern efficient methods.
  • Move UI C++ without making any significant API changes (to begin with).

… so I think its not an all-or-nothing situation with UI code.

If you make a shiny new API, it will of course look nice and simple and an improvement on existing code, but over time it will gather its own cobwebs. So I think its reasonable to check on whats wrong with the existing UI and see if that can be solved.

Other things to consider.

  • It would be sensible to have some experience extending the existing UI before attempting a rewrite.
  • For such a large project you will (eventually) need the support of existing developers.
  • Its worth checking with existing developers to see whats wrong with the existing API, their input may be useful.
  • We don’t in fact use the C-API for UI all that much (not directly), a lot is done in Python, so how much do we gain by having a new API.
  • Are you solving real problems?
    – Did you benchmark how much older OpenGL API use slows down the interface? (I did a while back, and the I found it was taking hardly any time), would improving OpenGL-API use even give noticeable performance gain?
    – You reference smart-pointers, while reference counting can be nice, we don’t have a problem with memory leaks with in the UI (at least not in years as far as I know).