Preserve user/system-configured C_FLAGS.
This broke the rpm package build on fedora: They enable a hardened config (i.e. ASLR) by default, which adds -pie and -fPIC to linker and compiler flags. Overwriting C_FLAGS removed the compiler spec, but not the linker one, leading to an error like:
/bin/cc -std=gnu99 -Wall -ggdb -pedantic -specs=/usr/lib/rpm/redhat/redhat-hardened-ld CMakeFiles/mkdata.dir/tools/mkdata.c.o -o mkdata -rdynamic
bin/ld: CMakeFiles/mkdata.dir/tools/mkdata.c.o: relocation R_X86_64_32 against `.rodata' can not be used when making a shared object; recompile with -fPIC
CMakeFiles/mkdata.dir/tools/mkdata.c.o: error adding symbols: Bad value
With this fix, the error is gone:
/bin/cc -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -std=gnu99 -Wall -g -ggdb -pedantic -specs=/usr/lib/rpm/redhat/redhat-hardened-ld CMakeFiles/mkdata.dir/tools/mkdata.c.o -o mkdata -rdynamic
When the dialog is opened, the text area is focused. When enter is
pressed (and the form is submit) the window now behaves as expected and
adds the stream to the playlist and closes. The text area is now also
cleared once the form is submit, previously the old stream was still
visible when the dialog was opened a second time.
Fix the bug I've introduced in my PR #78, breaking the add
track/playlist action. We have to decode URIs before sending them back
to our socket!
fixes#80
Previously, browsing entities with non-ascii characters in their URI
under Safari wouldn't work. Directories would be empty, songs wouldn't
be added. I haven't tried it, but this behavior seems to be common to
Webkit-based browsers, so Chrome would be affected too.
This turned out to be because Safari normalizes all unicode strings to
NFC, breaking the link with MPD-spewed URIs, which are in NFD.
An obvious fix would have been to normalize all URIs to NFD, but
unfortunately, Safari doesn't have `str.normalize()`. Adding
normalization capabilities to our JS side would have involved
introductiing libraries such as `unorm`, which is rather big.
We could have done it on the C side, but it involves introducing `icu`,
which is far from trivial too.
After much fussing around, I stumbled on a simple solution: URI-encode
our URI when creating our browser table row. This magically prevents
Safari from trying to mess with our unicode form before we get the
chance to send it back to our server.
