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

Methods to request and check window focus #613

Merged
merged 8 commits into from Oct 9, 2014

Conversation

Projects
None yet
@Bromeon
Member

Bromeon commented May 24, 2014

This pull request is based on #525 by @Foaly.

It extends the sf::Window public interface with two methods:

  • void requestFocus() to give the window the focus
  • bool hasFocus() const to check whether the window is currently focused

I tested the functionality on Windows 8.1 and Ubuntu 12.04. Here's a simple test program, based on Foaly's:

#include <SFML/Graphics.hpp>

int main()
{
    sf::RenderWindow window(sf::VideoMode(200, 200), "SFML works!");
    window.setFramerateLimit(60);

    sf::Clock clock;
    while (window.isOpen())
    {
        sf::Event event;
        while (window.pollEvent(event))
        {
            if (event.type == sf::Event::Closed)
                window.close();
            if (event.type == sf::Event::KeyReleased && event.key.code == sf::Keyboard::Escape)
                window.close();
        }

        if (clock.getElapsedTime() > sf::seconds(2))
        {
            window.requestFocus();
            clock.restart();
        }

        window.setTitle(window.hasFocus() ? "Focused" : "Lost");
        window.clear(window.hasFocus() ? sf::Color::White : sf::Color::Black);
        window.display();
    }
}

I haven't gotten feedback concerning the X11 check as suggested by @FRex, it would be nice if somebody could have a look at commit 2df07b2.

@Bromeon Bromeon added this to the 2.2 milestone May 24, 2014

@FRex

This comment has been minimized.

Show comment
Hide comment
@FRex

FRex May 24, 2014

Contributor

Only XSetInputFocus needs the window to be viewable, X docs don't say anything about XRaiseWindow needing it too and it works on xfce too, it actually works same as both calls together I think - it'll both move the window to top and give it the key input/focus, but that is probably a window manager quirk.

The get method seems fine. It regards a rolled xfce window as not focused but that's probably a good thing, since it's as good as a minimized window (which is regarded as not focused too, I hope that's how it's supposed to be..) - you can't say user/window manager is 'focused' on our window if he has it minimized or rolled up.

