centreWithSize(width, height, monitor = -1)

General JUCE discussion
1

Hi,

What about adding this parameter to centreWithSize so it center on the specific monitor if specified (else does the current code) ?
It’s a one liner but it saves typing:

        RectangleList rects = Desktop::getInstance().getAllMonitorDisplayAreas();
         setBounds((rects.getRectangle(monitor).getX() - width) / 2, (rects.getRectangle(monitor).getY() - height) / 2, width, height);
2

Well, centreWithSize is used for child windows too, in which case a monitor number would be meaningless. I don’t really like having parameters that may be ignored depending on the context.

The TopLevelWindow class provides “centreAroundComponent” which is what I normally use when I need to put a window on a particular screen. Is that the sort of thing that you’re looking for?

3

No it’s not exactly the same thing.
I want to move a window to a particular monitor, and center it on this monitor at the same time. It’s a 2 liner work, but since centerWithSize seems to be what I would look for (from the name), I thought about adding the monitor index in the function.
I know centreWithSize use the parent component to find out the sizes to center with, but the additional parameter would bypass the parentComponent and use the monitor.rect instead when non default.
It seems intuitive to use this way:
centreWithSize(1280, 1024); // Usual centering with the parent component
centreWithSize(1280, 1024, 0); // Center on the first screen (which is usually want you want on the TLW like you said)
centreWithSize(1280, 1024, 1); // Center on the second screen and so on…

4

How do you choose this monitor number? The only common task I can imagine where you need to specify a monitor is if you want to put a component on the same screen as another one, and in that case passing a target component is much better than a monitor number.

5

I don’t know on Mac, but on linux the number is what is specified in the xorg.conf (screen section).
Xinerama returns the monitor area respecting the indexes set in its configuration file.

I think windows does this too, when you go to display property, the monitor number is displayed (1 or 2 on the screen icon).

No, I wasn’t clear. This is for the first top level windows. I want to start a TLW on one screen and another component on the other screen. I can’t refer to any other component by that time.

6

Ok, but that’s a very unusual requirement. I’d only consider adding very commonly-needed functionality into the component class, and this really doesn’t sound like a candidate.

7

To be honest, I think default Juce behaviour of centreWithSize is broken.
If you have 2 monitors, and use a centreWithSize in your main DesktopWindow component, it pops up between both screen (this is the only software doing this, and this is disturbing).

Being able to specify a monitor with this method would be very useful feature, but if you don’t think it’s needed, it’s not a problem, the 2 lines on the top of this thread provide a workaround.
In all cases, please at least fix this “in the middle of the total monitor area” bug (or write something explicit in the documentation, stating not to use centreWithSize in the DesktopWindow).
Also, if your main window have a OpenGL component, placing it in the middle of 2 monitors only allow rendering to a single monitor.

8

True, centreWithSize isn’t designed to understand multi-screen setups, it’s mainly for normal, child comps. That’s why I provided the centreAroundComponent call in TopLevelWindow, which is desktop-aware.

9

Ok, then I don’t understand how to use the centreAroundComponent to position the first window on the first monitor.
To what I read both method act exactly the same if you use “0” as the first parameter (that is popping in the middle of both monitor).

10

Sorry, I was talking crap - centreWithSize does take account of multi-monitors, and does centre the component on the main monitor. It works perfectly well on mac/windows, as I use it all the time. It should do so in linux too, unless you’ve got some weird setup that’s actually treating the whole desktop as one large area?

11

Well, I’ve only tried on linux/Xinerama to be honest.
If I get the list of rectangles for the monitor and center on the first rect, it’s working.
My code is :

        Desktop::getInstance().refreshMonitorSizes();
        RectangleList rects = Desktop::getInstance().getAllMonitorDisplayAreas();
        if (rects.getNumRectangles() > 1)
            // Full screen on the first monitor
            setBounds(rects.getRectangle(0));
        else
            // Don't go fullscreen 
            centreWithSize(1024,768);

I think there is something weird going on here then. I wonder if it’s linked to the Xinerame soname fix from the linux forum, as without the fix getAllMonitorDisplayAreas() returned only one rect of the total virtual size, and with the fix, it’s returning both rect with their respective native size.
Since I’ve done both tests at the same time, maybe I should try centreWithSize again.

In all case, the remark about specifying the monitor to centre onto still hold.

12

Ok, let me know if you find out any clues.

But I’m not going to add the monitor number thing. Specifying a monitor by its index is such an unusual thing to do that I’d rather people write custom code if they really need to do that. It certainly isn’t a useful-enough task to justify inclusion in the Component class.