New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Window fails to appear if size is greater than desktop resolution #215

Closed
malpert opened this Issue Apr 29, 2012 · 14 comments

Comments

Projects
None yet
6 participants
@malpert

malpert commented Apr 29, 2012

If the set size of an SFML window is larger than the desktop resolution, the window does not appear at all, however the program does run and is shown in the taskbar. This is baffling to a programmer that's unaware of this issue.

The most reasonable thing to do is to shrink the window to the desktop resolution so that it will at least appear. Yes, the programmer may be upset that the window is not the size they expected, but that the window exactly fits the width and/or height of their monitor should be a pretty big hint as to what happened.

Edit: Tested on Windows 7 64-bit

@retep998

This comment has been minimized.

Show comment
Hide comment
@retep998

retep998 Apr 29, 2012

What OS are you using?
The best thing to do is to actually fix the issue, but if that doesn't work then SFML should throw an exception or however SFML deals with errors. Invisibly shrinking the window could result in some major problems, because the programmer STILL wouldn't know what exactly is wrong.

retep998 commented Apr 29, 2012

What OS are you using?
The best thing to do is to actually fix the issue, but if that doesn't work then SFML should throw an exception or however SFML deals with errors. Invisibly shrinking the window could result in some major problems, because the programmer STILL wouldn't know what exactly is wrong.

@ghost ghost assigned LaurentGomila Apr 29, 2012

@malpert

This comment has been minimized.

Show comment
Hide comment
@malpert

malpert Apr 30, 2012

I'm using Windows 7 64-bit (added to issue).

This was discussed on the forums before I made the issue here: http://en.sfml-dev.org/forums/index.php?topic=7685.0

Laurent said that the OS is the one causing the window not to appear, meaning it can't simply be fixed. The main thing I've been trying to point out is that nobody knows this problem exists until it happens to them. And when it happens, nobody understand what's happening. Nothing about the current behavior (the window simply not appearing) indicates that the programmer set the window size too large. Laurent pointed out that developers often compile in system:window mode since this isn't a console program, and so would not see any warnings about the size if they were written to stdout. It's also questionable whether they would catch an exception. And this would become increasingly more difficult to debug if this was happening on an end user's computer since it's very likely the developer consistently worked on a higher resolution monitor. I used SFML for quite some time and never experience this problem. Then one day I was working on my laptop for a change and the window just wouldn't show up. "I know it was just working! The code is identical! It's the same OS! What's happening!?!?!?" I'm just trying to help others avoid that frustration.

The bottom line, in my opinion, is that the best way to reliably convey the most information about this problem to whoever is using the program when it happens is to simply squeeze the window to fit within the desktop resolution. If it happens to a developer, hopefully they'll see that the borders of the window are up against the edges of the screen and they're realize it's related to the size. If it happens to an end user, at least the program sort of works and they can report a bug by saying something like "everything looks squeezed or short" and maybe will send a screenshot that also shows that the window borders are hitting the edges of the screen.

Since I know about this problem, I've more or less resolved it in my own program with the following code.

sf::RenderWindow App    ( sf::VideoMode
                            ( std::min(sf::VideoMode::getDesktopMode().width,(unsigned)1000)
                            , std::min(sf::VideoMode::getDesktopMode().height,(unsigned)1000)
                            , 32)
                        , "Graph Search");

So here you can see that I've set the size to 1000x1000, but if the desktop resolution is ever smaller than that, it will squeeze the window. I suppose another solution may be to add similar code to the tutorials to essentially teach this problem to developers right when they get started.

malpert commented Apr 30, 2012

I'm using Windows 7 64-bit (added to issue).

This was discussed on the forums before I made the issue here: http://en.sfml-dev.org/forums/index.php?topic=7685.0

Laurent said that the OS is the one causing the window not to appear, meaning it can't simply be fixed. The main thing I've been trying to point out is that nobody knows this problem exists until it happens to them. And when it happens, nobody understand what's happening. Nothing about the current behavior (the window simply not appearing) indicates that the programmer set the window size too large. Laurent pointed out that developers often compile in system:window mode since this isn't a console program, and so would not see any warnings about the size if they were written to stdout. It's also questionable whether they would catch an exception. And this would become increasingly more difficult to debug if this was happening on an end user's computer since it's very likely the developer consistently worked on a higher resolution monitor. I used SFML for quite some time and never experience this problem. Then one day I was working on my laptop for a change and the window just wouldn't show up. "I know it was just working! The code is identical! It's the same OS! What's happening!?!?!?" I'm just trying to help others avoid that frustration.