I checked the set method 'throughly' (as throughly as I can, being me):

  1. The way it was before, setting window to focus when it was rolled, on other desktop or minimized crashed with X error - because XSetInputFocus needed the window to be viewable, this has been fixed.
  2. The way it is now it'll not bring up a minimized window or pull window to current desktop from another one but will make it appear on top and steal the input if it was covered by some other window.
  3. If I change the code to call XSetInputFocus only if the window is viewable and call XRaiseWindow always then it'll unminimize windows, pull them from other desktops but it'll not do anything at all with a rolled window (won't unroll, won't unminimize, won't pull them to current desktop).
    (This is all on xfwm4 from xfce4 on Fedora 20 and X.Org X Server 1.14.4 BTW).
Contributor

FRex commented May 24, 2014

Only XSetInputFocus needs the window to be viewable, X docs don't say anything about XRaiseWindow needing it too and it works on xfce too, it actually works same as both calls together I think - it'll both move the window to top and give it the key input/focus, but that is probably a window manager quirk.

The get method seems fine. It regards a rolled xfce window as not focused but that's probably a good thing, since it's as good as a minimized window (which is regarded as not focused too, I hope that's how it's supposed to be..) - you can't say user/window manager is 'focused' on our window if he has it minimized or rolled up.

I checked the set method 'throughly' (as throughly as I can, being me):

  1. The way it was before, setting window to focus when it was rolled, on other desktop or minimized crashed with X error - because XSetInputFocus needed the window to be viewable, this has been fixed.
  2. The way it is now it'll not bring up a minimized window or pull window to current desktop from another one but will make it appear on top and steal the input if it was covered by some other window.
  3. If I change the code to call XSetInputFocus only if the window is viewable and call XRaiseWindow always then it'll unminimize windows, pull them from other desktops but it'll not do anything at all with a rolled window (won't unroll, won't unminimize, won't pull them to current desktop).
    (This is all on xfwm4 from xfce4 on Fedora 20 and X.Org X Server 1.14.4 BTW).
@mantognini

This comment has been minimized.

Show comment
Hide comment
@mantognini

mantognini May 25, 2014

Member

It seems I forgot to make the application active when requesting the focus... Here is a patch: https://gist.github.com/mantognini/1e3cc79ace4cfa93bd85

Member

mantognini commented May 25, 2014

It seems I forgot to make the application active when requesting the focus... Here is a patch: https://gist.github.com/mantognini/1e3cc79ace4cfa93bd85

@eXpl0it3r

This comment has been minimized.

Show comment
Hide comment
@eXpl0it3r

eXpl0it3r May 26, 2014

Member

requestFocus on Windows 8.1 lets the taskbar button blink. I wonder if it shouldn't actually force the window into the foreground. I mean if you want to have focus, don't you want to force it? At least it works if the focus is on the console window.
Otherwise I guess request fits quite nicely.

Member

eXpl0it3r commented May 26, 2014

requestFocus on Windows 8.1 lets the taskbar button blink. I wonder if it shouldn't actually force the window into the foreground. I mean if you want to have focus, don't you want to force it? At least it works if the focus is on the console window.
Otherwise I guess request fits quite nicely.

@TankOs

This comment has been minimized.

Show comment
Hide comment
@TankOs

TankOs May 27, 2014

Member

Is there a way to force focus?

Member

TankOs commented May 27, 2014

Is there a way to force focus?

@TankOs

This comment has been minimized.

Show comment
Hide comment
@TankOs

TankOs May 27, 2014

Member

My opinion however is that it should not be forced. Dropping and setting focus of a window is something the user does, not the program. On Linux, as far as I know, you can also request attention in X instead of popping up the window. Dunno, like always, how it's on OS X. ;)

What do you think?

Member

TankOs commented May 27, 2014

My opinion however is that it should not be forced. Dropping and setting focus of a window is something the user does, not the program. On Linux, as far as I know, you can also request attention in X instead of popping up the window. Dunno, like always, how it's on OS X. ;)

What do you think?

@mantognini

This comment has been minimized.

Show comment
Hide comment
@mantognini

mantognini May 27, 2014

Member

I agree, that would be nicer for the end user. On OS X you can also give a visual notification to the user (I need to implement it and I've never done it so..).

If the majority prefer having a visual notification, don't apply the patch I provided above.

Member

mantognini commented May 27, 2014

I agree, that would be nicer for the end user. On OS X you can also give a visual notification to the user (I need to implement it and I've never done it so..).

If the majority prefer having a visual notification, don't apply the patch I provided above.

@MarioLiebisch

This comment has been minimized.

Show comment
Hide comment
@MarioLiebisch

MarioLiebisch May 27, 2014

Member

Is there a way to force focus?

At least not on Windows, no.

Member

MarioLiebisch commented May 27, 2014

Is there a way to force focus?

At least not on Windows, no.

@TankOs

This comment has been minimized.

Show comment
Hide comment
@TankOs

TankOs May 27, 2014

Member

@mantognini Okay.

I think in this case we might think about doing it consistently and not interrupting the user with his work, but to request focus. ;)

Member

TankOs commented May 27, 2014

@mantognini Okay.

I think in this case we might think about doing it consistently and not interrupting the user with his work, but to request focus. ;)

@mantognini mantognini referenced this pull request May 27, 2014

Merged

Feature/grab mouse #614

3 of 5 tasks complete
@eXpl0it3r

This comment has been minimized.

Show comment
Hide comment
@eXpl0it3r

eXpl0it3r May 28, 2014

Member

@Bromeon did you apply @mantognini's patch regarding the focus request? Also, can you give a some status information on the feature?

It seemed to work fine on Windows for me.

Member

eXpl0it3r commented May 28, 2014

@Bromeon did you apply @mantognini's patch regarding the focus request? Also, can you give a some status information on the feature?

It seemed to work fine on Windows for me.

@Bromeon

This comment has been minimized.

Show comment
Hide comment
@Bromeon

Bromeon May 28, 2014

Member

No, I have not applied the patch yet. There is still an ongoing discussion concerning what's the best behavior. Personally, I wouldn't enforce focus on minimized windows, as long as this can be done consistently across platforms.

Member

Bromeon commented May 28, 2014

No, I have not applied the patch yet. There is still an ongoing discussion concerning what's the best behavior. Personally, I wouldn't enforce focus on minimized windows, as long as this can be done consistently across platforms.

@mantognini

This comment has been minimized.

Show comment
Hide comment
@mantognini

mantognini May 28, 2014

Member

I'll give you a patch tomorrow or on Friday that doesn't force focus but instead make the application icon bounce in the dock (the way OS X shows such notification to the user).

Member

mantognini commented May 28, 2014

I'll give you a patch tomorrow or on Friday that doesn't force focus but instead make the application icon bounce in the dock (the way OS X shows such notification to the user).

@MarioLiebisch

This comment has been minimized.

Show comment
Hide comment
@MarioLiebisch

MarioLiebisch May 28, 2014

Member

Isn't there a system preference or anything like that on OS X? Windows users are able to set the default values/behavior, so you can have "always steal" or "never steal" - just the way you want.

Member

MarioLiebisch commented May 28, 2014

Isn't there a system preference or anything like that on OS X? Windows users are able to set the default values/behavior, so you can have "always steal" or "never steal" - just the way you want.

@mantognini

This comment has been minimized.

Show comment
Hide comment
@mantognini

mantognini May 28, 2014

Member

No, there's no such setting.

Member

mantognini commented May 28, 2014

No, there's no such setting.

@mantognini

This comment has been minimized.

Show comment
Hide comment
@mantognini
Member

mantognini commented May 29, 2014

I've updated the gist with a new patch. https://gist.github.com/mantognini/1e3cc79ace4cfa93bd85

@Bromeon

This comment has been minimized.

Show comment
Hide comment
@Bromeon

Bromeon May 29, 2014

Member

@mantognini, so this patch makes the application icon bounce and not steal focus anymore?

Since there's no author information associated with the diff, how do you want me to apply it? Should I squash it into your previous commit and sign-off-by? You can also push to the branch directly if you want, and do as you prefer.

Member

Bromeon commented May 29, 2014

@mantognini, so this patch makes the application icon bounce and not steal focus anymore?

Since there's no author information associated with the diff, how do you want me to apply it? Should I squash it into your previous commit and sign-off-by? You can also push to the branch directly if you want, and do as you prefer.

@mantognini

This comment has been minimized.

Show comment
Hide comment
@mantognini

mantognini May 29, 2014

Member

Yes, no focus hijacking with that patch.

Should I squash it into your previous commit and sign-off-by?

Yes, that would be nice.

Member

mantognini commented May 29, 2014

Yes, no focus hijacking with that patch.

Should I squash it into your previous commit and sign-off-by?

Yes, that would be nice.

@Bromeon

This comment has been minimized.

Show comment
Hide comment
@Bromeon

Bromeon May 29, 2014

Member

Done. I needed to fix several conflicts, because the void->bool change happened only later in time... could you check whether I didn't mess things up?

Member

Bromeon commented May 29, 2014

Done. I needed to fix several conflicts, because the void->bool change happened only later in time... could you check whether I didn't mess things up?

@mantognini

This comment has been minimized.

Show comment
Hide comment
@mantognini

mantognini May 29, 2014

Member

It works perfectly. :-)

Member

mantognini commented May 29, 2014

It works perfectly. :-)

