Slashdot Mirror
ROX Desktop Update
tal197 writes: "More than two years since the ROX desktop (a desktop based around the filesystem) was last
mentioned on slashdot, the second stable branch of the central
ROX-Filer
component has just been released. It's still pretty light and fast, despite all the
changes, and integrates well with other desktops too."
I tried it via X11 redirection on my iPAQ (running Familiar GNU/Linux). It wouldn't take much hassle to make ROX the ultimative PDA environment: ROX is lean as in resources as well as in screen space, it's very functional and flexible, and it can be used with a stylus or with a one-key mouse.
What I like so much about the ROX-Filer is that is acheives the useful functionality of Gnome/KDE without the cruft, so it goes unbelievably fast.
/usr/local/bin for command-line support. Removing a package is as simple as removing those three folders. Of course, the AppDirs don't run as cleanly under command lines and library tools, but there is a patch to bash to support AppDirs and ROX-Lib demonstrates well how libraries can work in this system. In the meantime scripts that wrap AppRun calls are easy enough to place in the path.. I have PythonTheater (a media player designed with ROX in mind) configured in this manner (http://xtheater.sourceforge.net/)
:)
And Python programmers should take a look at ROX-Lib. The primary bit that is really cool is the really simple API for creating, accessing and modifying xml configuration files that follow the same ~/Choices/ convention that ROX-Filer follows, which seems infinitely better than the standard of polluting your home directory with dotfiles and dotdirectories... Not only that, but also will generate a nice, usable GUI to manipulate those files without the programmer having to build it by hand (though the programmer has to provide a well hinted sample xml file, but this is *far* more trivial than writing the gui out by hand). Not only does this make things easy on the developer, but also enforces consistency among apps that choose to use it.
Also, the entire concept of AppDirs is very very nice. Installing an application simply involves dragging it wherever you want, and it doesn't scatter files all over the file system, making package management a moot point. The de-facto standard has been to scatter files all over the damn place right next to other packages and this creates a huge problem package managers have been trying to solve effectively, but it is never perfect (packages occasionally make modifications not tracked by these managers). AppDir as ROX is designed around and specifies keeps package files well separated, in its own AppDir, own subdir of a system Choices directory, or per-user Choices directories. Nothing stops a bad developer from breaking this convention, but there rarely is a need, at most placing a wrapper script in
Only issue with ROX-Lib is that it is python specific, so all that cool stuff is only for python developers, but I like python too
XML is like violence. If it doesn't solve the problem, use more.
The app-directory idea is neat, but it has its problems. Some things do require a central registry of applications - like associating particular file types with particular apps. So what do you do - scan the whole hard disk at boot looking for app directories and registering them?
On RISC OS each app-directory had a file inside called !Boot which was run whenever the filer _saw_ the app. Normally this was (effectively) a shell script which set some system-global environment variables for associations with particular filetypes. Needless to say this action of silently running !Boot files was a great way to spread viruses. But surprisingly opening a directory full of apps was still pretty snappy.
This system extended to libraries - a library would usually be installed as an app directory and it would need to be 'seen' by the filer before anything using that library could find it. Later on even the temporary directory (called !Scrap) did this. That is cute - you can move the temporary directory from one place to another just by clicking and dragging - but it's a nuisance that these things have to be 'seen' on every startup. IIRC there was later some method to save a session file which would visit every application seen so far, and run this session file again next time.
Since ROX-filer is just a file manager and doesn't have to set system-wide things like file assocations, it doesn't suffer from these problems AFAIK. But is there any real _need_ for app-directories?
It seems to me that they were most useful when using a handful of floppies and maybe a small hard disk; when applications were small enough to fit on a single floppy and so just copying from one disk to another was enough to 'install' an app. But how do you deal with depedencies on a particular library version, for example? Using a package manager which can check these things looks like a good idea.
Maybe a fusion of app-directories and RPM/dpkg packages would be useful. How about a package which you can double-click on to run the application immediately, but also choose to install 'centrally' (perhaps by dragging it to some strange-looking icon at the bottom of the screen) to make it install as a package, with binaries in $PATH and all that stuff.
I dunno - I liked app directories on RISC OS, but I also like Unix-style package management with install and uninstall scripts and dependency checking. And I recognize that software packaging on Unix/Linux is more complex than it was on RISC OS or even on NextStep.
I wonder what OS X does in this area?
-- Ed Avis ed@membled.com
There are a few things you can do about this:
I may make an option so that right-clicking a file goes straight to the context menu. For most users, though, it's better to show them the whole menu every time.