File drop

[Hapax]

SFML doesn't need to implement the drop event as long as it destroy the events that it doesn't use and that has been discussed (for SFML 3). Don't think it got confirmed for certain though.

Then, you could implement this event from the remaining events yourself. Still, if SFML wanted to, I suppose it could transform this event into its own.

[Ruckamongus]

SDL's API is exactly how I imagined SFML to have it. Really, all I'd want is a file path, I can get the name, figure out what to do with it, etc. myself. Still, we're going down the "SFML is not SDL so stop comparing" and "give us a proper usage case" road. It seems the consensus is it's not going to happen unless somebody can produce a working PR (even then who knows?).

I should clarify I love SFML despite the tone of my post; I use it almost exclusively. It just seems that development is very slow due to... excessive thoughtfulness? It seems a topic, suggestion, or PR can be beat around for months at a time with no real progress to be made.

[Phanoo]

I completely agree, and that's why i often make fun and cynical answers to Laurent's posts. His work is great no problem. BUT. Tooooo much thoughtfulness, endless useless debates instead of implementing the damn functionnality that would take less time than talking about it (well ok, not all of them are easy to implement, but some ARE)

I've also asked for a way to set Line Height attribute for Texts, first answer i got is something like "why would you need that", "just edit the font itself"...

I'm making a (free) software that aims for professional quality with SFML, and i just can't forget the drag&drop for my users, wake up we are in 2017 lulz

Dunno why we have to justify the evidence

[Laurent]

I don't know if you noticed, but now that SFML development is driven by the team and the community (most contributions are "external" now), things get more easily integrated. I don't even participate to most of the discussions, and when I do, it's to comment on implementation things.

Line height is implemented by the way.

If you provide a (not even complete) PR for drag&drop, it will probably be integrated.

Dunno why we have to justify the evidence

I like to think that questioning everything, even the evidence, allows to come up with new choices and ideas. If we all make the same things, similar to what others did before us, ... what's the point?

[FRex]

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
}

[Hiura]

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.

This might be okay for Microsoft Windows platforms, but SFML aims to be cross-platform and therefore such assumptions are frequently what make API limited, forcing people to write more workaround than necessary.

Note that a PR is already open with exactly the same focus and issues. See my concerns there: https://github.com/SFML/SFML/pull/1222#issuecomment-301183280 (It also has setFileDroppingEnabled, which is an interesting feature.)

I think it's the right time to get a proper API design about how to handle different data types as this is a common feature with the scheduled improvement of the clipboard API. Without answering this first, we might end up with inconsistent APIs.

[FRex]

This is just for files, the other data can have own event to not force users to do switch in a switch. I don't think anything in events right now requires such a construct. I actually noticed the text only clipboard we got when I took a look at this which is why I thought we might focus on the biggest catch first here too.

Honestly, even file names are kind of problematic-ish because on Windows they use a 16bit wchar and on Linux it's all normal chars in UTF8. I converted to an std::string because I assume we use that for filename, as we do in all the loadFromFile and openFromFile functions. Text drag and drop can be sf::String of course.

According to http://anton.maurovic.com/posts/win32-api-approach-to-windows-drag-and-drop/ Windows supports non-file list drag and drop (and it clearly does as you can drag and drop text between textual elements of different windows/programs) but only via COM or a third party library that wraps that COM..?

According to https://www.freedesktop.org/wiki/Specifications/XDND/ Linux (or more accurately anything using X) seems to support other kinds of data. No idea about Wayland but it probably does too and we don't have a Wayland backend anyway.

I've seen LCL (a Pascal GUI toolkit, quite portable and using one of other GUI toolkits as backend) only implement the file list drag and drop, Qt seems to implement it all and mesh it into one 'drop event'.

Toggling the drop acceptance of course possible too (for winapi at least, not sure with X and win COM).

I also have no idea for a good API.

I also hate to give Windows only stuff a slack but maybe drop files is a good cut off point to satisfy most users with least effort. No drag and drop at all will be much worse than a drag and drop that only handles file list and one that handles everything will be complicated, so this might do or at least do for now.

We are already cutting many corners and saying we are not that rich of a windowing toolkit, like not supporting transparent and non rectangular windows, the tray, client side decorations, etc. and just tell people to use the window handle then so we might as well do just file drop since it'll satisfy most users and the code for the (sadly..) most popular platform is SO simple.

I'm not sure if that COM code for rich drag and drop needs more than just a handle, but the win api file drop required handling a message in SFML code, I'll try see if it's possible to replace the message handler or not with just what SMFL exposes to user and the winapi, if yes then this might serve as a workaround for now.

[Phanoo]

I didnt managed to get filedrop working only with SFML's getWindowHandle + windows API functions. I'm able to get the drop icon when a file is dragged into the window but the callbacks doesn't work despite my attempts. I'm not sure if it's possible without modifying SFML code to handle the windows filedrop messages. (please note i'm not familiar with windows API, I just messed with some code found here and there)


For the way it should work, getting the files paths and drop position is really all everyone needs IMO, + something to enable/disable it (so the developer can use it to create specific drop zones).

[FRex]

It's sort of possible but you'll need a global pointer for the original function and some global structure (not in the example) to inform yourself of the files being dropped and of the names themselves. Sadly, the userdata of the handle can't be used - SFML uses that to store sf::Window pointer.

See: https://gist.github.com/FRex/3f7b8d1ad1289a2117553ff3702f04af

I'm not familiar with win api either BTW.

[barnack]

Uhm honestly i think this feature would be appreciated by many people.
I'd eventually help with the coding of the Windows side, but correct me if i'm wrong, i had the impression that SFML libraries aim to be totally cross platform, not allowing to have a platform specific function. If that's the case. And my knowledge of Linux system interaction is little to totally inexistent, hence my help would be meaningless...
But i really whish someone with overall knowledge/time could develop that feature in the library.
Some use examples?
drag images in an image viewer,
drag programs to a shortcut-management custom window,
drag textures in a game supporting custom textures / make character "modding" more user friendly.
But mostly, something which is always hugely undervalued: editors.
Map editors always benefit from drag-drop. May it be a .lua script of events being copied from another map, may it be map's settings exported in an external ini file, up to the simpler and conventional "drag the file type this editor makes in order to open it", which works from any editor, not only games ones.

[FRex]

Windows implementation for drag and drop files (but not text) is a non-issue and available in link above (and before in some old PR too I believe): https://gist.github.com/FRex/3f7b8d1ad1289a2117553ff3702f04af
The real problem is creating a nice API and implementations for X (and Mac..) to actually achieve cross-platformness of that.
There were plenty of use cases already mentioned too (and I'm in totally favor, not that it matters more than anyone else's opinion here).

[barnack]

Well yeah being possible is not the issue; but it'd be much more clean to push it as an event within the library rather than having the external call unwrapped

[FRex]

The Events are all PODs, that's the problem. We can't just put a vector of strings into the Event. They need to be stored elsewhere (but where?) somehow and then retrievable from there and cleaned up when they're no longer needed...

[barnack]

The Events are all PODs, that's the problem. We can't just put a vector of strings into the Event. They need to be stored elsewhere (but where?) somehow and then retrievable from there and cleaned up when they're no longer needed...

Is "a string pointer" the answer to your question?

[FRex]

And what about pointer invalidation, where is it actually stored, who owns and frees it?