RFC: about DnD of filenames to an FLTK app

[Manolo]

When files are dragged from a file manager window to an FLTK app,

platform-specific behaviours are presently as attached.

I don't remember what X11 configuration produces "file://" prefixes

and URI-encoded filenames. That's not what I see now.

Shouldn't we uniformize this and have the X11 platform behave as

all others do, that is, put pathnames on separate lines without encoding

nor prefixes ?

That would make 1.4 slightly changed relatively to 1.3 in behaviour

but not in API. Nevertheless, user code that would decode encoded

filenames or that would remove "file://" prefixes would just do nothing

with the uniformized behaviour. Existing 1.3 code would be largely compatible

with the modified 1.4 behaviour with no change. The only difference

would be that an app expecting multiple pathnames on a single line would

receive them on successive lines.

Comments? Suggestions?

[Albrecht Schlosser]

On 3/6/23 11:29 Manolo wrote:

When files are dragged from a file manager window to an FLTK app,

platform-specific behaviours are presently as attached.

I don't remember what X11 configuration produces "file://" prefixes

and URI-encoded filenames. That's not what I see now.

This behavior very likely depends on the file manager that issues the drag-n-drop operation.

Shouldn't we uniformize this and have the X11 platform behave as

all others do, that is, put pathnames on separate lines without encoding

nor prefixes ?

Yes, that would be a good simplification of the required user code.

That would make 1.4 slightly changed relatively to 1.3 in behaviour

but not in API. Nevertheless, user code that would decode encoded

filenames or that would remove "file://" prefixes would just do nothing

with the uniformized behaviour. Existing 1.3 code would be largely compatible

with the modified 1.4 behaviour with no change.

I believe that this would be a minor issue (users could easily account for this).

The only difference

would be that an app expecting multiple pathnames on a single line would

receive them on successive lines.

That might be a bigger issue. It could impact parsing files in user code.

Comments? Suggestions?

Another thing I'm not sure about is removing and thus hiding the prefixes like "file://" or "computer://". Maybe there is some significant information in these prefixes that some programs are using for whatever reason (I don't know one, but anyway).

Here are some examples, created with three different file managers (nemo, nautilus, thunar) and the FLTK editor example program in Wayland and/or X11 mode:

nemo DND to FLTK editor in Wayland mode:

davs://info%40<my_domain>@webdav.<my_cloud>/users/<my_domain>/fltk/glpuzzle.png

davs://info%40<my_domain>@webdav.<my_cloud>/users/<my_domain>/fltk/keyboards.png

nautilus DND to FLTK editor in Wayland mode:

file:///run/user/1000/gvfs/dav:host=webdav.<my_cloud>,ssl=true,user=info%2540<my_domain>/users/<my_domain>/fltk/glpuzzle.png

file:///run/user/1000/gvfs/dav:host=webdav.<my_cloud>,ssl=true,user=info%2540<my_domain>/users/<my_domain>/fltk/keyboards.png

thunar: No DND and no copy/paste to editor with in Wayland mode

thunar DND to FLTK editor in x11 mode (see note 2 below):

file:///run/user/1000/gvfs/dav:host=webdav.<my_cloud>,ssl=true,user=info%2540<my_domain>/users/<my_domain>/bilder/Screenshot%20from%202020-05-30%2021-20-16.png

file:///run/user/1000/gvfs/dav:host=webdav.<my_cloud>,ssl=true,user=info%2540<my_domain>/users/<my_domain>/bilder/Screenshot%20from%202020-12-22%2022-52-41.png

thunar copy-paste to FLTK editor in x11 mode (see note 2 below):

davs://info%40<my_domain>@webdav.<my_cloud>/users/<my_domain>/bilder/Screenshot%20from%202020-05-30%2021-20-16.png

davs://info%40<my_domain>@webdav.<my_cloud>/users/<my_domain>/bilder/Screenshot%20from%202020-12-22%2022-52-41.png

(End of examples)

Note 1: I replaced all personal parts with '<...>' including the '<' and '>' characters which are not part of the original string.

Note 2: I succeeded in using 'thunar' in one example but couldn't reproduce it later. I didn't investigate further.

Maybe we could make this behavior change optional or provide a function/method like "normalize_filename_list()" with different options which parts to "normalize" and which ones not. It could also help to provide a "parse_filename()" method that could split the filenames in their distinct parts like prefix, host, directory, filename, or something similar.

Just my 2 ct.

[Manolo]

Le lundi 6 mars 2023 à 17:52:49 UTC+1, Albrecht Schlosser a écrit :

Here are some examples, created with three different file managers (nemo, nautilus, thunar) and the FLTK editor example program in Wayland and/or X11 mode:

nemo DND to FLTK editor in Wayland mode:

davs://info%40<my_domain>@webdav.<my_cloud>/users/<my_domain>/fltk/glpuzzle.png

davs://info%40<my_domain>@webdav.<my_cloud>/users/<my_domain>/fltk/keyboards.png

nautilus DND to FLTK editor in Wayland mode:

file:///run/user/1000/gvfs/dav:host=webdav.<my_cloud>,ssl=true,user=info%2540<my_domain>/users/<my_domain>/fltk/glpuzzle.png

