Using Qt for the Blender Interface

The interface, modeling, 3d editing tools, import/export, feature requests, etc

Moderators: jesterKing, stiv

Aardbei
Posts: 0
Joined: Wed Nov 29, 2006 2:01 pm

Using Qt for the Blender Interface

Post by Aardbei » Wed Nov 29, 2006 3:06 pm

When I'm browsing through the Blender source code, I'm not happy. Everything from the user interface is put into large files and written in C, which make it hard to make any adjustments, let alone to add in new features.

A lot of code is duplicated around the place, OpenGL is often called natively (bad, bad, OpenGL ain't a 2D toolkit), states are switched on and off to anyone's wishes and there's no such thing as a widget-concept in Blender.

Basically, replacing the current "GUI"-code with something like Qt or any other real widget toolkit (which would bring along a lot of needed things for Blender), would mean a total rewrite of that specific part of the code.

Qt is fully GPL these days, available for Windows, OS X and Linux. Would there be any reason not to switch to a real GUI-toolkit, apart from the work that's needed?

It would solve a lot of bugs with Blender (and add new ones, but that's a whole different story :mrgreen:), users would be happy and dancing, the streets would become paved in gold and milk and honey would flow.

It would also fix the unprofessional looking shaky widgets in Blender, the 4px alignment of "windows" and Blender could use sexy programmer interfaces to draw new widget or viewport elements instead of using OpenGL natively. Qt would add another benefit: style sheets for all widgets, dialog/window editing through Qt Designer, easy experimenting with new layouts and sexy GUI animations (sorry, let's pretend I didn't say anything about that last feature).

Am I alone in the dark? Or are there more people out there that would like to see Blender using a real GUI-toolkit?

I think Blender deserves it. It's a great program, really. But the code under tha hood is certainly not always that great. Heck, if anyone thinks it would be nice to have a QtBlender, I'd even be willing to start hacking on it myself...

[/end rant from a Blenderlover]

stiv
Posts: 0
Joined: Tue Aug 05, 2003 7:58 am
Location: 45N 86W

Post by stiv » Wed Nov 29, 2006 9:09 pm

Yeah, we totally suck. The best thing to do is delete both the source and any executables off your system before they contaminate everything.

Aardbei
Posts: 0
Joined: Wed Nov 29, 2006 2:01 pm

Post by Aardbei » Wed Nov 29, 2006 9:29 pm

I understand your sarcasm, but I didn't say you suck, nor did I say that Ton sucks and I didn't say his vroomjacket sucks either.

It's just that I'm greatly annoyed. I would really like to help with Blender, even if it's just small stuff, but I can't because it takes far too much time to dive into those large source files, trying to find my way inside of them. It takes far too long to get a grip on what does what and why and how.

Please don't get me wrong or think I'm trying to flame or to put off anyone, I'm just trying to say the gui-code could be much more efficient in terms of readability and the ability to add new things to it.

Perhaps I'm spoiled by all the large gui-toolkits and large scale C++ programs, but for me, the gui-code in Blender equals a visit to hell.

That doesn't mean I don't like Blender, nor do I dislike the rest of Blender (for instance, I think the new modifier-stuff is awesome and kicks totally butt!). Actually, I'd just like to see it being improved so that new programmers or part-time programmers could help you guys with Blender and make the program even better!

If you did read my previous post, you've probably also read I even offered to help out myself...

LetterRip
Posts: 0
Joined: Thu Mar 25, 2004 7:03 am

Post by LetterRip » Thu Nov 30, 2006 3:45 am

Qt is fully GPL these days, available for Windows, OS X and Linux. Would there be any reason not to switch to a real GUI-toolkit, apart from the work that's needed?
There is probably zero (or at least quite little) chance of QT or GTK or any other rather heavy gui toolkit being used with Blender. Ton very much wants to keep the download size to roughly within its current size, and not have significant outside dependencies other than what ships standard with most platforms.

Even if Ton were willing on the download side or on the blender load time side, I suspect that the toolkits are rather ram hungry - which means a lot less ram that can be used for your mesh, scene, etc.

The OpenGL is scheduled for a partial cleanup with the interface refactor and the tool api refactor (which come after 2.43), if you'd like to help you might want to introduce yourself on the bf-committers mailing list.
It's just that I'm greatly annoyed. I would really like to help with Blender, even if it's just small stuff, but I can't because it takes far too much time to dive into those large source files, trying to find my way inside of them. It takes far too long to get a grip on what does what and why and how.
If you check the blender development documents on the wiki, there is a section that can help you navigate things faster, also cscope and other source browsers should help. Generally the advice is to scan space.c for the function or a related function you are interested in, then use cscope or just grep to find the area of source you want work on.
Please don't get me wrong or think I'm trying to flame or to put off anyone, I'm just trying to say the gui-code could be much more efficient in terms of readability and the ability to add new things to it.
I don't think there is any disagreement there. Improving the gui related code is a todo, as is improving the flexibility of the code as relates to the interface, both of those should help readability and extensibility.

Of course if those will for certain happen right after 2.43 is in question - the refactors have both been in the cards for awhile. Ton was willing to do them for this release - but it was agreed that since the changes would be large and widespread it would delay this coming release too long, and thus it has been pushed back to after 2.43 (which should come end of December or so).

LetterRip

Aardbei
Posts: 0
Joined: Wed Nov 29, 2006 2:01 pm

Post by Aardbei » Thu Nov 30, 2006 7:32 am

LetterRip wrote:There is probably zero (or at least quite little) chance of QT or GTK or any other rather heavy gui toolkit being used with Blender. Ton very much wants to keep the download size to roughly within its current size, and not have significant outside dependencies other than what ships standard with most platforms.
Well, I can understand that as well and I appreciate it when Ton wants to keep everything as small, lean and clean as possible.

Let's put it another way then. Would it be acceptable if Blender would start using a library like Cairo (using Glitz) and a custom small sized and themable widget toolkit? (where a widget is just the same as what Blender is currently doing with the scissor/viewport-thing, just a bit more defined and extensible).

Qt was just an example.

I'll have a look at that developer list.

jesterKing
Site Admin
Posts: 207
Joined: Fri Oct 18, 2002 12:48 pm
Location: Finland

Post by jesterKing » Thu Nov 30, 2006 8:25 am

I think a C-library for the UI would stand much better chances of being considered.

/Nathan

joeri
Posts: 96
Joined: Fri Jan 10, 2003 6:41 pm
Contact:

Post by joeri » Thu Nov 30, 2006 4:07 pm

Yes please, can we slowdown the interface so it's easier for programmers to work on blender? Who uses blender for real 3d work anyway?

Aardbei
Posts: 0
Joined: Wed Nov 29, 2006 2:01 pm

Post by Aardbei » Thu Nov 30, 2006 9:03 pm

Could you leave the sarcastic comments away, please? Is this how you welcome potentially new developers into the Blender developer community? I sure hope not.

You are one of the developers on Blender, are you?

Changes can actually be a good thing. You seem to be affraid of changes, while you're using a software package that's shunned by a number of people because it's different. They have to change their minds and start using it.. you see what I'm getting at? Change is a good thing.

And heck, if there's one thing I'd want from a fully widgetized gui (without the slow subwindows from the operating system, that is), it would be speed... (more speed than I can currently get on my laptop, at least)

You don't know me or my programming work, but if there's anything I've always wanted, it was speed and sexy graphics (in that specific order).

kAinStein
Posts: 63
Joined: Wed Oct 16, 2002 3:08 pm

Post by kAinStein » Thu Nov 30, 2006 11:21 pm

Aardbei wrote:Could you leave the sarcastic comments away, please? Is this how you welcome potentially new developers into the Blender developer community? I sure hope not.
Honestly: Is that the way you introduce yourself to a community? I also do not hope so. Please check your attitude.

LetterRip
Posts: 0
Joined: Thu Mar 25, 2004 7:03 am

Post by LetterRip » Fri Dec 01, 2006 6:18 am

joeri and stivs, please do lay off the sarcasm it really isn't helpful or necessary.

kAinStein,

while his initial post was a bit critical I don't think he deserved the rather biting sarcasm he has recieved - all such a response does is discourage potential developers.

Aardbei - stivs is a developer he is one of our python API gurus, Joeri was one of the founders of Blender before it became open source. JesterKing is another developer, i am also but my actual coding activity is fairly limited. i'm not familiar with the nick kAinStein.

In response to your question - no potential developers are generally not greeted with sarcastic responses :) but I guess it depends on who you meet first and whether you might have touched a nerve :) (people frequently slag Blender on the UI side; and new coders frequently slag Blenders source as being difficult - there are some legitimate beefs with both - but they tend to be blown out of proportion and often times there are lots of unwarranted criticisms made out of ignorance).

