File drop

[Hiura]

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

Here I suggest an alternative that can deal with pointer invalidation & ownership, did you have a look at it?

[FRex]

I didn't but I thought of 64 bit ID + invalidate on next pop event or some other call too, the only problem it has is that now events are pure data with 0 extras or context needed and that'd change it. It'd feel awkward compared to rest of the API but I'd not mind personally (clearing on pop event might be bad for people storing all events per frame in a buffer though and clearing on display is a bit weird but at least not problematic, dedicated clear method for these is of course out of the question because everyone would forget to call it...).

[Hiura]

It'd feel awkward compared to rest of the API

That's understandable. Yet, I think for 2.x it's fine. For 3.x we can come up with a better design which leverage post C++-98 facilities. With C++17, variant and smart pointers this is not an issue. This probably can be achieved with C++14 as well.

[FRex]

Perhaps a callback into user code then, if it's set the window accepts dropped files (and passes the paths to it). No memory issues, no action at a distance clean ups, etc.

[Hiura]

I'm not convinced callbacks are better here. To start with, callback API stray much further apart from the current API. Callbacks also tend to generate memory complication for the user. If they want callback, they can implement such system on top of a "regular" system, such as the one I suggested.

[FRex]

Just for the file drop, not for everything. This feature is very specific and unlike the others already anyway, it's rare and not representable as a POD even. What memory complications do callbacks cause?

[Laurent]

Just for the file drop, not for everything

That's why it would be weird. All other SFML events are reachable by polling the event queue, and this specific one would be delivered through a callback. Although I understand the technical limitations of the Event union, I'm not in favor of introducing this kind of design inconsistency in the API.

[Hiura]

I understood you meant only for file drop event, that's why I think the API would be too different from the rest of the Event-related API. C++ is not a managed memory language -- just stating the obvious here -- hence making sure your callback is always callable is not a trivial thing to do: the user has to make sure all references are still valid and so on. It also tends to generate spaghetti code. I think this kind of design should not be forced upon the user unless no other solution is possible at all, or we might lose the S of SFML.

[FRex]

If anything, I'd find a callback simple and easy to understand personally. Callback with just a list of dropped items, window reference and user pointer seems like a really good solution that avoids weird lifetime action at a distance implicit agreements ('poll for paths before next display' or something) and doesn't look weird in the API (because it'd look weird to have getPaths() in sf::Window that is only supposed to be used after a certain event is handled, and we already go away from 'pure events' to event + poll window or something so it's not consistent with all the other events).

We already have 'callbacks' in InputStreams, sort of (since function pointer or virtual function is how 'callbacks' are done pre-C++11, save for people who use third party std::function like classes), and 'white sprite because I deleted sf::Texture' is a common beginner problem already that comes from the same mistake, all the caveats that are possible here already apply in SFML. I don't see how a callback instead of polling could generate spaghetti code.

[Phanoo]

I understood you meant only for file drop event, that's why I think the API would be too different from the rest of the Event-related API. C++ is not a managed memory language -- just stating the obvious here -- hence making sure your callback is always callable is not a trivial thing to do: the user has to make sure all references are still valid and so on. It also tends to generate spaghetti code. I think this kind of design should not be forced upon the user unless no other solution is possible at all, or we might lose the S of SFML.

I'd suggest not to worry much about the S of SFML. Too much S = a lib that would not be useful for any serious project. Just avoid getting horribly complicated like the OpenGL api, but we are far, FAR from that. Currently i had more problems fighting against the simplicity of some SFML interfaces rather than their complexity.
Just make a decision and go for it, nobody will ever agree on whether a callback is the best solution or not.

[eXpl0it3r]

Just to relink this here as well, I've started a solution design, so we can collect all the required information in one place with pro/contra arguments and potential API designs.

It's in the wiki, as such if anyone feels like working on this topic, feel free to edit it.

https://github.com/SFML/SFML/wiki/SD:-File-Drop