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.
Related
I would like to know if there is some way to pass the window handle of the window that was active before my application was started (either through a click on the taskbar icon) or a double click on my application's icon on the desktop.
I guess this is not possible, but I wanted to ask anyway.
Thank you for the help!
Strictly, the window that was active immediately before yours was the shell. Your application was started by the shell, and what you are really asking is what was the application that was active before the shell. Now that's an ask!
It's easy to enumerate the top level windows, which is basically what the shell does to give you the task list. That gives you a list of candidates. Not so easy to know which one, although the order in which they are returned could be a clue.
It's also relatively easy to get the Z-order for the running applications. It's highly likely that the application that was running before yours is the one with the highest Z-order, excluding your app and the shell.
My guess is that would be close enough for most purposes. After that I'm out of ideas.
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.
I need to know if the user has hidden an icon added by my program to the system tray area.
Is it technically feasible?
UPDATE
My program - yowindow displays the current temperature in the system-tray icon.
I want to spare the server load by not auto-updating the weather for the users who don't see the tray-icon.
No.
And what would you do with this information, even if you had it?
(caveat - I guess you could do a screen-grab, work out where the taskbar is, figure out where the system tray is, "parse" out each icon, then bitmap compare each against your own icon. But really...)
It might be worth your while looking at this related question
Based on first Edit to question
I can see your point. But look at it from the windows API designer's POV. They provided a facility for icons to be created in an "always visible" manner. And every man+dog went ahead and put an icon in there, on the presumption that the user would always want to know about their product (please note, I'm not claiming that you're in this group here).
They've noticed this runaway behavior, and whilst they can't now take away the ability to create these icons, they want to give the user control.
Now we come to the problem. Imagine, for a second, that you're a less than enlightened developer. And if you detect that your icon has been hidden, you pop up a message prompting the user to un-hide your icon. Maybe you do this once per login. Maybe you do it every half an hour. It's just a general level of user annoyance, similar to having 40 icons appear in the tray, when the user doesn't care about most of them
The question is - if you were designing an API to allow developers to discover whether their icon is, in fact, hidden. How do you allow your benign usage, whilst preventing the behavior in the previous paragraph? Spend a few minutes trying to pretend to be a windows API designer, and try to write the necessary function(s) (for the sake of argument, assume the annoying developers aren't willing to implement the IAmEvil interface, or whatever, or would be willing to implement the IOnlyDoGood interface...)
Hopefully, your icon is useful, and users will either a) show your icon, or b) remove your application (if it's not doing what they want/need)
There is no API function for that as far as I know, and there's no good solution to the problem. You could directly after the installation show a message from the tray telling the user that the icon may be hidden. Not that it will help, but it's all you can do. I've seen programs that bug the user by periodically showing that message but this is really NOT a good thing to do.
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.
new Windows 7 hides systray icons by default.
what is the recommended way to show information to users now?
I need to have a small clickable icon visible to user so user can access my "tool" anytime. Should I use the gadget to show my GUI instead? Can it communicate with my Delphi app somehow?
Without more information it's a little difficult to provide a recommendation.
However, I would imagine that a sufficiently important tool, the user would simply keep minimized. They could then use Jumplists to access quick functionality.
For example, Live Messenger uses this setup on Win7.
If your users really like your icon/application they can always choose to not hide your application.
The only difference is that only the user can choose which icon is shown, instead of every application claiming it's "real estate".
In my opinion this is a good functionality and if I were you I wouldn't change the application, just provide a first run GUI which explains how to make your tray icon visible in windows 7.
The entire reason why change was made, was to stop programs like yours. If you need to show information, go ahead and do so. But the notification areas ("systray") is not where shortcuts go. For that, you've got the start menu, desktop and/or the quick launch bar (and please let the user decide).