I just couldn't stop myself on this one...

Quote:

Original post by Mayrel 1) The GNU project is not 'over'. 2) The GNU project has not achieved their aim.

Nor will they ever.

Everybody has known since between 1996 and 1998 that HURD, for all intents and purposes, is a failure. Move along, folks.

Wait. Let me get this straight. Oluseyi, you want to get rid of folders? Does that mean all files are clumped together? Or are you suggesting that with your concept, you would never use a file manager to select files, you would just use a search feature to look for your files? Aren't folders metaphors for actual folders in an office, where you organize things?

Quote:

Original post by Cipher3D Wait. Let me get this straight. Oluseyi, you want to get rid of folders? Does that mean all files are clumped together? Or are you suggesting that with your concept, you would never use a file manager to select files, you would just use a search feature to look for your files?

Read. Read the other member comments as well.

Quote:

Aren't folders metaphors for actual folders in an office, where you organize things?

In the case of the office, you have to expend significant effort to store things before you can retrieve them efficiently. You also have to remember to put them back. This works, though, because physical objects are limited by the fact they can only be in one place at once, so the place may as well be predictable.

Furthermore, the office folder is a discoverable interface. The drawers are basically all in front of you, and you get a good idea of their contents by looking at the little labels above their handles.

Computer folders, on the other hand, have tended to reflect application groupings (all the files pertaining to this or that application) as opposed to data groupings. Your reports don't naturally come together; you have to expend energy to organize them upfront.

But I have a computer! Why doesn't it do all that for me?

Maybe it can.

I wonder Oluseyi, are you still working on that? (The thread above)

Quote:

Original post by Oluseyi Quote: Original post by Cipher3D Ok, so if you say X should be totally destroyed, how should the windowing manager be like? I don't really understand why X is so bad. Well, maybe it is slow because it sticks to the client/server model although 99% of users don't take advantage of the client server feature, but what else is bad about X? The problem with X is that it has no concept of objects. Everything must be described - and thus sent over the wire - as a description in terms of lines, pixels and colors. Why can't the window manager inform the windowing system of how to draw various widgets, and then describe the interface at this higher level?

But, of course, that isn't a problem with client/server GUIs. That's a problem very specifically with X. Indeed, it's a problem with an X that doesn't contain an extension for, say, SVG or Display PostScript visuals.

Quote:

X must die. Quote: Original post by Mayrel How do you suggest we go about that? Start by evaluating tasks. What do users typically want to do with their computers? For each of these tasks, break them down into their component tasks until we finally get at the point where atomic operations occur. We must then ask ourselves, what is the most natural, efficient and intuitive for a person to communicate the intent to perform that operation to a computer, and document the entire process. There, that wasn't so hard, was it?

Easy to say, hard to do. What you think is the most natural, efficient and intuitive way for a person to tell a computer to do a particular thing is most unlikely to be same for me.

Quote:

Quote: 1. Users shouldn't have to save files. The problem with this is that +we can't pick a sensible name for a document. The second potential problem is that if storage is transparent, undo information will need to be stored on the disk. This means the user will need to periodically discard undo information or run out of disk space. First off, most users never fill their hard disks. The cost of memory is falling continuously.

Most users never fill their hard disks, true. Most users never store a lifetime's worth of undo information with their files, either.

Quote:

Now, let's assume that we have intrinsic versioning as a property of the filesystem. The default discard interval will be set such that the average user maintains a reasonable balance between the ability to roll back and memory consumption. Voila! Memory problem solved.

That assumes that it's okay to silently lose undo data. A better alternative, surely, would be to use user interaction to ask whether its okay to discard information. If the user assents, a good mechanism might be to store all undo information for an hour, then store hourly versions for the rest of that day, daily versions for a week, weekly versions for a month, and yearly versions thereafter. That gives you a long period of recall, but the 'precision' is reduced the longer a particular version has been kept for. Since that's how humans tend to remember things, it's probably reasonable to have a computer do the same.