Back to code topics, as jesterking states a C library would stand a higher chance of making it in. C++ libraries are sometimes allowed with C wrappers as long as we have a 'garunteed' maintainer and it is something that the core devs don't need to work on the code of.

Presumably we will need to do some changing of the 'guts' of the GUI toolkit as a practical reality of supporting current gui functionality.

Since you appear interested in making this happen, I suspect your best odds of doing so are send an email to bf-committers with the following information

1) toolkits to consider
2) brief overview of the toolkit, including
a) particular advantages we could expect from its usage
b) how cross platform is it? What windows versions does it run on, what os x versions, all posix including linux, irix, bsd and sun os?
c) does it have a c wrapper
d) what sort of size difference could we expect to see in the downloadable binaries for the major platforms (windows, os x, linux) (ie stripped and zipped binary size)
e) what sort of overhead for load time can be expected?
f) what sort of impact it might be expected to have on ram consumption and processor overhead and also impact on graphics card ram consumption and overhead
g) and a nice bonus - does it have good python bindings?

Also let people how much of the work you would be willing to do to make it happen.

Providing that information would provide ton et al information to make an informed decision.

Even if it isn't agreed that it would be a good idea, the refactor could potentially make it much easier for such a toolkit to be able to easily substitute in directly, or alternatively help us to plan out the refactor.

