Hello everyone,
I am happy to announce that we have pushed to develop many Linux improvements to JUCE. Here is a brief description about the changes:
If you want to know more, please check the commit.
We invite you all to try out and test it. If you find any bugs, please don’t hesitate to report.
Enjoy!
Sorry for repeating this =)
But may be you have some plans for wayland support and for multy-touch support?
That would be cool! =)
TI sitara linux supports only wayland =(
We definitely want to support wayland. It is in our road-map, but I can’t promise any dates.
I know that any estimates are pain, but probably you can tell is it possible to get multi-touch and wayland support in near future?
TI does not support X11 in their Sitara Linux SDK =(
Sorry, but we don’t have any immediate plans to support wayland.
How about multi-touch support for X11?
JUCE framework seems prepared since we have it on other platforms, so hopefully not a complicated task?
Wayland support would be great…
Multi touch support on X11 requires support for XInput2. Or JUCE could go more generic and support libinput, but then it won’t work with other X11 apps. So I guess for embedded this shouldn’t be a problem. It’s definitely a fun hacking project… 
May I also ask if there are plans to implement it in the near future?
It’s something we are aware of but we have not scheduled any work on this.
May we expect the wayland / multi-touch support or there is no any hope for that?
Hey guys,
Thanks for the update.
What about the compatibility with the VST3 SDK ?
Baptiste
Hello!
Are there any plans for wayland/multi-touch support?
We’ll need to move towards supporting Wayland eventually but it’s not on our immediate roadmap.
That is very sad =\ waiting for more than 2 years for these features…
Soooo, sorry to repeat it again, but can we please have wayland support?
Just my two-cents here:
I think Wayland support would be totally cool and would pave way for support on some rather interesting embedded devices (eg: STMicro, Broadcom). I would know first hand as I did various proofs of concepts of porting JUCE to some special hardware at an old workplace, although adoption fell through for various reasons.
With the way JUCE is written it makes it easier to implement Wayland, and there aren’t too many massive challenges in hooking the display, input servers… I just think the overall cost to benefit ratio is low, and this is not just from a support overhead view.
For one, there is difficulty in playing nicely with the future ideas the team has; iirc, there was expressed interest on the forum in dropping GL for Vulkan+Metal, which means Wayland will never be supported (because it only supports EGL, and JUCE’s GL support is already minimal imho).
Maybe more importantly, the more popular plugin formats that JUCE supports (eg: VST3) would have to be totally rejigged/rewritten to play nicely with Wayland (which is probably optimistic). As of now, on the juce6 branch, X11 is their basis on Linux.
Part of the recent Linux changes on the juce6 branch was decoupling the X11-specific code from the ComponentPeer code. There’s now a single LinuxComponentPeer class in juce_linux_Windowing.cpp which takes a templated WindowHandleType and all of the X11 code lives in native/x11. Theoretically it should be fairly straightforward in the future to add support for another windowing system like Wayland, but it’s not something that will happen in the short-term.
the more popular plugin formats that JUCE supports (eg: VST3) would have to be totally rejigged/rewritten to play nicely with Wayland
The VST3 SDK only supports XEmbed for embedding plug-in windows so I’m not sure we’d ever be able to move away from X11 there.
Cool, thanks for clarifying!
So, taking in account the same answer repeating from 2017 year, this means it will never happen?
Sorry to sound rough - but it always better to know the truth than wait for something that will never happen, especially for a commercial framework.
