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

Adjusted WindowImplX11. #780

Closed
wants to merge 1 commit into
base: master
from

Conversation

Projects
None yet
8 participants
@TankOs
Member

TankOs commented Jan 13, 2015

  • Replaced Xlib event names by XCB equivalents.
  • Removed XCB_CW_OVERRIDE_REDIRECT in order to let the WM handle mapping the window to the full screen.
  • Fixed mouse grabbing in fullscreen mode. Removed keyboard grabbing to allow the user to "alt+tab" out of the window.
  • Completely revised fullscreen handling: The screen's resolution is not changed at all anymore. Instead the WM is asked for going fullscreen and the view is scaled.
Adjusted WindowImplX11.
* Replaced Xlib event names by XCB equivalents.
* Removed XCB_CW_OVERRIDE_REDIRECT in order to let the WM handle mapping
  the window to the full screen.
* Fixed mouse grabbing in fullscreen mode. Removed keyboard grabbing to
  allow the user to "alt+tab" out of the window.
* Completely revised fullscreen handling: The screen's resolution is not
  changed at all anymore. Instead the WM is asked for going fullscreen
  and the view is scaled.

@TankOs TankOs self-assigned this Jan 13, 2015

@TankOs TankOs added this to the 2.3 milestone Jan 13, 2015

@TankOs

This comment has been minimized.

Show comment
Hide comment
@TankOs

TankOs Jan 13, 2015

Member

Related issues: #771, #724, #535, #274

Member

TankOs commented Jan 13, 2015

Related issues: #771, #724, #535, #274

@mantognini

This comment has been minimized.

Show comment
Hide comment
@mantognini

mantognini Jan 13, 2015

Member

Completely revised fullscreen handling: The screen's resolution is not changed at all anymore. Instead the WM is asked for going fullscreen and the view is scaled.

Does that mean the view is stretched or is it letterboxed?

Member

mantognini commented Jan 13, 2015

Completely revised fullscreen handling: The screen's resolution is not changed at all anymore. Instead the WM is asked for going fullscreen and the view is scaled.

Does that mean the view is stretched or is it letterboxed?

@LaurentGomila

This comment has been minimized.

Show comment
Hide comment
@LaurentGomila

LaurentGomila Jan 13, 2015

Member

Completely revised fullscreen handling: The screen's resolution is not changed at all anymore. Instead the WM is asked for going fullscreen and the view is scaled.

So you always stay at desktop resolution? This defeats one of the advantages of the fullscreen mode (ie. taking control on the screen resolution).

Member

LaurentGomila commented Jan 13, 2015

Completely revised fullscreen handling: The screen's resolution is not changed at all anymore. Instead the WM is asked for going fullscreen and the view is scaled.

So you always stay at desktop resolution? This defeats one of the advantages of the fullscreen mode (ie. taking control on the screen resolution).

@mantognini

This comment has been minimized.

Show comment
Hide comment
@mantognini

mantognini Jan 13, 2015

Member

On Mac, SFML 1.6 used to perform a hard switch but that's no longer the case for two main reasons: a) performances were not significantly better with a hard video mode switch than with backbuffer/letterboxed view; b) Apple's discourage this practice. See 8f0037d for more details.

While b) might not hold on Linux per se, I think it's also better to avoid messing with the user's desktop settings (with some WM, windows are resized and icons moved on the desktop). However, we could argue that's up to the application developer to choose wisely a fullscreen config...

But I'm pretty sure the first point holds. Could someone confirm it?

@LaurentGomila maybe you see another aspect in favor of hard switch beside UX and perfs?

Member

mantognini commented Jan 13, 2015

On Mac, SFML 1.6 used to perform a hard switch but that's no longer the case for two main reasons: a) performances were not significantly better with a hard video mode switch than with backbuffer/letterboxed view; b) Apple's discourage this practice. See 8f0037d for more details.

While b) might not hold on Linux per se, I think it's also better to avoid messing with the user's desktop settings (with some WM, windows are resized and icons moved on the desktop). However, we could argue that's up to the application developer to choose wisely a fullscreen config...

But I'm pretty sure the first point holds. Could someone confirm it?

@LaurentGomila maybe you see another aspect in favor of hard switch beside UX and perfs?

@LaurentGomila

This comment has been minimized.

Show comment
Hide comment
@LaurentGomila