@Bromeon Bromeon self-assigned this May 29, 2014

@Bromeon

This comment has been minimized.

Show comment
Hide comment
@Bromeon

Bromeon May 29, 2014

Member

Thank you.

Concerning the Linux implementation, do things behave as one would expect? I tested on Ubuntu, where an opened window gains focus and is brought to the front, while a minimized window (even on a different desktop) gets a notification on the sidebar. It looked good to me, but I'm not the typical Linux UX guy :)

Member

Bromeon commented May 29, 2014

Thank you.

Concerning the Linux implementation, do things behave as one would expect? I tested on Ubuntu, where an opened window gains focus and is brought to the front, while a minimized window (even on a different desktop) gets a notification on the sidebar. It looked good to me, but I'm not the typical Linux UX guy :)

@abodelot

This comment has been minimized.

Show comment
Hide comment
@abodelot

abodelot May 30, 2014

Contributor

Just tested the branch feature/window_focus on a Debian/OpenBox and Debian/Xfce system.
I didn't encounter the same behaviour reported by @Bromeon:

  • If the window is opened and on the active desktop, window is brought to front (focus forced)
  • But if the window is minimized, or opened/minimized on an inactive desktop, nothing happens. (no visual notification).

@TankOs

My opinion however is that it should not be forced. Dropping and setting focus of a window is something the user does, not the program.

I agree. Also, that would be more consistent with Windows and MacOS implementation, since it's my understanding - after reading the comments - that focus is requested and not forced on these platforms.
So wouldn't it be better if requestFocus send a visual notification (blinking taskbar) on Linux, regardless the window is opened/minimzied or on a active/inactive desktop?

On Linux, as far as I know, you can also request attention in X instead of popping up the window

