Using Qt for the Blender Interface

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

Moderators: jesterKing, stiv

Niels_42
Posts: 0
Joined: Tue Aug 22, 2006 8:59 pm

Post by Niels_42 »

FYI: A Qt benchmark overview: http://zrusin.blogspot.com/2006/10/benchmarks.html

I think the actual coders should decide what frameworks, if any, Blender uses. My personal preference would be a Qt GUI, with KDE extensions. Both from a user and a programmer point of view.
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.
I don't understand the problem with "heavy" -- a large toolkit moves GUI code from the application itself, making it lighter and smaller. All desktops already has such a toolkit, why not use it?
Why this need to keep the download size down? I know that there are still people on dialup, but it's not like there's a new blender every other day. Is 15MB every 6 months really such a disaster?
Dependencies: Users are used to them by now. All large applications have them, and the package managers usually handles everything just fine. I don't see a big problem in adding libxyz as a dependency, and I doubt most users will even notice.

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

Post by LetterRip »

Niels_42,
I don't understand the problem with "heavy" -- a large toolkit moves GUI code from the application itself, making it lighter and smaller. All desktops already has such a toolkit, why not use it?
Our largest user base is windows - so for that platform, none of the toolkits will reduce overhead just add it. We are a pure opengl program, any element not in opengl likely slows things down. On linux and many other unixes, you can avoid loading a gui at all and just load blender from the command line. If you are running in any environment other than QT than a QT gui is pure overhead.
Why this need to keep the download size down? I know that there are still people on dialup, but it's not like there's a new blender every other day. Is 15MB every 6 months really such a disaster?
Personally I do quicky downloads all of the time of testing builds when I'm on a computer that isn't mine to confirm that the latest test builds work on all sorts of computers, or if I want to do a quick show off of new features in CVS etc.

A small binary is extremely important for portability - it doesn't fit on a floppy but fits great on a cheapo usb key with plenty of room to spare for your save files.

It also is small enough that if someone asks me for a build with my new testing features I can trivially email it to them.

Small builds also means faster compile, build, and zip up - so saves on developer time.

If a toolkit offered compelling reasons to change to it, it might be worth sacrificing some size, etc. but thus far there is nothing compelling.

LetterRip

Niels_42
Posts: 0
Joined: Tue Aug 22, 2006 8:59 pm

Post by Niels_42 »

LetterRip wrote:Our largest user base is windows - so for that platform, none of the toolkits will reduce overhead just add it.
This is what Openoffice and Mozilla does -- invent their own toolkit and use it on all platforms. There are pros and cons.
LetterRip wrote:We are a pure opengl program, any element not in opengl likely slows things down.
True, but that's not the whole story. You have to look at where speed is important. When we're talking about the gui and about clicking buttons and moving sliders, speed isn't a concern. The issue is possibly with the 3d view. It's true that raw OpenGL is faster than almost anything, but if that speed comes at the price of heaps of difficult code, it may not be worth it. Maybe it's worth 1.2% gui speed to offload gui rendering to a dedicated toolset.
LetterRip wrote:On linux and many other unixes, you can avoid loading a gui at all and just load blender from the command line.
But that's not the situation we're talking about.
LetterRip wrote:If you are running in any environment other than QT than a QT gui is pure overhead.
And if you're offline, the network stack in the OS is bloat... You're right, but it's not a very large practical concern.
LetterRip wrote:
Why this need to keep the download size down? I know that there are still people on dialup, but it's not like there's a new blender every other day. Is 15MB every 6 months really such a disaster?
Personally I do quicky downloads all of the time of testing builds when I'm on a computer that isn't mine to confirm that the latest test builds work on all sorts of computers, or if I want to do a quick show off of new features in CVS etc.
That's a point, but only for few people. The vast majority of users only download new versions.
LetterRip wrote:A small binary is extremely important for portability - it doesn't fit on a floppy but fits great on a cheapo usb key with plenty of room to spare for your save files.
That's true even if the size grows to 100MB.
LetterRip wrote:It also is small enough that if someone asks me for a build with my new testing features I can trivially email it to them.
I think that's nice of you, but I can't see that this feature should dictate development.
LetterRip wrote:Small builds also means faster compile, build, and zip up - so saves on developer time.
Again, true. And every developer will always do his best not to bloat the code. But many other projects -- in fact most -- depend on some kind of toolset, without that scaring away developers.
LetterRip wrote:If a toolkit offered compelling reasons to change to it, it might be worth sacrificing some size, etc. but thus far there is nothing compelling.

LetterRip
I think that's the best answer.

Thanks

rmunn
Posts: 0
Joined: Mon Dec 04, 2006 2:10 pm

Post by rmunn »

LetterRip wrote: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
Cairo is a rendering engine, not a GUI toolkit. The GTK toolkit, which is a complete widget toolkit (written in C) that uses Cairo as its backend, is a bit of a larger download: http://gladewin32.sourceforge.net/modules/news/ has a 5.88Mb .exe installer for the GTK environment under Windows. (Linux environments would already have GTK).

So the cost in download size is non-trivial, but not huge either. The cost in development time to tear out the existing code and rebuild it would probably be the largest cost, to be weighed against what it would gain. The main gains, IMHO, would be an interface that would be more familiar and less off-putting to new users. That's quite a win, and not to be sneezed at. OTOH, it would involve quite a lot of work, so it's not a shoo-in either.

MHO, (speaking as someone who doesn't have to put in all the coding work to make it happen :wink: ) is that an interface based on GTK (which, since it's written in C, would be less work to implement than Qt) is definitely something that should be considered -- but that it'll probably go on the "nice to have someday, but not yet" list.

kattkieru
Posts: 17
Joined: Wed Oct 16, 2002 3:30 pm

Post by kattkieru »

Not that I'm a blender source coder but I wanted to chime in here:

1) GTK causes lots of headaches under windows, especially if you have multiple programs using it that aren't using the same version. (Dunno if this has been fixed, but Gimp and Gaim couldn't coexist for a while there because of this issue.) Also, GTK has no proper Mac port. No, X11 does not count. I *really* pray nobody ends up thinking a GTK port of Blender would be a Good Idea.

2) QT is snappier than I think most people expect or realize. Benefits of using it: Blender would finally be free of all its translation and i18n issues, there'd be a very nice UI designer available (possibly even retargetable for Python script UIs), UI coding in pure QT & C++ is *dead* easy, and it's very much cross-platform. Cons: it does add bloat. Also, it's not certain that using it would be faster than GHOST is currently. It would, however, be interesting to run tests on QT and GHOST and see where each outpaces the other.

3) GHOST doesn't really have any issues with it. It's stable, cross-platform, and at this point rather mature. The major UI issues in Blender stem from the sheer volume of new features being shoehorned into every nook and cranny, from poor naming conventions ("IPO", "RetOpo"), and from a lack of documentation on them. (Saying, "Read the code, it's all there!" doesn't count as documentation.) Anyway, instead of trying to merge in another toolkit, which as stated above would bring with it a number of issues both practical and political (never have figured out why people *insist* on C-based GUI toolkits with modern optimizing compiler efficiency being what it is, but I don't want to get into that argument), why not increase the usability of GHOST and aid in the upcoming code refactoring? Enforcing UI consistency -- keyboard shortcuts working the same in different spaces, the ability to type in numerical values for all tools (broken in some of the newer mesh tools), the ability to zoom-stretch tracks in the Sequencer, vertically, more than you currently can -- these are things that would benefit users, and sooner, more than a code fork or a rebuilding of the GUI using some other toolkit.

Personally, sure, I'd love to see a QT port of Blender. I think the benefits outweigh the code bloat considerations, but I don't see myself being able to help in that effort nor do I see the main developers agreeing that such would be a good idea. However, I'm willing to bet anyone offering patches to fix current issues in the UI and extend the functionality of GHOST would be welcomed with open arms.

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

Post by LetterRip »

Enforcing UI consistency -- keyboard shortcuts working the same in different spaces, the ability to type in numerical values for all tools (broken in some of the newer mesh tools), the ability to zoom-stretch tracks in the Sequencer, vertically, more than you currently can -- these are things that would benefit users, and sooner, more than a code fork or a rebuilding of the GUI using some other toolkit.
Not taking numerical input is probably a bug, so please report it. lukep is reviewing all of our bindings - once the tool api refactor happens - refactoring the bindings for consistency will be easier. Regarding tracks - file a request in the sequencer requests page at the wiki or in the conversation on the sequencer at blender nation.

LetterRip

mongrol
Posts: 0
Joined: Wed Jul 21, 2004 9:55 pm

Post by mongrol »

I'd like to offer an intermediate linux users opinion.

