[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: An idea for integrating Unix filesystem and GUI

Brenden T. wrote:
James G wrote:

> I think that this is unfortunate, and that the Unix file system is not far from being suitable as the foundation
> for a GUI. ... I think that the addition of three new directories within the root directory would be a
> significant step towards making the Unix file system a suitable scheme for building GUIs upon.

Well, I like your idea, I think it has merit. Certainly Apple seems to have had good success with a similar technique with their file browser. Having a standard that OS file browsers could standardize on might assist Linux acceptance on the desktop.

Here's a few questions I have for the list:

1. Is anyone working on anything similar? It does no good I think to be redundant or work at cross-purposes, perhaps there is an existing project that already aims to provide this feature.

2. Assuming that the answer to 1 is "no", would anyone be interested in seeing a standard for a "desktop file system hierarchy" developed? Would anyone participate in such a project, at least for feedback and critique?


Frankly, it's a short sighted attempt. It does somewhat resemble the presentation system on the microsoft desktop. But microsoft has moved on in their technology. The scheme is supposed to be `everything is a database`. You can _query_ the system for information on localhost or localnet, or for things like printers and shares available to you. It does not matter where that information is physically. In contrast, the given proposal asks for a physical expression of information in various categories. Don't do that. Use a presentation layer and build configuration entities that guide the query processing.

For those config places you might need a physical expression but it
can be local or remote again, so just push it through a config system
layer. - Now wheeew, there are config system layers beneath modern
desktops, just who is writing services that can be queried and who is
writing the query processor, who is going to define the api of the
query processor, and also builds a gui applet that shows the power of
it. I wouldn't mind if it looks like the xp applet shipped for a few
years, it doesn't serve the purpose of distributed unix domains but
it would be a good start.

Note that it is not strictly problematic since there is many an xml
based technology at hand to fold into such a system, making config
files, config queries, query transformations, result transformation,
result visualization. May be that's the reason no nerd has implemented
an instance so far, well, may be, it needs a certain skill about
these technologies but at the same time one does not present much
of a new invention to the world. Just plain two month engineering
work but all engineers are in a paid job somehwere...

have fun,
-- guido                        http://google.de/search?q=guidod
GCS/E/S/P C++/++++$ ULHS L++w- N++@ d(+-) s+a- r+@>+++ y++ 5++X-

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]