I can confirm this. Example:

  • launch gimp on desktop 1, then load an image
  • switch to desktop 2 before image is loaded
  • once image is loaded, gimp is blinking in the desktop 1 taskbar
Contributor

abodelot commented May 30, 2014

Just tested the branch feature/window_focus on a Debian/OpenBox and Debian/Xfce system.
I didn't encounter the same behaviour reported by @Bromeon:

  • If the window is opened and on the active desktop, window is brought to front (focus forced)
  • But if the window is minimized, or opened/minimized on an inactive desktop, nothing happens. (no visual notification).

@TankOs

My opinion however is that it should not be forced. Dropping and setting focus of a window is something the user does, not the program.

I agree. Also, that would be more consistent with Windows and MacOS implementation, since it's my understanding - after reading the comments - that focus is requested and not forced on these platforms.
So wouldn't it be better if requestFocus send a visual notification (blinking taskbar) on Linux, regardless the window is opened/minimzied or on a active/inactive desktop?

On Linux, as far as I know, you can also request attention in X instead of popping up the window

I can confirm this. Example:

  • launch gimp on desktop 1, then load an image
  • switch to desktop 2 before image is loaded
  • once image is loaded, gimp is blinking in the desktop 1 taskbar
@MarioLiebisch

This comment has been minimized.

Show comment
Hide comment
@MarioLiebisch

MarioLiebisch May 30, 2014

Member

So wouldn't it be better if requestFocus send a visual notification (blinking taskbar) on Linux, regardless the window is opened/minimzied or on a active/inactive desktop?

This should be up to the window manager on how to handle it. Or do you specifically have to pick either way? If so, I think just flashing would be better.

Member

MarioLiebisch commented May 30, 2014

So wouldn't it be better if requestFocus send a visual notification (blinking taskbar) on Linux, regardless the window is opened/minimzied or on a active/inactive desktop?

This should be up to the window manager on how to handle it. Or do you specifically have to pick either way? If so, I think just flashing would be better.

@Bromeon

This comment has been minimized.

Show comment
Hide comment
@Bromeon

Bromeon May 30, 2014

Member

@abodelot Thank you for your tests.

Also, that would be more consistent with Windows and MacOS implementation, since it's my understanding - after reading the comments - that focus is requested and not forced on these platforms.
So wouldn't it be better if requestFocus send a visual notification (blinking taskbar) on Linux, regardless the window is opened/minimzied or on a active/inactive desktop?

Yes, totally. The question is what we can do on X11 level. I've quickly found this description and this code where a similar example is used.

However, I wonder how much sense it makes to dig deeply in X11 docs when we're going to replace it with XCB soon...

Member

Bromeon commented May 30, 2014

@abodelot Thank you for your tests.

Also, that would be more consistent with Windows and MacOS implementation, since it's my understanding - after reading the comments - that focus is requested and not forced on these platforms.
So wouldn't it be better if requestFocus send a visual notification (blinking taskbar) on Linux, regardless the window is opened/minimzied or on a active/inactive desktop?

Yes, totally. The question is what we can do on X11 level. I've quickly found this description and this code where a similar example is used.

However, I wonder how much sense it makes to dig deeply in X11 docs when we're going to replace it with XCB soon...

@abodelot

This comment has been minimized.

Show comment
Hide comment
@abodelot

abodelot May 30, 2014

Contributor

@Bromeon I've also investigate on my own and got the Urgency Hint working with SFML.
X11 Documentation:

The UrgencyHint flag, if set in the flags field, indicates that the client deems the window contents to be urgent, requiring the timely response of the user.

Emercy Hint is implemented by a visual notification (usually, a blinking taskbar) by most Linux WM.

Replace the requestFocus method in src/SFML/Window/Unix/WindowImplX11.cpp with the following:

////////////////////////////////////////////////////////////
void WindowImplX11::requestFocus()
{
    // Ensure WM hints exist
    XWMHints* hints = XGetWMHints(m_display, m_window);
    if (hints == NULL)
        hints = XAllocWMHints();

    if (hints != NULL)
    {
        // Add Urgency Hint flag (visual notification)
        hints->flags |= XUrgencyHint;
        XSetWMHints(m_display, m_window, hints);
        XFree(hints);
    }
}

Here's the same function in a patch on top of the feature/window_branch if you prefer (but I think you guys would rather squash commits to keep the history clean).

When calling this method:

  • Nothing happens if the window is already focused (on the active desktop)
  • A visual notification is displayed (task blinking in the taskbar) if the window is either:
    • on another desktop (any status)
    • minimized on the active desktop
    • visible but not focused on the active desktop

