Hacks that seem to fix issues on linux

Hello,
I have had a few issues with my linux builds in development, and I found several hacks that fix said issues with no apparent side effects. I wanted to create this thread to possibly understand why they are not fixed by default and what would take to get them in. I tried to check the development branch to make sure that they didn’t have updates, and couldn’t find anything.

  1. The first issue has to do with the alt key not working. I found the following patch that solved the issue for me. I don’t know if it is a generic fix, but it definitely works for me on GNOME.

    https://forum.juce.com/t/alt-key-not-working-on-linux/15830/4

  2. The second issue pertained to lack of transparency on drag and drop. I understand that it used to be done via XRender, and saw a thread where Jules talked about not using XRender, and still being able to do transparency. The following code is the culprit of opaqueness in my drag and drop business:

bool Desktop::canUseSemiTransparentWindows() noexcept
{
   #if JUCE_USE_XRENDER
    if (XRender::hasCompositingWindowManager())
    {
        int matchedDepth = 0, desiredDepth = 32;

        return Visuals::findVisualFormat (display, desiredDepth, matchedDepth) != 0
                 && matchedDepth == desiredDepth;
    }
   #endif

    return false;
}

By returning true here, I can fix my woes. I can totally see where this could break…If you don’t have compositing capabilities. But if it works on my intel graphics card and GNOME (A pretty typical setup), perhaps it would be nice to allow users to get the benefits of transparency without having to hack this. I tried enabvling JUCE_USE_XRENDER, but JUCE didn’t compile for me despite having the correct library. If using XRender is considered the correct fix, I can look into it more, but it definitely felt like a weird dependency. I don’t mind doing investigation if needed. But even a macro would be enough for me. For my purposes, I would not be horribly bothered by requiring compositing in the worst case. I would love to see a more robust solution here.

I know these are not perfect solutions, but these are issues that would be nice to have fixed. It’s hard to (and I don’t) recommend JUCE if some of these issues (I’ve found others I’m not including here) simply don’t work on Linux. Please don’t take that as negative, the fact that I’m posting these issues are a testament to the fact that I would love to see wider adoption IFF Linux becomes a first class citizen. Great work regardless.

2 Likes

I’ve just pushed a fix for 1 that will appear on the develop branch as soon as it clears our CI system.

We care about supporting Linux, but things like this can slip under our radar as only a relatively small percentage of our users are building GUI apps on there. Please keep letting us know where things are not working as expected!

Thank you for this post. I’m using Juce 6.0.5 and my transparency on dragged images is also not working in Linux (Using Fedora 33, tried both Wayland and X11, both use Gnome).

The problem is indeed in Desktop::canUseSemiTransparentWindows(). This function is returning false when the system does in fact support it. Modifying it to return true always allows transparency to work correctly on my system.