LaurentGomila Jan 13, 2015

Member

Mainly performances, yes, even if this point is less important nowadays.

Member

LaurentGomila commented Jan 13, 2015

Mainly performances, yes, even if this point is less important nowadays.

@TankOs

This comment has been minimized.

Show comment
Hide comment
@TankOs

TankOs Jan 13, 2015

Member

@mantognini
It is stretched, because that's what would happen in classic fullscreen as well.

@LaurentGomila @mantognini
What performance issue are you referring to? The upscaling? If yes, then I doubt it will be an issue on any supported hardware.

If you are referring to some kind of exclusive mode: There is no such thing on Linux/X/GLX.

In fact the new implementation fixes some issues and allows to easily tab out of the window without resolution change parties. ;) Personally I don't see a real reason to change the screen resolution anymore. Quite some games are doing the same on Linux mainly for avoiding issues.

Member

TankOs commented Jan 13, 2015

@mantognini
It is stretched, because that's what would happen in classic fullscreen as well.

@LaurentGomila @mantognini
What performance issue are you referring to? The upscaling? If yes, then I doubt it will be an issue on any supported hardware.

If you are referring to some kind of exclusive mode: There is no such thing on Linux/X/GLX.

In fact the new implementation fixes some issues and allows to easily tab out of the window without resolution change parties. ;) Personally I don't see a real reason to change the screen resolution anymore. Quite some games are doing the same on Linux mainly for avoiding issues.

@mantognini

This comment has been minimized.

Show comment
Hide comment
@mantognini

mantognini Jan 13, 2015

Member

My point was that performance was not an issue, so, for me, your new impl is ok.

Well, up to a point. ;)

I feel, as other users who made me change the impl on OS X (see above commit link), that when you ask for a 800x600 view, full screen or not, you should get a 800x600 view -- not something that is reported as such but is in fact stretched -- for the sake of UX.

Also, on OS X, if you perform a hard video mode change to 800x600 you get a rect with the correct ratio. Isn't that not also the case on Linux? If that's the case, the view the user get through SFML should match that ratio -- whether SFML performs a hard or soft switch. If that not the case, I think it's reasonable to do it anyway.

Member

mantognini commented Jan 13, 2015

My point was that performance was not an issue, so, for me, your new impl is ok.

Well, up to a point. ;)

I feel, as other users who made me change the impl on OS X (see above commit link), that when you ask for a 800x600 view, full screen or not, you should get a 800x600 view -- not something that is reported as such but is in fact stretched -- for the sake of UX.

Also, on OS X, if you perform a hard video mode change to 800x600 you get a rect with the correct ratio. Isn't that not also the case on Linux? If that's the case, the view the user get through SFML should match that ratio -- whether SFML performs a hard or soft switch. If that not the case, I think it's reasonable to do it anyway.

@def8x

This comment has been minimized.

Show comment
Hide comment
@def8x

def8x Jan 14, 2015

After shortly experimenting with it, I must say I am definitely in favor of this new implementation, even if it does not really respect the specified video mode. Performance issues can still somewhat be worked around by using a smaller sf::RenderTexture, which is then upscaled and drawn as a sprite.
In addition to fixing the mentioned issues, these adjustments also greatly improve support for multi-monitor systems by opening the fullscreen window on the monitor the mouse is currently at (under xfwm4 with TwinView) with the respective monitor's native resolution.
Previously, SFML would show fullscreen windows at an incompatible resolution (1920x1080 on a 1280x1080 monitor) on an arbitrary monitor (probably just the first one returned by xrandr).

However, there is currently a bug on my system (or my code?) where using sf::Style::Fullscreen either in the first call to create() or the constructor of sf::Window silently fails, instead resulting in a regular window with a grabbed mouse cursor:
sf::RenderWindow window(sf::VideoMode(640, 480), "Title", sf::Style::Fullscreen);

It is required to call the create() function one more time to actually make the window full-screen. Can anyone else reproduce this?

def8x commented Jan 14, 2015

After shortly experimenting with it, I must say I am definitely in favor of this new implementation, even if it does not really respect the specified video mode. Performance issues can still somewhat be worked around by using a smaller sf::RenderTexture, which is then upscaled and drawn as a sprite.
In addition to fixing the mentioned issues, these adjustments also greatly improve support for multi-monitor systems by opening the fullscreen window on the monitor the mouse is currently at (under xfwm4 with TwinView) with the respective monitor's native resolution.
Previously, SFML would show fullscreen windows at an incompatible resolution (1920x1080 on a 1280x1080 monitor) on an arbitrary monitor (probably just the first one returned by xrandr).

However, there is currently a bug on my system (or my code?) where using sf::Style::Fullscreen either in the first call to create() or the constructor of sf::Window silently fails, instead resulting in a regular window with a grabbed mouse cursor:
sf::RenderWindow window(sf::VideoMode(640, 480), "Title", sf::Style::Fullscreen);

It is required to call the create() function one more time to actually make the window full-screen. Can anyone else reproduce this?

@TankOs

This comment has been minimized.

Show comment
Hide comment
@TankOs

TankOs Jan 14, 2015

Member

@mantognini
You effectively get 800x600 -- in fact it is stretched to 800x600. ;) The result is nearest to the previous behavior when the monitor handled the upscaling, that's why I haven't added anything on top of that. I wasn't aware that it's done differently on OSX.

I'm not sure if I want to enforce a ratio. I can also find nothing about that in the documentation. Remember that if you force a letter box/correct ratio, there's no way for the user to NOT use it, for whatever reason. I think this should at least be an option. I would not expect a ratio correction personally.

@def8x
Yes definitely, I forgot to mention the multi-head advantage. Since I'm using two heads, I was happy to see a resolution of 1920x1080 working on both screens, where the 2nd screen allows a maximum of 1280x1024 only. :)

I will try to reproduce your problem, thanks for reporting.

Member

TankOs commented Jan 14, 2015

@mantognini
You effectively get 800x600 -- in fact it is stretched to 800x600. ;) The result is nearest to the previous behavior when the monitor handled the upscaling, that's why I haven't added anything on top of that. I wasn't aware that it's done differently on OSX.

I'm not sure if I want to enforce a ratio. I can also find nothing about that in the documentation. Remember that if you force a letter box/correct ratio, there's no way for the user to NOT use it, for whatever reason. I think this should at least be an option. I would not expect a ratio correction personally.

@def8x
Yes definitely, I forgot to mention the multi-head advantage. Since I'm using two heads, I was happy to see a resolution of 1920x1080 working on both screens, where the 2nd screen allows a maximum of 1280x1024 only. :)

I will try to reproduce your problem, thanks for reporting.

@mantognini

This comment has been minimized.

Show comment
Hide comment
@mantognini

mantognini Jan 14, 2015

Member

You effectively get 800x600 -- in fact it is stretched to 800x600.

I'm not sure to get what you mean by it. 800x600 is stretched to 800x600? Put differently, do you use letterboxing or not? Does 800x600 windows fill the whole screen even if it's not a 4:3 monitor?

Member

mantognini commented Jan 14, 2015

You effectively get 800x600 -- in fact it is stretched to 800x600.

I'm not sure to get what you mean by it. 800x600 is stretched to 800x600? Put differently, do you use letterboxing or not? Does 800x600 windows fill the whole screen even if it's not a 4:3 monitor?

@eXpl0it3r

This comment has been minimized.

Show comment
Hide comment
@eXpl0it3r

eXpl0it3r Jan 14, 2015

Member

@BlueCobold has provided example screenshots of the current behavior on OS X and as stated on that thread, I don't agree with the current implementation. Maybe I'm just biased by Windows, but when in fullscreen you really want the full screen.

And since the ratio adjustment isn't really the job of SFML, I'd say it should fully stretch. That would be the behavior on Windows.

But I'm also open for different perspective on that matter. For me it just feels wrong to have a small "window" in fullscreen. 😉

Member

eXpl0it3r commented Jan 14, 2015

@BlueCobold has provided example screenshots of the current behavior on OS X and as stated on that thread, I don't agree with the current implementation. Maybe I'm just biased by Windows, but when in fullscreen you really want the full screen.

And since the ratio adjustment isn't really the job of SFML, I'd say it should fully stretch. That would be the behavior on Windows.

But I'm also open for different perspective on that matter. For me it just feels wrong to have a small "window" in fullscreen. 😉

@mantognini

This comment has been minimized.

Show comment
Hide comment
@mantognini

mantognini Jan 14, 2015

Member

Maybe I'm just biased by Windows, but when in fullscreen you really want the full screen.