I believe this is the expected behaviour, window cannot "steal" the focus anymore.

Contributor

abodelot commented May 30, 2014

@Bromeon I've also investigate on my own and got the Urgency Hint working with SFML.
X11 Documentation:

The UrgencyHint flag, if set in the flags field, indicates that the client deems the window contents to be urgent, requiring the timely response of the user.

Emercy Hint is implemented by a visual notification (usually, a blinking taskbar) by most Linux WM.

Replace the requestFocus method in src/SFML/Window/Unix/WindowImplX11.cpp with the following:

////////////////////////////////////////////////////////////
void WindowImplX11::requestFocus()
{
    // Ensure WM hints exist
    XWMHints* hints = XGetWMHints(m_display, m_window);
    if (hints == NULL)
        hints = XAllocWMHints();

    if (hints != NULL)
    {
        // Add Urgency Hint flag (visual notification)
        hints->flags |= XUrgencyHint;
        XSetWMHints(m_display, m_window, hints);
        XFree(hints);
    }
}

Here's the same function in a patch on top of the feature/window_branch if you prefer (but I think you guys would rather squash commits to keep the history clean).

When calling this method:

  • Nothing happens if the window is already focused (on the active desktop)
  • A visual notification is displayed (task blinking in the taskbar) if the window is either:
    • on another desktop (any status)
    • minimized on the active desktop
    • visible but not focused on the active desktop

I believe this is the expected behaviour, window cannot "steal" the focus anymore.

@Bromeon

This comment has been minimized.

Show comment
Hide comment
@Bromeon

Bromeon May 30, 2014

Member

Thank you!

Why did you remove XRaiseWindow and XSetInputFocus? Does the focus request on non-minimized windows still work like this?

Member

Bromeon commented May 30, 2014

Thank you!

Why did you remove XRaiseWindow and XSetInputFocus? Does the focus request on non-minimized windows still work like this?

@abodelot

This comment has been minimized.

Show comment
Hide comment
@abodelot

abodelot May 30, 2014

Contributor

Why did you remove XRaiseWindow and XSetInputFocus?

These methods were used to enforce focus, which is not allowed anymore. As I said, focus is now requested by displaying a visual notification instead of being enforced: the window cannot steal the focus and needs user interaction to gain it.

Does the focus request on non-minimized windows still work like this?

Ah, I forgot to describe this case on my last post (which I edited) : Yes, if the window is visible on the active desktop but not focused, calling requestFocus will display the visual notification as well (taskbar blinking).

Contributor

abodelot commented May 30, 2014

Why did you remove XRaiseWindow and XSetInputFocus?

These methods were used to enforce focus, which is not allowed anymore. As I said, focus is now requested by displaying a visual notification instead of being enforced: the window cannot steal the focus and needs user interaction to gain it.

Does the focus request on non-minimized windows still work like this?

Ah, I forgot to describe this case on my last post (which I edited) : Yes, if the window is visible on the active desktop but not focused, calling requestFocus will display the visual notification as well (taskbar blinking).

@eXpl0it3r

This comment has been minimized.

Show comment
Hide comment
@eXpl0it3r

eXpl0it3r Oct 6, 2014

Member

You don't need to merge it, git checkout feature/window_focus will do the trick, but feel free to do it whenever you want. 😄

Member

eXpl0it3r commented Oct 6, 2014

You don't need to merge it, git checkout feature/window_focus will do the trick, but feel free to do it whenever you want. 😄

@mantognini

This comment has been minimized.

Show comment
Hide comment
@mantognini

mantognini Oct 6, 2014

Member

No, what I meant is: since later we will merge it into master and there will be some conflicts, unless this branch in rebased onto master before, we will have to test it again. It's less time consuming to test it once so let's rebase first (instead of test - rebase - test). 😉

Member

mantognini commented Oct 6, 2014

No, what I meant is: since later we will merge it into master and there will be some conflicts, unless this branch in rebased onto master before, we will have to test it again. It's less time consuming to test it once so let's rebase first (instead of test - rebase - test). 😉

@Bromeon

This comment has been minimized.

Show comment
Hide comment
@Bromeon

Bromeon Oct 6, 2014

Member

Was very funny to rebase with all the newlines and colons... so, have fun at reviewing whether I did it correctly 😛

Member

Bromeon commented Oct 6, 2014