file:///run/user/1000/gvfs/dav:host=webdav.<my_cloud>,ssl=true,user=info%2540<my_domain>/users/<my_domain>/fltk/keyboards.png

thunar: No DND and no copy/paste to editor with in Wayland mode

thunar DND to FLTK editor in x11 mode (see note 2 below):

file:///run/user/1000/gvfs/dav:host=webdav.<my_cloud>,ssl=true,user=info%2540<my_domain>/users/<my_domain>/bilder/Screenshot%20from%202020-05-30%2021-20-16.png

file:///run/user/1000/gvfs/dav:host=webdav.<my_cloud>,ssl=true,user=info%2540<my_domain>/users/<my_domain>/bilder/Screenshot%20from%202020-12-22%2022-52-41.png

thunar copy-paste to FLTK editor in x11 mode (see note 2 below):

davs://info%40<my_domain>@webdav.<my_cloud>/users/<my_domain>/bilder/Screenshot%20from%202020-05-30%2021-20-16.png

davs://info%40<my_domain>@webdav.<my_cloud>/users/<my_domain>/bilder/Screenshot%20from%202020-12-22%2022-52-41.png

(End of examples)

I'm afraid these examples didn't use the last code for Wayland which changed yesterday.

Wayland now produces the same as Windows and macOS, that is pathnames, one per line, except for special

prefixes such as "davfs://" that produce as in these examples.

There's something strange in some encoded strings visible above such as "user=info%2540<my_domain>" .

This seems to have been encoded twice, and thus to require being decoded twice to come out correctly.

1st decoding: %25 gives % because 0x25 is the codepoint of %

2nd decoding: %40 gives @ because 0x40 is the codepoint of @

Final result: user-info@<my_domain>

The correct encoding in one go I would have expected to see is "user-info%40<my_domain>".

 

[Albrecht Schlosser]

On 3/7/23 18:14 Manolo wrote:

Le lundi 6 mars 2023 à 17:52:49 UTC+1, Albrecht Schlosser a écrit :

Here are some examples, created with three different file managers (nemo, nautilus, thunar) and the FLTK editor example program in Wayland and/or X11 mode:

nemo DND to FLTK editor in Wayland mode:

davs://info%40<my_domain>@webdav.<my_cloud>/users/<my_domain>/fltk/glpuzzle.png

davs://info%40<my_domain>@webdav.<my_cloud>/users/<my_domain>/fltk/keyboards.png

nautilus DND to FLTK editor in Wayland mode:

file:///run/user/1000/gvfs/dav:host=webdav.<my_cloud>,ssl=true,user=info%2540<my_domain>/users/<my_domain>/fltk/glpuzzle.png

file:///run/user/1000/gvfs/dav:host=webdav.<my_cloud>,ssl=true,user=info%2540<my_domain>/users/<my_domain>/fltk/keyboards.png

thunar: No DND and no copy/paste to editor with in Wayland mode

thunar DND to FLTK editor in x11 mode (see note 2 below):

file:///run/user/1000/gvfs/dav:host=webdav.<my_cloud>,ssl=true,user=info%2540<my_domain>/users/<my_domain>/bilder/Screenshot%20from%202020-05-30%2021-20-16.png

file:///run/user/1000/gvfs/dav:host=webdav.<my_cloud>,ssl=true,user=info%2540<my_domain>/users/<my_domain>/bilder/Screenshot%20from%202020-12-22%2022-52-41.png

thunar copy-paste to FLTK editor in x11 mode (see note 2 below):

davs://info%40<my_domain>@webdav.<my_cloud>/users/<my_domain>/bilder/Screenshot%20from%202020-05-30%2021-20-16.png

davs://info%40<my_domain>@webdav.<my_cloud>/users/<my_domain>/bilder/Screenshot%20from%202020-12-22%2022-52-41.png

(End of examples)

I'm afraid these examples didn't use the last code for Wayland which changed yesterday.

Wayland now produces the same as Windows and macOS, that is pathnames, one per line, except for special

prefixes such as "davfs://" that produce as in these examples.

I didn't intend to show "exact" examples. I only wanted to point out that I can see different formats as provided by different file managers on the same system.

There's something strange in some encoded strings visible above such as "user=info%2540<my_domain>" .

This seems to have been encoded twice, and thus to require being decoded twice to come out correctly.

1st decoding: %25 gives % because 0x25 is the codepoint of %

2nd decoding: %40 gives @ because 0x40 is the codepoint of @

Final result: user-info@<my_domain>

The correct encoding in one go I would have expected to see is "user-info%40<my_domain>".

Yes, I see. The problem with this is that the sender encodes the data, and there may be inconsistencies.

Another issue is obviously the string

  "davs://info%40<my_domain>@webdav.<my_cloud>/users/<my_domain>/fltk/glpuzzle.png"

where you can see one '%40' and one literal '@' which is really weird.

After seeing these issues I wonder if it's useful to try to "decode" these strings in FLTK because we'd have to answer questions why a particular string is not decoded as "expected". If we leave them as-is we can always say that these strings are exactly as sent by the file manager or whatever program encoded them.