Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Changed SFML API to receive an sf::String as the window title instead of a std::string (in Window::Window and Window::setTitle). - Changed RenderWindow and WindowImpl APIs accordingly. - Changed WindowImplWin32 to use a Unicode window title only if the target OS supports it. - Changed WindowImplCocoa to always use Unicode window titles and added a utility function to Window/OSX/cpp_objc_conversion.mm. - Changed WindowImplX11 to set the Unicode window title as part of the _NET_WM_NAME specification, which sadly is not part of the official X standard, but the closest anything can get. Still set regular ASCII title as fallback.
- Loading branch information
Shiz
committed
Feb 12, 2013
1 parent
9cf259c
commit 6bc0776
Showing
14 changed files
with
71 additions
and
38 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
6bc0776
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.
Aren't these nearly the exact same changes as this?
#174
Not the same, but similar.
6bc0776
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.
Could be but it has the important difference:
While Shizmob's implementation stretches across all the major platform and has been tested.
Sure some critical points Laurent made on the other pull request might have been ignored here.
Anyways what's your goal by pointing towards the similarities? ;)
6bc0776
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 dunno. I'm curious as to why those critical points were ignored here. It seems silly, does it not?
6bc0776
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.
By reading the other comments again there aren't many actual critical points. The following two sentences are very generic and maybe Laurent has already thought about them in more detail, but just didn't have time to get around implementing it:
So unless you know more on what Laurent has thought when accepting the pull request, I guess you can't judge whether the points have been thought about or not.
And again the main difference between the pull requests are, that this one is clean, complete and tested, while the other one was quickly done and incomplete.
I still don't quite get what problem you see here...
6bc0776
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.
Fortunately, I sometimes change my mind so that some features end up being actually implemented ;)
In this case, the other functions that deal with strings are mainly (only?) those which take a filename, and supporting unicode filenames is a different story. The choice of the sf::String class for Unicode strings seems to be the best one with the current API, if something changes it won't happen before SFML 3.
So, right now it seems reasonable and realistic to me to apply this modification.
And yes, a complete and tested code makes a huge difference for integration.