I like blender to be fast. I love how light and feature packed it is in a small footprint. Moving blender to QT, GTK, FLTK <name your favourite cross platform toolkit> would be a bad move in that all these toolkits add weight to the application and that slows things down. I don't agree with the belief that these toolkits would add a familiarity to new users and therefore show blender in a more favourable light to them. The workflow and mechanics of the interface would be the same and the widgets on the current interface aren't that difference from widgets on other toolkits.

While I understand the opinion of some developers who would welcome this in that it would make the codebase more attractive and codeable the decision has to be weighed heavily on what it provides the user and as far as I can see, it's provides no positives and the negatives of weight, inconsistancy, dependancies on other projects and a massive effort to move over.

I realise blender looks odd to new people but once you actually start producing stuff with it, this superficial opinion quickly changes and the benefits of the current presentation shows through.

Niels_42
Posts: 0
Joined: Tue Aug 22, 2006 8:59 pm

Post by Niels_42 »

mongrol wrote:Moving blender to QT, GTK, FLTK <name your favourite cross platform toolkit> would be a bad move in that all these toolkits add weight to the application and that slows things down.
You can say that about any program. But most programs do use Qt, GTK or similar, simply because it's a smart move for most purposes. It's a good idea not to reinvent the wheel, but use GUI features already developed and streamlined in toolkits. Blender may be different, it may be that its demands are too special to be easily provided by common toolkits. But that has not been shown.
mongrol wrote:While I understand the opinion of some developers who would welcome this in that it would make the codebase more attractive and codeable the decision has to be weighed heavily on what it provides the user and as far as I can see, it's provides no positives and the negatives of weight, inconsistancy, dependancies on other projects and a massive effort to move over.
I agree that it's not essential (or wanted) to make a large change right now. But I think you're overstating the negatives a bit.
mongrol wrote:I realise blender looks odd to new people but once you actually start producing stuff with it, this superficial opinion quickly changes and the benefits of the current presentation shows through.
You can say that about any interface you've spend a couple of years on. There's a good reason why Windows / OSX / KDE / Gnome tries to make applications look and behave in a consistent manor.

Thanks

N86
Posts: 0
Joined: Mon Jul 25, 2005 11:51 am

Post by N86 »

Please do not use a toolkit. This just creates essentially another program you have to maintain and update insync with Blender. Cleaning up the code is the best option.
LetterRip wrote:
Quote:
Why this need to keep the download size down? I know that there are still people on dialup, but it's not like there's a new blender every other day. Is 15MB every 6 months really such a disaster?

Personally I do quicky downloads all of the time of testing builds when I'm on a computer that isn't mine to confirm that the latest test builds work on all sorts of computers, or if I want to do a quick show off of new features in CVS etc.

That's a point, but only for few people. The vast majority of users only download new versions.
This is not true. I can point you to some stats, but a lot of people download CVS builds. We wouldn't have sites like BlenderBuilds or Graphicall if this was the case. I download every new update of the CVS I can and have multiple installs on my system.

Niels_42
Posts: 0
Joined: Tue Aug 22, 2006 8:59 pm

Post by Niels_42 »

N86 wrote:Please do not use a toolkit. This just creates essentially another program you have to maintain and update insync with Blender. Cleaning up the code is the best option.
99% of desktop applications use a toolkit. Why is Blender different?

The user doesn't need to update the toolkit, nor do the developers have to maintain it. That's the whole point.

If you want Blender to be self-contained, why doesn't that apply to any other program you use?
N86 wrote:
LetterRip wrote:
Quote:
Why this need to keep the download size down? I know that there are still people on dialup, but it's not like there's a new blender every other day. Is 15MB every 6 months really such a disaster?

Personally I do quicky downloads all of the time of testing builds when I'm on a computer that isn't mine to confirm that the latest test builds work on all sorts of computers, or if I want to do a quick show off of new features in CVS etc.

That's a point, but only for few people. The vast majority of users only download new versions.
This is not true. I can point you to some stats, but a lot of people download CVS builds. We wouldn't have sites like BlenderBuilds or Graphicall if this was the case. I download every new update of the CVS I can and have multiple installs on my system.
Almost all open source projects provides anonymous CVS (or SVN) for exactly this purpose. That a website gives you a compiled version of current CVS every days is certainly nice of them, but that shouldn't really dictate developer choices.

And I still don't agree that using Qt or GTK would increase Blender in size -- quite the contrary actually, it should become smaller.

The thing we should be concerned about are whether Qt (or something else) would make Blender better. Will the source be easier to understand, extend and maintain? Will the interface improve? What about GUI speed? What about platform compatibility? Download convenience is, imo, a rather irrelevant point.

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

Post by LetterRip »

99% of desktop applications use a toolkit. Why is Blender different?
1) Most tools with GUIs performance is not that critical - most high end 3D software use their own toolkits
The user doesn't need to update the toolkit, nor do the developers have to maintain it. That's the whole point.
Clearly you haven't worked with any of the opensource toolkits ;) Most significant QT and GTK apps i'm aware of spent a huge amount of time upgrading to different versions of the toolkits. Most of them required tracking the latest CVS builds of the toolkit to keep current.
If you want Blender to be self-contained, why doesn't that apply to any other program you use?
This is a tool that requires performance - most others don't. This is a tool where the added productivity of using CVS can be ridiculously huge, that is almost never the case for other software.
Almost all open source projects provides anonymous CVS (or SVN) for exactly this purpose. That a website gives you a compiled version of current CVS every days is certainly nice of them, but that shouldn't really dictate developer choices.
Actually the availability of testing builds is very important to developers. Constant testing and feedback is a major benefit. Also because we are a cross platform and artists tool - most of our user base it is not reasonable to expect them to compile their own. Setting up and getting a build environment on Windows for instance is not trivial for most users.

Also you are advocating a change that appears to offer no significant benefit over using our current methods but a number of disadvantages.

LetterRip

Niels_42
Posts: 0
Joined: Tue Aug 22, 2006 8:59 pm

Post by Niels_42 »

LetterRip wrote:1) Most tools with GUIs performance is not that critical - most high end 3D software use their own toolkits
We don't know how large a performance penalty something like Qt would impose. Maybe it's worth it.

Would it be fair to say that Blender's GUI performance is mainly critical for a 3d view with a lot of polygons?
LetterRip wrote:
The user doesn't need to update the toolkit, nor do the developers have to maintain it. That's the whole point.
Clearly you haven't worked with any of the opensource toolkits ;)
Heh!
LetterRip wrote:Most significant QT and GTK apps i'm aware of spent a huge amount of time upgrading to different versions of the toolkits. Most of them required tracking the latest CVS builds of the toolkit to keep current.
I think you're overstating the added work a bit. If GTK develops nice new features, Blender would probably want to use them, so it's not all bad.
LetterRip wrote:
Almost all open source projects provides anonymous CVS (or SVN) for exactly this purpose. That a website gives you a compiled version of current CVS every days is certainly nice of them, but that shouldn't really dictate developer choices.
Actually the availability of testing builds is very important to developers. Constant testing and feedback is a major benefit. Also because we are a cross platform and artists tool - most of our user base it is not reasonable to expect them to compile their own. Setting up and getting a build environment on Windows for instance is not trivial for most users.
If Blender moves to GTK, users will install GTK on their computer, upgrade it rarely, Blender will shrink and everybody's happy. OK, that's oversimplifying things, but I just don't see using a toolkit as all bad and the end of civilization.
LetterRip wrote:Also you are advocating a change that appears to offer no significant benefit over using our current methods but a number of disadvantages.

LetterRip
I'm only advocating that we should talk about actual use-case benefits and developer improvements, not vague issues like "I like things as they are" or "C++ is evil". I've also stated that I think this is a decision for the developers, not newbies in the forums.

If you can't see any advantages to something like Qt at all, then I suggest that you're not looking at it completely unbiased -- no offense.

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

Post by stiv »

If you can't see any advantages to something like Qt at all, then I suggest that you're not looking at it completely unbiased -- no offense.
It is not a question of whether there are any advantages. The question is whether the advantages exceed the drawbacks, and by how much.

kattkieru
Posts: 17
Joined: Wed Oct 16, 2002 3:30 pm

Post by kattkieru »

Niels_42 wrote:We don't know how large a performance penalty something like Qt would impose. Maybe it's worth it.
I think that until someone goes ahead and runs the tests, showing what a BlenderQT port could do, talking about performance changes in any fashion is moot. I would like to see that test, though.
Would it be fair to say that Blender's GUI performance is mainly critical for a 3d view with a lot of polygons?
Actually no. Blender outpaces Modo and C4D when it comes to interface speed by a large margin, if the recent demos for both of those programs are any indication. Try reshaping the UI in Modo on a G4 and you'll be begging for Blender's responsiveness again.
I think you're overstating the added work a bit. If GTK develops nice new features, Blender would probably want to use them, so it's not all bad.
Like what? GHOST already has widgets that have all basic windowing toolkit functionality. Aside from GNOME integration (which is a feature that'd be wanted by a fraction of Linux users, who are in turn a fraction of total Blender users), what benefits would GTK bring to Blender? What features would be worth dropping GHOST, and going through all that work of integrating a new windowing toolkit, instead of just copying the features in GHOST?
If Blender moves to GTK, users will install GTK on their computer, upgrade it rarely, Blender will shrink and everybody's happy. OK, that's oversimplifying things, but I just don't see using a toolkit as all bad and the end of civilization.
It's not, but look at python. It's the largest truly external dependency Blender has, and between versions of it things break. Hell, right now Blender basically has to support three versions of Python (2.3, 2.4, and 2.5) because each version does things a little differently, and you can never be sure what a system has installed. From what I've seen of GTK and how it breaks programs between versions, I don't think introducing that kind of headache into Blender would be in any way an aid to the development cycle. (How many newbie messages are about Python not working?) Also, GTK is, again, not the best as a cross-platform solution. There is no proper Mac GTK port. By changing to it, Blender would either lose support for one OS or have to spend a great deal of time adding to GTK to bring it up to speed with Aqua.
If you can't see any advantages to something like Qt at all, then I suggest that you're not looking at it completely unbiased -- no offense.
The question really isn't one of visible advantages or disadvantages, but of weighing the two against each other. [edit: that was written before stiv posted.] Thus far no one's come up with solid reasons why the advantages outweigh the foreseen difficulties. So how about we be concrete: what problems do you think moving from GHOST to QT would solve, and what problems do you think such a move would introduce?

Here's some benefits off the top of my head for QT, which I may have mentioned above:
- Better international text support.
- Better window support, which could hopefully lead to true dual monitor support. Think of a Blender widget control embedded in a window, and then create two of them. Or more. Non-overlapping GUI design is brilliant, don't get me wrong, but stretching one window across two monitors is a hack.
- A GUI designer whose files could be retargeted.
- HTML help could be added to Blender through QT's HTML rendering widgets.
- Proper OS-level clipboard support.

Downsides:
- A tonne of work retargeting Blender for the system. All GHOST calls would need replacing, and I'm betting most of the screen drawing code would need to be tossed away and rewritten from the ground up.
- Tool shortcuts would be a hard port, although I think that's a part of the new Tools API?
- It's yet another external dependency that needs to be installed.
- A lot of Blender's GUI code would need to be recreated in QT to maintain the look of Blender across systems. That's going to require a lot of extending of widget classes. A *lot* of work.

Did I miss anything? Do the benefits outweigh the downsides?

Niels_42
Posts: 0
Joined: Tue Aug 22, 2006 8:59 pm

Post by Niels_42 »

Kattkieru, thank you very much for your answer. I largely agree with you, and the points you bring up are basically what I've been trying to say all along. We should judge this on technical merits.
kattkieru wrote:The question really isn't one of visible advantages or disadvantages, but of weighing the two against each other. [edit: that was written before stiv posted.] Thus far no one's come up with solid reasons why the advantages outweigh the foreseen difficulties. So how about we be concrete: what problems do you think moving from GHOST to QT would solve, and what problems do you think such a move would introduce?

Here's some benefits off the top of my head for QT, which I may have mentioned above:
- Better international text support.
- Better window support, which could hopefully lead to true dual monitor support. Think of a Blender widget control embedded in a window, and then create two of them. Or more. Non-overlapping GUI design is brilliant, don't get me wrong, but stretching one window across two monitors is a hack.
- A GUI designer whose files could be retargeted.
- HTML help could be added to Blender through QT's HTML rendering widgets.
- Proper OS-level clipboard support.

Downsides:
- A tonne of work retargeting Blender for the system. All GHOST calls would need replacing, and I'm betting most of the screen drawing code would need to be tossed away and rewritten from the ground up.
- Tool shortcuts would be a hard port, although I think that's a part of the new Tools API?
- It's yet another external dependency that needs to be installed.
- A lot of Blender's GUI code would need to be recreated in QT to maintain the look of Blender across systems. That's going to require a lot of extending of widget classes. A *lot* of work.

Did I miss anything? Do the benefits outweigh the downsides?
Other pros:
- A better file selector with previews.
- Better desktop integration.

Other cons:
- Performance (possibly).
- Problems with C versus C++.

I don't know much about Blender development, and I can in no way judge whether the benefits outweigh the downsides. But I can hope that the real developers will at least consider options such as Qt from time to time, and consider them as you just did. Thanks.

Post Reply