Originally I was writing a message body really long and explanatory,
but the gist is this: there are window flag checking and setting
inconsistencies in SDL_CreateWindow, SDL_MinimizeWindow,
SDL_MaximizeWindow, SDL_RestoreWindow, and various other functions.
Furthermore, fullscreen windows aren’t restored to being fullscreen
when you call SDL_RestoreWindow post call to SDL_MinimizeWindow;
calling SDL_MaximizeWindow and manually refocusing input on a
minimized fullscreen window (as a user) doesn’t do anything to the
fullscreen state (i.e. refocused ‘should be’ fullscreen window is not
fullscreen or an already focused and fullscreen window is not affected
(unlike what happens when SDL_MinimizeWindow is called));
SDL_UpdateFullscreenMode calls SDL_MinimizeWindow on any already
fullscreen window (effects obvious); and SDL_MinimizeWindow,
SDL_MaximizeWindow, and SDL_RestoreWindow among others do not call any
functions to generate window events but SDL_ShowWindow and
SDL_HideWindow do (which might mean the corresponding events aren’t
generated at all when the API calls are making the changes).
That is a lot of text, all of which SDL’s wiki and SDL’s headers do
not mention the subjects of. I noticed all of these things after
investing attempts at tracking a window’s current state in my own
window API (which is layered atop SDL’s) resulting in inconsistent
behavior (due to SDL’s window flags not being set consistently by API
functions). There were other things about SDL too, like how a window
will not be maximized to its maximum size or the size of a largest
maximized window on the window’s current display because it can only
be maximized to the latter (and only when the maximum size is greater
than or equal to the resulting maximized window’s size). That wasn’t
documented in the header or the wiki as well.
I’m afraid to continue implementing a window API atop SDL’s because of
small and very unpredictable details like these which are not
documented and could be fixed silently in the future (and thus
silently break or render redundant any code on my own part meant to
work around SDL’s invisible inconsistencies).
If you submit patches that don’t break anything that’s currently expected to work, I suspect Sam and Ryan would take them. 
JosephSent via mobile
On Jul 5, 2014, at 17:20, Charles Swain wrote:
Originally I was writing a message body really long and explanatory,
but the gist is this: there are window flag checking and setting
inconsistencies in SDL_CreateWindow, SDL_MinimizeWindow,
SDL_MaximizeWindow, SDL_RestoreWindow, and various other functions.
Furthermore, fullscreen windows aren’t restored to being fullscreen
when you call SDL_RestoreWindow post call to SDL_MinimizeWindow;
calling SDL_MaximizeWindow and manually refocusing input on a
minimized fullscreen window (as a user) doesn’t do anything to the
fullscreen state (i.e. refocused ‘should be’ fullscreen window is not
fullscreen or an already focused and fullscreen window is not affected
(unlike what happens when SDL_MinimizeWindow is called));
SDL_UpdateFullscreenMode calls SDL_MinimizeWindow on any already
fullscreen window (effects obvious); and SDL_MinimizeWindow,
SDL_MaximizeWindow, and SDL_RestoreWindow among others do not call any
functions to generate window events but SDL_ShowWindow and
SDL_HideWindow do (which might mean the corresponding events aren’t
generated at all when the API calls are making the changes).
That is a lot of text, all of which SDL’s wiki and SDL’s headers do
not mention the subjects of. I noticed all of these things after
investing attempts at tracking a window’s current state in my own
window API (which is layered atop SDL’s) resulting in inconsistent
behavior (due to SDL’s window flags not being set consistently by API
functions). There were other things about SDL too, like how a window
will not be maximized to its maximum size or the size of a largest
maximized window on the window’s current display because it can only
be maximized to the latter (and only when the maximum size is greater
than or equal to the resulting maximized window’s size). That wasn’t
documented in the header or the wiki as well.
I’m afraid to continue implementing a window API atop SDL’s because of
small and very unpredictable details like these which are not
documented and could be fixed silently in the future (and thus
silently break or render redundant any code on my own part meant to
work around SDL’s invisible inconsistencies).
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
I write documents, not SDL’s source code. Also, can I please get some
input on changing SDL_INIT_NOPARACHUTE’s documentation? After reading
SDL’s source code and testing the behavior of this flag I’ve concluded
it does absolutely nothing and ALL of its documentation in both the
headers and wiki are incorrect, including the migration guide which
says that SDL doesn’t establishes signal handlers anymore (which it
does, for SIGINT and SIGTERM). I’ve tried telling people this on the
documentation mailing list, but that mailing list is a month dead.On 7/5/14, T. Joseph Carter wrote:
If you submit patches that don’t break anything that’s currently expected to
work, I suspect Sam and Ryan would take them.
Joseph
Sent via mobile
On Jul 5, 2014, at 17:20, Charles Swain <@Charles_Swain> wrote:
Originally I was writing a message body really long and explanatory,
but the gist is this: there are window flag checking and setting
inconsistencies in SDL_CreateWindow, SDL_MinimizeWindow,
SDL_MaximizeWindow, SDL_RestoreWindow, and various other functions.
Furthermore, fullscreen windows aren’t restored to being fullscreen
when you call SDL_RestoreWindow post call to SDL_MinimizeWindow;
calling SDL_MaximizeWindow and manually refocusing input on a
minimized fullscreen window (as a user) doesn’t do anything to the
fullscreen state (i.e. refocused ‘should be’ fullscreen window is not
fullscreen or an already focused and fullscreen window is not affected
(unlike what happens when SDL_MinimizeWindow is called));
SDL_UpdateFullscreenMode calls SDL_MinimizeWindow on any already
fullscreen window (effects obvious); and SDL_MinimizeWindow,
SDL_MaximizeWindow, and SDL_RestoreWindow among others do not call any
functions to generate window events but SDL_ShowWindow and
SDL_HideWindow do (which might mean the corresponding events aren’t
generated at all when the API calls are making the changes).
That is a lot of text, all of which SDL’s wiki and SDL’s headers do
not mention the subjects of. I noticed all of these things after
investing attempts at tracking a window’s current state in my own
window API (which is layered atop SDL’s) resulting in inconsistent
behavior (due to SDL’s window flags not being set consistently by API
functions). There were other things about SDL too, like how a window
will not be maximized to its maximum size or the size of a largest
maximized window on the window’s current display because it can only
be maximized to the latter (and only when the maximum size is greater
than or equal to the resulting maximized window’s size). That wasn’t
documented in the header or the wiki as well.
I’m afraid to continue implementing a window API atop SDL’s because of
small and very unpredictable details like these which are not
documented and could be fixed silently in the future (and thus
silently break or render redundant any code on my own part meant to
work around SDL’s invisible inconsistencies).
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
SDL_INIT_NOPARACHUTE SDL_INIT_NOLONGEREXISTS. I think the
constant is still defined for ? reasons, but I don’t know what they
are. SDL.h’s comments are in error.
My vote: Remove it, replace with this on-the-spot “patch”:
— SDL.h.b0rked
+++ SDL.h
@@ -116,3 +116,3 @@
#define SDL_INIT_EVENTS 0x00004000
-#define SDL_INIT_NOPARACHUTE 0x00100000 /*< Don’t catch fatal signals /
+/ SDL_INIT_NOPARACHUTE removed (no longer needed.) /
#define SDL_INIT_EVERYTHING (
@@ -124,7 +124,5 @@
/
-
- This function initializes the subsystems specified by \c flags
-
- This function initializes the subsystems specified by \c flags
-
- Unless the ::SDL_INIT_NOPARACHUTE flag is set, it will install cleanup
-
- signal handlers for some commonly ignored fatal signals (like SIGSEGV).
*/
extern DECLSPEC int SDLCALL SDL_Init(Uint32 flags);
The reason I believe a comment is necessary is because even though it
does nothing, it has existed in 2.x releases. As such, it cannot
just disappear without comment. I didn’t make a proper patch (though
patch(1) may take the above!) because I imagine I didn’t do it the
doxygen way above because I cannot be bothered to take the time to
find out what that is now. Exercise for the reader.
JosephOn Sun, Jul 06, 2014 at 03:28:58PM -0500, Charles Swain wrote:
I write documents, not SDL’s source code. Also, can I please get some
input on changing SDL_INIT_NOPARACHUTE’s documentation? After reading
SDL’s source code and testing the behavior of this flag I’ve concluded
it does absolutely nothing and ALL of its documentation in both the
headers and wiki are incorrect, including the migration guide which
says that SDL doesn’t establishes signal handlers anymore (which it
does, for SIGINT and SIGTERM). I’ve tried telling people this on the
documentation mailing list, but that mailing list is a month dead.
On 7/5/14, T. Joseph Carter <@T_Joseph_Carter> wrote:
If you submit patches that don’t break anything that’s currently expected to
work, I suspect Sam and Ryan would take them.
Joseph
Sent via mobile
On Jul 5, 2014, at 17:20, Charles Swain wrote:
Originally I was writing a message body really long and explanatory,
but the gist is this: there are window flag checking and setting
inconsistencies in SDL_CreateWindow, SDL_MinimizeWindow,
SDL_MaximizeWindow, SDL_RestoreWindow, and various other functions.
Furthermore, fullscreen windows aren’t restored to being fullscreen
when you call SDL_RestoreWindow post call to SDL_MinimizeWindow;
calling SDL_MaximizeWindow and manually refocusing input on a
minimized fullscreen window (as a user) doesn’t do anything to the
fullscreen state (i.e. refocused ‘should be’ fullscreen window is not
fullscreen or an already focused and fullscreen window is not affected
(unlike what happens when SDL_MinimizeWindow is called));
SDL_UpdateFullscreenMode calls SDL_MinimizeWindow on any already
fullscreen window (effects obvious); and SDL_MinimizeWindow,
SDL_MaximizeWindow, and SDL_RestoreWindow among others do not call any
functions to generate window events but SDL_ShowWindow and
SDL_HideWindow do (which might mean the corresponding events aren’t
generated at all when the API calls are making the changes).
That is a lot of text, all of which SDL’s wiki and SDL’s headers do
not mention the subjects of. I noticed all of these things after
investing attempts at tracking a window’s current state in my own
window API (which is layered atop SDL’s) resulting in inconsistent
behavior (due to SDL’s window flags not being set consistently by API
functions). There were other things about SDL too, like how a window
will not be maximized to its maximum size or the size of a largest
maximized window on the window’s current display because it can only
be maximized to the latter (and only when the maximum size is greater
than or equal to the resulting maximized window’s size). That wasn’t
documented in the header or the wiki as well.
I’m afraid to continue implementing a window API atop SDL’s because of
small and very unpredictable details like these which are not
documented and could be fixed silently in the future (and thus
silently break or render redundant any code on my own part meant to
work around SDL’s invisible inconsistencies).
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
As for patching SDL, if you can USE it, you should be able to note
where something doesn’t work as expected and have a look at the
innards. Probably you CAN fix the problem if you work one little
piece at a time. Don’t be afraid to try, you can always revert your
changes if they don’t work. And when you’ve got something that
works, you’re only a hg diff away from a patch submission.
JosephOn Sun, Jul 06, 2014 at 03:28:58PM -0500, Charles Swain wrote:
I write documents, not SDL’s source code. Also, can I please get some
input on changing SDL_INIT_NOPARACHUTE’s documentation? After reading
SDL’s source code and testing the behavior of this flag I’ve concluded
it does absolutely nothing and ALL of its documentation in both the
headers and wiki are incorrect, including the migration guide which
says that SDL doesn’t establishes signal handlers anymore (which it
does, for SIGINT and SIGTERM). I’ve tried telling people this on the
documentation mailing list, but that mailing list is a month dead.
On 7/5/14, T. Joseph Carter <@T_Joseph_Carter> wrote:
If you submit patches that don’t break anything that’s currently expected to
work, I suspect Sam and Ryan would take them.
Joseph
Sent via mobile
On Jul 5, 2014, at 17:20, Charles Swain wrote:
Originally I was writing a message body really long and explanatory,
but the gist is this: there are window flag checking and setting
inconsistencies in SDL_CreateWindow, SDL_MinimizeWindow,
SDL_MaximizeWindow, SDL_RestoreWindow, and various other functions.
Furthermore, fullscreen windows aren’t restored to being fullscreen
when you call SDL_RestoreWindow post call to SDL_MinimizeWindow;
calling SDL_MaximizeWindow and manually refocusing input on a
minimized fullscreen window (as a user) doesn’t do anything to the
fullscreen state (i.e. refocused ‘should be’ fullscreen window is not
fullscreen or an already focused and fullscreen window is not affected
(unlike what happens when SDL_MinimizeWindow is called));
SDL_UpdateFullscreenMode calls SDL_MinimizeWindow on any already
fullscreen window (effects obvious); and SDL_MinimizeWindow,
SDL_MaximizeWindow, and SDL_RestoreWindow among others do not call any
functions to generate window events but SDL_ShowWindow and
SDL_HideWindow do (which might mean the corresponding events aren’t
generated at all when the API calls are making the changes).
That is a lot of text, all of which SDL’s wiki and SDL’s headers do
not mention the subjects of. I noticed all of these things after
investing attempts at tracking a window’s current state in my own
window API (which is layered atop SDL’s) resulting in inconsistent
behavior (due to SDL’s window flags not being set consistently by API
functions). There were other things about SDL too, like how a window
will not be maximized to its maximum size or the size of a largest
maximized window on the window’s current display because it can only
be maximized to the latter (and only when the maximum size is greater
than or equal to the resulting maximized window’s size). That wasn’t
documented in the header or the wiki as well.
I’m afraid to continue implementing a window API atop SDL’s because of
small and very unpredictable details like these which are not
documented and could be fixed silently in the future (and thus
silently break or render redundant any code on my own part meant to
work around SDL’s invisible inconsistencies).
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
2014-07-06 21:48 GMT-03:00, T. Joseph Carter :
SDL_INIT_NOPARACHUTE SDL_INIT_NOLONGEREXISTS. I think the
constant is still defined for ? reasons, but I don’t know what they
are. SDL.h’s comments are in error.
[…]
The reason I believe a comment is necessary is because even though it
does nothing, it has existed in 2.x releases. As such, it cannot
just disappear without comment.
It having existed in previous 2.x releases is precisely why it’s still
around. Remove the constant and you’ll break building programs made
for an earlier version of SDL 2 (leaving it as a no-op is not much of
a problem because SDL will just ignore the flag and the program will
move on happily).
I suppose you could have a #define flag that actively prevents old
constants and such from being used at all, but you still need to
retain that stuff if you want to keep backwards compatibility working.
Ah, good point. The flag’s value cannot be reused without an API
breakage as the flag would possibly be specified by SDL 2.x apps
until the ABI is changed, which won’t happen within the scope of SDL
2.x.
I’m still in favor of removing SDL_INIT_NOPARACHUTE from the source,
even if it’s replaced with SDL_INIT_UNUSABLE_2X or something with a
comment indicating it was formerly SDL_INIT_NOPARACHUTE. Replaces
one bit of unused cruft with another?but at least it’s self-labeling
cruft that can be removed when the ABI changes.
JosephOn Sun, Jul 06, 2014 at 11:32:02PM -0300, Sik the hedgehog wrote:
2014-07-06 21:48 GMT-03:00, T. Joseph Carter <@T_Joseph_Carter>:
SDL_INIT_NOPARACHUTE SDL_INIT_NOLONGEREXISTS. I think the
constant is still defined for ? reasons, but I don’t know what they
are. SDL.h’s comments are in error.
[…]
The reason I believe a comment is necessary is because even though it
does nothing, it has existed in 2.x releases. As such, it cannot
just disappear without comment.
It having existed in previous 2.x releases is precisely why it’s still
around. Remove the constant and you’ll break building programs made
for an earlier version of SDL 2 (leaving it as a no-op is not much of
a problem because SDL will just ignore the flag and the program will
move on happily).
I suppose you could have a #define flag that actively prevents old
constants and such from being used at all, but you still need to
retain that stuff if you want to keep backwards compatibility working.
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
2014-07-06 23:50 GMT-03:00, T. Joseph Carter :
I’m still in favor of removing SDL_INIT_NOPARACHUTE from the source,
even if it’s replaced with SDL_INIT_UNUSABLE_2X or something with a
comment indicating it was formerly SDL_INIT_NOPARACHUTE. Replaces
one bit of unused cruft with another?but at least it’s self-labeling
cruft that can be removed when the ABI changes.
You have absolutely no idea against which version of SDL2 a program
was written for, and that’ll trigger a compiler error that a random
user trying to build it most likely would have no idea about. So
removing it will still cause problems (not as bad as ABI breakage, but
still brings some problems).
That’s why I suggested the #define thing, that makes it easier to
prevent use of deprecated functionality without leaving programs in a
state that they may need to be rewritten (the idea can even be used to
prevent old functions from being used as soon as better replacements
are introduced). If the program suddenly won’t build, just change the
#define. I think Allegro has something like this.
I haven’t worked with Mercurial in awhile, so I’ll need to relearn things.
Also, main point shouldn’t be changing how that flag is defined but
what the documentation says (so we aren’t lying to users).
Also, I looked at SDL.h’s comment for SDL_Init and it looks like a
highly butchered version of SDL 1.2’s comment for SDL_Init.On 7/6/14, Sik the hedgehog <sik.the.hedgehog at gmail.com> wrote:
2014-07-06 23:50 GMT-03:00, T. Joseph Carter :
I’m still in favor of removing SDL_INIT_NOPARACHUTE from the source,
even if it’s replaced with SDL_INIT_UNUSABLE_2X or something with a
comment indicating it was formerly SDL_INIT_NOPARACHUTE. Replaces
one bit of unused cruft with another?but at least it’s self-labeling
cruft that can be removed when the ABI changes.
You have absolutely no idea against which version of SDL2 a program
was written for, and that’ll trigger a compiler error that a random
user trying to build it most likely would have no idea about. So
removing it will still cause problems (not as bad as ABI breakage, but
still brings some problems).
That’s why I suggested the #define thing, that makes it easier to
prevent use of deprecated functionality without leaving programs in a
state that they may need to be rewritten (the idea can even be used to
prevent old functions from being used as soon as better replacements
are introduced). If the program suddenly won’t build, just change the
#define. I think Allegro has something like this.
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Also, main point shouldn’t be changing how that flag is defined but
what the documentation says (so we aren’t lying to users).
I just changed this in the source code (haven’t checked the wiki)…
https://hg.libsdl.org/SDL/rev/c6398920a9ca
–ryan.