-
Notifications
You must be signed in to change notification settings - Fork 482
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
Implement sdl2::hint::video_minimize_on_focus_lost #639
Implement sdl2::hint::video_minimize_on_focus_lost #639
Conversation
src/sdl2/hint.rs
Outdated
/// - `false`: do not minimize the SDL_Window if it loses key focus when in fullscreen mode | ||
/// | ||
/// [Official SDL documentation](https://wiki.libsdl.org/SDL_HINT_VIDEO_MINIMIZE_ON_FOCUS_LOSS) | ||
pub fn video_minimize_on_focus_lost(value: bool) -> bool { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you want value
renamed to something like should_minimize
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As long as you can precisely which value does what, I'm fine with both. If there isn't any ambiguity like "I don't know if true or false actually enables the hint that I want to use because there is 'DISABLE' in the name" (I don't know if there is any actual hint like that, but just as an example). If there is no room for ambiguity, it's fine by me.
src/sdl2/hint.rs
Outdated
/// Sets the SDL_HINT_VIDEO_MINIMIZE_ON_FOCUS_LOSS hint. | ||
/// | ||
/// # Default | ||
/// By default a SDL_Window is minimized if it loses key focus when in fullscreen mode. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you want each SDL_Window
to be a link to the SDL_Window struct docs?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You don't have to. One link to the official document is enough, users are expected to go look at the official SDL2 documentation if they need additional information.
src/sdl2/hint.rs
Outdated
@@ -3,6 +3,27 @@ use sys::hint as ll; | |||
use std::ptr; | |||
use libc::c_char; | |||
|
|||
const VIDEO_MINIMIZE_ON_FOCUS_LOST: &'static str = "SDL_VIDEO_MINIMIZE_ON_FOCUS_LOST"; | |||
|
|||
/// Sets the SDL_HINT_VIDEO_MINIMIZE_ON_FOCUS_LOSS hint. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this be just SDL_HINT_VIDEO_MINIMIZE_ON_FOCUS_LOSS
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How about A hint that specifies if a SDL_Window is minimized if it loses key focus when in fullscreen mode.
(directly from sdl's docs)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How about A hint that specifies if a SDL_Window is minimized if it loses key focus when in fullscreen mode. (directly from sdl's docs)?
Perfect
I've never written a macro but the simple "1"/"0" hints ought to be a good candidate for a Opinions? |
Definitely, but make sure the macro cannot only be seen from within sdl2::hint and nowhere else |
src/sdl2/hint.rs
Outdated
/// | ||
/// * `value`: | ||
/// - `true`: do minimize the SDL_Window if it loses key focus when in fullscreen mode | ||
/// - `false`: do not minimize the SDL_Window if it loses key focus when in fullscreen mode |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You don't have to repeat yourself or enumerate every value like that, this would have been enough :
/// * `value`: `true` to enable minimizing of the Window if it loses key focus when in fullscreen mode , `false` to disable this feature. Defaults to X
If it has a default value (and it is explicitly said in the SDL2 documentation), it would be nice to include what is the default value as well.
By the way, you don't have to say SDL_Window
instead of Window
when the equivalence is this obvious.
@Cobrand Please take another look. |
Thinking about this a little more... do you think people would benefit from us implementing a Assuming we can make all of the hints typesafe and take the individual get/set approach I don't see any gain in exposing |
|
Updated, please review again. I'm sorry we're going back and forth over and over -- I believe this revision should be all that is necessary functionally. The documentation is quite repetitive though so if you want that redone a particular way just let me know. This patch allows me to change some game code like so: diff --git a/crates/media/src/renderer.rs b/crates/media/src/renderer.rs
index b7f9bee..6f98b78 100644
--- a/crates/media/src/renderer.rs
+++ b/crates/media/src/renderer.rs
@@ -57,7 +57,7 @@ impl Renderer {
#[cfg(target_os="macos")]
{ builder.position(0, 0); }
- sdl2::hint::set("SDL_VIDEO_MINIMIZE_ON_FOCUS_LOSS", "0");
+ sdl2::hint::set_video_minimize_on_focus_lost(false);
} else {
builder.resizable();
} |
pub fn get_video_minimize_on_focus_lost() -> bool { | ||
match get(VIDEO_MINIMIZE_ON_FOCUS_LOST) { | ||
Some(value) => match &*value { | ||
"1" => true, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I deliberately chose to map anything non-"1"
to false because a consumer could set a hint to "foobar"
if they wanted to for whatever reason but, AFAIK, that will not enable the feature (ignoring the default of being enabled for this particular hint).
Build failed because of docs. |
The 'set_with_priority' is kind of verbose, how about merging both 'set_*' into one which takes What do you think ? |
I agree with your observation that the priority-variant is overly verbose. Reasons I see for not going the
Counter points:
I do not have a counter point for 3 and because of that I think using |
Good point for Hint::Default. It's still a hassle because you have to look up Hint to know which variant should be used by default while with Option it would instantly make sense if you read the documentation of any of the set_hint function.
Anyway you can keep it like this or make every function take value & hint as parameters, it's up to you, I'm fine with either one. Two functions for each is kind of verbose but it can't be helped I guess.
…On Apr 19, 2017, 16:25, at 16:25, Taryn Hill ***@***.***> wrote:
Reasons I see for not going the `Option<Hint>` route:
1) `sdl2::hint::set_video_minimize_on_focus_lost(false)` would become
`sdl2::hint::set_video_minimize_on_focus_lost(false, None)` to get the
same behavior that users would probably expect from the option-less
form.
2) When someone with SDL2 knowledge reads
`sdl2::hint::set_video_minimize_on_focus_lost(false, None)` they will
be forced to look up documentation while thinking "What could possibly
be none/nullable here? Is this actually optional or was this made
optional to create a smaller API surface?" instead of instantly
understanding what is happening here.
3) Instead of using `Option<Hint>` we should just use `Hint` because
`Hint::Default` exists.
Counter points:
1) Users should be reading the docs already and (eventually) tooling
will make this easier (IDE suggestions, etc)
2) We are already deviating from / adding on to SDL2 by introducing
these functions so pre-existing knowledge isn't a good argument.
I do not have a counter point for 3 and because of that I think using
`Option` here as a shortcut for `Hint::Default` isn't a good idea.
--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
#639 (comment)
|
I'll leave it as-is then and hope this won't become a pain point or irritation for users. Do you have an opinions regarding the documentation? If not this is ready to merge if desired. |
Merged, thanks again ! |
Awesome, thank you! |
Let's decide on documentation, namespacing, etc for a single function before diving into a ton of more complex hints.