No, you're probably right but since I've got barely no feedback (and I'm no Windows user) such issue can happen. 😉

As I said in my answer on that thread, maybe we should investigate the addition of another style flag (HardSwitchFullscreen). Even though I would personally discourage people of using it, I'm not against allowing people who love messing with the user desktop settings using it -- their customer will probably complain enough for me. :-P

On the soft switch mode: should it be scaled to fit the screen with the proper ratio (with letterboxing), or just stretched? I'd go for the first since the rendering is better.

Member

mantognini commented Jan 14, 2015

Maybe I'm just biased by Windows, but when in fullscreen you really want the full screen.

No, you're probably right but since I've got barely no feedback (and I'm no Windows user) such issue can happen. 😉

As I said in my answer on that thread, maybe we should investigate the addition of another style flag (HardSwitchFullscreen). Even though I would personally discourage people of using it, I'm not against allowing people who love messing with the user desktop settings using it -- their customer will probably complain enough for me. :-P

On the soft switch mode: should it be scaled to fit the screen with the proper ratio (with letterboxing), or just stretched? I'd go for the first since the rendering is better.

@TankOs

This comment has been minimized.

Show comment
Hide comment
@TankOs

TankOs Jan 14, 2015

Member

But it might not be what the developer or even the user wants. 800*600 is requested, how it's interpreted is then up to the developer. Let's not over-complicate this. ;-)

Member

TankOs commented Jan 14, 2015

But it might not be what the developer or even the user wants. 800*600 is requested, how it's interpreted is then up to the developer. Let's not over-complicate this. ;-)

@TankOs

This comment has been minimized.

Show comment
Hide comment
@TankOs

TankOs Jan 14, 2015

Member

Oh, a use-case that just came into my mind: Imagine you choose 800*600 because some projector you use doesn't support another mode, but you can easily scale it by pressing some buttons on the hardware. The effective resolution would be smaller if SFML did letterboxing. ;-) Yes, this is probably not a big deal, but it shows that SFML should not interfere, as stretching might indeed be intended.

Member

TankOs commented Jan 14, 2015

Oh, a use-case that just came into my mind: Imagine you choose 800*600 because some projector you use doesn't support another mode, but you can easily scale it by pressing some buttons on the hardware. The effective resolution would be smaller if SFML did letterboxing. ;-) Yes, this is probably not a big deal, but it shows that SFML should not interfere, as stretching might indeed be intended.

@BlueCobold

This comment has been minimized.

Show comment
Hide comment
@BlueCobold

BlueCobold Jan 14, 2015

Contributor

I agree with @eXpl0it3r here. If the developer/user decides to use a resolution for fullscreen mode, it is exactly what he should get - and it is what both user and developer would expect to happen anyway. If they want a 4:3 ratio on a 16:9 screen, so be it. If they want letterboxing to keep aspect-ratio, the developer can still do it himself. As you noticed with the beamer/projector, the natively requested resolution may have a pretty solid reason (apart from being the thing you asked the system for in the first place). If SFML doesn't change the physical resolution and only renders into a smaller render-target to then scale it to full screen size, the developer could do that himself already while he cannot do the other thing (native resolution instead of faked one) if forced by SFML.

Contributor

BlueCobold commented Jan 14, 2015

I agree with @eXpl0it3r here. If the developer/user decides to use a resolution for fullscreen mode, it is exactly what he should get - and it is what both user and developer would expect to happen anyway. If they want a 4:3 ratio on a 16:9 screen, so be it. If they want letterboxing to keep aspect-ratio, the developer can still do it himself. As you noticed with the beamer/projector, the natively requested resolution may have a pretty solid reason (apart from being the thing you asked the system for in the first place). If SFML doesn't change the physical resolution and only renders into a smaller render-target to then scale it to full screen size, the developer could do that himself already while he cannot do the other thing (native resolution instead of faked one) if forced by SFML.

@i8degrees

This comment has been minimized.

Show comment
Hide comment
@i8degrees

i8degrees Jan 15, 2015

For whatever it is worth … I agree with @eXpl0it3r and @BlueCobold on the resolution issue, but.. I also think that, as @mantognini stated, taking into consideration of supporting both methods is worth while. (I feel like both methods have their merits / use cases).

Cheers!

i8degrees commented Jan 15, 2015

