OS X improvement: warnings + bugfix + refactoring, the lot!

[mantognini]

This PR fixes the warnings detected by static analyser regarding OS X, as well as clang's warning for regular build. That is, it replaces deprecated setColor for sf::Text, fixes a bit the documentation in one place, removes #warning that are anyway useless, replaces some deprecated Cocoa feature with newer ones (10.7+) and uses static_cast instead of C-cast where appropriate.

It also improves desktop/fullscreen modes detection for 10.8+ as explained in this comment and how they are handled when creating a fullscreen view.

Furthermore, it importantly refactors SFOpenGLView and splits this monolithic implementation into several files to make it manageable by human being. This way I can implement #614 correctly (already did, actually!)

In addition to all that, it fixes a bug related to fullscreen mode: when resizing a fullscreen window, the fullscreen mode was completely broken.

Finally, in order to anticipates some refactoring for #827: NSImage can now be easily created from raw pixel data.

NB: the branch is still named osx_warning but its content is significantly more important than just fixing warning. I didn't rename it as I don't know how GitHub will react...

[mantognini]

Actually... there's a bug in there. 😩 I'm currently working on some refactoring (to grab the cursor maybe more elegantly) so I'll update this PR when the refactoring is done and the bug fixed.

[louis-langholtz]

improves desktop size detection for 10.8+ as explained in this comment.

Does the iOS code need a similar change perhaps?

I've noticed with the latest master branch code (that I've built for iOS) that on orientation change the resize event is fired and its data shows width and height values that are twice what sf::RenderWindow::getSize() returned (at least right after the sf::RenderWindow construction returns). It's like the initial getSize() call returned values in points and the resize event has values in pixels and where there are two pixels per point.

It would be preferable for these width/height values to be consistently in the same units and for those units to always be in pixels.

[mantognini]

Does the iOS code need a similar change perhaps?

The related code is heavily different so I don't think so. But there might be some inconsistency with backing factor somewhere -- this thing is a nightmare at least on OS X for SFML.

[mantognini]

I just updated the description of this PR as it now includes a few more thing. Testing/feedback welcome!

[louis-langholtz]

Opened an issue for the problem I’d mentioned. Also wrote a fix and made a pull request for those changes: Bug: iOS orientation change handling re-scales window size by backingScaleFactor #1049. Hope this helps at least on the iOS side of things then.

On Jan 26, 2016, at 1:12 PM, Marco Antognini notifications@github.com wrote:

Does the iOS code need a similar change perhaps?

The related code is heavily different so I don't think so. But there might be some inconsistency with backing factor somewhere -- this thing is a nightmare at least on OS X for SFML.

—
Reply to this email directly or view it on GitHub #1042 (comment).

[eXpl0it3r]

The OpenGL example and Glsl.inl fixes are not really OS X specific, but I guess that doesn't really matter. 😉

Would be great if some other OS X users could test this.

[mantognini]

The OpenGL example and Glsl.inl fixes are not really OS X specific

No, absolutely not. Even more reasons to check this PR! :-)

(I've put it in here because it calms down BuildBot.)

[Bromeon]

Why this change? It doesn't add information, just makes the documentation more verbose. Now the parameter descriptions are even identical for all four parameters.

[eXpl0it3r]

Does Doxygen allow to document multiple parameter in one line?

[Bromeon]

Yes, the official documentation even uses a x,y,z example, so using a single \param here seems pretty appropriate ;)

[mantognini]

Interestingly clang doesn't like it and emit a warning.

[Bromeon]

clang bugreport! 😛

[Bromeon]

As a side note, I'm personally a big fan of keeping things concise, including documentation. It's amazing how people write stuff like

/**
 * Checks if the object is stored.
 * 
 * @param object Object that is checked.
 * @return true if the object is stored, false otherwise.
 */
boolean containsObject(Object object) { ... }

where the method name alone would contain 100% of the documentation's information, just to fit in some questionable document-everything-strictly policy. The only thing it does is becoming outdated at the next refactoring. 😉

SFML contains quite a few such places, even if not that extreme. It's not something we have to adapt now that the documentation is already written, but I would not force currently concise documentation to the same level of verbosity, either.

[mantognini]

clang bugreport!

Technically, I would need to go through Apple's bug report system as they modify clang for their needs... But you're right -- and I totally agree on the readability/conciseness part. However, last time I used it, it took them two years to answer my bug report. In the meantime, let's have a happy BuildBot report, shall we? 😄

[eXpl0it3r]

So will you adjust the docs?
Do you think you'll find more testers or can I add this to the merge list?

[mantognini]

So will you adjust the docs?

I'd leave the commit as-is to get a clean build bot feedback. When the missing feature from clang is added, we can always change it back.

Do you think you'll find more testers or can I add this to the merge list?

We have two choice here: a) assume I do my job right and merge it, or b) put pressure on the community until testers show up. Besides me, who would be in favor of b) -- I cannot stress enough how much I'd love to see more good contributions for OS X from the community.

[eXpl0it3r]

Since we've still not found more testers, do you thin we should go ahead and merge it?

Currently there seems to be merge conflicts, so a rebase would be nice.

[mantognini]

I could update this and include a "fix" for #1006 (i.e. dropping support for 32 bits), then we could indeed merge it so that #614 & #827 can move on as well.

[eXpl0it3r]

👍

[mantognini]

Rebased and updated (dropping 32-bit support)

[eXpl0it3r]

This PR has been added to my merge list, meaning it will be merged soon, unless someone raises any concerns.