Overhaul of UI

Since a lot of users seem to be comfortable with breaking changes if they bring progress, are there any plans to eventually overhaul the UI?

For example, tree views and list views and their models could need a redesign. They seem overly complex and don’t benefit much from inheritance. I thought items could probably be implemented as child components, which would eliminate much of the awkward hit testing and other redundant code. Nesting components doesn’t seem costly at all. They could be used more often to structure UI elements at lower levels, instead of re-coding geometry over and over again.

Actually I like most of the current components very much. IMHO however, every component should require a Positioner, of which there can be a variety of subtypes ranging from Rectangle (default) to LayoutFrame and FlexBox. This will ensure upwards compatibility with responsive layouts. In addition to Positioners, components could also use a unified API that layout & styling frameworks can attach to.

As we are at it, it would be great if all emerging layout & styling solutions (also by ROLI) could be provided as modules. Doing a UI framework is absolutely non-trivial, takes time and is prone to errors and dead ends that require a redo. Modules will allow for multiple solutions to evolve and coexist. They will also enable evolution of the UI w/o breaking existing code.

Sorry for bumping this, but it is of great importance to me to know if any higher level UI frameworks that might eventually emerge from ROLI will be provided as extension modules (rather than being baked into the library). Is it safe to assume that?

I started working on such a framework, which is a major investment, and need to be sure it will be able to coexist with similar solutions in the future. It would be a shame to be forced to abandon the project, if that risk couldn’t be ruled out.

I would be surprised, if they give a public statement with that amount of commitment. Did you try to contact Jules or Tom directly?
Like I said, I wouldn’t put too much hope into that.
Try to be as loosely coupled as possible, maybe even prefer std over juce library where possible.

If your module works as drop-in replacement for the existing Components and widget, it’s not in vain at all.

Actually it’s not a far reaching commitment that would limit future options. Quite to the contrary. Since juce_graphics, juce_gui_basics and juce_gui_extra are already modules, adding yet another module, e.g. juce_gui_layout, would be the most natural thing to do in order to stay flexible and backwards compatible.

My module’s components derive from the various subclasses of juce::Component by adding a new interface (and translating between the two). Therefore keeping up with changes to the Component API will be easy.

I just see how it might possibly be tempting for ROLI to modify Juce components in a way that they will no longer work as standalone units. It that case it will be very hard to work around the dependency on a hard-wired built-in framework.

We do very much want to revamp our UI offering!

The tricky bit, and the reason why we’ve not got something underway is that there are just too many options - and all of them are radically different.

For example, we could:

  • create a new, more modern set of C++ classes to replace the existing Component classes
  • just overhaul and modernise the existing stuff to make it faster, have more effects, etc, but keep it fairly backwards-compatible
  • create a script-based layer on top of our existing UI classes - and there are many very different options for this - e.g. javascript, lua, some other language. Then should it use an existing framework like react, or CSS, or something proprietary etc
  • provide an easy integration with e.g. chromium and let existing web tech handle the GUI frameworks
  • build a declarative system based on e.g. ValueTrees, which is an approach some people have done themselves

…etc… etc…

Yes, we’d like to do something, but very hard to make the right choice here!

7 Likes

Please no additional layers, C++ is my preferred layer :wink:

PS: and no API changes

+1 for preferring the first two options.

I wouldn’t mind soft API changes though.
Or keeping the existing Widgets/Components as a parallel world for time being, making way for a fresh start with modern C++, smart pointers and lambdas, and float based positioning
(which is probably the biggest but welcome breaking change for modern displays and the new dpi scaling)

4 Likes

…right, and the fact that probably everyone will have their own, strongly-held, contradictory opinion to this makes the job of deciding what to do even harder!

4 Likes

Thanks for replying, jules. Much appreciated. I’ve experienced this paralysis of too many options and conflicting user demands quite a few times. I think all the approaches you mention are interesting, except two, which I would consider problematic:

“let existing web tech handle the GUI frameworks”

Desktop audio apps and plug-ins are vastly different from web apps. Responsive layout is great and desirable, but the client-side scripting and all the other extra hoops of web UIs don’t quite fit this engineering domain. Developers would be required to code their UI in Javascript, CSS and everything. IMHO this would be too restrictive, distracting and too slow for real-time.

But most importantly, if someone wanted a third party framework, they would probably integrate it on their own. That said, if there was a module for this, I would certainly play around with it and maybe use it for business apps, but not audio.

“script-based layer on top of our existing UI classes”

I think anything “on top” is basically fine, as long as it remains an option (module). I however doubt scripting is necessary. One of the strengths of Juce is its native snappiness. From my current approach I just learned that ‘scripting’ and editing a UI in a declarative fashion is absolutely doable with native C++. What it boils down to is to separate application code from layouts by making them (visually) editable data structures.

As for the direction to take, I strongly advocate focussing on the streamlining of a basic set of components as a start. These will be needed in any case, as users will want to keep using them for fast & minimal UIs and as building blocks for their own custom components. This set of components will be a great foundation for whatever more sophisticated solution can be built “on top”.

The whole point I am trying to make is that whatever solutions might emerge, they should remain an option (modules), so to allow for multiple emerging ideas to evolve in parallel and coexist (and not to eventually annihilate investments built on top of components, of course).

Could you agree with that?

Yes, if we choose to do something radical then it’ll certainly be an optional parallel module, we wouldn’t force a completely different approach on everyone, that’d obviously be a bad idea.

For every person like you who says “no way” to something like the web-tech approach, there’s another set of users for whom that’d be a perfect fit for their needs. So really, the hard bit here is choosing an approach that’s both practical for us to do, and which annoys the fewest number of people. I’m sure that there’s no choice we could make that’d possibly please everyone.

Yes, if we choose to do something radical then it’ll certainly be an optional parallel module

Thanks. That’s good news. It certainly encourages users to contribute to the evolution of the UI. I would think ROLI will eventually come up with more than one solution anyway. There is no such thing as a one-size-fits-all. Web stuff like Electron is beautiful (e.g. Atom, VS Code), but not for every use case. If anything like this emerged, there needed to be room for native alterantives as well.

As said, streamlining a set of basic components (with a sensible interface that UI frameworks can plug into) should be a safe bet to start with. You’ll need these in any case, except for 100% third party frameworks.

I think you should consider supporting UIs built in ReasonML. It’s a great language, and because of the OCaml backend it can be efficiently compiled to both native and javascript.

I really like the Revery project: https://github.com/revery-ui/revery

I’m currently looking into how I can link the Reason/OCaml frontend to a JUCE backend. That may be the best way to go about this — the traditional JUCE UI works as normal, with this layer on top.

It encourages good design practices — complete “separation of church and state” when it comes to UI code and the underlying logic. It also provides a layer of familiarity to web developers, while also being purely native.

My ideal framework is basically a mix of JUCE and Revery, but I’m still trying to figure out how exactly to get that to work, especially with audio plugins. Lots of FFIs and “extern C”.

1 Like