On 10 Jan 2008, at 18:53, Greg Ercolano wrote:
> On my system I have LANG and LOCALE unset.
>
> I made sure firefox (2.0.0.11 in this case) wasn't already running,
> and fired it off from the fedora3 command line after first doing
> an echo $LANG ; echo $LOCALE which were both undefined.
This seems most odd - I've been testing this on my F7 box, and both
Firefox and Seamonkey return multi-byte characters, exactly as Greg
describes.
This is particularly puzzling as I have gone to some lengths to
ensure my settings are specifically UTF-8, yet they are both
returning something that is clearly *not* UTF-8. I suppose it *might*
be UTF-16, or UCS-2, or perhaps some other random MBCS encoding... I
haven't (yet) tried generating any strings that would trigger the
upper byte to be non-zero, but I imagine if I did I could probably
take a guess at what the actual encoding is... But why's it not just
UTF-8, though? Odd.
Another thing I notice is that both Firefox and Seamonkey pass the
text as:
file:///path/to/image.jpg<NL>
File:image.jpg
It's not all that obvious to me why the basename is passed twice -
seems redundant.
Nautilus, meanwhile, (I've got gnome running on this box and am using
nautilus as my file browser) seems to pass the Right Thing.
Also, the gnome terminal seems happy - dropping a filename onto it
from any of the browsers, it seems to cope just fine, so clearly it
understands and knows how to interpret the various encodings.
Anyway, in other News: OSX - not good. Specific issues are:
- whilst Fl::event_text(), Fl::event_length() have valid values when
the handle() method receives FL_DND_RELEASE, they frequently (but not
always!) are empty by the time that dnd_open() runs... In general,
they seem to be empty, a few times they seem to be not empty, but
filled with garbage...
- dnd_open doesn't check that urls in non-null, so segfaults may ensue.
- the string passed from Safari (and I think Finder) has no trailing /
n, so the code that counts the passed urls returns zero for a single
file, 1 for 2 files, etc... Therefore, a single file is always
rejected (it looks like zero files!) I guess a more robust counting
scheme is needed!
- the value in event_text seems fine (when you get it!) - I think it
really is UTF-8, so it works fine without the multi-byte workarounds.
Dropped from Safari, it looks like file:///path/to/image.jpg which is
good. Dropped from Finder it seems to be just a bare path, which
again is fine.
- Greg's tweak to handle file:// prefixes also segfaults. Alvin's
version works. The difference seems to be that, when passed the string:
file:///path/to/image.jpg
Greg strips the "file:" off so it becomes
///path/to/image.jpg
which seems to cause OSX some problems.
Alvin instead strips "file://" off, leaving just
/path/to/image.jpg
Which of course is OK.
More comments to follow, if I get the time...
Cheers,
--
Ian
_______________________________________________
fltk mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk
