Why does file dropped provide the full file path

[yintercept]

When things like newImage only accept relative paths/file names?

It means whenever you load something from a drop event you have to go through the process
of parsing the full path just to get the filename for use in other functions like creating newImage.

[slime]

The full path – and even the partial path – of dropped files isn't usable with love's APIs, it's mainly there for reference/display purposes. You can, however, read the contents of the file into a FileData (using File:read), and then load that into an Image via love.graphics.newImage(filedata).

For dropped folders, and for dropped zip files, you can also pass the folder or file's full path into love.filesystem.mount, which will let you read from that folder or zip file with love.filesystem just like you can read from the game's source directory (other full paths won't work, only ones that have been obtained via a drop event).

[ivan]

Also, the dropped file could be on another HDD/partition so a relative path wouldn't work in that case.
Lua's io library accepts absolute paths so you could still access that file.

[raidho36]

PhysFS works with a virtual filesystem (ironically enough). That's normally your .love ZIP archive plus the save folder. Physical folders on users' storage devices are inaccessible, with sole exception for dropped files.

There's a good reason for this. LOVE is a game-specific framework, intended only for making games. Even professional game developers screw up raw filesystems sometimes, and amateurs tend to just spread crap all over the host filesystem so can't be trusted with it. It also prevents rookie mistakes like hard-coding absolute paths to game files, which then requires that the game is installed in exactly specific folder (and even hard drive) for no reason at all. And it handles different OSes filesystem conventions (i.e. your asset and save folders) transparently.