In OSX, Dock when visible, reserves space that other windows can't use. How's that done?
In my use case,
I want to limit the space in which all application windows can open,
Whenever a new popup comes up it should be confined within the limited space and centred relative to the limited space
Something like Desktop Coral for windows.
You can write an apple script, which continuously monitors which application is started and resizes it to the desired size on launch. Small example to do so is given in following script:
https://gist.github.com/akshay-bhardwaj/daf93c2e1ed8b79a4619
Hope this helps. If you have further issues please feel free to ask
Regards
Related
In OS X Lion, when user toggle app full-screen, the window moves to the right to the new space and this new space has a default background.
In QuickTime X, when user toggle full screen, desktop background on the new space that gets created is black.
Is there a code to have a custom desktop image for the newly created space?
I know that it's possible to change the desktop background of every space in Lion through system preferences but I need not to change it, but to have it already set up when the space gets created for letting the app going full-screen.
Unfortunately, no. The default linen texture is shown when transitioning an application to a full screen (so that it has it's own space).
It's possible to set different desktop pictures for normal, non-application spaces using the methods available in NSWorkspace (i.e. – setDesktopImageURL:forScreen:options:error:), but they don't really let you control the space that the image is set on – it seems to just set whatever space you're currently on.
So sadly, the answer is no.
I am creating a toolbar on Windows that is being ported over to the Mac, is there such a concept as a workarea on the Mac, like there is on Windows.
If you are unfamiliar of what the workarea on Windows is, it is basically a defined space that all open windows can re-size in. Meaning normally you can re-size your windows to fill the whole screen, but if I change the workarea to a smaller size when you try to maximize your open windows they will stop at the boundaries of the new workarea. For example the Windows taskbar does this. If you move your windows taskbar up or down, then this affects how much space you have left for open windows to utilize, the taskbar is changing your workarea dimensions.
Windows uses the following function SystemParametersInfo with SPI_SETWORKAREA passed into to change the size of a workarea. Is there an equivalent to this on the Mac?
Thanks.
Yes, there is a mechanism in OS X to keep maximized windows from overlapping the Dock. Look at NSScreen's -visibleFrame method.
What does it mean by multiple monitor support for an application?
In the old days computers only ever had a single screen attached. Now they often have more than one attached and a desktop that spans those screens.
You need to make sure that your app:
Maximises to the monitor that it is most closely associated. A badly written app might always maximise a window to the primary monitor.
Remember which monitor it was displayed on when last run, and restore to that monitor when it starts up again.
Avoid displaying on a monitor that is no longer available. For example, consider a laptop with an attached screen. If you show the window at coordinates for a screen that has been disconnected (e.g. laptop user on the move) then they won't be able to see it.
It all depends on the application.
For some applications it just means that that you could open a very big window.
For others it might mean that you could open two windows, one for each monitor. For example, Lightroom, lets you view a collection of thumbnails on one window and a full-sized image on the other.
We have a Linux based system that does not use a Window manager. When we start certain applications (for instance Firefox) from a terminal window (e.g. Firefox &) we find that no matter what we do, we can't get the application to display full screen.
If we run xrandr, it shows the default resolution is 1280x1024, but when we try to maximize Firefox (by pressing F11) the application is only sized to 1203x650.
Another application that seems to have the same problem is the evince PDF reader.
Our application is not configured to run a window manager (and we don't want to add one), so I'm wondering if there is something else that we can do to get these applications to render full screen.
Thanks...
Although you don't want to use a window manager, you might need to use a window manager.
I haven't dug into the X server sources around this, so I can't definitively say X requires a window manager to run properly. But as somebody who writes X client code, and hacks the X server, on minimalist embedded devices with small screens, low CPU power and no GPU... let's just say, all the major players in that space use one, and have good reasons for it.
If you want to avoid chewing up a lot of disk space, RAM or CPU power doing window management, you should check out matchbox. It's a low-footprint window manager designed to meet those criteria, and it's what many folks in that minimalist embedded space are using. My employer uses it on cell phones, configured so that only one app at a time is visible to the user, and the foreground app takes up the whole screen with no window borders. But you can use it other ways, too - Nokia uses it for their Maemo-based network tablets.
You could use xwit(1) to forcibly resize and place the windows. But as as far as I know, X11 in itself does not have the concept of a "maximized" window; the very idea is only added by most window managers and/or applications (like Firefox).
Does passing the "-geometry=1280x1024+0+0" option to Firefox help?
Oh, also... if you don't explicitly set a window manager, you might be unexpectedly falling back to the default X11 window manager. If you're not absolutely positive there's no window manager, you should check into this possibility.
In a fairly graphics intsensive application the requirements state that it should default to full screen mode even though the application is running under Windows. I know many games do this but I find it annoying. The default IMO should be to open in a window rather than full screen mode. I am proposing the first time the user runs the application they should select the default behavior. Am I wrong?
I think the annoyance-factor depends a lot on what the application tries to do.
If it is some utility that I might start while working in 5 different applications and it forces its fullscreen-ness on my, then I'd get highly annoyed.
If it is a specialized application that helps me with the entire workflow of a given task (so that I never or rarely need any other apps open at the same time), then fullscreen might actually be a valid default.
Whatever you do, just make sure that toggling the startup behaviour is very discoverable. Because no matter which way you'll go, some of your users will disagree with your decision. And for them it should be very easy to change to their prefered way.
I would follow the requirement the first time the application is launched. I would also provide a simple way to switch from full screen to windowed, for instance by pressing ESC (and another way to go back to full screen). Then I would store the mode when quitting the application and restore this mode at next launch.
Before doing the opposite of what your requirements say, I'd have the requirements changed.
However, what about giving the user the choice at install time?
The window at first-start-up should default to the optimal size for the largest proportion of users. For a graphics-intensive full-featured app, that may very well be full screen.
As for individual user preferences for window size, it seems to me most users won’t know if they want full screen or not until after they’ve started to use the app and see how much screen space they need and how much they use the window in conjunction with other windows. Asking them which size they want at install or first-start-up could thus be annoying and even confusing. It’s better to put such a setting under Options/Preferences.
Perhaps the best thing to do is save the window status on exit. Users who like it non-maximized thus only have to non-maximize it (and size it) once and then forget about it. The only consideration is to have some way to reset the window to the default (e.g., Window > Standard Size menu item) for novice users who accidentally resize or reposition the window to something bizarre and don’t know how to get it back. Alternatively, you could have a Window > Keep Sizes and Positions menu item for users to explicitly save the window status across sessions.
Go back to the requirements writers and ask them if they have considered non-traditional monitor setups, such as:
30" or larger monitor. Do you really want your app hogging up all the screen real-estate?
Multiple monitors. Which monitor will you run on? Can the user move your app from one monitor to another? Can your app span more than one monitor?
Virtual desktops. Can the user move your app from one desktop to another? Can they switch desktops while your app is running? Can your app span more than one desktop?
Such setups are increasingly common, especially large monitors. IMO, full-screen mode (the default for many older Windows apps) is becoming less and less useful.
The problem with presenting the user with the option of initially selecting fullscreen / vs windows is that they haven't used the software yet. How can they make a decision on which is better for them, without experience?
I would run the app in whichever mode provided the best user experience and then offer an option to change it both in the Preferences and though a hint while starting up the application for the 2nd time.