The bottom line, in my opinion, is that the best way to reliably convey the most information about this problem to whoever is using the program when it happens is to simply squeeze the window to fit within the desktop resolution. If it happens to a developer, hopefully they'll see that the borders of the window are up against the edges of the screen and they're realize it's related to the size. If it happens to an end user, at least the program sort of works and they can report a bug by saying something like "everything looks squeezed or short" and maybe will send a screenshot that also shows that the window borders are hitting the edges of the screen.

Since I know about this problem, I've more or less resolved it in my own program with the following code.

sf::RenderWindow App    ( sf::VideoMode
                            ( std::min(sf::VideoMode::getDesktopMode().width,(unsigned)1000)
                            , std::min(sf::VideoMode::getDesktopMode().height,(unsigned)1000)
                            , 32)
                        , "Graph Search");

So here you can see that I've set the size to 1000x1000, but if the desktop resolution is ever smaller than that, it will squeeze the window. I suppose another solution may be to add similar code to the tutorials to essentially teach this problem to developers right when they get started.

@kimci86

This comment has been minimized.

Show comment
Hide comment
@kimci86

kimci86 Jul 9, 2012

Contributor

Actually, the window is created, but it is positioned out of the screen.
You can see it by moving the window : Alt+Space > Move. Then you press the arrow keys and move the mouse.
The window appears !
So a simple solution is to call myBigWindow.setPosition(sf::Vector2i(0,0));

Contributor

kimci86 commented Jul 9, 2012

Actually, the window is created, but it is positioned out of the screen.
You can see it by moving the window : Alt+Space > Move. Then you press the arrow keys and move the mouse.
The window appears !
So a simple solution is to call myBigWindow.setPosition(sf::Vector2i(0,0));

@nitrix

This comment has been minimized.

Show comment
Hide comment
@nitrix

nitrix Jul 15, 2012

So what I understand: the behavior is intended. The window is simply too big to fit the screen and must be moved around to be seen, but it is created and drawn correctly. No bugs.

In my opinion, because we already have access to sf::VideoMode::getDesktopMode() to set the proper size, it is our job to use it properly. SFML shouldn't add said limits. If one ever were to use a specificly (huge) value, we should let him do so, chances are he knows what he is doing - or simply can't program a software that make sense.

nitrix commented Jul 15, 2012

So what I understand: the behavior is intended. The window is simply too big to fit the screen and must be moved around to be seen, but it is created and drawn correctly. No bugs.

In my opinion, because we already have access to sf::VideoMode::getDesktopMode() to set the proper size, it is our job to use it properly. SFML shouldn't add said limits. If one ever were to use a specificly (huge) value, we should let him do so, chances are he knows what he is doing - or simply can't program a software that make sense.

@malpert

This comment has been minimized.

Show comment
Hide comment
@malpert

malpert Jul 16, 2012

nitrix, I disagree. Please read my comment.

malpert commented Jul 16, 2012

nitrix, I disagree. Please read my comment.

@nitrix

This comment has been minimized.

Show comment
Hide comment
@nitrix

nitrix Jul 16, 2012

Helping the new developers who are using the library the wrong way by limiting its capabilities ?

I'm just a bit reticent. What I noticed from major projects, some people do crazy stuff and they expect it to work, even if it's not an official feature.

But let's say I agree with you, we need a test case scenario:
You made your program to work on a height of 1000 pixels. Buttons, clickable coordinates on the screen, triggers or whatever, some of them are hard-coded or relative to another object. If the user have a smaller screen, like 800 pixels, what would you do? Resize the screen and take the risk to break the application or only show the part of it the screen can display...

The latter seems better to me, but we'd have to move at least the window at 0,0 if it's bigger than your screen to fix another problem mentioned earlier. Yet.... man this almost never happens, it's really case specific. If you need that kind of check, you could always add it to your software, no?

I guess Laurent will have the last word on this. Sure thing, the "fallback behavior" must be documented.

nitrix commented Jul 16, 2012

Helping the new developers who are using the library the wrong way by limiting its capabilities ?

I'm just a bit reticent. What I noticed from major projects, some people do crazy stuff and they expect it to work, even if it's not an official feature.

But let's say I agree with you, we need a test case scenario:
You made your program to work on a height of 1000 pixels. Buttons, clickable coordinates on the screen, triggers or whatever, some of them are hard-coded or relative to another object. If the user have a smaller screen, like 800 pixels, what would you do? Resize the screen and take the risk to break the application or only show the part of it the screen can display...

