Getting/setting title of sf::Window?

[RetroX]

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()

[Laurent]

Yes, I'm going to add it.

Is GetTitle() really necessary?

[Thiziri]

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.

[Nexus]

Why do you need to get a window's title? I can't imagine a good use case, at the moment...

[Thiziri]

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.

[RetroX]

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.

[Qix]

*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.

[Laurent]

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

[Qix]

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.

[Laurent]

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?

[Qix]

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

[FRex]

Rewrite tiny part of sfml yourself? This is extremely niche feature.

[Laurent]

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.

[Qix]

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!!

[FRex]

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.