Quote:

The third issue, naming files. Why do we refer to files by name anyway? Of all the natural and mechanical properties they have, that's probably the most useless and unnatural. When you refer to the pictures in your photo album, don't you mentally categorize them by subject(s), location and date?

I've no idea about the date. I would categorise by subjects, location and, of course, the image itself -- I have a vague recollection of what it looks like. I might, potentially, wish to enter the text "spain me mother river mountain" into a search box.

Quote:

When you refer to a report with a colleague at work, isn't it what the report is about - say, Q2 2004 Walt Disney Radio Presentation - that you base your discussion around? So why do our user interfaces foist upon us the busywork of coming up with creative file names, managing them and remembering them?

So wouldn't you call that file "Q2 2004 Walt Disney Radio Presentation"? If not with a name, how else would you identify it? How would you identity that file to other programs?

Quote:

And why do we explictly have to save? In the old days, saving served as a valuable pause mechanism for programs due to the limitations of hardware. Today there already are programs that continuously save in the background with no discernible negative impact on user productivity. In fact, I'd go further and say that auto-saving increases productivity, because you won't lose much work/data in the event of an unexpected interruption of operation.

That's fine. Explicit saving is suspect. However, if saving is automatic, I want some way to revert to the last 'checkpoint'. Also, what does one do about files that are opened by more than one process at the same time? Does only one of them get to open it in update mode? Do the others get it in readonly mode, an editable 'snapshot' mode that doesn't effect the on-disk file, a copy of the file in their personal region of storage, or a 'fork' of the on-disk file that can be merged later by someone who has permission to read both prongs?

Quote:

Moving on, why do we have directories? Actually, to answer this in non-rhetorical fashion, we have directories because of the limitations of older computers, which couldn't count beyond a very attainable limit like 256 or 1,024 without jumping through hoops, so the directory was introduced as a means of "resetting the counter." Is that limitation still practical? My computer can count to at least 4 billion without breaking a sweat. There's no reason why I should be forced/required to store my files somewhere in a hierarchy - a hierarchy with a dangerous tendency to grow wide and one in which it is ludicrously easy to lose files.

Directories are an obviously correct idea. You appear to be assuming that a directory is necessary a purely heirarchical structure. A directory is merely an index of files. On most operating systems, files can be in multiple directories. In some operating systems, directories can be generated on the fly. There's no technical reason why a UNIX-like operating system couldn't have an 'unfinished reports' directory from which files disappear when their finished status is switched on.

Quote:

Quote: 3. Users shouldn't be able to select files from a dialog. This is just stupid. Because the file manager can be open all the time, he argues, file selection dialogs are crufty. Which misses the fact that, on many modern UIs, file selection dialogs are the file manager. Uh, his point was that user shouldn't have to select files from a dialog, particularly given that the file explorer (or Finder, or whatever) provides the same functionality but with a different interface. It's confusing.

No. His point was most definately that the dialog shouldn't have a different interface from the file manager. The dialog should merely be an interface to the file manager.

Quote:

You don't think so? Read JWZ's comments about his mom and OS X.

I read it. The fault was not caused by the file selection box looking a little different, the fault was caused by the file selection box behaving in an obviously wrong way.

Quote:

