Re: GNOME and file selection boxes

[Felix Bellaby <felix pooh u-net com>]

Stuart Parmenter muttered in a separate thread:
> Ok, there seem to a an AWFUL lot of modules in CVS.  (most of which I don't
> have any idea what are/do)
[clip]
> just wondering.  it seems like a waste to have so many directories with so
> little organization

Hmm...  And I rather think that gnome is planning on organising its
document naming model around directory trees... :P

It is extremely difficult to arrange a project like gnome in a way
that is "obvious" and "right" for all the people using it. The general
adoption of concurrent working in most work places means this is a
widespread problem (if usually on a smaller scale :o).

Even looking at my "home" home directory, I have to ask what happened
to the clean up I did a few weeks ago. It is just too easy to drop
files in arbitrary places with cryptic names. We have all seen dos
systems with 90% of the documents stuck in one directory and given
names like "repm2jul.doc". Long filenames and directories should help 
but do end users really use them ? DO YOU ? HONESTLY, for ALL your
docs ?

Does this problem have a solution ? Perhaps not :=(

However, I think it deserves some thought. If GNOME ties us to a 
directory tree naming model for documents then there is little
prospect of any progress being made. At least with a degree of 
flexibility built into the GNOME standard there is hope that things 
might improve. Using directory trees would also hinder GNOME from
migrating to other storage media like databases ( (: ).

What kind of flexibility could GNOME implement ? 

On the API side, we need a naming system that can be universal, can 
incorporate directory trees and is already a standard. The Baboon
module already includes a non-standard naming system which is a cut 
back version of the CORBA naming service so why do not we use the 
CORBA naming service to name documents ? These names could be hidden
from non-CORBA software by providing handling functions in libgnome.

In addition a means to access the data in a document starting from its
naming context name is essential. There are a vast number of ways of
doing this including several standard CORBA services. A quick fix for
the moment would be an API call that opened whichever file matched the 
document name. In the longer term, the document names could identify
document parts rather than files (making OLE rather cleaner) or even
individual peices of data used by document parts.

On the user side, we need a translation service from user names
to API names that can be used for all documents accessed by the 
user. This translation service should accomodate extensions and 
support translation from existing strings:

	CosNaming::Name translate_user_doc_name (User user, 
						 string user_name);

and direct access to the user via replaceable document selection boxes:

	CosNaming::Name get_doc_name_direct (User user, ...); 

The second function would need parameters which could tie down the
user to selecting certain forms of document and an intelligent way
of discovering the right kind of selection box to display to each user. 
Both of these problems sound like areas where the CORBA trading
service would provide a distributed solution. Something less ambitious 
might suffice but this is not the first proposed use of the trading.

A decision on how documents are named by the API needs to be taken 
quickly because there is already a lot of software that assumes 
filenames are "The Right Thing". Implementing flexible user names only
really requires the fixing of an API for the translation service and
the long haul of getting everyone to use it. The translations
themselves can be trivial until we think of something better. 

Do you think any of this is worth the effort ?

Felix

PS I have just thought of something better than trivial translations. 
How about i18n of filenames ? It would be nice if the .desktop files 
had their names translated using gettext.