Recently quite a comtion has come over the
direction of gnome, it's changes, and it's target audience. I,
personally, seem to average somewhere around 1/2 to 1 hour a day trying
to get something to work in gnome that usually just isn't going to work
anyway. So my hour is basically spent as time "learning" the
(lack of) system.
For those who care, this is a link to:
a profile of my days with gnome
which details a tipical day of me working with gnome and burning time,
but it's not incredibly important to the current point, so don't let it
distract you from the rest of the article :)
Now much has already been said on the subject, even before the gnome
war. In particular the distinction between systems that are
easy
to learn vs
easy
to use without learning has been very enlightening.
This issue also has a massive similarity to the ideas of
Languages For Smart
People vs
Langagues
For the Masses.
I think when people say "I wish more people would use X" {where X =
linux, or a programming language, etc}, that what many of them they
really mean is "I wish more people would act like the people that I
currenly see using X". I discovered this for myself when after
saying
"I wish everyone would be on the internet" in the early 90's, I
found
myself saying "I wish these people would *leave* the internet"
{coinicdently, this was shortly after the windows drivers were
written}.
I propose that what we need to do, is to similarly create the Desktop
for Smart People, in which we do not assume the user is a idiot {i.e.
incapable of learning}. So, we will have to understand that everyone in
the world will not use it.
Ok, that may sound neat, but what does it mean? It means a
desktop, that is
easy
to learn, but has no limit to how much there is to learn. One
that's based on a few, small components that can be learned quickly,
and are re-usable in new combinations of which the consequences can be
explored over a entire lifetime. One that has a interface that is
turing complete.
A few default options of what there is to do in a menu system don't cut
it. The menu system of programs should be a front end to a
simple,
interpeted language
which has all the features, like
scheme,
which can in turn have a parser for whatever syntax the user needs for
his current task. A {sourcastic} discussion of language
principles and features is over in
The Languages Of Suffering.
The the principals of languages should come through in our desktop and
programs, making once and for all the line between using and
programming unidentifiable.
As a user, I should be able to stop using the menu system, and get a
command prompt (of the programming language... not bash ;) Some might
say that I'm reinventing emacs, and in some sence there right.
But emacs dosn't have quite the good visual graphical support that
gnome has. Also, emacs uses Common Lisp, which is a older
dialect. It would be better if we could update it with the
simpler dialect of scheme. someone is trying something like this
now:
texmacs is a TeX based
"word processor" with guile scheme scripting in it... a interesting
project. Think of it as a cross between lyx and emacs.
guilemacs
was a guile based emacs that looks like development stopped on though.
emacs link...
siag
All this would be driving it to become the easiest system to develop
in. And think of how much code would be submitted in a system in
which using and programming couldn't be distinguished... It would
mean that, in classical vocabulary, every "user" would be a
"developer", and could just submit a copy of whatever they just
did. and there "programming expertice" would get better every day
as they used their word processor, etc.
Really what were looking for is something like a cross between nextstep
(OSX) and emacs.
*one namespace*
integration of filesystem and namespace (automatic filename->symbol
conversion. (spaces and wierd chars could be handled ok by a
extra function of symbol->string thus:
(open (find-in (find-in (find-in root-directory-list usr) local)
(string->symbol "HoRiBLe *name* by \"Meanie\"')
but that'd be just having access to the filesystem as a list. we
should integrate the filesystem hierarchy, with the module
system. and of course theres nothing preventing us from creating
a reader macro to do automatic string->symbol via (gimmie-object
##/usr/local/bin/lyx) (assuming the ## is the begining of our
reader macro syntax) . in fact the macro could call the "gimmie-ojbect"
and just return the object it'self with ##/usr/local/bin/lyx.
Integration of the development environment with the desktop, the IDE
& file manager should be the same thing.
integrated "GUI builder". by left clicking on anything I should
be able to change it into "layout mode", without loading a seperate
application.
//note: integration with "tex" or tex-like operations...
emblems - if the mime type system is integrated with the native
"type system" (or type standard), a user should be able to create new
types on the fly, and use those types to sort his file list.
(see example on next page)
mime types & "real types"
Our internal scheme type system should be extended to recognize mime
types, so (number? ##/usr/local/bin/hello.world.tx) would be #f,
but (texmacs-data? ##/usr/local/bin/hello.world.tx) would be
#t. Of course type systems are often coupled closely with object
systems, so we might need to pick a standard object system (something
like tinyclos, but bigger?)
So that's the idea. Now
how would we do it? check out:
