Women in Technology

Hear us Roar

  Switching Back to Desktop Linux
Subject:   resource forks, virtual desktops etc.
Date:   2006-06-02 08:12:45
From:   saschabrossmann
Response to: The UI matters

the resource fork awareness problem has been fixed with tiger. all of the shell tools now deal properly with resource forks. if they still have to, that is: most applications i know have not used the resource fork for any relevant(!) data since years (say hello to windows data exchange). the only exceptions i still encounter from time to time are internet shortcuts (.webloc) and classical postscript fonts. and that's it.

concerning virtual desktops i have become quite happy with virtue (a fork from desktop manager). i still would like to see some improvements with the default terminal application, though (like window tabs, use of x11 bitmap fonts, fullscreen mode, a proper meta key, more speed, extended coluor support... for example -- otherwise i think it is quite nice)

otherwise comparing the (G)UI to x11 plus gnome/kde/whatever and some other comparisons in the article make me faintly smile... oh no, i am not going to waste my time on that topic. >;->

Full Threads Oldest First

Showing messages 1 through 1 of 1.

  • resource forks, virtual desktops etc.
    2006-06-04 19:13:24  sjk [View]

    all of the shell tools now deal properly with resource forks. if they still have to, that is: ...

    Well, that depends how you're defining "shell tools". :-)

    It's still very easy to accidentally zap resource forks if you're not careful manipulating files with many Unix commands. Any sort of stdout redirection can be troublesome, e.g. substitutions/replacements using traditional Unix commands like awk, sed, etc. since none of them (or any shells!) are resource fork-aware. Using language commands like perl, python, ruby (invoked directly or indirectly) can easily clobber resource forks. The BOMArchive GUI tool preserve resource forks but zip/unzip commands don't. Pick your poison.