The Future

Current and future work


Better AppDir support

Better core App Dir support

Currently ROX-Filer uses the function rox_spawn() to start other programs. However it does not directly support App Dirs, each caller to rox_spawn() must do that itself and not all do. This means only partial support for our own format!
We should re-write rox_spawn() to directly support App Dirs itself, removing that burden from its callers. The various libraries should also support it.


This is a long-term plan for how to handle configuration in ROX.

  • Use the config system when it's ready.
    This stores settings in a similar way to ROX, but using XDG_CONFIG_DIRS in place of CHOICESPATH (default is
    ~/.config rather than Choices, but you can use anything). D-BUS is used to send notification of changes,
    and to send settings to remote applications.
  • Move options user interfaces out of ROX-Filer and ROX-Session and have them run small Python applications
    when the user chooses Options from the menu. The change notification means that changes to the settings will
    still be instant effect.
  • Move non-session-related options out of ROX-Session's Options box and into a number of separate applications
    (DisplaySettings, MouseSettings, etc). They're only in there at the moment because the XSettings system requires
    a single application to set all XSettings.

Road map:

  1. Make ROX-Session start a D-BUS session on login (done)
  2. Migrate to storing choices using basedir spec (done)
  3. Help with config system.
  4. Get ROX-Lib to use new config system.
  5. Get ROX-Filer and ROX-Session to use ROX-Lib for options. The filer's options box should also be split (so that you only see pinboard options when opened from the pinboard menu, etc).

Note: Just to be clear on this: the idea is not to centralise the user interface (regedit, etc), but only to rationalise the storage of the options (they already get saved outside the applications). Whenever this comes up, someone suggests having a 'control centre' application where all the options for all applications go. This might be a fun programming exercise, but it's terrible UI, rather akin to moving all the light switches in your house to a single room (neat, but annoying).

So, if you're looking to configure ROX-Filer, you'll still get to the options through the ROX-Filer application directory (the same object you use to run it, read the documentation, etc). Separate configuration applications should be created only where there isn't already an application obviously associated with those options (eg, the default font or screen resolution).

2004-04-13 All the XSettings options have been moved out of ROX-Session and into a new python applications, which communicate with ROX-Session using D-BUS (which ROX-Session now starts on login). Find them in /uri/0install/

Drag-and-drop saving in all GTK applications

Can I get drag-and-drop saving in all my Gtk+ applications?

See httpthis feature request. Feel free to add a comment if you want this. Type the comment into
the box marked `Additional Comments' and click on the `Save Changes' button.
In the mean-time, Stephen Watson has created some tools to make converting existing programs easier: This was for
GTK+ 1.2, not the current GTK+2.2. In any case GTK+ 2.4 will have a different load/save interface.
The Gimp now (version 2.3.x in CVS) does drag-and-drop saving from the toolbar, if the preview widget is enabled there. They can't do it using the save box, due to GTK limitations:

http autostart

A draft of the Autostart Specification has appeared. Possibly we should support it.

On the other hand, it requires .desktop files and doesn't support application directories, so it might not be useful for us.

Icon themes

ROX-Filer lets you choose an icon theme from a menu in Types section of the Options box, allowing you to theme all your icons at once. There is a standard for icon naming, which should allow us to share themes:

However, we still cannot share themes (although this has improved with recent Filer versions) because the icon names are inconsistent (we implemented one version of the spec, but it changed again).

It seems that there is now a (conflicting) icon naming specification too.

Restrict read/write access to dragged files

Is there a way of restricting read/write access to files to drag and drop?

The idea is that my application is effectively put into a chroot-like prison (perhaps, with the exception of a configuration directory with quota, say), so that I have full control over which files can be actually accessed. After a second thought, this is probably an old idea floating around in this community, but I have not found any hints, yet.

This is a good idea, but the problem is always with the X server. Any X application can listen for events (key logger) or create them. So, a sandboxed program can just searh for an xterm and start typing commands! Apart from that, there's nothing stopping you doing it now (you can even run the program on a different machine; it can still get the dragged data, provided host names in DnD are turned on in ROX-Filer's config box).

See Plash: the Principle of Least Authority shell for an experimental implementation of this.

Shared MIME run actions

This is about offering the user a list of applications which can open a particular file. Ideally, applications should be able to add themselves to this list in a way that can be picked up by all desktops. Also, the user's preferred handler for opening a particular type should affect all applications.
See http

Shared default shortcuts

Every application running should use the same keys for Save, Quit, etc.

The File menu

The file menu is really getting too long now. We should probably hide items that don't apply and think about removing unneeded items (eg, 'Count', now that Info does it). -- Thomas Leonard
It does need pruning, but I'd prefer not to hide items. It's better if the menu layout doesn't change each time it appears. -- Stephen Watson
Right, although some things change anyway (eg, Shift Open is displayed as 'Open as Text', 'Mount', etc). There's also a new menu API going into GTK at the moment, but I haven't looked into it. -- Thomas Leonard


  • Look Inside and Open AVFS really do the same thing, but one for files and one for apps.

- Send To is really just to help people find it if they didn't read the manual. Noone actually uses it (apart from binding a key to it).
I beg to differ! :-) That "bind to key" aspect is important because, without an explicit menu entry, there's no easy way to bind the key. In any case, the File menu is the obvious place for Send To (see the FAQ at the end of this page, for example) -- John Pettigrew

  • Count and Permissions should be moved to Info (which becomes Properties). Need a way to report errors while counting. Have a Permissions button for directories for the full interface?
  • Need extra items for multiple-selections (bulk rename, permissions, etc).
  • Move Find somewhere else, so it works on everything by default?
  • The panel and pinboard File menus should match the main one.

Trash / recycle bin / undelete feature

Instead of asking users whether they really want to delete something irreversably, we should simply move it to a trash directory and offer the user the chance to undo the action if it was a mistake.

Perhaps we can use The Trash specification?

Virtual File System

  • Since 1. AVFS is outdated, 2. gnome-vfs restricts the opening of files to programs supporting it and 3. FUSE is Linux-only yet, I would like to suggest some kind of "open" vfs layer that enables the user to use whatever VFS he could lay his hands on. -- Alex Kloss
  • Freedesktop are planning a new cross-desktop VFS: see http

When 'show iconified windows' is on, show thumb

Suggestion: in options, when 'show iconified windows' is on, add:

  1. make a snapshot (thumb) of the minimized window and use it as icon (toggle)
  2. show only iconified windows of current workspace (toggle) (done in ROX-Filer 2.3)

I like that idea. They would help the user have a better idea of what the minimized folder was, and it would help disinguish more clearly the fact that the minimized program in question is, in fact, a minimized program and not a shortcut. --James Gecko

Rejected ideas

  • Keep the path entry minibuffer open at all times. We had a patch for this, but it turned out it wasn't useful (even the original author requested it be removed). Pressing / is pretty easy.
  • Back and Forward browser-type buttons. Again, we had a patch for this and again it was decided to remove it. The extra buttons make the interface much more confusing for very little gain. See the 'Recently Visited' submenu from the bookmarks button for an easier way to backtrack.
  • Have a script (App Dir/AppBoot) that gets run when you open a filer window showing the application (like RISC OS did). This is a massive security risk. Some people suggest reducing what the script can do (eg, only setting environment variables). It doesn't matter; any change is a security risk (setting PATH is an obvious example, but even something 'harmless' like BROWSER will allow anyone to hijack your machine the next time you try to view a URL).