For whatever it is worth … I agree with @eXpl0it3r and @BlueCobold on the resolution issue, but.. I also think that, as @mantognini stated, taking into consideration of supporting both methods is worth while. (I feel like both methods have their merits / use cases).

Cheers!

@BlueCobold

This comment has been minimized.

Show comment
Hide comment
@BlueCobold

BlueCobold Jan 15, 2015

Contributor

Thing is that a developer, who's using SFML, can implement the soft-switch ("keep native and stretch it") himself easily for all platforms while he cannot add a hard-switch if SFML already does this soft-switch.

Contributor

BlueCobold commented Jan 15, 2015

Thing is that a developer, who's using SFML, can implement the soft-switch ("keep native and stretch it") himself easily for all platforms while he cannot add a hard-switch if SFML already does this soft-switch.

@TankOs

This comment has been minimized.

Show comment
Hide comment
@TankOs

TankOs Jan 15, 2015

Member

@BlueCobold What are the issues with using a soft switch only?

Member

TankOs commented Jan 15, 2015

@BlueCobold What are the issues with using a soft switch only?

@BlueCobold

This comment has been minimized.

Show comment
Hide comment
@BlueCobold

BlueCobold Jan 15, 2015

Contributor

@TankOs

  1. The device you might want to use to show the game on might not support the soft resolution (attached beamer)
  2. FragmentShaders will see the native resolution while SFML-developers don't (no way the developer could fix problems related to that) - there already is a bugreport for OS X about this in the forum since OS X does some kind of windowed soft-resolution-scaling for "old" apps which don't support retina screens. With soft-switching, all OS will have this issue.
  3. A developer can implement a soft-switch himself if SFML uses hard-switch, but the developer cannot implement a hard-switch if SFML uses a soft-switch
  4. A soft-switch isn't what the developer asked for in the first place
  5. Higher memory footprint, because internally large buffers are used always
  6. More effort internally for SFML - you need to scale various event coordinates (Mouse in/out for example), shape-coordinates, (render)texture-coordinates, etc. Especially coordinates used by Sprites which are used with a RenderTexture will have totally screwed texture-coordinates/textureRects. I don't see how you want to get this thing handled at all, because there's no way to even detect that problem.
  7. Screenshots being taken would be large instead of the resolution you wanted your app to have
  8. Recorded videos would have large resolution instead of the resolution you wanted your app to have - this really impacts performance for screen-capturing and will have messed up quality - imo one of the worst things of all in this list.
  9. Mouse-speed doesn't change as you would expect by using a window with lower resolution
  10. It might interfer (and pretty surely will) with other stuff the developer might want to do by using OpenGL directly additional to SFML
  11. What if the game/application wants to set a resolution higher than the one currently used be the user's desktop? It might be rare, but it surely could happen that the user is not using maximum resolution for his desktop. Then SFML would render in higher resolution and scale it down.
  12. An application using 800x600 in windowed would behave differently than the same application using 800x00 fullscreen. Doesn't make any sense.
  13. all the other crap I didn't even think of yet

1), 2), 6) and 8) being the worst ones in the list imo. 6) would totally screw up my own SFML-games. 7 and 8 would kill some planned features.

Contributor

BlueCobold commented Jan 15, 2015

@TankOs

  1. The device you might want to use to show the game on might not support the soft resolution (attached beamer)
  2. FragmentShaders will see the native resolution while SFML-developers don't (no way the developer could fix problems related to that) - there already is a bugreport for OS X about this in the forum since OS X does some kind of windowed soft-resolution-scaling for "old" apps which don't support retina screens. With soft-switching, all OS will have this issue.
  3. A developer can implement a soft-switch himself if SFML uses hard-switch, but the developer cannot implement a hard-switch if SFML uses a soft-switch
  4. A soft-switch isn't what the developer asked for in the first place
  5. Higher memory footprint, because internally large buffers are used always
  6. More effort internally for SFML - you need to scale various event coordinates (Mouse in/out for example), shape-coordinates, (render)texture-coordinates, etc. Especially coordinates used by Sprites which are used with a RenderTexture will have totally screwed texture-coordinates/textureRects. I don't see how you want to get this thing handled at all, because there's no way to even detect that problem.
  7. Screenshots being taken would be large instead of the resolution you wanted your app to have
  8. Recorded videos would have large resolution instead of the resolution you wanted your app to have - this really impacts performance for screen-capturing and will have messed up quality - imo one of the worst things of all in this list.
  9. Mouse-speed doesn't change as you would expect by using a window with lower resolution
  10. It might interfer (and pretty surely will) with other stuff the developer might want to do by using OpenGL directly additional to SFML
  11. What if the game/application wants to set a resolution higher than the one currently used be the user's desktop? It might be rare, but it surely could happen that the user is not using maximum resolution for his desktop. Then SFML would render in higher resolution and scale it down.
  12. An application using 800x600 in windowed would behave differently than the same application using 800x00 fullscreen. Doesn't make any sense.
  13. all the other crap I didn't even think of yet