The latter seems better to me, but we'd have to move at least the window at 0,0 if it's bigger than your screen to fix another problem mentioned earlier. Yet.... man this almost never happens, it's really case specific. If you need that kind of check, you could always add it to your software, no?

I guess Laurent will have the last word on this. Sure thing, the "fallback behavior" must be documented.

@nitrix

This comment has been minimized.

Show comment
Hide comment
@nitrix

nitrix Jul 16, 2012

On more thing I'm thinking, you cannot resize a window to the size of the screen. The title bar heigh or window borders are different on every OS and depending on the window manager the user is running. (I'm using i3wm here)

nitrix commented Jul 16, 2012

On more thing I'm thinking, you cannot resize a window to the size of the screen. The title bar heigh or window borders are different on every OS and depending on the window manager the user is running. (I'm using i3wm here)

@Mitmischer

This comment has been minimized.

Show comment
Hide comment
@Mitmischer

Mitmischer Jul 16, 2012

@nitrix Just my humble opinion: One should not rely on a specific window size to make his program work - we dont do in traditional GUI programs either. In GUI programs, we rely on a window manager to handle when our window is resized.

I prefer resizing the window to fullscreen if it is too big and then shrinking the content, so that there is at least a chance to see something. Leaving the window as is results in some parts not being shown at all - this makes the program totally unusable. Additionally, I'd fire a resize-event. The user himself should appropriately react to the resize-event, he can for instance hide the less important parts to create space or agree to the shrinking.

Mitmischer commented Jul 16, 2012

@nitrix Just my humble opinion: One should not rely on a specific window size to make his program work - we dont do in traditional GUI programs either. In GUI programs, we rely on a window manager to handle when our window is resized.

I prefer resizing the window to fullscreen if it is too big and then shrinking the content, so that there is at least a chance to see something. Leaving the window as is results in some parts not being shown at all - this makes the program totally unusable. Additionally, I'd fire a resize-event. The user himself should appropriately react to the resize-event, he can for instance hide the less important parts to create space or agree to the shrinking.

@nitrix

This comment has been minimized.

Show comment
Hide comment
@nitrix

nitrix Jul 16, 2012

@Mitmischer : Mhhh, you are right, tho some people are writing images / sprites using X/Y coordinates, but anyway.
So it's either

  1. Position the window at 0,0 so at least part can be seen
  2. Fallback to the getFullscreenMode().at(0) //biggest fullscreen resolution supported, then fire a resize event if it doesn't already, or maybe a special event like "resolution not supported" ? I guess there must be already some kind of check like this for resolutions that doesn't make sense in fullscreen mode, we could simply adapt it.

Yeah actually I think 2) it's the best idea considering what everyone said. @malpert Are you working on a fix or simply reporting? I could do it overnight and push a request to Laurent.

nitrix commented Jul 16, 2012

@Mitmischer : Mhhh, you are right, tho some people are writing images / sprites using X/Y coordinates, but anyway.
So it's either

  1. Position the window at 0,0 so at least part can be seen
  2. Fallback to the getFullscreenMode().at(0) //biggest fullscreen resolution supported, then fire a resize event if it doesn't already, or maybe a special event like "resolution not supported" ? I guess there must be already some kind of check like this for resolutions that doesn't make sense in fullscreen mode, we could simply adapt it.

Yeah actually I think 2) it's the best idea considering what everyone said. @malpert Are you working on a fix or simply reporting? I could do it overnight and push a request to Laurent.

@malpert

This comment has been minimized.

Show comment
Hide comment
@malpert

malpert Jul 16, 2012

@nitrix I was not working on a fix, no. My only goal has been to prevent the confusion caused when this bug is encountered for the first time. It took me quite a while to figure out what was going on when I encountered it myself. I've simply been looking for the most appropriate method of informing the developer or user of what has happened. I didn't realize that the window was simply moved off screen and could be repositioned.

  1. Positioning the window at 0,0 is definitely works. The window is visible again, and the user can clearly see how the window is too large for the desktop. This method is probably more informative than resizing, especially to a user that doesn't know what the window is supposed to look like normally, and therefore might not realize the window is being squeezed with the other method (and so would not report a bug).

  2. Resizing the window is certainly a more drastic solution. Depending on how the developer placed objects, they may be come squeezed or disappear, or maybe even cause a crash. On the other hand, if a developer makes their program resizable, then this solution might work fine, as long as the right events are fired.

After thinking about this some more, I'm leaning strongly towards simply repositioning the window at 0,0. I think it's the solution with the best potential to inform the developer or user of what has happened and with the least potential to cause a crash or mess up the workings of the program (that is if it can actually work with part of the window hidden).

