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

Author Topic: File drop  (Read 12265 times)

0 Members and 1 Guest are viewing this topic.

Mr_Blame

  • Full Member
  • ***
  • Posts: 192
    • View Profile
    • Email
File drop
« on: October 07, 2015, 04:04:09 pm »
Hello  :)
Why can't we add support for file dropping in window(you know when you drag'n'drop a file in editor window and it opens it)(as example it is supproted in GLFW)

eXpl0it3r

  • SFML Team
  • Hero Member
  • *****
  • Posts: 9324
    • View Profile
    • development blog
    • Email
Re: File drop
« Reply #1 on: October 07, 2015, 04:25:40 pm »
Please follow the contribution guidelines for feature requests:

A feature request should always contain a rationale for the change. Whenever you suggest a feature, argue from a user perspective: in which way is SFML limited? What use cases does the feature allow? How can other users benefit from the change?
Official FAQ: https://www.sfml-dev.org/faq.php
Nightly Builds: https://www.nightlybuilds.ch/
——————————————————————
Dev Blog: https://dev.my-gate.net/
Thor: http://www.bromeon.ch/libraries/thor/

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32144
    • View Profile
    • SFML's website
    • Email
Re: File drop
« Reply #2 on: October 07, 2015, 07:17:54 pm »
What does it mean to "support" it? What kind of files should we handle, and what should we do with them?

When you drop a file on an executable, its path is passed as an argument so you can retrieve it with argv[1] and do whatever you want with it in your program.
Laurent Gomila - SFML developer

Mr_Blame

  • Full Member
  • ***
  • Posts: 192
    • View Profile
    • Email
Re: File drop
« Reply #3 on: October 07, 2015, 09:11:28 pm »
In glfw it supports any file format. In glfw when you drop a file in app's OPENNED WINDOW it calls callback with params: window on wich was dropped a file and its name.

zsbzsb

  • Hero Member
  • *****
  • Posts: 1409
  • Active Maintainer of CSFML/SFML.NET
    • View Profile
    • My little corner...
    • Email
Re: File drop
« Reply #4 on: October 08, 2015, 12:08:38 am »
You do realize that dropping isn't limited to files, drag and drop can support a wide variety of meta types. And then if we did implement the dropping part, the next request is for starting the drag from within an SFML window.

And you still haven't answered the basic questions from the contribution guidelines.
Motion / MotionNET - Complete video / audio playback for SFML / SFML.NET

NetEXT - An SFML.NET Extension Library based on Thor

Ruckamongus

  • Jr. Member
  • **
  • Posts: 64
    • View Profile
Re: File drop
« Reply #5 on: October 08, 2015, 10:58:28 pm »
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).

GraphicsWhale

  • Full Member
  • ***
  • Posts: 131
    • View Profile
Re: File drop
« Reply #6 on: October 09, 2015, 11:06:09 pm »
I don't see how this would benefit many people. I suppose possibly custom music selection? In game resource editing? But then again, that's pretty rare, and a file selection dialog could easily work just as well.

Having a mechanism to interact with outside media makes sense for Simple and Fast Multimedia Library. End user convenience is in the aforementioned part.

I don't see how drag-and-dropping has to do with multimedia. It's just a faster alternative to dialog boxes.

Anyway, aside from my terribly ignorant implementation idea

Why'd you suggest it then? :) /s

Satus

  • Full Member
  • ***
  • Posts: 105
    • View Profile
    • Email
Re: File drop
« Reply #7 on: October 09, 2015, 11:50:14 pm »
Well, I can imagine some use cases for this feature, for example image gallery or video/music player, or level editor.

GraphicsWhale

  • Full Member
  • ***
  • Posts: 131
    • View Profile
Re: File drop
« Reply #8 on: October 10, 2015, 02:20:45 am »
Well, I can imagine some use cases for this feature, for example image gallery or video/music player, or level editor.

While those are all valid uses for drag-and-drop, I'm not quite convinced the first two are the kind of applications one would make using SFML. Or why anybody would want to make them at all for that matter. Still support the feature, though, because the third one you stated is relevant and actually sounds pretty helpful.

Satus

  • Full Member
  • ***
  • Posts: 105
    • View Profile
    • Email
Re: File drop
« Reply #9 on: October 10, 2015, 02:29:58 am »
While those are all valid uses for drag-and-drop, I'm not quite convinced the first two are the kind of applications one would make using SFML.

Well, if I remember correctly, there was video player implemented with SFML and that it wasn't bad at all.

But yeah, I'm not sure that is this feature will be used by more than few people.

binary1248

  • SFML Team
  • Hero Member
  • *****
  • Posts: 1385
  • I am awesome.
    • View Profile
    • The server that really shouldn't be running
