I don't
need an integrated web browser for any of the other file types
Who said anything about an "integrated web browser"? Nielsen said
A key element of the Internet Desktop will be to
get rid of Web browsers as a separate application category.
which is not necessarily equivalent to providing an "integrated Web browser". He goes on to say:
The Internet Desktop will provide a framework for presentation applets that are optimized for each of the various data types accessed by the user. HTML will obviously be one such data type, and an HTML viewer will definitely be available.
(although I'm not certain that they'd all be "applets"; I'd like to see a "lines of code" or "bytes of generated code" value, with public flogging for anybody referring to anything above that value as an "applet").
A "Web browser" could (to a first order of approximation) be viewed as a combination of:
an HTML presentation widget;
code to fetch stuff via HTTP, FTP, etc.;
with the HTML presentation widget firing up the latter code if you click on a link.
Making it fairly easy for arbitrary presentation (and editing) widgets to insert links into their display, at least when they're displaying something text-based (which might involve recognizing strings that look like URLs, as some mail programs do, for example), and to cause a new window to be popped up, and to fetch a document, when the link is activated, might be a way of providing this functionality. In some sense you could, I guess, think of this as an "integrated Web browser", but it's not a case of swallowing up a separate Web browser program into other applications, it's a case of providing Internet access capability to those applications, just as file access capability is provided by OS libraries (at least in the case of the second bullet item).
(I have the impression that this may well be the way in which Internet Explorer is "integrated" into Windows - a bunch of library routines, or COM objects, exist that provide that functionality, and IE is one application that uses those routines/objects.)
Of all of these, "browsing" my computer (in the WWW sense) assists me with only two types of files: graphics, and html.
Well, I've read Word documents, graphics, source code, MP3 files, video files, etc. from links in a browser.
And if you're saying that none of those documents have links in them, well, I could imagine somebody might put links in Word documents - or source code; I've put URLs into source code for references, and it might be nice to be able to click on them and have the reference document pop up in another window.
and it would require extra work on my part to create an html document that would allow an integrated web browser to give me anything extra.
You're not presuming here that only HTML documents can contain links, I hope....
If I actually
needed a program that could view html documents, it makes more sense (to me.. my own personal opinion, of course:) to open a program that is specifically designed to read and manipulate html.
...which would be the "presentation applet" for HTML.
but I disagree that a web browser is used to look at the same information on remote computers as a local file browser. I do not use files on my local computer the way I use html files on a server, but rather more the way I use an
FTP client
Perhaps you use your browser as something like an FTP client, but that doesn't mean that everybody does. I think it would be an extremely interesting experiment to see whether one could organize a desktop around hypertext.
No, Procom have GPLed an implementation of the NetBEUI protocol, specificat ions for which have been available for a while. (Look in "The NetBIOS Frames Protocol" section of the IBM document in question - yes, IBM, who were involved in it, as well as in SMB.)
No. SMB-atop-NetBEUI is no more "native" than is SMB-atop-NetBIOS-over-TCP.
Yes, the NetBEUI headers take fewer bytes than the NetBIOS Session Service, TCP, and IP headers, but it's not at all clear that this necessarily buys you that much.
Local files, on the other hand, are created using many different types of programs, and require a seperate application to view more often than web information does.
"More often" isn't necessarily sufficient justification. The desktop environment he discusses would presumably run whatever code was appropriate for the data, regardless of whether it came from the Web or not.
Local information is being created by a single user for specialized use, with little view towards the overall structure of the filesystem. Information is usually contained within single files, with little relation to other files other than basic categories in directories.
Is that because the location information is best structured that way, or because people aren't used to structuring it as hypertext (or hyperwhatever, as a node could well not be text...), or because the tools for structuring it in that fashion are inconvenient or unfamiliar?
It may well be that structuring at least some of the stuff on your (electronic) desktop as hypertext might make it easier to keep track of.
See, for example, something Nielsen says in "The Internet Desktop":
The Internet Desktop will provide navigation as a universal support mechanism that cuts across the presentation applets. For example, the Desktop's history mechanism will allow users to return to previously seen information objects no matter what presentation applet was used to display them: the history list, bookmark list, etc. will include Internet objects, email messages, and corporate documents intermixed according to the individual user's information access behavior (each person has a single consciousness leading to a linear user experience that can structure the history of information use). There will also be some kind of universal search feature to allow users to find objects by content, though it currently not clear how to extend the search from local data to Internet data (most likely, the search will be scoped with billion-object searches reserved for exceptional cases).
The latency issue is perhaps a more severe problem, although perhaps some form of caching is the right way to handle that.
Why enter all of your money and handlings automatically when the bank can do it for you?
Because:
my credit cards aren't from my bank;
my brokerage accounts aren't from my bank.
Also, can I control into which categories the bank dumps transactions? No, I don't want their idea of which category or categories some particular credit card purchase belongs in, I want my idea.
(Also, my bank doesn't own my wallet, and I keep a record of cash transactions in Quicken 2000 - which, by the way, also implements that "dead desktop-centric model".)
The only way most people can rember what file is the birthday card you made for your son Bobby is to name it "Bobby_First_BDay" or some such.
...which doesn't necessarily help them remember where they put that birthday card - unless, say, they put all their birthday cards together.
By ditching the file extension BS you also get the bonus of using the extension for your (as user) own purposes. Name all your Family files "foo.fam" and all your porn files "naked_teen.porn".
If you have a system (desktop, OS, whatever) that can identify the type of a file in some fashion other than by its extension (e.g., by associating a file type with the file as an extended attribute, or by checking for a file type in the data at the beginning of the file), you can do that as well, without having to identify them by the first component of the pathname relative to your home/desktop/whatever directory.
Or, if you have a desktop environment that, by default, doesn't display the last component of the file name (e.g., Windows 9x/Windows NT), you can do that as well - "foo.fam.jpg" would show up as "foo.fam", and "Bobby_First_BDay.fam.jpg" would show up as "Bobby_First_BDay.jpg".
You may very well organize items based on their "topic" or "theme" but in the end you really organize them by name.
"Organize" in what sense? If I only organized them by the file name, I wouldn't have subdirectories of my home directory - the subdirectories correspond to topic.
And, in any case, I don't organize them by the application I happened to use when I last dealt with them.
Root..]/[app name]/[user]/[category]..[subcat]
As long as I can see all files associated with a given category together, regardless of what application happened to be used to create/edit the particular file.
But gnome apps want gnome DD calls, where KDE apps want KDE calls.
The calls aren't what matters for drag-and-drop; the underlying protocol is what matters. GTK+ 1.2 and Qt 2.0 both use the Xdnd protocol, and other toolkits do so or will do so as well; hopefully this will make it more likely that you can drag and drop stuff between applications. (Current versions of KDE use Qt 1.x, which doesn't use Xdnd; you'll probably have to wait for KDE 2.0 to drag/drop songs from KFM to Xmms.)
As for Netscape, it currently uses Motif; GTK+ 1.2[.x] also supports the Motif drag-and-drop protocol, but other toolkits don't, so, unfortunately, that doesn't work as well as it should. Hopefully more toolkits will also add support for the Motif protocol, if possible (so that applications using Motif and applications not using Motif can mutually drag-and-drop; no, putting Xdnd support into Lesstif, even if that's possible, won't necessarily help, as you may have to deal with statically-linked binaries for non-open-source applications, or with applications dynamically linked with Motif 2.x).
YES, you can STILL have different WM's with different look/feel, but the UNDERLYING OBJECT MODEL MUST BE STANDARDIZED!
It's not necessary to standardize the object model in order to solve the drag-and-drop problem, but the lack of a standard object model might be an issue if you want to mix KDE and GNOME stuff, as KDE and GNOME have different object models - you probably won't be able to use a GNOME (Bonobo) object inside Konqueror (the KDE 2.0 file manager) or use a KDE object inside Nautilus.
I also suspect that you're not likely to see them agree on an object model any time soon, necessary though doing so might be.
(I'm saying nothing about whether people should standardize. I'm just saying that I suspect they won't standardize the desktop object model any time soon.)
The XFree86 Project has traditionally focused on Intel x86-based platforms (which is where the `86' in our name comes from), but our current release also supports other platforms. One of our current goals is to increase the range of platforms that XFree86 runs on.
Likewise, unless you're Microsoft, you can't force anyone to use a particular widget set, UI, anything.
It's not clear you can even do that if you're Microsoft; one of the applications running on the NT partition of my home machine uses GTK+. (No, it's not the Gimp, it's Ethereal.)
One major issue comes to mind when thinking about this type of solution, installing software, how the heck is this gui going to take the place of running configure scripts, editing makefiles, and compiling/installing new software.
It's not. The sort of people who'd only use the GUI are the sort of people who'd be installing precompiled software, e.g. using Kpackage or some other package installer. If you want to install from source, you'd probably use the X application xterm, or another application of that sort.
I think they should start not from gnome, but from nothing, instead of using xfree86, create somthing truly new, xfree86 is great but i think what it does could be implemented more efficiently.
If you want to paste over then you select it, delete it, select what you want to paste in, and paste it in...
Or, if the X application is cooperative, you select what you want to cut/copy, do a cut/copy, select what you want to paste it over, and to a paste. The belief of some to the contrary, paste-current-selection is not all there necessarily is to text copying in X....
If you don't want to move your fingers off the keyboard you stay in the CLI,
Only if your GUI's keyboard-drivability is inadequate. I like it when the GUI is keyboard-drivable - if I can dismiss a dialog box by hitting the Esc key, it's quite convenient, and I can usually do that in Windows and can often do it in UNIX/X.
FreeType supports antialiasing...
...but you need more than just FreeType supporting it - you also need X supporting it, and, no, connecting X to a FreeType-based font server is not sufficient to magically make X do anti-aliasing; anti-aliasing requires multiple colors, and, unless I've misremembered, an X graphics context contains only a foreground and a background color - you'd either have to have the additional colors automatically allocated from the colormap (which might break applications), or have the toolkit that's doing anti-aliased drawing allocate the colors itself and tell the X server what colors to use (which requires an X protocol extension).
Yes. (If I weren't posting to this thread, I'd moderate your comments up a fair bit....) Existing GUIs may be better than a poke in the eye with a sharp stick (yes, I've started to use KFM on my machine at home for some documents; I find it more convenient to click on some folder icons and then click on a document than to switch to some xterm, pushd to the relevant directory, and fire up the Acrobat reader on the relevant document), but I suspect you can do a lot better than that.
This will be the next killer app that makes the next big shift in OS usage.
Assuming that it's one killer app. It may well be that the UI for office worker bees, the UI for developers (hardware, software, etc.), the UI for accountants, the UI for the "typical" home computer user (if such a person exists), etc. may be different.
(The current desktop metaphor has somewhat of an "office worker bee" feel to it - perhaps not entirely surprising, given that the Xerox Star, which was one of the first commercial systems with that flavor of UI, was a product intended for, err, umm, office worker bees, and I suspect that said worker bees were at least one of the intended markets for MacOS and Windows.
At least in the MacOS/Windows incarnation, I suspect it was also intended for standalone machines, although the Star was definitely not intended to be solely a standalone machine; a networked environment, especially one that includes not only a LAN but the Internet, may also call for some UI changes.)
The hierarchy thing *is* the groovy way to store, organise and retrieve files. Especially when you have nice things like symlinks.
"Especially" indeed. One problem with hierarchical file systems is that they're trees, not graphs; it is not necessarily the case that a given document belongs only in one place.
That's why I can usually find a file on my computer more quickly than I can find a document around my house.
I can usually find either one quickly if I know where it is - but I'm not sure that counts as "finding".
A truly "groovy" way to "store, organize, and retrieve files" would be one that would help me find files if I have some idea what they're about but don't know where they are.
My collection of documents includes saved e-mail messages, bookmarked URLs, saved netnews articles, random text files that I've filled up with notes to myself, etc.. I save a lot of e-mail messages in folders for particular topics - but sometimes an e-mail message belongs in more than one such folder (which I currently handle by saving them in multiple folders).
Perhaps a hypertext scheme would work better, in which I could have a "folder" that's actually an HTML document with text in it, plus links to said saved mail messages, links to documents on other machines, etc..
However, I might not know all the things to which a given document might pertain, or I might not know what page is relevant to something I'm working on, so even that might not be good enough; a full-text search capability might also be useful.
Source code might fit better into the conventional hierarchical directory structure, but perhaps there isn't One True Way to organize data....
From a user perspective life would be simplified. If you download a particualr graphic format it would automatically be placed in the correct directory to be "seen" by the correct graphics program.
"Simplified" only for those users who expect their image files to be stored in one location, rather than having their family pictures for the grandparents stored in one place, the pictures from last year's vacation in another place, their pr0n in another place, etc..
However, I don't file physical documents based solely on whether they're letters or pictures or financial reports or...; I file them primarily based on what they pertain to. And sometimes that even changes - reports from financial accounts may move from a folder for the financial account to a folder for a particular year's income taxes when tax time comes around, for example.
Now, if the location - in the sense of "the directory in which the files are placed" - is invisible to the user, e.g. a system where you can ask "where are all the pictures of my family" or "where are the pictures I took from my vacation last year" or..., it might work as an implementation detail.
I didn't come up with the notion of "directory trees as implementation detail, rather than end-user metaphor" on my own; others have suggested that a hierarchical directory structure might not be the best way to show a user the organization of their files. See, for example, Jakob Neilsen's The Death of File Systems paper, in which he says:
Relax, oh Nerdy Reader: I am not going to take away your beloved file-system APIs. Here I am talking about what the user experiences, not how we provide that experience. The file system has been a trusted part of most computers for many years, and will likely continue as such in operating systems for many more. However, several emerging trends in user interfaces indicate that the basic file-system model is inadequate to fully satisfy the needs of new users, despite the flexibility of the underlying code and data structures.
There is no need for users to know how their information is stored inside the guts of the computer. Indeed, the notion of a continuous file is itself an abstraction: It masks the fact that the information is normally stored on noncontiguous sectors of the hard disk. From a user perspective, current file systems are based on three assumptions:
Information is partitioned into coherent and disjunct units, each of which is treated as a separate object (file). Users typically manipulate information using a file and are restricted to be "in" one file at a time.
Information objects are classified according to a single hierarchy: the subdirectory structure.
Each information object is given a single, semiunique name, which is fixed. This file name is the main way users access information inside the object.
Window systems have made these assumptions less intolerable, but they still exist. Modern computing, particularly the Internet, is further undermining these assumptions in several ways.
Now, to get my new sound card running I had to look up the how-to, realize that my card wasn't supported, find out the how-to was out of date and that it support was just recently available (linux.aureal.com), find the drivers, compile, debug abit and then I got sound.
Yup, there's more to be fixed than just the UI; one shouldn't have to thrash around like that to get sound out of one's computer. (If one believes that the free UNIXes should only be used by those who are "smart enough" to use them, one should note that if somebody truly is "smart enough" to use a free UNIX, they're probably also smart enough to realize that their time could be better spent doing something other than screwing around trying to get their sound card to work....)
I suspect that they are preparing as a commercial product a UNIX porting layer (similar to Wine) which will allow Office and other MS products to run.
Mainsoft - the folks whose MainWin product was used for the IE4 and IE5 ports to UNIX - already have MainWin for Linux in "limited beta release". It implements an API that is "tightly controlled" by Microsoft, namely the, err, umm, Win32 API and various Microsoft APIs atop it.
With the radical redesign of OSX, it would make sense from a technical standpoint to make an OSX-specific port (probably with Carbon, since that would take the least effort).... Anyway, writing an OSX port would involve doing a lot of UN*X-ish code.
I thought the whole point of Carbon was that it was a modified version of the MacOS Classic API; would that not mean that an OS X port to Carbon would involve doing little UNIX-ish code, if any?
This means that after the initial effort of doing an OSX version of Office, it would be a relatively small effort to do versions for other Unices, including Linux.
Presumably you mean "to other Unices that support the Carbon APIs"; the only such UNIX I know if is, err, umm, MacOS X....
If they didn't use Carbon, they'd presumably use Cocoa, in which case it might involve doing some more UNIX-ish code, but would also presumably involve doing a lot of Cocoa code that wouldn't Just Port to a UNIX/X system.
What I'd like to see is a port of all the Win32 APIs and DirectX to Linux.
Such as MainWin for Linux (although I see no sign that MainWin implements the DirectX APIs)?
Hell, they'd probably go to the trouble of writing their own toolkit.
Only if MainWin (which is what was used for the IE 4 and IE 5 ports to various UNIXes) won't do the trick. (I.e., they may just let Mainsoft write the toolkit in question for them, given that Mainsoft have already done so....)
Slashdot Mirror
Who said anything about an "integrated web browser"? Nielsen said
which is not necessarily equivalent to providing an "integrated Web browser". He goes on to say:
(although I'm not certain that they'd all be "applets"; I'd like to see a "lines of code" or "bytes of generated code" value, with public flogging for anybody referring to anything above that value as an "applet").
A "Web browser" could (to a first order of approximation) be viewed as a combination of:
with the HTML presentation widget firing up the latter code if you click on a link.
Making it fairly easy for arbitrary presentation (and editing) widgets to insert links into their display, at least when they're displaying something text-based (which might involve recognizing strings that look like URLs, as some mail programs do, for example), and to cause a new window to be popped up, and to fetch a document, when the link is activated, might be a way of providing this functionality. In some sense you could, I guess, think of this as an "integrated Web browser", but it's not a case of swallowing up a separate Web browser program into other applications, it's a case of providing Internet access capability to those applications, just as file access capability is provided by OS libraries (at least in the case of the second bullet item).
(I have the impression that this may well be the way in which Internet Explorer is "integrated" into Windows - a bunch of library routines, or COM objects, exist that provide that functionality, and IE is one application that uses those routines/objects.)
Well, I've read Word documents, graphics, source code, MP3 files, video files, etc. from links in a browser.
And if you're saying that none of those documents have links in them, well, I could imagine somebody might put links in Word documents - or source code; I've put URLs into source code for references, and it might be nice to be able to click on them and have the reference document pop up in another window.
You're not presuming here that only HTML documents can contain links, I hope....
...which would be the "presentation applet" for HTML.
Perhaps you use your browser as something like an FTP client, but that doesn't mean that everybody does. I think it would be an extremely interesting experiment to see whether one could organize a desktop around hypertext.
No, Procom have GPLed an implementation of the NetBEUI protocol, specificat ions for which have been available for a while. (Look in "The NetBIOS Frames Protocol" section of the IBM document in question - yes, IBM, who were involved in it, as well as in SMB.)
No. SMB-atop-NetBEUI is no more "native" than is SMB-atop-NetBIOS-over-TCP.
Yes, the NetBEUI headers take fewer bytes than the NetBIOS Session Service, TCP, and IP headers, but it's not at all clear that this necessarily buys you that much.
"More often" isn't necessarily sufficient justification. The desktop environment he discusses would presumably run whatever code was appropriate for the data, regardless of whether it came from the Web or not.
Is that because the location information is best structured that way, or because people aren't used to structuring it as hypertext (or hyperwhatever, as a node could well not be text...), or because the tools for structuring it in that fashion are inconvenient or unfamiliar?
It may well be that structuring at least some of the stuff on your (electronic) desktop as hypertext might make it easier to keep track of.
See, for example, something Nielsen says in "The Internet Desktop":
The latency issue is perhaps a more severe problem, although perhaps some form of caching is the right way to handle that.
Fine. Then replace "Linux" with "Linux distributions" in his question.
Because:
Also, can I control into which categories the bank dumps transactions? No, I don't want their idea of which category or categories some particular credit card purchase belongs in, I want my idea.
(Also, my bank doesn't own my wallet, and I keep a record of cash transactions in Quicken 2000 - which, by the way, also implements that "dead desktop-centric model".)
...which doesn't necessarily help them remember where they put that birthday card - unless, say, they put all their birthday cards together.
If you have a system (desktop, OS, whatever) that can identify the type of a file in some fashion other than by its extension (e.g., by associating a file type with the file as an extended attribute, or by checking for a file type in the data at the beginning of the file), you can do that as well, without having to identify them by the first component of the pathname relative to your home/desktop/whatever directory.
Or, if you have a desktop environment that, by default, doesn't display the last component of the file name (e.g., Windows 9x/Windows NT), you can do that as well - "foo.fam.jpg" would show up as "foo.fam", and "Bobby_First_BDay.fam.jpg" would show up as "Bobby_First_BDay.jpg".
"Organize" in what sense? If I only organized them by the file name, I wouldn't have subdirectories of my home directory - the subdirectories correspond to topic.
And, in any case, I don't organize them by the application I happened to use when I last dealt with them.
As long as I can see all files associated with a given category together, regardless of what application happened to be used to create/edit the particular file.
The calls aren't what matters for drag-and-drop; the underlying protocol is what matters. GTK+ 1.2 and Qt 2.0 both use the Xdnd protocol, and other toolkits do so or will do so as well; hopefully this will make it more likely that you can drag and drop stuff between applications. (Current versions of KDE use Qt 1.x, which doesn't use Xdnd; you'll probably have to wait for KDE 2.0 to drag/drop songs from KFM to Xmms.)
As for Netscape, it currently uses Motif; GTK+ 1.2[.x] also supports the Motif drag-and-drop protocol, but other toolkits don't, so, unfortunately, that doesn't work as well as it should. Hopefully more toolkits will also add support for the Motif protocol, if possible (so that applications using Motif and applications not using Motif can mutually drag-and-drop; no, putting Xdnd support into Lesstif, even if that's possible, won't necessarily help, as you may have to deal with statically-linked binaries for non-open-source applications, or with applications dynamically linked with Motif 2.x).
It's not necessary to standardize the object model in order to solve the drag-and-drop problem, but the lack of a standard object model might be an issue if you want to mix KDE and GNOME stuff, as KDE and GNOME have different object models - you probably won't be able to use a GNOME (Bonobo) object inside Konqueror (the KDE 2.0 file manager) or use a KDE object inside Nautilus.
I also suspect that you're not likely to see them agree on an object model any time soon, necessary though doing so might be.
(I'm saying nothing about whether people should standardize. I'm just saying that I suspect they won't standardize the desktop object model any time soon.)
True.
False. On the home page of XFree86, it says:
Note, for example, that the list of systems on which XFree86 has been tested in the XFree86 3.3.6 README includes "Linux (Intel x86, DEC Alpha/AXP and m68k)" (emphasis mine).
It's not clear you can even do that if you're Microsoft; one of the applications running on the NT partition of my home machine uses GTK+. (No, it's not the Gimp, it's Ethereal.)
There's also Qt for Win32 as well.
It's not. The sort of people who'd only use the GUI are the sort of people who'd be installing precompiled software, e.g. using Kpackage or some other package installer. If you want to install from source, you'd probably use the X application xterm, or another application of that sort.
E.g., Berlin?
The Xerox Star came out in 1981; it had a desktop metaphor. The Apple Lisa came out in 1983.
X11 uses PostScript for its display model? News to me....
(X11 with Display PostScript does, but that's another matter.)
Or, if the X application is cooperative, you select what you want to cut/copy, do a cut/copy, select what you want to paste it over, and to a paste. The belief of some to the contrary, paste-current-selection is not all there necessarily is to text copying in X....
Only if your GUI's keyboard-drivability is inadequate. I like it when the GUI is keyboard-drivable - if I can dismiss a dialog box by hitting the Esc key, it's quite convenient, and I can usually do that in Windows and can often do it in UNIX/X.
...but you need more than just FreeType supporting it - you also need X supporting it, and, no, connecting X to a FreeType-based font server is not sufficient to magically make X do anti-aliasing; anti-aliasing requires multiple colors, and, unless I've misremembered, an X graphics context contains only a foreground and a background color - you'd either have to have the additional colors automatically allocated from the colormap (which might break applications), or have the toolkit that's doing anti-aliased drawing allocate the colors itself and tell the X server what colors to use (which requires an X protocol extension).
Yes. (If I weren't posting to this thread, I'd moderate your comments up a fair bit....) Existing GUIs may be better than a poke in the eye with a sharp stick (yes, I've started to use KFM on my machine at home for some documents; I find it more convenient to click on some folder icons and then click on a document than to switch to some xterm, pushd to the relevant directory, and fire up the Acrobat reader on the relevant document), but I suspect you can do a lot better than that.
Assuming that it's one killer app. It may well be that the UI for office worker bees, the UI for developers (hardware, software, etc.), the UI for accountants, the UI for the "typical" home computer user (if such a person exists), etc. may be different.
(The current desktop metaphor has somewhat of an "office worker bee" feel to it - perhaps not entirely surprising, given that the Xerox Star, which was one of the first commercial systems with that flavor of UI, was a product intended for, err, umm, office worker bees, and I suspect that said worker bees were at least one of the intended markets for MacOS and Windows.
At least in the MacOS/Windows incarnation, I suspect it was also intended for standalone machines, although the Star was definitely not intended to be solely a standalone machine; a networked environment, especially one that includes not only a LAN but the Internet, may also call for some UI changes.)
"Especially" indeed. One problem with hierarchical file systems is that they're trees, not graphs; it is not necessarily the case that a given document belongs only in one place.
I can usually find either one quickly if I know where it is - but I'm not sure that counts as "finding".
A truly "groovy" way to "store, organize, and retrieve files" would be one that would help me find files if I have some idea what they're about but don't know where they are.
My collection of documents includes saved e-mail messages, bookmarked URLs, saved netnews articles, random text files that I've filled up with notes to myself, etc.. I save a lot of e-mail messages in folders for particular topics - but sometimes an e-mail message belongs in more than one such folder (which I currently handle by saving them in multiple folders).
Perhaps a hypertext scheme would work better, in which I could have a "folder" that's actually an HTML document with text in it, plus links to said saved mail messages, links to documents on other machines, etc..
However, I might not know all the things to which a given document might pertain, or I might not know what page is relevant to something I'm working on, so even that might not be good enough; a full-text search capability might also be useful.
Source code might fit better into the conventional hierarchical directory structure, but perhaps there isn't One True Way to organize data....
"Simplified" only for those users who expect their image files to be stored in one location, rather than having their family pictures for the grandparents stored in one place, the pictures from last year's vacation in another place, their pr0n in another place, etc..
However, I don't file physical documents based solely on whether they're letters or pictures or financial reports or...; I file them primarily based on what they pertain to. And sometimes that even changes - reports from financial accounts may move from a folder for the financial account to a folder for a particular year's income taxes when tax time comes around, for example.
Now, if the location - in the sense of "the directory in which the files are placed" - is invisible to the user, e.g. a system where you can ask "where are all the pictures of my family" or "where are the pictures I took from my vacation last year" or..., it might work as an implementation detail.
I didn't come up with the notion of "directory trees as implementation detail, rather than end-user metaphor" on my own; others have suggested that a hierarchical directory structure might not be the best way to show a user the organization of their files. See, for example, Jakob Neilsen's The Death of File Systems paper, in which he says:
Yup, there's more to be fixed than just the UI; one shouldn't have to thrash around like that to get sound out of one's computer. (If one believes that the free UNIXes should only be used by those who are "smart enough" to use them, one should note that if somebody truly is "smart enough" to use a free UNIX, they're probably also smart enough to realize that their time could be better spent doing something other than screwing around trying to get their sound card to work....)
Mainsoft - the folks whose MainWin product was used for the IE4 and IE5 ports to UNIX - already have MainWin for Linux in "limited beta release". It implements an API that is "tightly controlled" by Microsoft, namely the, err, umm, Win32 API and various Microsoft APIs atop it.
They used MainWin for both IE4 and IE5.
Mainsoft have MainWin for Linux in "limited beta release".
The desktop on which they're working is called GNOME. Eazel aren't doing a new desktop, they're doing the Nautilus file manager for GNOME 2.0.
I thought the whole point of Carbon was that it was a modified version of the MacOS Classic API; would that not mean that an OS X port to Carbon would involve doing little UNIX-ish code, if any?
Presumably you mean "to other Unices that support the Carbon APIs"; the only such UNIX I know if is, err, umm, MacOS X....
If they didn't use Carbon, they'd presumably use Cocoa, in which case it might involve doing some more UNIX-ish code, but would also presumably involve doing a lot of Cocoa code that wouldn't Just Port to a UNIX/X system.
Such as MainWin for Linux (although I see no sign that MainWin implements the DirectX APIs)?
Yes, MainWin for Linux "is now in limited beta release, with general customer availability scheduled for early first quarter of 2000." (The page in question even offers a MainWin-based port to Linux of one of the main productivity applications that comes with Windows.)
Only if MainWin (which is what was used for the IE 4 and IE 5 ports to various UNIXes) won't do the trick. (I.e., they may just let Mainsoft write the toolkit in question for them, given that Mainsoft have already done so....)