Welcome, Guest. Please login or register. Did you miss your activation email?

Author Topic: File drop  (Read 66369 times)

0 Members and 1 Guest are viewing this topic.

Hiura

  • SFML Team
  • Hero Member
  • *****
  • Posts: 4321
    • View Profile
    • Email
Re: File drop
« Reply #45 on: October 27, 2017, 04:01:11 pm »
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?
SFML / OS X developer

FRex

  • Hero Member
  • *****
  • Posts: 1848
  • Back to C++ gamedev with SFML in May 2023
    • View Profile
    • Email
Re: File drop
« Reply #46 on: October 27, 2017, 04:10:11 pm »
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...).
Back to C++ gamedev with SFML in May 2023

Hiura

  • SFML Team
  • Hero Member
  • *****
  • Posts: 4321
    • View Profile
    • Email
Re: File drop
« Reply #47 on: October 30, 2017, 03:26:31 pm »
Quote
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.
SFML / OS X developer

FRex

  • Hero Member
  • *****
  • Posts: 1848
  • Back to C++ gamedev with SFML in May 2023
    • View Profile
    • Email
Re: File drop
« Reply #48 on: November 06, 2017, 01:26:05 pm »
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.
Back to C++ gamedev with SFML in May 2023

Hiura

  • SFML Team
  • Hero Member
  • *****
  • Posts: 4321
    • View Profile
    • Email
Re: File drop
« Reply #49 on: November 07, 2017, 10:30:45 am »
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.
SFML / OS X developer

FRex

  • Hero Member
  • *****
  • Posts: 1848
  • Back to C++ gamedev with SFML in May 2023
    • View Profile
    • Email
Re: File drop
« Reply #50 on: November 07, 2017, 10:44:19 am »
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?
Back to C++ gamedev with SFML in May 2023

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32498
    • View Profile
    • SFML's website
    • Email
Re: File drop
« Reply #51 on: November 07, 2017, 11:01:53 am »
Quote
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.
Laurent Gomila - SFML developer

Hiura

  • SFML Team
  • Hero Member
  • *****
  • Posts: 4321
    • View Profile
    • Email
Re: File drop
« Reply #52 on: November 07, 2017, 11:02:59 am »
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.
SFML / OS X developer

FRex

  • Hero Member
  • *****
  • Posts: 1848
  • Back to C++ gamedev with SFML in May 2023
    • View Profile
    • Email
Re: File drop
« Reply #53 on: November 07, 2017, 11:30:33 am »
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.
Back to C++ gamedev with SFML in May 2023

Phanoo

  • Full Member
  • ***
  • Posts: 136
    • View Profile
Re: File drop
« Reply #54 on: January 03, 2018, 04:40:04 pm »
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.
« Last Edit: January 03, 2018, 07:45:10 pm by ratatax »

eXpl0it3r

  • SFML Team
  • Hero Member
  • *****
  • Posts: 11027
    • View Profile
    • development blog
    • Email
Re: File drop
« Reply #55 on: August 05, 2021, 03:40:39 pm »
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
Official FAQ: https://www.sfml-dev.org/faq.php
Official Discord Server: https://discord.gg/nr4X7Fh
——————————————————————
Dev Blog: https://duerrenberger.dev/blog/

 

anything