My original intent for the resizing method was simply to inform the user that something is wrong (and because I didn't know I could just reposition the window). But @Mitmischer, you suggest harnessing this automatic resizing behavior to ensure the program is in working condition, with the entire window visible and all its GUI elements working. But for the program to end up in that condition after being resized, the developer would likely have had to make it resizable from the get go, with everything in the window able to adapt to that resizing. And if that's the case, then when the program is moved to 0,0 and is too big for the screen, the user can just resize it.

I think this warrants a little more discussion, but I feel that simply repositioning to 0,0 is probably the best solution.

malpert commented Jul 16, 2012

@nitrix I was not working on a fix, no. My only goal has been to prevent the confusion caused when this bug is encountered for the first time. It took me quite a while to figure out what was going on when I encountered it myself. I've simply been looking for the most appropriate method of informing the developer or user of what has happened. I didn't realize that the window was simply moved off screen and could be repositioned.

  1. Positioning the window at 0,0 is definitely works. The window is visible again, and the user can clearly see how the window is too large for the desktop. This method is probably more informative than resizing, especially to a user that doesn't know what the window is supposed to look like normally, and therefore might not realize the window is being squeezed with the other method (and so would not report a bug).

  2. Resizing the window is certainly a more drastic solution. Depending on how the developer placed objects, they may be come squeezed or disappear, or maybe even cause a crash. On the other hand, if a developer makes their program resizable, then this solution might work fine, as long as the right events are fired.

After thinking about this some more, I'm leaning strongly towards simply repositioning the window at 0,0. I think it's the solution with the best potential to inform the developer or user of what has happened and with the least potential to cause a crash or mess up the workings of the program (that is if it can actually work with part of the window hidden).

My original intent for the resizing method was simply to inform the user that something is wrong (and because I didn't know I could just reposition the window). But @Mitmischer, you suggest harnessing this automatic resizing behavior to ensure the program is in working condition, with the entire window visible and all its GUI elements working. But for the program to end up in that condition after being resized, the developer would likely have had to make it resizable from the get go, with everything in the window able to adapt to that resizing. And if that's the case, then when the program is moved to 0,0 and is too big for the screen, the user can just resize it.

I think this warrants a little more discussion, but I feel that simply repositioning to 0,0 is probably the best solution.

@LaurentGomila

This comment has been minimized.

Show comment
Hide comment
@LaurentGomila

LaurentGomila Jul 17, 2012

Member

If moving the window to (0, 0) solves the problem, it's definitely the best solution, because it does exactly what the user wrote in his code. We can imagine that someone wants to create windows larger than the desktop on purpose.

Thanks a lot for the tests and feedback. Feel free to continue the discussion if you want.

Member

LaurentGomila commented Jul 17, 2012

If moving the window to (0, 0) solves the problem, it's definitely the best solution, because it does exactly what the user wrote in his code. We can imagine that someone wants to create windows larger than the desktop on purpose.

Thanks a lot for the tests and feedback. Feel free to continue the discussion if you want.

@nitrix

This comment has been minimized.

Show comment
Hide comment
@nitrix

nitrix Jul 17, 2012

In my opinion (0,0) is the best solution. Simply add a small note to make sure it's documented in case somebody is trying to do it on purpose. Can we see this implemented in the RC Laurent ?

nitrix commented Jul 17, 2012

In my opinion (0,0) is the best solution. Simply add a small note to make sure it's documented in case somebody is trying to do it on purpose. Can we see this implemented in the RC Laurent ?

@LaurentGomila

This comment has been minimized.

Show comment
Hide comment
@LaurentGomila

LaurentGomila Jul 18, 2012

Member

Can we see this implemented in the RC Laurent ?

I don't think it's an urgent task.

Member

LaurentGomila commented Jul 18, 2012

Can we see this implemented in the RC Laurent ?

I don't think it's an urgent task.

@LaurentGomila

This comment has been minimized.

Show comment
Hide comment
@LaurentGomila

LaurentGomila Jun 30, 2013

Member

I managed to fix this issue. The window not appearing was actually a bug in SFML, not the default OS behaviour. The OS behaviour was to resize the window to the desktop size, but I also managed to remove this constraint.

Member

LaurentGomila commented Jun 30, 2013

I managed to fix this issue. The window not appearing was actually a bug in SFML, not the default OS behaviour. The OS behaviour was to resize the window to the desktop size, but I also managed to remove this constraint.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment