If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Comment

For those of you that were with us for the transition of Qt 3 to Qt 4, we do not plan to repeat that difficult transition with Qt 5. To be explicit here ? we believe we can keep source compatibility for the majority of cases, but we believe that breaking binary compatibility is needed.

That's very good.

Qt will require OpenGL (ES) 2.0 to work.

That's interesting. KDE has long marketed their solution as superior because it could automatically fall back to a non-composited environment and work fine, unlike Gnome3. Also, Ubuntu was just talking about how their Qt based Unity2D desktop was going to assume no hardware acceleration at all times. I can see how this might piss some people off, although i trust it was done for a good reason (better acceleration for most people).

We should expect that over time all UIs will be written in QML. JavaScript will become a first class citizen within the Qt community and we should expect that a lot of application logic and even entire applications will be written in JavaScript instead of C++. The expectation is that many application developers will actually start out with QML and JavaScript and only implement functionality in C++ when required.

And this is really interesting. It sounds like they are really moving away from the C++ model of development with Qt5, and on to the new WPF - oops, i mean Qt Quick - development.

It physically has modules for various peripheral functionality, but the toolkit itself is still pretty monolithic. Some people might have a problem with a "Hello world" app pulling in a .so that weighs about 11MB (on x86-64 anyway; probably a little bit smaller on architectures like x86 or ARM that would actually be used in a more memory-constrained application).