in my engine at startup. Any other behavior (under X11) makes absolutely
no sense to me.
The priority system will then still allow the users to set their
preference with the environment variable. Hopefully, developers don’t
do something stupid and block the users there.
The priority system lets programs override the environment variables.
And yes, this can make sense: if you provide the ability to change the
setting through the program’s usual UI, you don’t want environment
variables to interfere with it.
2013/11/7, Norfanin :> Sik the hedgehog wrote:
Don’t forget programs can override the hints. You could easily do that
to by-pass the environment variables.
in my engine at startup. Any other behavior (under X11) makes absolutely
no sense to me.
The priority system will then still allow the users to set their
preference with the environment variable. Hopefully, developers don’t
do something stupid and block the users there.
The priority system lets programs override the environment variables.
And yes, this can make sense: if you provide the ability to change the
setting through the program’s usual UI, you don’t want environment
variables to interfere with it.
Sure. If the application allows to change the setting, then the user
doesn’t have to go through the environment variable. However, future
versions of SDL might add another setting to a hint and the
application using the override priority would then block it.
More work for the developers to make it easier for the users.
I agree, minimize on focus lost is a big PITA on X11. It’s not only SDL
based programs that do this (Chrome comes to mind, when you are viewing a
video full screen on Linux, if you click on a different window on another
monitor, the full screen window just goes out to windowed mode again).
I think the solution might be in finding something of a compromise…let’s
say, if a user hits alt-tab, the intention is probably to minimize the full
screen window (at least on single monitor systems). But if we lost focus
just for a volume up key and minimize then…that’s just completely counter
intuitive.
2013/11/7 Alex Szpakowski > My 2c on the OS X side of things:
I completely disable SDL?s minimize-on-focus-loss in OS X because the rest
of the operating system doesn?t work like that: fullscreen windows either
stay in the background when focus is lost or have their own unique Space
(OS 10.7+), although windows can still be minimized manually. All OS X
programs also have the capability to hide themselves completely (which is
different from minimizing an individual window), via the menubar or a
hotkey.
When a window in a program is minimized, it creates a new icon for the
window in the dock separate from the actual program - it?s very very rare
for an OS X program to minimize one of its windows without the user
explicitly pressing a button to do so.
Expos? and Spaces also take away some of the usefulness of minimizing
individual windows, since they provide (imo) better functionality for some
of the cases where one might?ve wanted a window to be minimized.
On Nov 7, 2013, at 3:12 PM, Andre D wrote:
I have a huge problem with games which do this on multiple monitor
platforms, I don’t expect the game to go minimal when I select
something in a different window for an example.
On Thu, Nov 7, 2013 at 2:10 PM, Sam Lantinga wrote:
Because they often don’t. On Windows, for example, if you lose focus,
you
just get a fullscreen windiow in the background.
Maybe this logic needs to not be generic for all platforms, but have
each
platform know when it should minimize or not? Can we even tell what the
right behavior is under X11?
On Thu, Nov 7, 2013 at 10:48 AM, Andre D wrote:
Why minimise on focus lost? Should the window manager not be handling
that
On Nov 7, 2013 11:44 AM, “Ryan C. Gordon” wrote:
Just to add that on Linux (ubuntu 12.04 with “classic gnome”) the
behaviour of ALT-TAB is correct:
It’s worth noting, too, that on Ubuntu 12.04 with Unity, hitting the
volume key on your keyboard will make your fullscreen window vanish
(as it
minimizes to the dock when the volume control notification thing pops
up
over the window).
It’s really harsh. I’m thinking this is not the best way for X11 to
work,
and it’s the minimize-on-focus-lost behavior that causes it.
Yeah, unfortunately we have absolutely no way of distinguishing between
these two cases. All we know is that we lost focus, not why we lost focus.
Unless someone has a great idea on that …? :)On Thu, Nov 7, 2013 at 2:04 PM, Gabriel Jacobo wrote:
I agree, minimize on focus lost is a big PITA on X11. It’s not only SDL
based programs that do this (Chrome comes to mind, when you are viewing a
video full screen on Linux, if you click on a different window on another
monitor, the full screen window just goes out to windowed mode again).
I think the solution might be in finding something of a compromise…let’s
say, if a user hits alt-tab, the intention is probably to minimize the full
screen window (at least on single monitor systems). But if we lost focus
just for a volume up key and minimize then…that’s just completely counter
intuitive.
2013/11/7 Alex Szpakowski
My 2c on the OS X side of things:
I completely disable SDL?s minimize-on-focus-loss in OS X because the
rest of the operating system doesn?t work like that: fullscreen windows
either stay in the background when focus is lost or have their own unique
Space (OS 10.7+), although windows can still be minimized manually. All OS
X programs also have the capability to hide themselves completely (which is
different from minimizing an individual window), via the menubar or a
hotkey.
When a window in a program is minimized, it creates a new icon for the
window in the dock separate from the actual program - it?s very very rare
for an OS X program to minimize one of its windows without the user
explicitly pressing a button to do so.
Expos? and Spaces also take away some of the usefulness of minimizing
individual windows, since they provide (imo) better functionality for some
of the cases where one might?ve wanted a window to be minimized.
On Nov 7, 2013, at 3:12 PM, Andre D wrote:
I have a huge problem with games which do this on multiple monitor
platforms, I don’t expect the game to go minimal when I select
something in a different window for an example.
On Thu, Nov 7, 2013 at 2:10 PM, Sam Lantinga <@slouken> wrote:
Because they often don’t. On Windows, for example, if you lose focus,
you
just get a fullscreen windiow in the background.
Maybe this logic needs to not be generic for all platforms, but have
each
platform know when it should minimize or not? Can we even tell what
the
right behavior is under X11?
On Thu, Nov 7, 2013 at 10:48 AM, Andre D wrote:
Why minimise on focus lost? Should the window manager not be handling
that
On Nov 7, 2013 11:44 AM, “Ryan C. Gordon” wrote:
Just to add that on Linux (ubuntu 12.04 with “classic gnome”) the
behaviour of ALT-TAB is correct:
It’s worth noting, too, that on Ubuntu 12.04 with Unity, hitting the
volume key on your keyboard will make your fullscreen window vanish
(as it
minimizes to the dock when the volume control notification thing
pops up
over the window).
It’s really harsh. I’m thinking this is not the best way for X11 to
work,
and it’s the minimize-on-focus-lost behavior that causes it.
See if you can catch the key event before losing focus? Then at least
you can try to guess why you lost focus in some cases (e.g. if you get
the volume key event before the volume window comes up, you can safely
assume that losing focus immediately after was the result of that).
I doubt this will work though, I imagine you lose focus without ever
receiving the key event
2013/11/7, Sam Lantinga :> Yeah, unfortunately we have absolutely no way of distinguishing between
these two cases. All we know is that we lost focus, not why we lost focus.
Unless someone has a great idea on that …?
On Thu, Nov 7, 2013 at 2:04 PM, Gabriel Jacobo wrote:
I agree, minimize on focus lost is a big PITA on X11. It’s not only SDL
based programs that do this (Chrome comes to mind, when you are viewing a
video full screen on Linux, if you click on a different window on another
monitor, the full screen window just goes out to windowed mode again).
I think the solution might be in finding something of a
compromise…let’s
say, if a user hits alt-tab, the intention is probably to minimize the
full
screen window (at least on single monitor systems). But if we lost focus
just for a volume up key and minimize then…that’s just completely
counter
intuitive.
2013/11/7 Alex Szpakowski
My 2c on the OS X side of things:
I completely disable SDL?s minimize-on-focus-loss in OS X because the
rest of the operating system doesn?t work like that: fullscreen windows
either stay in the background when focus is lost or have their own
unique
Space (OS 10.7+), although windows can still be minimized manually. All
OS
X programs also have the capability to hide themselves completely (which
is
different from minimizing an individual window), via the menubar or a
hotkey.
When a window in a program is minimized, it creates a new icon for the
window in the dock separate from the actual program - it?s very very
rare
for an OS X program to minimize one of its windows without the user
explicitly pressing a button to do so.
Expos? and Spaces also take away some of the usefulness of minimizing
individual windows, since they provide (imo) better functionality for
some
of the cases where one might?ve wanted a window to be minimized.
On Nov 7, 2013, at 3:12 PM, Andre D wrote:
I have a huge problem with games which do this on multiple monitor
platforms, I don’t expect the game to go minimal when I select
something in a different window for an example.
On Thu, Nov 7, 2013 at 2:10 PM, Sam Lantinga wrote:
Because they often don’t. On Windows, for example, if you lose
focus,
you
just get a fullscreen windiow in the background.
Maybe this logic needs to not be generic for all platforms, but have
each
platform know when it should minimize or not? Can we even tell what
the
right behavior is under X11?
On Thu, Nov 7, 2013 at 10:48 AM, Andre D wrote:
Why minimise on focus lost? Should the window manager not be
handling
that
On Nov 7, 2013 11:44 AM, “Ryan C. Gordon” wrote:
Just to add that on Linux (ubuntu 12.04 with “classic gnome”) the
behaviour of ALT-TAB is correct:
It’s worth noting, too, that on Ubuntu 12.04 with Unity, hitting
the
volume key on your keyboard will make your fullscreen window vanish
(as it
minimizes to the dock when the volume control notification thing
pops up
over the window).
It’s really harsh. I’m thinking this is not the best way for X11 to
work,
and it’s the minimize-on-focus-lost behavior that causes it.
It seems the guys at Mozilla figured it out: https://bugzilla.mozilla.org/show_bug.cgi?id=578265
El nov 7, 2013 10:28 p.m., “Sam Lantinga” escribi?:> Yeah, unfortunately we have absolutely no way of distinguishing between
these two cases. All we know is that we lost focus, not why we lost focus.
Unless someone has a great idea on that …?
On Thu, Nov 7, 2013 at 2:04 PM, Gabriel Jacobo <@Gabriel_Jacobo> wrote:
I agree, minimize on focus lost is a big PITA on X11. It’s not only SDL
based programs that do this (Chrome comes to mind, when you are viewing a
video full screen on Linux, if you click on a different window on another
monitor, the full screen window just goes out to windowed mode again).
I think the solution might be in finding something of a
compromise…let’s say, if a user hits alt-tab, the intention is probably
to minimize the full screen window (at least on single monitor systems).
But if we lost focus just for a volume up key and minimize then…that’s
just completely counter intuitive.
2013/11/7 Alex Szpakowski
My 2c on the OS X side of things:
I completely disable SDL?s minimize-on-focus-loss in OS X because the
rest of the operating system doesn?t work like that: fullscreen windows
either stay in the background when focus is lost or have their own unique
Space (OS 10.7+), although windows can still be minimized manually. All OS
X programs also have the capability to hide themselves completely (which is
different from minimizing an individual window), via the menubar or a
hotkey.
When a window in a program is minimized, it creates a new icon for the
window in the dock separate from the actual program - it?s very very rare
for an OS X program to minimize one of its windows without the user
explicitly pressing a button to do so.
Expos? and Spaces also take away some of the usefulness of minimizing
individual windows, since they provide (imo) better functionality for some
of the cases where one might?ve wanted a window to be minimized.
On Nov 7, 2013, at 3:12 PM, Andre D wrote:
I have a huge problem with games which do this on multiple monitor
platforms, I don’t expect the game to go minimal when I select
something in a different window for an example.
On Thu, Nov 7, 2013 at 2:10 PM, Sam Lantinga wrote:
Because they often don’t. On Windows, for example, if you lose
focus, you
just get a fullscreen windiow in the background.
Maybe this logic needs to not be generic for all platforms, but have
each
platform know when it should minimize or not? Can we even tell what
the
right behavior is under X11?
On Thu, Nov 7, 2013 at 10:48 AM, Andre D wrote:
Why minimise on focus lost? Should the window manager not be
handling that
On Nov 7, 2013 11:44 AM, “Ryan C. Gordon” wrote:
Just to add that on Linux (ubuntu 12.04 with “classic gnome”) the
behaviour of ALT-TAB is correct:
It’s worth noting, too, that on Ubuntu 12.04 with Unity, hitting the
volume key on your keyboard will make your fullscreen window vanish
(as it
minimizes to the dock when the volume control notification thing
pops up
over the window).
It’s really harsh. I’m thinking this is not the best way for X11 to
work,
and it’s the minimize-on-focus-lost behavior that causes it.
May as well say the same about just everything in SDL that could be
considered a setting, really.
2013/11/7, Norfanin :> Sik the hedgehog wrote:
The priority system lets programs override the environment variables.
And yes, this can make sense: if you provide the ability to change the
setting through the program’s usual UI, you don’t want environment
variables to interfere with it.
Sure. If the application allows to change the setting, then the user
doesn’t have to go through the environment variable. However, future
versions of SDL might add another setting to a hint and the
application using the override priority would then block it.
More work for the developers to make it easier for the users.
Yeah, unfortunately we have absolutely no way of distinguishing between
these two cases. All we know is that we lost focus, not why we lost
focus.
Unless someone has a great idea on that …?
On Thu, Nov 7, 2013 at 2:04 PM, Gabriel Jacobo wrote:
I agree, minimize on focus lost is a big PITA on X11. It’s not only SDL
based programs that do this (Chrome comes to mind, when you are viewing
a
video full screen on Linux, if you click on a different window on
another
monitor, the full screen window just goes out to windowed mode again).
I think the solution might be in finding something of a
compromise…let’s say, if a user hits alt-tab, the intention is
probably
to minimize the full screen window (at least on single monitor systems).
But if we lost focus just for a volume up key and minimize then…that’s
just completely counter intuitive.
2013/11/7 Alex Szpakowski
My 2c on the OS X side of things:
I completely disable SDL?s minimize-on-focus-loss in OS X because the
rest of the operating system doesn?t work like that: fullscreen windows
either stay in the background when focus is lost or have their own
unique
Space (OS 10.7+), although windows can still be minimized manually. All
OS
X programs also have the capability to hide themselves completely (which
is
different from minimizing an individual window), via the menubar or a
hotkey.
When a window in a program is minimized, it creates a new icon for the
window in the dock separate from the actual program - it?s very very
rare
for an OS X program to minimize one of its windows without the user
explicitly pressing a button to do so.
Expos? and Spaces also take away some of the usefulness of minimizing
individual windows, since they provide (imo) better functionality for
some
of the cases where one might?ve wanted a window to be minimized.
On Nov 7, 2013, at 3:12 PM, Andre D wrote:
I have a huge problem with games which do this on multiple monitor
platforms, I don’t expect the game to go minimal when I select
something in a different window for an example.
On Thu, Nov 7, 2013 at 2:10 PM, Sam Lantinga wrote:
Because they often don’t. On Windows, for example, if you lose
focus, you
just get a fullscreen windiow in the background.
Maybe this logic needs to not be generic for all platforms, but have
each
platform know when it should minimize or not? Can we even tell what
the
right behavior is under X11?
On Thu, Nov 7, 2013 at 10:48 AM, Andre D wrote:
Why minimise on focus lost? Should the window manager not be
handling that
On Nov 7, 2013 11:44 AM, “Ryan C. Gordon” wrote:
Just to add that on Linux (ubuntu 12.04 with “classic gnome”) the
behaviour of ALT-TAB is correct:
It’s worth noting, too, that on Ubuntu 12.04 with Unity, hitting
the
volume key on your keyboard will make your fullscreen window
vanish
(as it
minimizes to the dock when the volume control notification thing
pops up
over the window).
It’s really harsh. I’m thinking this is not the best way for X11
to
work,
and it’s the minimize-on-focus-lost behavior that causes it.
Yeah, unfortunately we have absolutely no way of distinguishing between
these two cases. All we know is that we lost focus, not why we lost focus.
Unless someone has a great idea on that …?
On Thu, Nov 7, 2013 at 2:04 PM, Gabriel Jacobo wrote:
I agree, minimize on focus lost is a big PITA on X11. It’s not only SDL
based programs that do this (Chrome comes to mind, when you are viewing a
video full screen on Linux, if you click on a different window on another
monitor, the full screen window just goes out to windowed mode again).
I think the solution might be in finding something of a
compromise…let’s say, if a user hits alt-tab, the intention is probably
to minimize the full screen window (at least on single monitor systems).
But if we lost focus just for a volume up key and minimize then…that’s
just completely counter intuitive.
2013/11/7 Alex Szpakowski
My 2c on the OS X side of things:
I completely disable SDL?s minimize-on-focus-loss in OS X because the
rest of the operating system doesn?t work like that: fullscreen windows
either stay in the background when focus is lost or have their own unique
Space (OS 10.7+), although windows can still be minimized manually. All OS
X programs also have the capability to hide themselves completely (which is
different from minimizing an individual window), via the menubar or a
hotkey.
When a window in a program is minimized, it creates a new icon for the
window in the dock separate from the actual program - it?s very very rare
for an OS X program to minimize one of its windows without the user
explicitly pressing a button to do so.
Expos? and Spaces also take away some of the usefulness of minimizing
individual windows, since they provide (imo) better functionality for some
of the cases where one might?ve wanted a window to be minimized.
On Nov 7, 2013, at 3:12 PM, Andre D wrote:
I have a huge problem with games which do this on multiple monitor
platforms, I don’t expect the game to go minimal when I select
something in a different window for an example.
On Thu, Nov 7, 2013 at 2:10 PM, Sam Lantinga <@slouken> wrote:
Because they often don’t. On Windows, for example, if you lose
focus, you
just get a fullscreen windiow in the background.
Maybe this logic needs to not be generic for all platforms, but have
each
platform know when it should minimize or not? Can we even tell what
the
right behavior is under X11?
On Thu, Nov 7, 2013 at 10:48 AM, Andre D wrote:
Why minimise on focus lost? Should the window manager not be
handling that
On Nov 7, 2013 11:44 AM, “Ryan C. Gordon” wrote:
Just to add that on Linux (ubuntu 12.04 with “classic gnome”) the
behaviour of ALT-TAB is correct:
It’s worth noting, too, that on Ubuntu 12.04 with Unity, hitting
the
volume key on your keyboard will make your fullscreen window
vanish (as it
minimizes to the dock when the volume control notification thing
pops up
over the window).
It’s really harsh. I’m thinking this is not the best way for X11
to work,
and it’s the minimize-on-focus-lost behavior that causes it.