1), 2), 6) and 8) being the worst ones in the list imo. 6) would totally screw up my own SFML-games. 7 and 8 would kill some planned features.

@TankOs

This comment has been minimized.

Show comment
Hide comment
@TankOs

TankOs Jan 15, 2015

Member

@BlueCobold Very good points, thanks a bunch for that list. I don't get 1 however: Every resolution for soft-switching is supported, since only the view is scaled. You could even use a resolution of 123*456 if SFML would not prevent that in sf::VideoMode::isValid().

Due to the outlined points and generally giving the user the option makes me want to implement both techniques through different sf::Styles.

What do the other SFML team members say? It would affect all platforms.

Member

TankOs commented Jan 15, 2015

@BlueCobold Very good points, thanks a bunch for that list. I don't get 1 however: Every resolution for soft-switching is supported, since only the view is scaled. You could even use a resolution of 123*456 if SFML would not prevent that in sf::VideoMode::isValid().

Due to the outlined points and generally giving the user the option makes me want to implement both techniques through different sf::Styles.

What do the other SFML team members say? It would affect all platforms.

@LaurentGomila

This comment has been minimized.

Show comment
Hide comment
@LaurentGomila

LaurentGomila Jan 15, 2015

Member

In case it helps:

Member

LaurentGomila commented Jan 15, 2015

In case it helps:

@BlueCobold

This comment has been minimized.

Show comment
Hide comment
@BlueCobold

BlueCobold Jan 15, 2015

Contributor

@TankOs The ability to use 123x456 is the only thing that is really really neat about soft-switch. Of course I believe both ways getting implemented would be a great thing, but if I had to chose one of the two, I'd always vote for hard-switch.

Contributor

BlueCobold commented Jan 15, 2015

@TankOs The ability to use 123x456 is the only thing that is really really neat about soft-switch. Of course I believe both ways getting implemented would be a great thing, but if I had to chose one of the two, I'd always vote for hard-switch.

@eXpl0it3r

This comment has been minimized.

Show comment
Hide comment
@eXpl0it3r

eXpl0it3r Jan 16, 2015

Member

Since with the current implementation fullscreen mode is broken completely and we've yet to come to a verdict on the whole fullscreen discussion, should I merge this in the meantime or do you, @TankOs, want to update it?

As for the discussion in general, let's keep it on the forum, either in the already on going discussion thread or if someone feels like it, they can open a new thread.

Only comment here further if you're actually referring to the PR.

Member

eXpl0it3r commented Jan 16, 2015

Since with the current implementation fullscreen mode is broken completely and we've yet to come to a verdict on the whole fullscreen discussion, should I merge this in the meantime or do you, @TankOs, want to update it?

As for the discussion in general, let's keep it on the forum, either in the already on going discussion thread or if someone feels like it, they can open a new thread.

Only comment here further if you're actually referring to the PR.

@TankOs

This comment has been minimized.

Show comment
Hide comment
@TankOs

TankOs Jan 22, 2015

Member

I will change this PR.

Member

TankOs commented Jan 22, 2015

I will change this PR.

@binary1248

This comment has been minimized.

Show comment
Hide comment
@binary1248

binary1248 Mar 14, 2015

Member

Superseded by #825.

Member

binary1248 commented Mar 14, 2015

Superseded by #825.

@binary1248 binary1248 closed this Mar 14, 2015

@binary1248 binary1248 added s:superseded and removed s:undecided labels Mar 14, 2015

@binary1248 binary1248 deleted the bugfix/altf4 branch Apr 2, 2015

@TankOs TankOs removed their assignment Apr 30, 2015

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