Looks interesting, I come from a Qt background so cross-platform toolkits always have a bit of interest for me. It does seem like it's definitely for people building highly customised interfaces, rather than looking for OS-based look and feel but there's some nice bits. I think I'll give it a whirl when I've got time for a side project.
We use Qt at work for one of the big projects, and we are very happy. That to be said, juce is small, embeddable (your executable can be around ~600kb on windows), and while you can statically link to Qt it's still bigger, and some things don't work right (plugins).
Fair point, both you and malkia. I'm C99/C11 guy though, but always resort to Qt for frontends. I wish we had more (any) C only solutions out there. Yeah, I know..Glib...sigh.
We "were" in the same boat: our company decided to build UIs using C# and leaving the hardcore modules to C/C++, interfacing them via COM. Developing UI interfaces in C++ under Windows is a pain in the ass.
An example of this is our SpyStudio product[1], which was developed in C# using our Deviare technology[2] for instrumenting binary applications.
We had a legacy application using MFC/C++ and no one anymore likes MFC at the studio, so we had to either somehow switch to C#/Windows.Forms|WPF overnight or slowly move to something else. Since there is MfcMigration toolkit for Qt - slow progress was the choice - so every week less and less of MFC is visible, and more and more from Qt.
Other toolkits can benefit if there is a transition layer - or at least something where you can plug into the existing message pipeline, windowing system - and then start replacing widget by widget, dialog by dialog.
Looking at it quickly, you should use JUCE over Qt if you're building a custom UI from scratch and you want a lot of multimedia help, you should use Qt if you're building a more traditional desktop application.
reply