.. and one of the reasons they keep failing (imho) is that they continue to try to maintain a ‘backwards compatability’ with the window/sub-window parent/child relationship in the touch interface, and nobody wants to have to switch paradigms when they’re trying to get things done.
I believe iOS designers learned from that negative experience.
There haven’t been many changes to the big ticket items, but we have finished off better Windows windowing, and we have started work on the JUCE marketplace. We’re also working hard on improving the Direct2D renderer.
However, there have also been some additional useful things added to JUCE 8:
Windows Arm support for applications and plug-ins
Local notifications (particularly useful for accessibility)
Somewhere where we can showcase all the third-party JUCE modules, tools and JUCE-based projects. It’ll be along the same lines as the Visual Studio Marketplace.
We removed it from the roadmap as it was finished.
From the previous roadmap update:
Support for Windows 11 snap layouts is coming. Snap layouts are accessed by hovering the mouse over a window’s maximize button to bring up a set of options for positioning that window in relation to others.
When you have a chance, can we have more details about this? This sounds like an important change.
Also, is there “an official/supported method” to disable Direct2D and revert to JUCE7 rendering if it causes issues(see relevant thread)? I don’t see it in the roadmap and I’m not migrating to JUCE8 because I can’t risk those problems in production. I wonder if I am alone with this.
I haven’t tested this, but I wonder whether you’re using a recent JUCE 8 release, or something older. We made some significant changes to window handling on Windows, including adding support for the “Snap Window” feature, shortly after the initial release of JUCE 8. If you haven’t already, please check the current develop branch.
You could also mention the many improvements to the Android platform added to JUCE 8 post-launch: support for floating windows and split-view, correct reporting of safe-area insets, ability to change the app style, support for virtual MIDI devices (within the MIDI 2.0 preview branch). These are all extremely useful additions!
In successive JUCE releases we have improved the GUI rendering performance on both macOS/iOS and Windows, and we’re now turning our attention to embedded platforms and Linux. JUCE is used in flagship hardware products and the ability to render increasingly complex UIs more efficiently is becoming more important.
It seems to something new in JUCE 9 roadmap Would you like to share some details on this? Does JUCE plan to switch to hardware rendering on Linux desktop (such as Vulkan)? Or it is something else?
Part of the work will be investigating the possibilities. Given the constraints of popular embedded devices running Linux, it seems very unlikely Vulkan is always going to be available, add on top of that the amount of effort required for a Vulkan renderer (just look at the effort required for the recent Direct2D renderer) it seems unlikely this is where we will focus our attention. However, maybe there is merit in improving our OpenGL renderer, adding support for something like OpenGL ES, or just improving the performance of the software renderer for these platforms. It would be hard to say anything definitive without first doing some more investigative work.
Any estimated timeline for MIDI 2.0 making it to the main/stable JUCE branch? Just hope it’s not something dependant on Window’s implementation because Microsoft has been dragging their feet for 2 years already.