[Thunar-dev] Spatial or not-spatial?

Benedikt Meurer benedikt.meurer at unix-ag.uni-siegen.de
Fri Mar 4 17:40:21 CET 2005


Jari Rahkonen wrote:
>>> I'm sorry to butt in, but I'm a bit confused. You're right in that
>>> the amount of data is increasing in both the web and modern
>>> filesystems, but that seems to me to be the only major similarity
>>> between the two.
>>
>> Its the only similarity we are interested in. You can compare other 
>> aspects of WWW and local file systems, but that won't probably help in 
>> discussion of Thunar.
>>
> And why is this one aspect the most relevant? That's what I didn't get. 
> This
> makes me wonder; what do you people use file managers for? I know I don't
> use them to find stuff, but to manage (Move, Copy etc.) and open files 
> (with
> relevant software). I'm very sorry if I'm missing the whole point here. I
> just think there's more to it than a difference in scale. They don't call
> browsers web managers, right?

No, I don't you miss the point here. The file manager is primarily meant to

  a) Browse file system
  b) Manage files
  c) Open files
  d) Manage desktop

(see http://thunar.xfce.org/wiki/design:analysis). For a) to c) you 
first need to get to your files, which you can do traditionally by:

  a) clicking through the icon/list view
  b) clicking through the tree view
  c) using the location bar or the open location dialog

While these 3 methods are common today, they are only suitable for 
relatively small amounts of data. a) involves a lot of clicking around 
and scrolling through the view, while the treeview involved in b) is not 
very helpful if you have deeply nested directories. c) is only useful if 
you know where to look into, which is seldomly the case - if you can 
remember all your file locations, then you are lucky, but take into 
account that others might have more data on their file system.

So, the 3 classical attempts listed above are nice and - most of the 
times - fast if you have only a few files/directories or if you are very 
used to the stuff you are browsing. But if your collection of files is 
increasing in size or if you have to manage stuff from others, a query 
interface becomes handy, where you can simply tell the file manager to 
do the "looking around" work for you and spend the time you'd have 
wasted searching for a particular file doing some real work instead or 
whatever.

Hope that explains the use-case. ;-)

>>> I search the web to find data. I search my file system to locate
>>> a certain file or to find certain types of files.
>>
>> I dunno about your files, but usually files contain data and thats 
>> their whole purpose *IMHO*, so it doesn't matter if data is contained 
>> in a local file or a webpage, its just the data that you are 
>> interested in not the container.
>>
> I understand that the point is to separate the process of file managing
> from the underlying architecture to make it more intuitive. Files are just
> containers for data, and the data is really the only thing important here.
> You're right there. So the filesystem is just a big database just like the
> internet, and a database cannot be used efficiently without a query
> interface. In the end you shouldn't need to worry about directories, files
> and whatnot at all because the data content is all that is important.

Damn, you explained it yourself, I should read the whole mail before 
starting to answer. :-)

> But wouldn't this kind of difference in file/data management implicate
> large changes in the whole operating system UI? How would a filemanager
> that does things differently (intuitive or not) from all the other
> software (and I don't mean other file managers) make things easier for the
> user?

(Smile while you read the following paragraph)

I'd call this a "Silent Upgrade": We'll simply ship the new features in 
the UI together with some kind of legacy UI (to allure users), and 
upgrade the user's minds to the new UI without explicit notice on the 
users side and in the end the user will be addicted to the new UI. ;-)

> - Jari

greets,
Benedikt




More information about the Thunar-dev mailing list