Re: File drop
« Reply #10 on: October 10, 2015, 05:11:58 pm »
The question that really has to be asked is: Is SFML the library people would use when they need this kind of interaction with other applications? It is true that other libraries like GLFW have support for this, but I honestly can't think of a use case where one would use GLFW over something like... Qt or wxWidgets or any other more specialized UI library to create an application that needs this kind of support.

Just think about it, SFML's main target is applications that do all their rendering exclusively through OpenGL. Most of the time, SFML applications don't even need proper UI widget support. There are GUI libraries like SFGUI and TGUI, but their users know well that they aren't designed to compete with "real" widget libraries like Qt that provide native looking widgets. If someone really needs drag and drop support in an application making use of SFML, they would be better off embedding an SFML window into a widget from another library. This brings me to what I think the reason is that GLFW supports drag and drop: From what I can tell, GLFW doesn't allow embedding their windows in widgets from other libraries like SFML does, so I guess from that point of view providing their own drap and drop support kind of makes sense.

As examples, look at any game that would typically be played in fullscreen. They probably don't support drag and drop even when you play them in windowed mode. The example of the video player that was brought up isn't a typical application of the sfeMovie library if you ask me. sfeMovie's main purpose is to provide applications who render exclusively through OpenGL a way to render movies as part of their 2D/3D scene. If you asked me to make a video player application, sure I could use SFML and sfeMovie, but why do so if I could make something even better and more suited to the task using Qt and a dedicated movie playback library (if Qt doesn't already support it somehow)?

It's all a question of what SFML is and isn't designed to do. I don't know what direction GLFW is taking/took, but SFML tries to have a well-defined aim. This means having to reject supporting stuff that only sees use in niche application types.
SFGUI # SFNUL # GLS # Wyrm <- Why do I waste my time on such a useless project? Because I am awesome (first meaning).

GraphicsWhale

  • Full Member
  • ***
  • Posts: 131
    • View Profile
Re: File drop
« Reply #11 on: October 11, 2015, 02:56:52 am »
Pros:
- Great for resource importation (such as custom music or custom file format importer/exporter)
- Opens up new uses for SFML

Cons:
- Has to be implemented
- Has to be maintained
- Moves away from the library being about mostly about game development
- Introduces a feature that only works on certain platforms (doesn't work on mobile)

It'd be a cool feature, but there's understandable reasons why it probably wont be implemented.

IngloriousTom

  • Newbie
  • *
  • Posts: 17
    • View Profile
Re: File drop
« Reply #12 on: October 12, 2015, 05:05:54 pm »
I beg to differ !

- Has to be implemented
- Has to be maintained
True for any other feature

Quote
- Moves away from the library being about mostly about game development
While true for the library usage, the purpose is not limited to game development and I personally have three SFML projects unrelated to games.


Quote
- Introduces a feature that only works on certain platforms (doesn't work on mobile)
Not unheard of, since touch support is currently only available on mobile.

I would love to see drag and drop implemented because it is a common interaction in Windows, Linux and Mac, and certainly even more OS.
But I agree that it's a complex feature and few users will ever need it.

Hapax

  • Hero Member
  • *****
  • Posts: 2775
  • My number of posts is shown in hexadecimal.
    • View Profile
Re: File drop
« Reply #13 on: October 12, 2015, 05:44:25 pm »
Although I've not come across a time that I have used this, it could well be the fact that I didn't have the ability to do so so it was not a considered possibility.

Generating an sf::Event idea is an extremely interesting approach.

I would like to point out that SFML isn't "games-only" as many people keep saying. If it is, this introduction should probably be altered:
Quote
SFML provides a simple interface to the various components of your PC, to ease the development of games and multimedia applications.
Selba Ward - SFML drawables
Kairos - Timing Library
Rectangular Boundary Collision - Rectangular SAT Collision

@Hapaxiation - Hapaxia on Twitter

Nexus

  • SFML Team
  • Hero Member
  • *****
  • Posts: 6194
  • Thor Developer
    • View Profile
    • Bromeon
Re: File drop
« Reply #14 on: October 12, 2015, 11:02:16 pm »
I would love to see drag and drop implemented because it is a common interaction in Windows, Linux and Mac, and certainly even more OS.
Would you also be willing to draft an API, write an implementation, test it on various platforms, get feedback, and maintain it even 2 years later when new bugs appear? I'm not saying this alone would help the feature be integrated, but you should be aware that there's more to it than just "hey this would be nice, please implement it". This without considering the dozens of more important tasks at the moment, and the questionable scope of the feature itself ;)

I would like to point out that SFML isn't "games-only" as many people keep saying. If it is, this introduction should probably be altered:
People keep saying that SFML focuses on games, not that it is games-only. And this still holds true, most applications written with SFML are games. The user base is indeed a factor we consider when thinking about what needs to part of the library or not.
Zloxx II: action platformer
Thor Library: particle systems, animations, dot products, ...
SFML Game Development: first SFML book