| |
| |
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:
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):
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.
--
You received this message because you are subscribed to the Google Groups "fltk.coredev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fltkcoredev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fltkcoredev/e481d395-b5f6-c92b-4c62-040bd0781467%40online.de.
[ Direct Link to Message ] | |
|
| |
