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

X11: Keyevent Alt+F4 doesn't get triggered in Window mode #274

Closed
Robert42 opened this Issue Aug 21, 2012 · 14 comments

Comments

Projects
None yet
7 participants
@Robert42

Robert42 commented Aug 21, 2012

When using Window mode Alt+F4 doesn't get pulled as Event.

Normally That's nothing one notices as using sf::Style::Close, results in sending a Close Event.

See the original Topic within the forum: http://en.sfml-dev.org/forums/index.php?topic=8923.0

@LaurentGomila

This comment has been minimized.

Show comment
Hide comment
@LaurentGomila

LaurentGomila Aug 22, 2012

Member

Version of SFML? OS?

Does ALT+F4 trigger the Closed event with other window configurations?

Member

LaurentGomila commented Aug 22, 2012

Version of SFML? OS?

Does ALT+F4 trigger the Closed event with other window configurations?

@Robert42

This comment has been minimized.

Show comment
Hide comment
@Robert42

Robert42 Aug 22, 2012

SFML 2.0 bleeding edge (fetched and compiled yesterday)
OS: LinuxMint 13 x64

The only window configuration triggering the Close event are sf::Style::Close (and so of course sf::Style::Default)

The only window configuration triggering the Alt+F4 LeyPressed event is sf::Style::Fullscreen

Robert42 commented Aug 22, 2012

SFML 2.0 bleeding edge (fetched and compiled yesterday)
OS: LinuxMint 13 x64

The only window configuration triggering the Close event are sf::Style::Close (and so of course sf::Style::Default)

The only window configuration triggering the Alt+F4 LeyPressed event is sf::Style::Fullscreen

@albertvaka

This comment has been minimized.

Show comment
Hide comment
@albertvaka

albertvaka Nov 11, 2012

If you want Alt+F4 to work on borderless windows, just don't set the flag MWM_HINTS_FUNCTIONS in that case (at WindowImplX11.cpp). I can create a pull request with that fix if you want.

In non-borderless windows, when sf::Style::Close is not present, I think Alt+F4 should not work (so there is no bug for me in those cases). Alt+F4 is a shortcut for the close button, so if the close button is not present, the shortuct should not work (because you want a non-closeable window!).

albertvaka commented Nov 11, 2012

If you want Alt+F4 to work on borderless windows, just don't set the flag MWM_HINTS_FUNCTIONS in that case (at WindowImplX11.cpp). I can create a pull request with that fix if you want.

In non-borderless windows, when sf::Style::Close is not present, I think Alt+F4 should not work (so there is no bug for me in those cases). Alt+F4 is a shortcut for the close button, so if the close button is not present, the shortuct should not work (because you want a non-closeable window!).

@LaurentGomila LaurentGomila added the new label May 19, 2014

@LaurentGomila LaurentGomila removed their assignment May 19, 2014

@binary1248 binary1248 added the Linux label May 19, 2014

@binary1248

This comment has been minimized.

Show comment
Hide comment
@binary1248

binary1248 Jul 5, 2014

Member

So... what would be the expected behaviour?

Member

binary1248 commented Jul 5, 2014

So... what would be the expected behaviour?

@Robert42

This comment has been minimized.

Show comment
Hide comment
@Robert42

Robert42 Jul 5, 2014

The expected behavior would be, that independent on the window configuration you are using, pressing Alt+F4 can be handeled by the application. For example to quit the application.

Robert42 commented Jul 5, 2014

The expected behavior would be, that independent on the window configuration you are using, pressing Alt+F4 can be handeled by the application. For example to quit the application.

@binary1248

This comment has been minimized.

Show comment
Hide comment
@binary1248

binary1248 Jul 5, 2014

Member

So, do all three styles have to result in the same event(s) being fired or is it enough that some event is fired in each case?

I need a precise description of the real intended behaviour.

Member

binary1248 commented Jul 5, 2014

So, do all three styles have to result in the same event(s) being fired or is it enough that some event is fired in each case?

I need a precise description of the real intended behaviour.

@Robert42

This comment has been minimized.

Show comment
Hide comment
@Robert42

Robert42 Jul 5, 2014

For my use case some event would be enough for a workaround. However, the intended behaviour would be to get the same events so event handling won't get fuzzy

Robert42 commented Jul 5, 2014

For my use case some event would be enough for a workaround. However, the intended behaviour would be to get the same events so event handling won't get fuzzy

@binary1248

This comment has been minimized.

Show comment
Hide comment
@binary1248

binary1248 Jul 5, 2014

Member

So... the intended behaviour would be: Regardless of window style, Alt+F4 should always result in sf::Event::Closed being created?

Member

binary1248 commented Jul 5, 2014

So... the intended behaviour would be: Regardless of window style, Alt+F4 should always result in sf::Event::Closed being created?

@Robert42

This comment has been minimized.

Show comment
Hide comment
@Robert42

Robert42 Jul 5, 2014

yes

Edit: At least for my usecase. If we want to keep things more flexible: Regardless of the window style, Alt+F4 would always result in an KeyEvent

Robert42 commented Jul 5, 2014

yes

Edit: At least for my usecase. If we want to keep things more flexible: Regardless of the window style, Alt+F4 would always result in an KeyEvent

@eXpl0it3r eXpl0it3r removed this from the 2.x milestone Nov 13, 2014

@Robert42 Robert42 removed this from the 2.x milestone Nov 13, 2014

@eXpl0it3r

This comment has been minimized.

Show comment
Hide comment
@eXpl0it3r

eXpl0it3r Jan 7, 2015

Member

The XCB branch has been merged, as such this issue could be reinvestigated.

Member

eXpl0it3r commented Jan 7, 2015

The XCB branch has been merged, as such this issue could be reinvestigated.

@TankOs TankOs self-assigned this Jan 7, 2015

@TankOs

This comment has been minimized.

Show comment
Hide comment
@TankOs

TankOs Jan 7, 2015

Member

👀

Member

TankOs commented Jan 7, 2015

👀

@TankOs

This comment has been minimized.

Show comment
Hide comment
@TankOs

TankOs Jan 13, 2015

Member

Implemented in #780

Member

TankOs commented Jan 13, 2015

Implemented in #780

@binary1248 binary1248 added this to the 2.3 milestone Feb 24, 2015

@binary1248 binary1248 referenced this issue Mar 14, 2015

Merged

XCB fixes #825

@binary1248

This comment has been minimized.

Show comment
Hide comment
@binary1248

binary1248 Mar 14, 2015

Member

Implemented in #825 (revised version of #780).

Member

binary1248 commented Mar 14, 2015

Implemented in #825 (revised version of #780).

@binary1248 binary1248 assigned binary1248 and unassigned TankOs Mar 14, 2015

@binary1248

This comment has been minimized.

Show comment
Hide comment
@binary1248

binary1248 Mar 29, 2015

Member

Merged in b9cc6f5

Member

binary1248 commented Mar 29, 2015

Merged in b9cc6f5

@binary1248 binary1248 closed this Mar 29, 2015

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