(Don't know who JWZ is? Then you might as well roll over and die right now as far as this discussion is concerned. I expect you to know all the principal actors in the movement.

What is that? Some kind of argument from inverted ignorance?

Quote:

Where I differ is that I think that all major functionality should be immediately apparent to the user. The Start Menu hides top-line functionality between a three-tier menu (Start -> Program Menu -> Application). Bad. OS X' Dock is a much better idea, though it could probably use some tweaks.

I considered mentioning two thoughts in my post, but it was getting long.

One was that the menu could highlight submenus and items that contain new elements (and perhaps put a little "<= New" symbol alongside the item, just so you know). The other was that the main menu could contain a list of "New Programs" (or "New Tasks", as you might have it), from which programs expire after some predetermined time.

Whilst easier in the short term, the latter has the problem that the user has to figure out where the program has gone to when it's removed from the new list. You could use the former idea in a slightly modified form -- "<= Write Letter has moved here".

Quote:

The current notion of an "application" serves primarily as branding. It's unnecessary. A much better approach is to expose functionality, along the lines of "Create a Text Document" (as opposed to an implicit "Launch Microsoft Word") or "Paint a Picture" (versus the shockingly blank wall of "GIMP").

I see. You mean "application" in a different way to me. KDE's menus are better. "Word Processing" and "Image Editor" makes it clear what kind of window you want to make appear.

Quote:

But it's not just a presentation or menu entry issue. The deeper issue is why these applications should exist as segmented, isolated entities that duplicate functionality. I think it was you that boasted that your Gentoo Linux distribution contains 8200+ "applications". Wow. And how many types of applications does it contain? In other words, how many of those applications are, for all intents and purposes, redundant? How many of these application categories are esoteric, meaning that the majority of users will never, ever use them?

Almost all of them. I have 536 packages installed. Of those, perhaps only a hundred or so are "applications" -- most are just support packages that even a power user would never be aware of unless they stopped working.

Of course, this is not necessarily a good thing. Gentoo's strength is its diversity. A power user can always produce a system that is exactly what he wants. What Gentoo lacks is the notion of standardised 'sets' of packages that fulfil common needs.

There are tens of word processors. Out of the WYSIWYG ones, I only use LyX, because LyX does LaTeX with ease and I like LaTeX. It would, of course, be delightful if LyX was merely a "LaTeX Support Component" and "LyX Editor Interface Component" that I plugged into a "Text Document Component." But that isn't an option.

Quote:

The goal of a usable environment is to minimize the number of unnecessary decision points. Yes, configurability (and, by consequence, choice) is a virtue, but hide that behind an advanced user interface. When an average computer user wants to install Linux, do you think it's any wonder they look for the GUI button that says "Default"?

Sure. I wouldn't advise an average computer user to install Gentoo. Installing Gentoo is great if you have a desire to learn about Gentoo.

Quote:

Quote: What's the alternative? The data a specialised application uses, by its very nature, will be specialised for that application. Just. Not. True. I've written on the concept of codec-based data storage before, and I do not feel like reiterating my entire spiel. Suffice to say that the actual storage mechanism of the data can be independent of the nature of the data itself, opening up interesting possibilities through synergies of functionality. Yes, that's a fairly obtuse block of text, but I posted a link to a complete discussion earlier.

By the looks of things, your codec-based storage is, essentially, a component that knows about a particular storage format which parses that and gives the information to a component which provides a programmatic interface to the data.

That's fine, but means you'll have to be rather clever about what components you make. A video file, for example, contains not only an visual track, but also an audio track and perhaps a subtitle track. Each track has a different format, so your file is really a set of files -- three tracks and an index that pieces bits of the tracks together.

There's also the possibility of other types of track. If my movie was intended to be blended with realtime CGI, I might have a track that contains the camera position and orientation. Another track might contain GI data. I'd want to be able to view this movie in the normal media player.

Quote:

Quote: It isn't entirely unreasonable to suppose that a text editor can't open a video clip. No, but is it unreasonable to suppose that a user might want to embed a video clip in a text document (and by "text" here I include all word processors, not just the sort created by Emacs, vi and Notepad)?

You group Emacs with vi and Notepad as though it's a plain text editor. Emacs can display styled text and images. It's no WYSIWYG editor, but it is more visually sophisticated than many suppose.

Quote:

Oh, wait, but that's already possible! OLE, COM, ActiveX, Bonobo. Oluseyi, you're just reiterating the existing.

You forgot DCOP, KDE's object system.

Quote:

What I'm suggesting is that this approach to data become so much more intrinsic that "embedding" is no longer a function of the application, but of the entire platform/user environment.

I presume you're referring to a HTML-style layout-based system, where there'd be a few standard components for actually producing output (text, vector graphics, raster graphics, video, non-visual media) which would know how to be embedded within each other.

Then, any "interface" to a document would just translate the logical structure of the document into one of the generic display components.

Quote:

Quote: The problem with componentisation of the GUI and document-manipulation systems is that there is no component system that a large majority of the OSS development community is willing to get behind. Componentisation is tantamount to object-orientation, and many OSS developers are (inexplicably) opposed to object-orientation. That's beceause the platform allows for competing componentization. If the components are part of the operating system, the only way to write applications for the OS is in terms of those components (or to author new components), and using those components is ludicrously easy, then the issue becomes moot.

But such components will never be part of the operating system until enough people in positions of influence can agreed on which component system it should be based upon.

There's also the issue that it will very probably be easier to convert an existing program into a virtually opaque component than to make it into a fully fledged member of the component community.

This means that the benefits of a component architecture will not be seen very soon if such an architecture were introduced into Linux or some other free OS. Either you need a new OS where you must use the component system because there's no other choice, but few would use a system with no programs; or you modify an existing OS and a large number of its packages to support componentisation. That is a daunting task. At least KDE and GNOME are already componentised. One could make an adapter that allows their component system to interact with the OS's.

Quote:

Original post by Oluseyi Quote: Original post by Cipher3D Wait. Let me get this straight. Oluseyi, you want to get rid of folders? Does that mean all files are clumped together? Or are you suggesting that with your concept, you would never use a file manager to select files, you would just use a search feature to look for your files? Read. Read the other member comments as well. Quote: Aren't folders metaphors for actual folders in an office, where you organize things? In the case of the office, you have to expend significant effort to store things before you can retrieve them efficiently. You also have to remember to put them back. This works, though, because physical objects are limited by the fact they can only be in one place at once, so the place may as well be predictable. Furthermore, the office folder is a discoverable interface. The drawers are basically all in front of you, and you get a good idea of their contents by looking at the little labels above their handles. Computer folders, on the other hand, have tended to reflect application groupings (all the files pertaining to this or that application) as opposed to data groupings. Your reports don't naturally come together; you have to expend energy to organize them upfront.

My "documents" folder has the rough structure:

Documents|-- Fiction|-- Manuals|   `-- Infocom|-- Programming|   |-- Games|   |   |-- D20|   |   `-- The Art of Computer Game Design|   |-- Graphics|   |   |-- GLFW|   |   |-- OpenGL|   |   |   |-- 2.0|   |   |   `-- Extensions|   `-- Languages|       |-- C|       |-- C++|       |-- D|       |-- Eiffel|       |-- Haskell|       `-- Java|-- Operating Systems|   `-- SUSV3|-- Libraries|   |-- OpenGL -> ~/Documents/Programming/Graphics/OpenGL|   |-- OpenAL -> ~/Documents/Programming/Sound/OpenAL|   |-- StdC++|   `-- STL... Etc

That doesn't seem particularly "application-centric".

The folders for my programs are application-centric. But I don't see why I need to care about that. In fact, I like that the files that aren't in my home directory are, for the most part, segregated by package. A normal user never needs to worry about where a program, library, or some supporting file is, so long as the OS knows.

Just as a user's files are kept seperate from each other, there is merit, in my view, to keeping the files from a particular package apart. Within a package, file conflicts are somewhat unlikely, since the package-maker would notice. But two packages could potentially install conflicting files. Some Linux utilities and libraries are provided by more than one package. To avoid possibly breaking one package, they should be installed in entirely seperate places, and the package manager should be responsible for making the package's features available to the user and to other packages. Ideally, of course, no two packages would include the same file.

Quote:

Original post by Mayrel Easy to say, hard to do. What you think is the most natural, efficient and intuitive way for a person to tell a computer to do a particular thing is most unlikely to be same for me.

So collect data of a wide variety of users trying various interfaces along with demographic statistics. Evaluate the data, publish it openly, invite open peer review...

Come on, you're stalling!

Oh, and "Well, how do we collect this data?" Write a data collection service that various existing projects can snap into their products easily. That way, you can get a lot of useful feedback from a wide variety of projects - and they can get that feedback too.

Quote:

Most users never fill their hard disks, true. Most users never store a lifetime's worth of undo information with their files, either.

Blah blah blah. Non sequitur.

Quote:

That assumes that it's okay to silently lose undo data.

No. That assumes that there's a reasonable average which will be arrived at empirically, but also provides a system-wide (yet potentially functionality-/application-specific) configuration interface. In addition, this can be mentioned when the disk starts to become full but before any data is ever discarded, so that the user has a contextual understanding of the value of this feature before fiddling with it.

Asking the user at the beginning distracts from the task at hand, which, I can guarantee you, is not to configure Undo Data Preservation.

The rest of your comment I agree with, per the levels of configurability. Give advanced users as much power and flexibility as possible.

Quote:

I've no idea about the date. I would categorise by subjects, location and, of course, the image itself -- I have a vague recollection of what it looks like. I might, potentially, wish to enter the text "spain me mother river mountain" into a search box.

Okay, that's a start.

Say you had a separate file for each month's financial report by year. Simple data analysis can determine that a particular file is logically "July 2002 Financial Report" through the frequency of terms, cross referencing and relative prominence of items in the file (headings vs paragraph data). Essentially, Google your own data.

This can then allow you to indicate that you want "Financial Reports", or just "Reports". Am I suggesting entering this text into a search box of some sort? Not at all. Based on the frequency of occurence of terms in a variety of files, "collections" can be displayed with logical labels, with "related collections" placed as adjacent but lesser icons, allowing both visual navigation of data and what I'll call a three-point-pivot (the philosophy that any piece of data is three degrees of separation from any other at its most reasonably generic).

Quote:

So wouldn't you call that file "Q2 2004 Walt Disney Radio Presentation"? If not with a name, how else would you identify it? How would you identity that file to other programs?

See above. And programs are beside the point; why do I need multiple programs to access the same data? Why don't I organize the operations available around the data that I'm working with?

Quote:

That's fine. Explicit saving is suspect. However, if saving is automatic, I want some way to revert to the last 'checkpoint'.

Absolutely.

Quote:

Also, what does one do about files that are opened by more than one process at the same time? Does only one of them get to open it in update mode? Do the others get it in readonly mode, an editable 'snapshot' mode that doesn't effect the on-disk file, a copy of the file in their personal region of storage, or a 'fork' of the on-disk file that can be merged later by someone who has permission to read both prongs?

Well, that's a possibility, but, again, applications are an anachronistic approach to productivity.

Think of it as a "document container." Every bit of functionality can be invoked from the container if it is defined for the current data. It's sort of inverting the traditional placement of data and processing.

Quote:

Directories are an obviously correct idea. You appear to be assuming that a directory is necessary a purely heirarchical structure. A directory is merely an index of files.

Not true. Unix INODE structures tie files to directories.

Quote:

On most operating systems, files can be in multiple directories.

Not true. Symbolic links - hard or soft - are not the same as the file (or data, as I prefer to think of things) is part of multiple collections.

Quote:

In some operating systems, directories can be generated on the fly. There's no technical reason why a UNIX-like operating system couldn't have an 'unfinished reports' directory from which files disappear when their finished status is switched on.

That's an inherently inferior approach to a properties-based system.

Quote:

No. His point was most definately that the dialog shouldn't have a different interface from the file manager. The dialog should merely be an interface to the file manager.

Fine. What's you're response to my point?

Quote:

I read it. The fault was not caused by the file selection box looking a little different, the fault was caused by the file selection box behaving in an obviously wrong way.

I need a little more detail than "it was obviously wrong." What was wrong about it, and what would have made it right?

Quote:

What is that? Some kind of argument from inverted ignorance?

LOL.

JWZ is the guy who quit the Mozilla project a long time ago, making the critical observation that simply "opening the sources" doesn't solve organizational or managerial problems. I'm pretty sure you know this. I'm merely pointing out that a knowledge of "principal actors" and their impact on the philosophy and community behind OSS is important because it gives us a common basis from which to debate. It elevates our vocabulary and thus information tramsfer efficiency.

Quote:

I considered mentioning two thoughts in my post, but it was getting long. One was that the menu could highlight submenus and items that contain new elements (and perhaps put a little "<= New" symbol alongside the item, just so you know). The other was that the main menu could contain a list of "New Programs" (or "New Tasks", as you might have it), from which programs expire after some predetermined time. Whilst easier in the short term, the latter has the problem that the user has to figure out where the program has gone to when it's removed from the new list. You could use the former idea in a slightly modified form -- "<= Write Letter has moved here".

Interesting idea, but, as you correctly pointed out, dynamic menus invite confusion. Solving the confusion of a dynamic menu by making it dynamic in another respect is an unacceptable "solution."

Note that I only mean for major functionality to be at "Obvious Level." Create a Text Document, Browse the Internet, E-Mail, Send an Instant Message, Create an Office Document. Other applications/functionality can be in an Applications/"Do..." menu - and that menu should be top level.

The Macintosh Application (Apple) Menu is a good starter design, better than the Windows Start Menu.

Quote:

I see. You mean "application" in a different way to me. KDE's menus are better. "Word Processing" and "Image Editor" makes it clear what kind of window you want to make appear.

That's definitely a start, so I'll give them props for that.

Quote:

Almost all of them. I have 536 packages installed. Of those, perhaps only a hundred or so are "applications" -- most are just support packages that even a power user would never be aware of unless they stopped working. Of course, this is not necessarily a good thing. Gentoo's strength is its diversity. A power user can always produce a system that is exactly what he wants. What Gentoo lacks is the notion of standardised 'sets' of packages that fulfil common needs.

In my opinion, power users looking for that kind of "exactly what I want" system, that "I know the bare bones inside and out" are probably satisfied with Linux as it stands today. It's just not a good fit for average users - consumers and prosumers.

My concept of a functional desktop is based around the notion of the prosumer, a term that combines "producer" and "consumer". "Prosumer" is a term usually tightly associated with media; I'd like to see that mindset applied to user data as well.

Quote:

There are tens of word processors. Out of the WYSIWYG ones, I only use LyX, because LyX does LaTeX with ease and I like LaTeX. It would, of course, be delightful if LyX was merely a "LaTeX Support Component" and "LyX Editor Interface Component" that I plugged into a "Text Document Component." But that isn't an option.

But I gather that you think it should be? That's pretty much the approach that I'm talking about.

Quote:

By the looks of things, your codec-based storage is, essentially, a component that knows about a particular storage format which parses that and gives the information to a component which provides a programmatic interface to the data.

That's a decent exposition.

Quote:

That's fine, but means you'll have to be rather clever about what components you make. A video file, for example, contains not only an visual track, but also an audio track and perhaps a subtitle track. Each track has a different format, so your file is really a set of files -- three tracks and an index that pieces bits of the tracks together.

But that's exactly the point! All aggregate formats are composed of lesser data, sometimes including recursive instances of the format itself (think hierarchical 3D object format).

Quote:

There's also the possibility of other types of track. If my movie was intended to be blended with realtime CGI, I might have a track that contains the camera position and orientation. Another track might contain GI data. I'd want to be able to view this movie in the normal media player.

All we'd need is a codec.

The beauty of the codec-based approach is that it translates any binary data storage format, no matter how complex and specific, into a set of general abstractions that the operating system is designed to deal with. These can be expanded, of course; someone could write a new component. Once that happens, all applications will be able to deploy that functionality whenever they encounter data that requires it - in the appropriate context.

It's that data-centric approach again.

Quote:

You group Emacs with vi and Notepad as though it's a plain text editor. Emacs can display styled text and images. It's no WYSIWYG editor, but it is more visually sophisticated than many suppose.

My little dig at Emacs is beside the point. You got my meaning, and I think you agree.

Quote:

You forgot DCOP, KDE's object system.

I apologize. "And DCOP."

Quote:

I presume you're referring to a HTML-style layout-based system, where there'd be a few standard components for actually producing output (text, vector graphics, raster graphics, video, non-visual media) which would know how to be embedded within each other.

Not necessarily. I'm not conceited enough to think that I've solved all the problems or designed the system to a tee. Some of these ideas are still fairly amorphous, floating disembodied in ether.

Quote:

Then, any "interface" to a document would just translate the logical structure of the document into one of the generic display components.

Something like that. The specifics aren't quite set in stone yet. Feel free to make alternate suggestions.

Quote:

But such components will never be part of the operating system until enough people in positions of influence can agreed on which component system it should be based upon.

But this is Open Source, right? So I can take a Linux kernel with certain baseline functionality, some GNU tools, etc, and fork from there, right? And then release it on the web, announce it on Freshmeat.Net, comp.os.linux.announce, etc, right? And if people find it cool and interesting, it'll start to acquire cachet, right?

I don't agree with stimarco about a top-down, monolithic approach. I believe in an organic evolution, and I keep in mind that I may have the right intentions but the wrong approach, and someone else may solve the problem in a more correct fashion.

Quote:

There's also the issue that it will very probably be easier to convert an existing program into a virtually opaque component than to make it into a fully fledged member of the component community.

Halfway houses are acceptable transition mechanisms. I'm not naive enough to believe in "clean slate" initiatives - "Throw it all out! Start from scratch!" I believe in working gradually through the problem stack until a simple rebuild completes a total redesign. That way you always (hope to?) have a working, operational build that you can test.

Quote:

That is a daunting task.

You gotta start somewhere. Gradual mutation of an existing system, keeping your eye on the ball, serves the dual purpose of providing a familiar starting point; and maintaining, as I said above, an operational build at all times.

Quote:

At least KDE and GNOME are already componentised. One could make an adapter that allows their component system to interact with the OS's.

True, but sometimes design choices are pervasive in extent. I guess somebody'll have to give it a shot and see what sticks.

Quote:

Original post by Cipher3D I wonder Oluseyi, are you still working on that? (The thread above)

Sort of. Haven't written any code in over a year, largely because I haven't been running Linux. I could do it for Windows, but the expense and effort necessary to truly grok the Windows platform is beyond what I'm willing to do.

Quote:

Original post by Mayrel My "documents" folder has the rough structure: <hierarhcy diagram> That doesn't seem particularly "application-centric".

No, but you had to expend significant effort to create that. Most users aren't willing to expend that much effort. Hell, I get tired of expending that much effort, especially when you have to restore all your backups after a severe system crash.

I'd much rather have technology that creates those associations implicitly/automatically.

Quote:

There are tens of word processors. Out of the WYSIWYG ones, I only use LyX,

<pedantic>LyX isn't WYSIWYG, it's WYSIWYM.</pedantic>

Quote:

They must be replaced. By force, if necessary.

This is so crazy, my response needs to be both spelled out and capitalized: What The Fuck!?

Quote:

The problem with X is that it has no concept of objects. Everything must be described - and thus sent over the wire - as a description in terms of lines, pixels and colors. Why can't the window manager inform the windowing system of how to draw various widgets, and then describe the interface at this higher level?

My understanding is that this is exactly the way things could work. Gtk+, unfortunately, does not support this sort of behavior. I'm not sure why. It might be a limitation in the protocol of which I'm not aware. I think it's part of the interclient communications and messaging protocol(ICCMP), which establishes a standard upon which window managers in general can work.

Quote:

Now, let's assume that we have intrinsic versioning as a property of the filesystem. The default discard interval will be set such that the average user maintains a reasonable balance between the ability to roll back and memory consumption. Voila! Memory problem solved.

Strictly speaking, you don't need a discard interval. Every modification of the data could be mediated by a function that saves the changes or another function that records the change and references a function to undo it, much as regular undo works. Ideally, only the slice that is changed is affected. Periodically, the oldest of these changes are rolled together and a new intermediate (full size and of the same data type) is made and stored so that the more precise undo information can be discarded.

Also, the system needs to be able to blur the distinction between disk space and memory, which is already somewhat true. If undo information were first stored in memory, then written to disk, then recalled, rolled together and rewritten to disk, this would be true.

Quote:

If the components are part of the operating system, the only way to write applications for the OS is in terms of those components (or to author new components), and using those components is ludicrously easy, then the issue becomes moot.

Yeah. Ideally "authoring components" would be nearly a natural extension of simply using the system. you should not have to write code for, say, a simple program that lists some MP3's and allows you to play a random or particular song from such a list. You should already have components -- lists, MP3's (which are a composite of the fields of an ID3 tag and audio (or an audio codec, if you like)), a query function to connect the two, a random action and a play action. Click and drag to connect the appropriate parts.

Quote:

And then release it on the web, announce it on Freshmeat.Net

Are we still talking about a non-unix system? Freshmeat's only supposed to be about unix programs.

Quote:

Quote: I presume you're referring to a HTML-style layout-based system, where there'd be a few standard components for actually producing output (text, vector graphics, raster graphics, video, non-visual media) which would know how to be embedded within each other. Not necessarily. I'm not conceited enough to think that I've solved all the problems or designed the system to a tee. Some of these ideas are still fairly amorphous, floating disembodied in ether.

This is my intention, basically. Ideally, things should group themselves together logically without the need for an explicit layout as an HTML document does. There are also some problems with the HTML flow layout system (namely that blocks need to be reflowed or the page display needs to be delayed until the end based on the information of later blocks) that would preclude me from using this layout system more broadly outside of HTML and perhaps word processing, but what you're talking about is a decent arrow in the right direction.

I'd almost certainly implement a web browser by overriding the normal automatic layout and configuration systems and replacing them with HTML and CSS. Surprisingly little additional work would then be needed.

Quote:

Note that I only mean for major functionality to be at "Obvious Level." Create a Text Document, Browse the Internet, E-Mail, Send an Instant Message, Create an Office Document. Other applications/functionality can be in an Applications/"Do..." menu - and that menu should be top level.

My preferred solution is similar to the Windows XP start menu, but embedded directly on the desktop (I'd choose the right side). XP's default start menu has the common tasks Internet and Email always at the top, together with some of the more recently use applications. My solution would be similar with a "menu" (not the same as a regular menu because it's on the desktop) of Browse the Internet, Read Email, Create a text document, and some other tasks, and at the bottom, a "..." entry. If there are too few tasks to fill the right hand side, no "..." is needed, but there probably are, and clicking this entry yields something like the start menu (the entries on the desktop are included again here). If the start menu is too large, tasks are grouped together (the Freedesktop.org menu entry standard could feature this behavior!)

Quote:

Quote: Directories are an obviously correct idea. You appear to be assuming that a directory is necessary a purely heirarchical structure. A directory is merely an index of files. Not true. Unix INODE structures tie files to directories. Quote: On most operating systems, files can be in multiple directories. Not true. Symbolic links - hard or soft - are not the same as the file (or data, as I prefer to think of things) is part of multiple collections.

Unix Inodes are tied to the filesystem. The root filesystem is intended to abstract all the filesystems available to the system, but hardlinks are one place where the abstraction leaks through.

Symbolic links are soft links. Hard links are multiple names for the same inode. The former are made with "ln -s", the latter with "ln".