Strip leading "file://" before fl_filename_absolute()

[dannye]

At least on Linux, drag-n-drop'ing a blk file onto the workspace fails to locate the Makefile, because the filepath of the drop event begins with "file://" (unlike when selecting the blk file from the open dialog) which fl_filename_absolute() doesn't seem to handle correctly.

For example, file:///home/daniel/gb/pokered/maps/CeladonCity.blk becomes /home/daniel/gb/polished-map/file:///home/daniel/gb/pokered/maps/CeladonCity.blk

[Rangi42]

On some X11 platforms, files are received as a URL-encoded UTF-8 string, that is, non-ASCII bytes (and a few others such as space and %) are replaced by the 3 bytes "%XY" where XY are the byte's hexadecimal value. The fl_decode_uri() function can be used to transform in-place the received string into a proper UTF-8 string. On these platforms, strings corresponding to dropped files are further prepended by file:// (or other prefixes such as computer://).

https://www.fltk.org/doc-1.3/events.html

(There doesn't seem to be a function to strip whatever protocol a path starts with, but I can at least check for file:// and computer:// manually.)

[aaaaaa123456789]

(There doesn't seem to be a function to strip whatever protocol a path starts with, but I can at least check for file:// and computer:// manually.)

And if there was, you wouldn't want it, because you can get other stuff dropped too. For instance, my file manager, Nemo, can open an archive as if it was a directory — the files within get assigned synthetic non-file:// URLs. (This is the reason to use URLs in the first place.)

There are tools on the system to resolve arbitrary URLs like that, but I doubt you want that.