Was very funny to rebase with all the newlines and colons... so, have fun at reviewing whether I did it correctly 😛

@mantognini

This comment has been minimized.

Show comment
Hide comment
@mantognini

mantognini Oct 6, 2014

Member

Very good job rebasing all that s**t! BTW I used something like diff $(git diff feature/window_focus master) $(git diff old/feature/window_focus sha-before-first-commit) to track down the changes made during rebasing.

I'll re-test it very soon!

Member

mantognini commented Oct 6, 2014

Very good job rebasing all that s**t! BTW I used something like diff $(git diff feature/window_focus master) $(git diff old/feature/window_focus sha-before-first-commit) to track down the changes made during rebasing.

I'll re-test it very soon!

Foaly and others added some commits Jan 12, 2014

Added window methods to request and to check focus
Signed-off-by: Stefan Schindler <stefan@boxbox.org>
Signed-off-by: Jan Haller <bromeon@gmail.com>
Added OS X impl of requestFocus and hasFocus
Signed-off-by: Foaly <foaly.f@web.de>
Signed-off-by: Jan Haller <bromeon@gmail.com>
Changed Window::requestFocus() return type from bool to void
Reasons:
* Consistent with other sf::Window methods
* User can test whether focus succeeded by subsequent hasFocus() call
* Implementation would have to call hasFocus() anyway on some systems

Also: minor code style change in Window::hasFocus()
X11: Notify instead of force focus
Signed-off-by: Jan Haller <bromeon@gmail.com>
@Bromeon

This comment has been minimized.

Show comment
Hide comment
@Bromeon

Bromeon Oct 6, 2014

Member

Thanks, I fixed the protected.

Member

Bromeon commented Oct 6, 2014

Thanks, I fixed the protected.

@eXpl0it3r

This comment has been minimized.

Show comment
Hide comment
@eXpl0it3r

eXpl0it3r Oct 7, 2014

Member

Has been tested again on Windows 8.1 and seems to be fine, thus this PR has been added to my merge list and will be merge soon, unless further concerns are raised.

Member

eXpl0it3r commented Oct 7, 2014

Has been tested again on Windows 8.1 and seems to be fine, thus this PR has been added to my merge list and will be merge soon, unless further concerns are raised.

@mantognini

This comment has been minimized.

Show comment
Hide comment
@mantognini

mantognini Oct 7, 2014

Member

I haven't test it yet. ;)

Member

mantognini commented Oct 7, 2014

I haven't test it yet. ;)

@Bromeon

This comment has been minimized.

Show comment
Hide comment
@Bromeon

Bromeon Oct 7, 2014

Member

Would be nice if somebody could also test Linux :)

Member

Bromeon commented Oct 7, 2014

Would be nice if somebody could also test Linux :)

@TankOs

This comment has been minimized.

Show comment
Hide comment
@TankOs

TankOs Oct 7, 2014

Member

👍 Positive test on Arch Linux.

Member

TankOs commented Oct 7, 2014

👍 Positive test on Arch Linux.

@mantognini

This comment has been minimized.

Show comment
Hide comment
@mantognini

mantognini Oct 7, 2014

Member

Runs fine on OS X too. :-)

Member

mantognini commented Oct 7, 2014

Runs fine on OS X too. :-)

@eXpl0it3r

This comment has been minimized.

Show comment
Hide comment
@eXpl0it3r

eXpl0it3r Oct 9, 2014

Member

This PR will be merge today.

Member

eXpl0it3r commented Oct 9, 2014

This PR will be merge today.

@TankOs

This comment has been minimized.

Show comment
Hide comment
@TankOs

TankOs Oct 9, 2014

Member

Finally, awesome. 👌

Member

TankOs commented Oct 9, 2014

Finally, awesome. 👌

@eXpl0it3r eXpl0it3r merged commit 60c4f95 into master Oct 9, 2014

@eXpl0it3r eXpl0it3r deleted the feature/window_focus branch Oct 9, 2014

@eXpl0it3r

This comment has been minimized.

Show comment
Hide comment
@eXpl0it3r

eXpl0it3r Oct 9, 2014

Member

It is done. ✔️

Member

eXpl0it3r commented Oct 9, 2014

It is done. ✔️

@Foaly

This comment has been minimized.

Show comment
Hide comment
@Foaly

Foaly Oct 9, 2014

Contributor

Wow this is awesome! Thanks to everybody involved!

Contributor

Foaly commented Oct 9, 2014

Wow this is awesome! Thanks to everybody involved!

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