LetterRip

LetterRip
Posts: 0
Joined: Thu Mar 25, 2004 7:03 am

Post by LetterRip » Fri Dec 01, 2006 6:46 am

I just did some preliminary research

cairo does seem to be a pretty good fit,

it is in C, has a C API, and python bindings

http://cairographics.org/manual/language-bindings.html

it is small (177 kb compressed)

has good performance, good text support. Is fully cross platform.

http://cairographics.org/download
http://www.osnews.com/story.php?news_id=9609
http://www.gimp.org/%7Etml/gimp/win32/downloads.html

LetterRip

LetterRip
Posts: 0
Joined: Thu Mar 25, 2004 7:03 am

Post by LetterRip » Fri Dec 01, 2006 6:55 am

interesting overview of the 2d toolkits,

http://weblogs.mozillazine.org/tor/arch ... cairo.html

LetterRip

matt_e
Posts: 410
Joined: Mon Oct 14, 2002 4:32 am
Location: Sydney, Australia
Contact:

Post by matt_e » Fri Dec 01, 2006 7:40 am

Aardbei wrote:It's just that I'm greatly annoyed. I would really like to help with Blender, even if it's just small stuff, but I can't because it takes far too much time to dive into those large source files, trying to find my way inside of them. It takes far too long to get a grip on what does what and why and how.
First of all, it's not that bad. Even a self-taught fool like me has figured it out over time. Anyway, if the code is badly structured, swapping all the glBlahFunction() calls with CairoBlahFunction() isn't going to help anything. Structuring the code so it's easier to navigate is something that can be done independently of whatever toolkit is used, and I guarantee it'd be orders of magnitude easier to clean up and abstract Blender's GUI code than it would be to include some extra library, then recreate all the custom functionality that Blender needs, all the while making it as fast, stable, and cross-platform as Blender currently is.

joeedh
Posts: 31
Joined: Wed Oct 16, 2002 10:30 pm
Contact:

Post by joeedh » Fri Dec 01, 2006 8:25 am

Aardbei wrote: And heck, if there's one thing I'd want from a fully widgetized gui (without the slow subwindows from the operating system, that is), it would be speed... (more speed than I can currently get on my laptop, at least)
.
Why is opengl bad for 2D guis? Sure, coding things to be fast on all cards is hard, but just takes practice. I've coded a fairly full-featured (if not really full-widgeted) lightweight GUI toolkit myself (plus two other not-as-well-done frameworks), that went fairly fast and would've been MUCH faster if I'd made it in C, not python. :) It used opengl, though I admit I did design it to be usable with cairo as well; though sadly the python interfaces for that didn't work with my windowing library (I was using wxwidgets just for its windowing function *cringe*). :S

I think keeping opengl for blender UI would be a good idea; as I understand it you get a speed increase from doing it all in GL because you can write smarter ways to do overlays and the like that go a lot faster then what a non-GL host GUI toolkit can do.

Take menus for example; the proper way to do GL menus is to save the area of screen they're on, then paste it back whenever you want to redraw a menu. It requires no real draw cycles other then the menus, and goes lightning fast.

Joe

joeedh
Posts: 31
Joined: Wed Oct 16, 2002 10:30 pm
Contact:

Post by joeedh » Fri Dec 01, 2006 8:31 am

Aardbei wrote:I understand your sarcasm, but I didn't say you suck, nor did I say that Ton sucks and I didn't say his vroomjacket sucks either.

It's just that I'm greatly annoyed. I would really like to help with Blender, even if it's just small stuff, but I can't because it takes far too much time to dive into those large source files, trying to find my way inside of them. It takes far too long to get a grip on what does what and why and how.
That's because you're starting in the wrong files :) Other parts of blender are much cleaner (some are worse, some used to be MUCH worse :) ).

Here's some links for you:

http://www.blender3d.org/cms/Blender_Ar ... 336.0.html
http://www.blender3d.org/cms/Guides___S ... .87.0.html
http://www.blender3d.org/cms/Notes_on_SDNA.436.0.html

And especially read this:

http://mediawiki.blender.org/index.php/ ... w_Dev_Info

Post Reply