I like this feature request. I think it would fit well as an sf::Event? For example, lets say you have a media player. It'd be nice to allow a user to drag a media file from the desktop and drop it into the media player instead of having to go through a file->open type of dialog.
Formally:
In which way is SFML limited?
SFML does not have a way to know if something was dragged (such as a file) onto the running application window.
What use cases does the feature allow?
Allowing the opening of media files for a media player, save game/project files in some sort of editor (such as a scene designer), or dropping links/images from elsewhere to be modified in app.
How can other users benefit from the change?
Having a mechanism to interact with outside media makes sense for Simple and Fast Multimedia Library. End user convenience is in the aforementioned part.
How would it be implemented? I don't know. I've never used this feature in a lower level language, so I don't know the underlying considerations necessary to make a good proposal here. Here's a rudimentary idea:
enum MetaType {File, Text, Unknown};
struct DragData
{
sf::String Text;
MetaType Type;
}
//....Somehow be given a DragData struct from SFML:
DragData data;
if (Data.Type == MetaType::File)
{
std::ifstream File(Data.Text.toAnsiString());
}
Then a window can have a function or event that can return a DragData. I honestly have no idea what types would fall into the "MetaData" enum (again, I'm not really educated with this aspect), or how a window would handle multiple files or "DragData" structs dropped into the window at once.
Anyway, aside from my terribly ignorant implementation idea, I think the overall suggestion may not be a bad one. Especially if SFML will support file systems (I believe this idea was thrown around in the forums somewhere too).
I consider feature parity important, especially with stuff that is so simple to code (at least in Windows).
Someone will someday move to SDL or GLFW and say he missed this in SFML and say it online, just like people used to give SDL crap for not having multi window support long ago when SFML had it.
No one will care about 'oh, SFML is not like a super toolkit' and such and they will even say we are stupid for saying these things and spending time on excuses instead of implementation.
The use case of dropping images or scripts or whatever on the window is compelling enough to me.
As for types and stuff - no. This isn't how this works, all you get in a drop files event is a list of file names, not data, not types, etc. just a bunch of strings with full filenames of what files were dropped on the window, it's up to you to open them if you want and if they are no longer there or not accessible to your process or whatever - up to you to deal with it too.
Here is a proof of concept for Windows, of course that void * in Event is a placeholder just to get it running quickly. Maybe the list could be accessible in the window and be filled on event and the event to just contain a pointer to it and XY..? I have no idea, it's hard to do cleanly the way SFML does things.
As for Linux, it's a bit more complex and I didn't read into https://www.freedesktop.org/wiki/Specifications/XDND/ yet so that'll take a while, maybe it should wait until the API is in place.
Here is a repo https://github.com/FRex/SFML/tree/win32_drag_and_drop and a test program:
#include <SFML/Window.hpp>
#include <iostream>
int main(int argc, char ** argv)
{
sf::Window app(sf::VideoMode(640u, 480u), "Drag and Drop");
while(app.isOpen())
{
sf::Event eve;
while(app.pollEvent(eve))
{
if(eve.type == sf::Event::Closed)
app.close();
if(eve.type == sf::Event::FilesDropped)
{
std::printf("Got files on %d, %d:\n", eve.fileDrop.x, eve.fileDrop.y);
const auto& fs = *(const std::vector<std::string>*)(eve.fileDrop.files);
for(auto f : fs)
std::cout << f << std::endl;
std::cout << "-----------------" << std::endl;
}
}//while app poll event eve
app.display();
}//while app is open
}