2009/5/28 NoiseEHC <noise...@freemail.hu>:
> I think it's very important if we want to keep pushing Sugar that we
> distinguish between design decisions and bugs and unimplemented
> features. If we bring down good design ideas not by themselves but
> because of its implementation status, we risk ending up with nothing
> that brings new value compared to existing desktops.
> You say that like it would be a bad thing. The existing desktops
> are at least time-tested. Learning to deal with the common features
> of modern desktop systems is very valuable for children.
> This relies on the assumption that 8 years from now when children grow up we
> will still use directories. I do not dare to predict the future so I will
> leave it to you... :)

In graphical environments alone, directories are over 25 years old.
Since 8 is less than a third of that, there is only one safe bet.

It'd be way more than 25 years, except that we didn't even have
graphical environments much beyond that. Directories go back
about 40 years. 8 years is just another 20%.

This isn't the "Microsoft Windows XP Service Pack 2" feature set.
This is a concept that is pretty fundamental in computing.
It crosses platforms, it's in our network protocols, and it's even
required for all the programming languages that implement Sugar.

> The following things unfortunately cannot be done with a flat filesystem
> view:
> 1. Revision based view.
> 2. Tagging.

First, I think you didn't mean "flat". That's the Journal.
Second, both flat and tree systems can handle that.

> It is a totally different problem that the current Journal barely implements
> those things but dropping it in favor of "time-tested" solutions is a
> mistake IMHO. (Note that no filesystem solves those problems I have
> mentioned.)

No filesystem should! It looks like GNOME 3.0 will get you those
features on top of a plain old UNIX-style filesystem tree though,
without making the filesystem incompatible with both software
and humans.
Sugar-devel mailing list

Reply via email to