Best practices for *complex* gui apps?


#1

First, to give some context: I used Traktion back when it first came out and have been interested in JUCE ever since.  :)

 

I'm now contemplating using JUCE to port a fairly complex scientific application I've written in C++ using a homegrown opengl-based gui system (  http://www.kintek-corp.com/kinetic_explorer/ - see screenshot on this page ).  Our system can read complex hierarchical UI definitions from xml-like files, or create stuff dynamically in code.  Importantly, it has a layout engine to help when you have a bunch of checkboxes or labels or sliders that should be lined up in a table format, or packed into container, etc.

I've done the tutorials and am looking for a guide or overview about building complex gui apps with JUCE.  I don't find any discussion like this in the docs - in fact, I've only found an alphabetical listing of classes, which means GUI stuff is randomly sprinkled about - no technical overview of the GUI system that I can find.

 

I'm interested to learn about best practices for layout of serious GUI apps. E.g. apps with hundreds of controls, large sections of which that may get created dynamically based on content, etc.  Hand-coding coordinates/bounds in c++ is fine for apps with a couple sliders, but it feels unwieldly for doing large apps.

 

Where can I find information like this?  For example, "Here's how Traktion is put together."  :)

Thanks in advance for any tips!

 

Thomas Blom in Austin, TX

 


#2

Sounds like a great app, hope it goes well!

We don't really have any articles along those lines, though I doubt whether the advice for juce would differ from that for any other kind of GUI in other languages.

IMHO the main thing to focus on is to avoid your GUI and your data model getting too closely entangled (I made that mistake early on in Tracktion and we spent a lot of time last year refactoring it).

Another common beginner mistake is that when you have GUI elements like the graphs in your screenshot, they write them as a single big component, with logic inside their mouseDown/mouseDrag to manually figure out whether the user is dragging control points etc., and repaint bits of the component when things change. Much better to build the GUI out of nested components that each have a specific role.

I'm sure there are thousands of bits of good advice about this - hopefully other veterans will also give some good tips!


#3

Thanks for the reply Jules.

I've been coding interactive stuff for 30 years, so I do get your points.

However, there are important differences in GUI systems and their applicability to different scales/complexity of project, and this is what I'm trying to grok in a small amount of time, if possible.  :)

Namely, does the system have a layout engine.  If so, how is it used?  Can it read text files that a human can edit, or do you have to use the Introjucer to do layout graphically?  Most graphical-layout-frontends for static UI layout (e.g. xcode etc) are very tedius for anything beyond fairly simple UI, esp for coders who are fast typists but not designers, and a programmer-type will be better off resorting to editing a text file.   Would you layout the Photoshop interface with Introjucer?  You obviously did Traktion with it.  What was really tedious, what worked really well, how do you organize such a large scale project with tons of UI and have it be maintainable over time, especially with new devs coming and going on the project?  This is the kind of information I'm hoping to glean from people who have done it -- this kind of experience is built over time using a system, so I can't get it going through the tutorials, and I can't find an overview doc that speaks to these kind of large-scale questions (which makes me think people are not building big apps with JUCE, in general).  If you've just refactored Traktion, I'm sure you have thoughts about this!

I want to move us to a GUI system that more than just I am using, so that I can hand this project off to a less-experienced dev.  I'd rather not saddle them with something as huge as Qt, but I need to make sure whatever I choose is up to the task and has the resources avail (e.g. docs, community, examples) for large-scale projects.  I really really want to find this for JUCE, because I love the project and am a musician as well, but so far I get the impression it is not, generally, used for major standalone apps, or if so, the people doing it are not sharing their experience.

If you can speak to any of this I'd love to hear about it!  

Thomas


#4

 Would you layout the Photoshop interface with Introjucer?  You obviously did Traktion with it. 

No, Tracktion's entirely hand-coded. There's nothing in it that's simple enough to have been done in the introjucer's GUI editor. I've found that actually most GUIs I've worked on have been far too dynamic to be done in a tool like that.

Re: text-based layout formats, no, juce doesn't currently have one. We've discussed doing something analogous to QML and may decide to do that, but at the moment it's unclear. I've heard lots of user storeys about people rolling their own domain-specific layout formats though, using ValueTrees/XML or juce's javascript parser.


#5

Thanks, exactly the kind of feedback I'm looking for.

Agreed, complex dynamic UI always ends up in code, perhaps grabbing a container object that is layed out via a GUI tool or text-file and then populating that container in code.  Though if you don't have a layout engine, that population gets really tedious, having to compute coordinates for each element "by hand".  

But at least knowing how you did Traktion gives me a marker to navigate by.  Thanks!

If anyone else is reading this thread & doing big app complex UI, love to hear your thoughts.  Maybe I should just start the port & come to London in November and talk about it.  :)

Thomas