Something between AlwaysOnTop and normal windows

Bumping this in the hopes it might be added to Juce at some point...

Ok, so there are some more things to think about when adding this.

The Desktop::findComponentAt (Point<int> screenPosition) const call, gets messed up when creating these panels.

It has to do with the desktopComponents array beeing sorted in  z order.

Some how we would need to add the same conditions as with always on top windows. else drag and drop gets strange.

 

 


void Desktop::componentBroughtToFront (Component* const c)
{
    const int index = desktopComponents.indexOf (c);
    jassert (index >= 0);
    if (index >= 0)
    {
        int newIndex = -1;
        if (! c->isAlwaysOnTop()) <-- this should also count for floating tool panels (or what ever we call them)
        {
            newIndex = desktopComponents.size();
            while (newIndex > 0 && desktopComponents.getUnchecked (newIndex - 1)->isAlwaysOnTop())
                --newIndex;
            --newIndex;
        }
        desktopComponents.move (index, newIndex);
    }
}

+1 for this feature request, I really think it should be supported at some point

Quick-fix solution to the problem in the previous post was to set the isAlwaysOnTop flag of Component to true. but NOT by calling setAlwaysOnTop(), as that changes the window style. we just want Juce to handle it like the normal always on top windows internally.

Is there any progress regarding this feature? Actually, it should be quite simple. On Windows, all we need is a window style for floating windows. On Windows, this should create a native window with the style WS_POPUP and the application’s window handle as parent. Currently, JUCE automatically chooses WS_CHILD if a parent HWND is specified as Nikolai pointed out. I guess it should be equally easy in OS X. Something like a FloatingWindow class or similar which adds a title and close button would be a great addition. Clicking the title and moving the mouse while keeping the mouse button pressed should obviously allow the user to move the window as well.

Don’t know on the progress, but I have created a work/hack-around to get by.
It was all done in the Win32_Windowing (or similar name).
As Stian says, the flags etc to make the window is not a big deal to implement, but you also have to consider some other Juce “assumptions” regarding parent child relationships (see my post about coordinates).
@Stian jøss, første gang jeg har sett en annen Juce-utvikler fra nabolaget her.

Thanks, Nikolai! I’m usually not keen about maintaining our own JUCE branch, but we’ve done that a couple of times before. I suppose I might have to do so in this case as well… It seems quite essential, though, so we might hope for “an official” solution.
@Nikolai: Artig – hvor i landet er du? Jeg er i Oslo. Du kan sjekke https://acondigital.com/ hvis du er interessert. :slight_smile:

Yes this is a basic and commonly used feature of windowing systems, and almost impossible to emulate by other means. This is why UI toolkits usually have a way to specify the parent window of a dialog box. Eg. this is the signature in Qt:

QDialog(QWidget *parent = Q_NULLPTR, Qt::WindowFlags f = Qt::WindowFlags())

To fix finding the window at some given position you could go to the source — the Windows API:

POINT pos;
// in this example we use the cursor position
GetPhysicalCursorPos(&pos);
HWND hWnd = WindowFromPhysicalPoint(pos);
// WindowFromPhysicalPoint can return heavyweight components, this
// gets the top-level window if desired:
hWnd = GetAncestor(hWnd, GA_ROOT);
// I'm guessing at this point HWNDComponentPeer::getOwnerOfWindow(hWnd) will get
// you the JUCE window we're looking for

Note also that the current approach of Desktop::findComponentAt has the obvious flaw that it doesn’t take into account windows from other applications. As a consequence when dragging between windows, you can drop on a window which is hidden behind a window from another application.

Yep, we hear you. It’s a good request, we’ll certainly add it to our backlog.

Has this feature request made it off the backlog in JUCE 5?

Nope, I’m running with a modded/hacked solution that works. Although not elegant

+1. I’m going to have to hack this for the moment. We should be able to create ‘owned popup’ windows (to use MS Windows parlance), so they always stay on top of their parent window. It’s especially awkward when you don’t want them to appear on the Windows task bar (ie. like any normal desktop app with a main window and floating tool windows) - there’s no way to get to them when they go behind the main window. Hoping for a fix (well, implemented FR at least) ASAP please!

1 Like

I’m hoping for this as well… :wink:

2 Likes

+1 just running into this

1 Like

+2 I could really use this as well.

1 Like

Hi, anyone got this working?

I solved this years ago in QT in the following way:

  • add a list that specifies the z-order of child windows to your top level window
  • on each mouseUp event, I restored the z-order by calling toFront (false); in that order (a globalMouseListener would work here)
  • you can add at mouseDown the chance, if you have windows of the same importance to bring the clicked to the front of that part of the list

I remember that worked quite well, I think this approach could be used in a JUCE project as well…

That wouldn’t really have been necessary in Qt, though, because it already has the Qt::Tool window flag…

1 Like

…did it have that 2005? :wink:

Also you can do that with an arbitrary number of windows. The tool is one flag, my approach made it possible to have a base window, a couple of floating ones of the same importance and so on…

+3 – really need it here as well. Our host is just a regular application; on MacOS our modal plugin window gets the “topmost” style so it stays on top of everything else on the desktop, and on Windows it’s all to easy for the dialog to get behind the (now disabled) host app (e.g. after an alt-tab), leaving our users scratching their heads…