SetCursor in sf::Window

[NoIdea]

Hi everyone, as some people might know, a poll is circulating on the french forum about wether a SetCursor function should be added in SFML.
I'll try to translate the different arguments given so far :

-It is usefull because this function will be able to load a OS cursor (such as the "waiting cursor" which is a whereas it is a kind of blue circular thing on seven). This means no need to manage the different cursors for each OS : it would be included in SFML.

-every game/application needs to change cursors.

-Other API of the same "level" have this kind of function (SDL, allegro).

-Users can make there own function.

-It is to High level for SFML

-Not many users will use it

-...

I would like to have your point of views. If you answer another reason, please post an answer to say why.

Sorry for my english (im french).

Thank you.

[Calmatory]

I recently had to tackle with this issue with SDL(Yes, there are reasons to use it, still. ) and I would like to see a similar feature in SFML. Sure, it's not much work to implement one myself, but having it as a feature is a definite plus in my opinion.

[Mindiell]

No. Another reason.

If you are developping a game, I really think you don't want to use those crappy cursors, but instead use a beautiful cursor made by your team and more "inside" the game.

If you are developping an application, there is two possibilities (IMHO) :
- Something like an editor : use your own cursors, like in the game
- Something like an app : there is a lot of chance you are going t ouse Qt or WxWidgets, or such a lib. Use their cursors in order to maintain a compatibility between platforms

[NoIdea]

I don't exactly understand what you mean by "crappy cursors".
I'm proposing to add 2 functions to sf::Window :

SetCursor(sf::Sprite);
SetCursor(CURSOR_TYPE);

with enum CURSOR_TYPE(NORMAL,TEXT,WAIT, HAND, ...);

which means you can either use your cursor or use the system cursor (which is more user friendly for most applications).

[Mindiell]

I don't exactly understand what you mean by "crappy cursors".

Well, I don't like the basic cursor of the OS

I'm proposing to add 2 functions to sf::Window :
SetCursor(sf::Sprite);
SetCursor(CURSOR_TYPE);

Can you add a third function for an animated sprite (like I use in my games) ?
What if I want to use a sf::Shape instead ?

As you can see, there is a lot of possibilities about cursor thing. I really don't think that creating a specific function is a good thing.
I'm not against using a system cursor, just against the idea of a "specific function"...

[Spellbreaker]

I'd vote for it, it would be very helpful and is a standard-feature for such libs in my opinion.

[Canadadry]

I don't exactly understand what you mean by "crappy cursors".
I'm proposing to add 2 functions to sf::Window :

SetCursor(sf::Sprite);
SetCursor(CURSOR_TYPE);

with enum CURSOR_TYPE(NORMAL,TEXT,WAIT, HAND, ...);

which means you can either use your cursor or use the system cursor (which is more user friendly for most applications).

There is no need for the first one (SetCursor(sf::Sprite); ). we could already done that. And for the second one, in my opinion, there is no place for such feature in a multimedia library.

[Mindiell]

in my opinion, there is no place for such feature in a multimedia library.

As Hiura said it on the french forum, can you give us more than just a "no" ?

NoIdea explained why he wanted something like this (windowed app, not a game).

[NoIdea]

if you prefer, we can do a SetCursor(sf::Drawable).
Secondly, I never exactly understand the answers like :
-There is no need for this kind of function.
First of all because this kind of function is very used. Secondly, it is not because you can implement it by yourself that it should not already be done in SFML (because with that reasoning, no function should be implemented). Thirdly because even if it is there and you dont use it, whats the problem ?

[Canadadry]

As Hiura said it on the french forum, can you give us more than just a "no" ?

I already gave. Like i said, this kind of feature doesn't take place is this king of library. To use it we will need more gui object like textfiel, combobox... This is not a question of need, for me it's a question of integrity and design pattern.

Let's me give you an ohter example. If someone came here and ask for xml support because it's really usefull and used in many game. I would said the same thing which is : i don't think there is a place for this kind of feature in SFML. I would said the same thing for script like lua. I don't said there is no need but this is not the purpose af SFML. And all of that involve just me. Maybe Laurent won't have the same opinion.

And for SetCursor(sf::Drawable), did it just for now because it's simple avec wait for laurent's answer.

You've maid your point, we've maid our so I think we have enougth take about that, just wait for laurent'sanswer.

[Hiura]

My intervention was more about form than content. There is a very subtle difference between the two.

When you (I/whoever) say something like «A multimedia lib doesn't need that feature», this person is wrong.

Now you said that this feature is out of SFML's scope, which is different. All the subtleness is here.

Maybe Laurent won't have the same opinion.

Yes, maybe. BUT we still can discuss the thing more and more to come up with a strong position, with more arguments pro and against, unsoweiter, and maybe with something new.


NoIdea, please go on with your idea : you may come up with something great (for SFML or not).  :wink:

[NoIdea]

The main difference between Lua scripting and xml with my idea is that :
xml or Lua Scripting can be done by a Librairy which has nothing to do with SFML whereas SetCursor has to go with SFML : try to design an SetCursor which works with all API and call me back...

This is mainly why it is important to have this function in SFML. If Laurent would give us access to window handles by making things public / protected instead of private, this function could easily be done through system calls.
However, if you do not, it becomes a real mess to deal with system cursors.

Furthermore, I might point  out that the poll shows us that more people have another reason to say no than "it can be user implemented" (or GUI implemented) or it's to high level.

I dont know why, but Laurent has been very silent about this subject... maybe his point of view/solutions could be helpfull...

[Hiura]

I dont know why, but Laurent has been very silent about this subject... maybe his point of view/solutions could be helpfull...

I think it has nothing to do with this topic. He's maybe in holiday, has too much work or any other personnal reason that doesn't concern us. Let us be patient!   :wink:

[Mindiell]

if you prefer, we can do a SetCursor(sf::Drawable).

No, what I pointed is that one, two or three functions are maybe not sufficient for what every one needs : what about an animated sprite ?
I'm sure that if Laurent accpet this feature, he'll have to think a lot more than just add two functions...

Thirdly because even if it is there and you dont use it, whats the problem ?

This point is important for Laurent, he wants to keep the S of SFML : "Simple". He doesn't like add lots of functions just to have mre functions. I, actually, don't see a simple way to do what you wat and use a sprite, and use an animated sprite, and etc... This is certainly why Laurent didn't create this function first (and maybe because this is not the aim of the SFML like mooglwy said ).

[NoIdea]

I do not think that Cursors should be delt within the SFML. I think SFML should provide us functions to interact with the system independantly of which system :

Setting the cursor on windows is very simple : there is a function already made.
I'll bet its the same for linux, mac...

So im just asking Laurent to add a function in WindowImplWin32.hpp and the linux equivalent so that SFML provides a way to interact with the system.
For the moment, it is impossible to add this kind of function because WindowImplWin32 is hidden by pimpl idiom. Since SFML stops us, SFML should give us a solution.