Unicode window title (Only implemented in X11 so far) #174
Conversation
|
Thanks again for your help. But I'm not really interested in partial implementations. For this task, the main point is to have a good overall design: there are probably other classes/functions that deal with strings and would benefit from Unicode strings. I need to find a global way of handling them in SFML. Then, is sf::String the best solution? Then, before implementing anything, I need to make sure that every OS can support this feature. Implementation is the very last step, and to be honest, not the most difficult one. It's just a matter of finding the right function in the OS API. |
|
You have to start somewhere? According to what I can find, Windows supports UTF-16 window titles, I'm not sure about Mac OS X. You can't just not have Unicode support. Partial is better than none in my humble opinion. |
I will add Unicode support, as this issue (that you created) implies:
I partially agree ;) |
|
Ah. I understand. I wouldn't say this is quick and dirty though. sf::String supports Unicode, and having a method that takes sf::String seems to be the right way to do things. At least from what I can see. |
|
Just a quick thought, if there for example isn't supported on OS X. Cant sf::String then have a type of fallback mode to not use it there? Just wondering because there probably will be some stuff that will only work on one or two os, will it then be dropped everywhere? |
|
It'd probably be wise to convert sf::String via ToAnsiString and pass it to the normal setTitle in that case. |
You haven't modified the constructor, and you've kept the std::string version which is useless if there's a sf::String one. So to me this is quick and dirty: you added what you needed, without thinking about the feature more deeply, and try to integrate it smartly into the existing API. |
|
I originally did modified SetTitle to interpret std::string as UTF-8, keeping ASCII support and adding Unicode support. But I was under the impression you weren't too fond of that approach seeing as SDL did it that way. The reason why I didn't keep it that way is that it'd be odd to use UTF-8 std::string for titles, but sf::String for everything else Unicode. |
|
What I mean is that if you have a sf::String version, the std::string version becomes useless because sf::String can be implicitely constructed from std::string. sf::String already handles all string types automatically. |
|
Ah. I did not know that. Shall I go fix it? |
|
Fix it in your version if you want, but like I said I won't merge this pull request. However your X implementation will probably help me in the future, so thanks anyway ;) |
- 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.
Currently all it is is a new SetTitle method that uses sf::String for Unicode text. I've only implemented it on X11 so far, but it works.