SFML community forums
General => Feature requests => Topic started by: RetroX on March 07, 2010, 03:44:28 am
-
Probably been asked for before, but it seems like one of the very few features in SFML that is really needed. And while it can be done, the only solutions are not cross-platform.
Basically would be something like:
void sf::Window::SetTitle(std::string Title)
std::string sf::Window::GetTitle()
-
Yes, I'm going to add it.
Is GetTitle() really necessary?
-
Yes It is. I need this method for my future GUI, beucause actually I must save the title string for using it after and It is not very stylish.
-
Why do you need to get a window's title? I can't imagine a good use case, at the moment...
-
All "Mac Os like menues" in my GUI need to know the SFML window's title, because the first entry inside is this title precisely.
-
GetTitle() is just something that may be useful in a few situations and if you're going to add SetTitle(), it might as well be added, as well.
I find it odd that you would be able to set the title but not know what title that you had just set.
-
*necropost*
Is GetTitle() really necessary?
It'd be useful in cases where the title was changed outside of the program, i.e. by third-party window managers, sandboxes, or macros/scripts.
Plus, as others have said, it would just make sense as a convenience function.
-
It'd be useful in cases where the title was changed outside of the program, i.e. by third-party window managers, sandboxes, or macros/scripts.
Sounds like an extreme use case. And what would you do with the title anyway? To me it's something that you set, but never need to get back.
Plus, as others have said, it would just make sense as a convenience function.
If I added a getter for every setter that SFML provides, the API would have a lot more functions. And you know that I don't like that ;)
-
It'd be useful in cases where the title was changed outside of the program, i.e. by third-party window managers, sandboxes, or macros/scripts.
Sounds like an extreme use case. And what would you do with the title anyway? To me it's something that you set, but never need to get back.
Not really. I run multiple versions of my code in sandboxes all the time for memory profiling and such, and need to log/output the title name for debugging issues. It'd be a nice thing to have.
Plus, as others have said, it would just make sense as a convenience function.
If I added a getter for every setter that SFML provides, the API would have a lot more functions. And you know that I don't like that ;)
Oh jeez, one method won't hurt Laurent ;) You're leaving the API open-ended anyway by leaving it out.
-
I run multiple versions of my code in sandboxes all the time for memory profiling and such, and need to log/output the title name for debugging issues
But since you set the title of the window, you obviously already know it, so why do you need to read it from the window?
Oh jeez, one method won't hurt Laurent
It's not one method, it's a lot. If I add this one, which usefulness is not obvious to me, then why wouldn't I add all the other missing getters too?
-
I run multiple versions of my code in sandboxes all the time for memory profiling and such, and need to log/output the title name for debugging issues
But since you set the title of the window, you obviously already know it, so why do you need to read it from the window?
But you don't know it, that's the thing. I'm saying that third party applications can change the title. Yes I can store a string with the title I last applied to the window, but if if something like a sandbox appends "SomeTitle <sandboxie>" to the end, then I need a way to get that new title, which I have no control over.
Oh jeez, one method won't hurt Laurent
It's not one method, it's a lot. If I add this one, which usefulness is not obvious to me, then why wouldn't I add all the other missing getters too?
Because most other getters are defined as it is ;)
-
Rewrite tiny part of sfml yourself? This is extremely niche feature.
-
But you don't know it, that's the thing. I'm saying that third party applications can change the title. Yes I can store a string with the title I last applied to the window, but if if something like a sandbox appends "SomeTitle <sandboxie>" to the end, then I need a way to get that new title, which I have no control over.
Ok I get it. But:
- this is unreliable, what happens to your log if one of the sandboxes doesn't add its name to the window title? to me you should handle this yourself, to get consistent results
- it still doesn't convinces me (this is a very very very specific use case...)
:)
Rewrite tiny part of sfml yourself? This is extremely niche feature.
Or write an external function that uses window.getSystemHandle(), with one implementation per target OS.
-
But you don't know it, that's the thing. I'm saying that third party applications can change the title. Yes I can store a string with the title I last applied to the window, but if if something like a sandbox appends "SomeTitle <sandboxie>" to the end, then I need a way to get that new title, which I have no control over.
Ok I get it. But:
- this is unreliable, what happens to your log if one of the sandboxes doesn't add its name to the window title? to me you should handle this yourself, to get consistent results
- it still doesn't convinces me (this is a very very very specific use case...)
:)
Not really, it can be used in almost any logging/debugging use case. If I am working with pure SFML windows and want to know the title name for a quick log, I'm SOL. I'd have to wrap the window and hold a string, which is cluttered and goes against many designing rules/theories anyway (i.e. don't store data that can be easily obtained somewhere else). I think this applies.
Further, this is just such a small, simple thing that really should be in there. It just doesn't seem like a complete class without a getter such as this.
Rewrite tiny part of sfml yourself? This is extremely niche feature.
Or write an external function that uses window.getSystemHandle(), with one implementation per target OS.
But then that requires the extra time for each project to write/implement/create a wrapper for something that should already be implemented in a native window class!!
-
But then that requires the extra time for each project to write/implement/create a wrapper for something that should already be implemented in a native window class!!
Just edit source and header and cmake normally, possibly doing some conditional compilation that will end up printing to cout "Warning: Non-standard SFML extension function called for object at adress (this) of type (typeid(*this).name())." in debug each time you get title.
-
One use-case where setting the window title should be possible : « knowing which file/project is open ».
With sfeMovie, if you do a small video player, you may want to have the window title being "My Awesome Player - Batman Return.avi".
Same with an editor : "My Great Editor - TestingLevel.lvl"
Still in the editor, you may want to add "My Great Editor - TestingLevel.lvl (not saved)". or "(unsaved changes)"
-
One use-case where setting the window title should be possible
It.. is..? Getting isn't possible.
-
But then that requires the extra time for each project to write/implement/create a wrapper for something that should already be implemented in a native window class!!
Just edit source and header and cmake normally, possibly doing some conditional compilation that will end up printing to cout "Warning: Non-standard SFML extension function called for object at adress (this) of type (typeid(*this).name())." in debug each time you get title.
That would slow things down way too much to output.
Also, this should be in there anyway. It's a major API gap.
-
Also, this should be in there anyway. It's a major API gap.
This is just your opinion, based on a very specific use case. Unless you have other arguments, I won't consider this feature a "major gap" in the API.
I'm really sorry to reject this request (don't worry, I do it all the time, it's not against you ;) ), but I really need to be convinced that a feature will be useful to a majority of users before adding it. It might be absolutely necessary for you, but you should admit that your requirements are really specific and from a global point of view this function is really not the most important one to add in SFML.
-
I'm not saying I need this now, nor will I ever, it just seems pretty incomplete to not have it in there, that's all.
-
I understand your point of view. But my philosophy is to add a feature only if it is needed; "seems incomplete" is not enough for me ;)
-
I understand your point of view. But my philosophy is to add a feature only if it is needed; "seems incomplete" is not enough for me ;)
I can respect that. ;)