Kuro5hin.org: technology and culture, from the trenches
create account | help/FAQ | contact | links | search | IRC | site news
[ Everything | Diaries | Technology | Science | Culture | Politics | Media | News | Internet | Op-Ed | Fiction | Meta | MLP ]
We need your support: buy an ad | premium membership

[P]
The Future of the Linux Desktop

By zorander in Technology
Mon Dec 18, 2000 at 09:26:41 AM EST
Tags: Technology (all tags)
Technology

What will be the Linux desktop environment of the future? This question is usually answered with a pointer to the Gnome Foundation's web site, the web page of the K Desktop environment, or a statement of "it hasn't been decided yet." I read these answers on such pages as Slashdot Freshmeat, and Kuro5hin, as well as in several Usenet groups and mailing lists.

The open source community is a high powered development resource. Great ideas have come out of our community, but we are evolving into a very practical-minded group. We are open with our source code, but this does not automatically make us open to true innovation. We sometimes think in a box, one could say, and much of our work mimics what has been done before. Gnome and KDE, although better, are still based on a user interface that looks like Microsoft Windows. The Apache web server is based on NCSA httpd. StarOffice's Word Proccesor is functionally similar to Microsoft Word. So many similarities exist, in fact, that a user could go between the three without noticing any major differences. We do not want to portray ourselves as a "Windows Clone," but as a more functional and better solution to the computing problems of today.


In one sense, similar functionality between software programs with like goals is a good thing, because it provides a way to satisfy people who need to reproduce the capabilities of another operating system environment. However, it can also be a bad thing, because the Linux operating system has only a little more to offer than others. There are a lot of wonderful things to be said about Linux, but at the same time it is in many ways becoming a glorified Windows workalike. I'm not referring to the server market, where the superiority of Linux has already been established, but in the desktop market, both for business users and home users.

Linux needs to do something different, something more. It needs to interact with users in new and unheard of ways. The solid kernel and X window system provide a firm basis for new user interface technologies. The potential for these technologies, however, has not been realized yet.

One of the largest mistakes that has been made, however, is the way our graphical user interfaces (GUIs) function. The technology that forms the basis for even the most modern GUIs was developed in a laboratory in Palo Alto, California known as Xerox PARC, thirty years ago. Here, the early incarnations of the mouse formed. The concept of windows was developed, and allowing them to overlap was a new achievement. Xerox PARC invented the first WYSIWYG word processor, and ran it on a little machine called the Alto. The Alto was only two or three times as large as today's desktop computers but ran at a fraction of the speed.

Our computers today are much much more advanced, but the graphical user interface is suffering the same fate as the automobile right now. Before the early twentieth century, automobile technology was progressing quickly ahead and it was becoming practical for widespread use. With Henry Ford's Model T, the popularity of automobiles exploded. After that, however, the innovations ended. Sure, refinements were made: air conditioning, radios, antilock brakes, and airbags are all examples. Innovations, however, still only occurred within the bounds of four wheels and an internal combustion engine that runs on petroleum, just as it did ninety years ago.

GUI technology is taking a similar path. After the initial age of innovation and the creation of a crude but marketable product, so many people became so caught up in what had already been done that innovations in this field have reached a plateau. The early demos of the PARC Alto show screens that look little different from today's. Sure, now we have color and our screens are much more complex and responsive, but the basic technology is the same.

This slowdown in innovation is also true in other areas of technology, such as programming languages. The concepts behind object oriented programming (a top buzzword in the field) were also created thirty years ago at PARC. Their language was called Smalltalk and it still exists today. More importantly, however, the creators of C++, arguably one of the top languages in which new projects are written, based their ideas on Smalltalk.

A major problem in the way we look at computing today is that we see the computer as a monolithic tool, something that we sit in front of and use. The computer's true purpose can only be realized when we no longer acknowledge its existence. For example, for the purpose of telling time, my watch is the perfect tool. When I'm wearing it, I always know the time. I don't consciously look at it, but glance at it from time to time. It keeps me informed of the time and stays out of the way of other activities. The most important thing about it, however, is that when I don't have it, I notice. I am visibly affected by not knowing what time it is. When you don't notice a technology until it is gone then it is truly serving its purpose.

As a community we have unlimited potential if we can truly innovate. We are starting to compete with companies such as Microsoft and Apple. This is good, as it shows them that there are alternatives to the "default" operating systems. We as a community can also move faster than they can. With the current state of things, however, and the fact that we are working on little or no new desktop technology other than Gnome and KDE is not going to help us. If we don't act, one of our competitors will develop new technologies, and that will put a serious dent in the community, particularly as we scramble to create workalikes for their technologies in hopes of picking up a few users.

What can we do to accomplish this? First of all, all users should be programming the computer to serve them without even realizing it. How can a programming system be implemented that uses the input devices to generate code rather than requiring the user to write the code? How can we make the experience of using this computer as close to the experience of thinking as possible?

How should the workspace be organized? How can the user control this? The workspace should probably be an area conceivably mapped to a physical object that acts to let the user arrange and connect his work. It should truly be a workspace, and should be no less chaotic than the thoughts of the person who is using it at that time.

Issues such as how the human thought process can be aided by computers are still hard to answer, but in developing software to meet these goals, such problems will be slowly eliminated. The computer must aid the person in thinking, and this is a task that machines have not accomplished on a large scale. The interaction has to be completely natural to make the human-machine connection complete. How we are going to implement this is not yet apparent, but it will eventually be done, and we will have the advantage if we are the first to do it.

The future should not be a workalike of the past. In the next five years, we may see Gnome and KDE become stronger still, but do we want to be living with them in ten years? Or fifteen years? It is time to start developing new technologies. Xerox PARC, which made the largest contributions to computing to date, didn't write their code for the present, but for the future and we need to do the same.

Sponsors

Voxel dot net
o Managed Hosting
o VoxCAST Content Delivery
o Raw Infrastructure

Login

Related Links
o Slashdot
o Kuro5hin
o Freshmeat
o Also by zorander


Display: Sort:
The Future of the Linux Desktop | 122 comments (109 topical, 13 editorial, 0 hidden)
pwm (3.18 / 11) (#9)
by fluffy grue on Sat Dec 16, 2000 at 02:34:34 AM EST

For a rather interesting take on the whole WIMP interface, check out pwm, a very cool experimental window manager. The screenshots there don't really do it justice though - my setup might look a bit better (though I'm biased in that regard). Basically, the interface is minimalistic, and the really cool thing is that you can attach multiple windows to the same frame, making it very much a stream-of-consciousness interface in some ways. The interface doesn't get in the way, and it can be configured in just about any way you want (even moreso than fvwm2, my previous religious preference). I originally tried it out for use on small displays (i.e. the Sony Picturebook), and while configuring it for a 1024x480 screen (using Xnest) I got completely hooked on it. The only thing it's missing IMO is a decent pager.

Although this is still just evolutionary, rather than revolutionary, it certainly isn't a clone of any existing commercial system. It also tends to put background things into the background of perception, like your watch analogy - it can run WindowMaker dockapps, which are very good for having background, nonobtrusive but functional purposes (such as glancing at the time or weather or system load), and as a whole, pwm makes the system interface incredibly unobtrusive while being incredibly powerful at the same time.

It's little things like this which are important, IMO. Whining about the lack of innovation doesn't do you much good, and true innovation is actually quite difficult. If someone were to come up to you and say, "Design a revolutionary new interface for interacting with your system," could you do that? Innovations come from inspirations, and inspirations are difficult, if not impossible, to force; forced inspirations lead to things like the annoying fading menus in Why2K and forced bad metaphors like Bob.
--
"Is not a quine" is not a quine.
I have a master's degree in science!

[ Hug Your Trikuare ]

RE: pwm (3.00 / 2) (#18)
by MeanGene on Sat Dec 16, 2000 at 01:20:13 PM EST

Being an adventurous user, I'd love to try a different design. But is pwm really *that* different?

I mean, "several apps linked to the same frame" can be achieved within the "traditional" window managers by placing them on top of each other and alternating via either Alt-TAB or task-bar. Moreover, KDE already has a an application called 'konsole' that does exactly the same thing for xterms. And, need we forget the *ancient* technology of 'screen'?

Also, what is exactly the purpose of this "innovation"? How often do we have xterm and xv and editor of exactly the same size?

I am not disputing that pwm may be the perfect fit for some users, or that it is really fast with small footprint. I'm just wondering whether this particular feature has any *significant* UI merit.



[ Parent ]
Huh? (3.00 / 2) (#19)
by fluffy grue on Sat Dec 16, 2000 at 01:42:12 PM EST

Did you look at my linked screenshot? Almost all of my xterms are the same size (80x25), almost all of my Netscape windows are the same size, almost all of my Emacs windows are the same size... typically you don't link together multiple windows of different types, you link together multiple related windows of the same sort. You don't have just one frame, you have a bunch of separate frames you can go between, and it's a hell of a lot more powerful (and convenient) than the alt-tab mechanism you described.
--
"Is not a quine" is not a quine.
I have a master's degree in science!

[ Hug Your Trikuare ]
[ Parent ]

Nice. (none / 0) (#49)
by 11223 on Mon Dec 18, 2000 at 11:08:42 AM EST

Where can I get your pwm setup?

--
The dead hand of Asimov's mass psychology wins every time.
[ Parent ]

Setup? (4.00 / 1) (#58)
by fluffy grue on Mon Dec 18, 2000 at 03:04:14 PM EST

Do you mean the decor configurations? Those are just a slightly-modified version of look-akike (which is available from the pwm homepage or is in the source distribution or something). Basically I changed border_w to 4,1 and on tab_sel_colors I switched the red and green values (I like seeing which tab is active on inactive windows). Otherwise the look is unchanged.

For the dock, I just specified a geometry of +0+0 and an orientation of vertical ("dock "+0+0", 0" in the screen section of pwm.conf), and the dockapps I have running are (in order) wmCalClock, wmWeather, wmtop, wmavgload, and wmifs.

Keyboard and mouse bindings I have setup based on my own preferences, and IMO everyone should set those up for themselves rather than using someone else's configuration (what makes perfect sense to me is probably 'WTF' material for others).

The only remaining things to configure require a recompile. Of the CF_* flags in config.h, I only have uncommented CF_IGNORE_NONTRANSIENT_LOCATION (needed to force Netscape and XEmacs to be placed correctly), CF_NO_NUMBERING (I have tcsh setup with precmd/postcmd aliases to dynamically change the xterm titlebar to tell terminals apart), and CF_PACK_MOVE (dunno what that does, actually).

There's also an annoying "feature" in the window close command which causes pwm to issue a kill if a window doesn't specify that it accepts a close message at mapping time; as a result, if you close an XEmacs window, it issues a 'kill' instead, meaning the whole program dies (without any chance to save or anything), and IMO if a program doesn't accept close messages, then you should explicitly have to kill it anyway (much safer). To fix this, in clientwin.c's close_clientwin() function I commented out everything but the send_clientmsg() call. This makes XEmacs behave correctly again. For the rare app which requires a kill instead of a close, I have alt-shift-f4 mapped to 'kill' (and there's always the window ops mwnu).

Oh, and the xmms skin is the GTK+ theme, available from xmms.org. It's the only xmms skin out there which isn't gaudy, fugly, unreadable, or otherwise dumb. I wish xmms could be configured to just use normal widgets in a normal window, actually...
--
"Is not a quine" is not a quine.
I have a master's degree in science!

[ Hug Your Trikuare ]
[ Parent ]

Good idea. (5.00 / 1) (#59)
by 11223 on Mon Dec 18, 2000 at 03:21:41 PM EST

At some point, when I have time, I'll make a plugin for xmms that clones the SoundPlay interface.

--
The dead hand of Asimov's mass psychology wins every time.
[ Parent ]

Hehe (3.50 / 2) (#73)
by fluffy grue on Tue Dec 19, 2000 at 02:16:18 AM EST

That's the funniest damn HREF I've ever seen. :)
--
"Is not a quine" is not a quine.
I have a master's degree in science!

[ Hug Your Trikuare ]
[ Parent ]

Too narrow (2.42 / 7) (#10)
by Delirium on Sat Dec 16, 2000 at 04:30:19 AM EST

I think this is putting too narrow a focus on things - the future of the desktop in general (whether it be on Linux, Be, Windows, or Mac OS) is a much more important question than what the future of one particular OS's desktop will be. I personally hope that the future of the desktop is anything but X: its remote access features are its only redeeming value, and beyond that it is a complete nightmare to actually use. Just about every single other desktop system designed has advantages over X for a single user on a single computer.

Nah.. (2.50 / 2) (#11)
by evvk on Sat Dec 16, 2000 at 04:54:02 AM EST

X is bloated, slow etc. but at least it gives the freedom not to use the modern braindamanged desktop environment paradigm/GUI that windows et all almost force me to use. And this is what I care about. Much rather than seeing X die, I'd like to see the WIMP paradigm die. There are so little non-wimp graphical applications anymore. Hail the g'old DOS days! Most terminal applications are much better and simpler as well (links: the most usable browser, just missing graphics, many news readers, e.g. slrn: just a few keys needed). What I'd really like to have is graphical applications reminiscent of old DOS programs fitted to run in a single window in a "windowing" environment such as Ion (or something better?).

[ Parent ]
objects (3.00 / 4) (#13)
by mikpos on Sat Dec 16, 2000 at 11:01:41 AM EST

I've played around with this a little (mostly in my head, but also somewhat in code). My approach was, maybe not surprisingly, to work with everything as objects.

What I did was make a proof-of-concept for an objective shell (i.e. as a replacement for bash or tcsh or whathaveyou). It was kind of Smalltalk-ish, except much simpler (you couldn't define your own methods, and variables were implicitly declared), but with a syntax much like that of Objective C's (mainly because I think Smalltalk's syntax is so ugly). You would get a class by loading it from a .so file. My first real script looked something like this:

system = (CLoader file: stdstuff.so) symbol: system;
system execute: 'ls -l';

The back-end of it was written in Objective C, which made everything except the parsing embarrassingly easy (because Objective C has dynamic binding, if you're not familiar with it). I later added things like pipes: methods could return objects such as stdin and perform operations on them (or pass them around). Threads were also a must and were implemented early on.

It was all fun and good, and did well as a proof-of-concept, but things which would be essential would be:

  1. CORBA. This would probably work best with an inetd-type dispatcher for CORBA objects (or better yet, classes)
  2. a graphical representation. I was thinking that something like Buzz Tracker would provide a nice interface. You basically have a graph (in the mathematical/CS sense of the word) with the nodes being objects you've created and the lines being connections between them (such as pipes). Bonus points for adding superfluous 3D and translucency ;)

Basically, my "itch" for doing this was the problem with the current state of GUIs: you can't script GUIs. No, VB and Tcl do not count. Things which should be trivial, even such as making a GUI replacement of Unix yes, are extremely hard for some reason. With my plan, you could get or pass objects from/to applications, even while they're in the middle of running, making scripting quite easy, even for non-programmers (I hesitate to say the Average Joe).

One other problem I have with the current GUI: I don't like windows. I've been told (and I accept to a great degree) that the difference between no-windows and maximised-windows is pretty slim, but it is there. I hate having to start up X just because some of my favourite applications use it; my dream GUI is more-or-less Linux FBCon (thank God some people are starting to use GGI and OpenGL+GLUT).

Anyway maybe when I get some time, or someone (hopefully much smarter than me) does and gets to making a really cool scriptable object-oriented interface (GUI or otherwise).

TCL (3.00 / 2) (#21)
by fluffy grue on Sat Dec 16, 2000 at 04:01:32 PM EST

Actually, TCL's a very good scripting language on its own. And it's not a GUI (you might be thinking of TK, which is a windowing toolkit designed for TCL), and I don't think anyone would claim that TCL is a 'scripted GUI' as you had attempted to shoot it down as. Though as far as scriptable GUI systems, why doesn't TCL/TK count? (Hey, did you know that a lot of Tux Racer is scripted in TCL?)

Semantics aside, TCL can be used as a shell as it is, and it's got object-oriented extensions ([incr tcl] for example). Even without those, as an extension language it's very easy to add object-oriented semantics into TCL (like I did for the MU*-type engine I wrote as my networking project).

On a somewhat topical note, I'd consider TCL to be an innovation in the open-source community. It was written by some guy who had an idea for a simple, consistent extension language which is both functional and imperative, and has always been put under a BSDish license, even from the original release.
--
"Is not a quine" is not a quine.
I have a master's degree in science!

[ Hug Your Trikuare ]
[ Parent ]

tcl (2.50 / 2) (#24)
by mikpos on Sat Dec 16, 2000 at 06:28:57 PM EST

I'm sure Tcl is a great language, but what you're just doesn't fill the void. I'm looking for something for the end-user, not the programmer. There really isn't any language that's going to revolutionise things, especially since all languages are more or less the same. Instead of "VB and Tcl don't count", I should have said "conventional scripting doesn't count".

[ Parent ]
Ah, okay (4.00 / 2) (#25)
by fluffy grue on Sat Dec 16, 2000 at 06:52:42 PM EST

In that case, yes, I agree. It's too bad that visual language research seems to be going in circles and spinning its wheels for now. My advisor is doing research on visual languages for robotics control (though I don't think he has anything on his webpage), but for mainstream applications, yeah, right now everything's a textual scripting language, which is incredibly detached from the visual nature of things.

I personally think that there's a long way to go before it's possible to even consider making a standardized cross-application visual scripting mechanism though. First there needs to be unified semantics for describing, choosing and controlling widgets, and until the whole world is using one widgetset that wouldn't even be conceivable, and even if everyone were to use, say, GTK, even among GTK programs a lot of things are just plain inconsistent in ways which make even simple things, like using 100dpi fonts (instead of 72dpi), break the programs badly.

That said, in the context of trying to create a visual language with a unified communication/scripting mechanism for the purpose of building and interacting with GUIs and the like, yes, your SmallTalk-ish system definitely has merit. However, I don't see why you feel it's necessary to create a new language for that purpose rather than extending an established language (again, TCL is a good candidate for that).
--
"Is not a quine" is not a quine.
I have a master's degree in science!

[ Hug Your Trikuare ]
[ Parent ]

FilterTop (3.00 / 1) (#37)
by FunkyChild on Sun Dec 17, 2000 at 05:14:41 AM EST

Have a look at FilterTop. It's a Mac program that I think is the sort of thing you're looking for. I've been longing for a nice 'scriptable' GUI for ages and ages.

We already have great tools on the command line (eg. pipes, redirects etc.) - wouldn't it be nice to have the same sort of power in the GUI? Even something similar to 'Actions' in Photoshop would be good, where you could press 'record', then perform a sequence of tasks, then press 'stop' to save it, then be able to play back those actions.


-- Today is the tomorrow that you worried about yesterday. And now, you know why.
[ Parent ]
What's the replacement? (3.92 / 13) (#14)
by MeanGene on Sat Dec 16, 2000 at 11:11:52 AM EST

As much as any of us would like to be remembered for posterity as an inventor of a brand new computer-user interface, there're some things that we just cannot change.

The reason that functionally cars' "user interface" hasn't changed much in this century is that car manufacturers cannot change the fact that human drivers have two hands and two legs. The only variation IRC is the position of a shifter - steering column vs. between the seats. And thank god that brake pedal is always on the left of the gas pedal!

Tanks don't have a steering wheel - they have 2 handles for the left and the right track. This is not an "advanced user interface" - convention has been sacrificed for the sake of simpler design - no steering or differential on tanks!

Right now, just like in the times of Xerox PARC, computer users have a 2-dimensional screen, a keyboard and a pointing device. 2-dimensional screen IMHO is the main stumbling block - while it's here, all attempts to change the GUI will fail. So, I guess, we should wait for holographic true 3-dimensional displays or a direct brain interface of some sort...

UI innovations: cars, tanks, GUIs (4.00 / 1) (#48)
by flieghund on Mon Dec 18, 2000 at 10:32:07 AM EST

I agree wholeheartedly about the automobile "user interface" -- I test drove the new Toyota Echo, and it absolutely freaked me out that they moved the instrument console from behind the steering wheel to the center of the dashboard. I know someone who actually has an Echo and says they love it, but even they admit that it took a lot of getting used to.

IIRC, you can steer a tank. Just stop (or slow, or throw into reverse) one of the treads, while the other continues forward. The cheapy $5 RC cars "steer" via this method. And -- demonstrating that I have absolutely no clue about transmissions -- tanks have different rates of speed. The M1 Abrams has a top speed of 35 mph (or something like that), but it is certainly capable of travelling much slower than that. Perhaps I misunderstand what you mean by "differential."

Blaming the prevalence of two-dimensional screens for the lack of innovative GUIs is an easy way out of the argument. There exist today various 3D technologies (think gaming glasses) that range from really cheap (ELSA 3D glasses for $40) to really expensive (Sony? projection glasses, probably over $1000). I also don't see why a keyboard is necessarily a limitation. If you're implying that it is merely a "two-dimensional interface," I'd argue that it would be trivial to adapt it to 3-D. Just making this up on the spot: H is origin; bottom row is +/- along z-axis, home row is +/- along x-axis, top row is +/- along y-axis. Between single keypresses and chording, you could navigate (via keyboard) through a three-dimensional space (GUI). Seems like it'd be easy to do the same with your mouse; most 3-D viewers (like VRML browsers) already do this, with left-click, right-click, and middle-click controlling rotation and/or navigation along the three axes.

Would all of these take time to become accepted? Absolutely! But seriously, my first two computers didn't have a mouse. I used to load into Win 3.1 (to take advantage of better fonts) and navigate by keyboard. That was like hitting my head against a brick wall, so I went out and bought a mouse. But that was such a fundamental shift in the user interface that it took me quite a while to get used to it. Even today, over 10 years later, I still use keyboard shortcuts (like Alt-Tab, Alt-F4, etc.) about half the time, rather than clicking on something with a mouse. However, I also take full advantage of the features of my mouse: I feel crippled when I can't scroll using the mouse wheel.


Using a Macintosh is like picking your nose: everyone likes to do it, but no one will admit to it.
[ Parent ]
Well... (2.07 / 13) (#15)
by maketo on Sat Dec 16, 2000 at 12:13:47 PM EST

Why not sit down and code up the "new" GUI? I mean, I am sick of listening to "we as community have more potential to innovate" (this is not even true - all the community has done so far is immitate)...Just innovate! And show me the money!
agents, bugs, nanites....see the connection?
We can't all code... (2.50 / 2) (#34)
by bradenmcg on Sun Dec 17, 2000 at 03:40:24 AM EST

Many times people decide to write about a subject because they want to draw the attention of OTHERS to said subject. If the author could code it him/her-self, I'm willing to bet they would've tried...

<leonphelps>Yeah, now, uh, "sig," what is that?</leonphelps>
[ Parent ]
So instead of coding (3.00 / 1) (#63)
by Demona on Mon Dec 18, 2000 at 06:24:12 PM EST

find coders to team up with. As long as everyone is willing and able to work as a team (the Achilles' heel of any group effort, the chain being only as strong as the weakest link). Have a clear idea of your goals before you start trying to form a strong team, though -- replacing X (a la Berlin) is a far different job than "creating the desktop/user interface of tomorrow".

[ Parent ]
Why is there a need for change? (2.90 / 10) (#16)
by ObeseWhale on Sat Dec 16, 2000 at 12:14:00 PM EST

You commented that our UIs will suffer the fate of cars, never changing. I'd have to agree with you, except you seem to hold the conviction that this is a "bad" thing. The reason cars have not fundamentally changed for 90 years is because they WORK. They work well, are easy to understand, etc.

The same holds true for windowing UIs. Why should we stop using Enlightenment, Window Manager, Afterstep, etc. There's really nothing wrong with them. While change can often bring great advantages, in this case there really is no reason for change. If there was a big enough demand for change, IE a problem in the current system, people would start coding a new UI.

This is not to say people haven't undertaken such projects. There's always 3DWM, but I don't see much of a point to those, the status quo works. If it ain't broke, don't fix it.

---

"The hunger for liberty may he suppressed for a time; yet never exterminated. Man's natural instinct is for freedom, and no power on earth can succeed in crushing it for very long."
-Alexander Berkman
cars have worked the same for 90 yrs? (3.75 / 4) (#23)
by spectatorion on Sat Dec 16, 2000 at 05:22:29 PM EST

that is not true. you used to have to crank a car up. they used to run on diesel. there were no seatbelts, brake-lights in the rear windshield, airbags, etc. Of course, there is still a long way to go. cars are still inefficient (in energy terms), polluting, noisy, smelly, dangerous (ahem...ford/firesteone, but that's not the only example) and way too expensive.

what does this have to do with computers? well, many modern GUIs are unstable, bloated, over-engineered, underplanned, and poorly executed. there is a long way to go in GUI development. I want a GUI that will take up very little RAM, will be fast, and will not get in the way of my work but will make it easier. Show me which GUI will do that. None, as far as I'm concerned, although the free ones are getting there (except in the RAM department, where they seem to be going the opposite direction...which is expected, but very unfortunate).

[ Parent ]
The GUI you dream of is already implemented (3.66 / 3) (#27)
by cezarg on Sat Dec 16, 2000 at 07:36:16 PM EST

It's called photon. Seriously, forget the OSS efforts and do yourself a favour and download QNX (preferably the full version not the 1.44MB challenge even though that one is way cool in itself). I'm typing this from within QNX. I've only used it for two days but it keeps surprising me at how fast how stable and how responsive it is. Photon has all the necessary widgets and they are all very usable and very complete. While it's not earth shattering GUI revolution I think it's already where other UIs are trying to get. There is an excellent web browser bundled with it (Voyager) that's really complete and rock solid. On my system it seems even more stable than IE.

One thing that's really noticable when I work in QNX is that I (almost) never hear my hard disk. I don't know how they manage it but this thing just manages to work fine with the real memory of your machine. Try QNX it'll force you to reevaluate some of the beliefs you have about GUIs. I hope you'll enjoy it as much as I do.

[ Parent ]

Incremental Cars (4.50 / 2) (#33)
by Brandybuck on Sun Dec 17, 2000 at 01:10:24 AM EST

All of the differences you cite between the cars of yesteryear and the cars of today are merely incremental improvements. The basic car is the same. Four wheels, engine, chassis, body, steering wheel, even the trunk. Now if cars has evolved into motorcycles, THAT would have been a radical change.

In the same way, GUIs are undergoing the same kind of incremental changes. If you compare the original Xerox PARC workstation with today's KDE you will see huge differences. But the basics are still the same. Windows, icons, mice and pointers. And everything has been incremental: Xerox -> Lisa -> Macintosh -> OS/2 PM -> Windows 3.0 -> OS/2 WPS -> Windows95 -> KDE. It's not really as linear as this, as there's also a spur for the X11 window managers and desktops that KDE also inherited from.

I want a GUI that will take up very little RAM, will be fast...

Blackbox...

...and will not get in the way of my work but will make it easier.

Opinions will vary, but I think KDE comes close to fitting this bill, with GNOME hard on its heels. If you could get the functionality of KDE, a mature KOffice, and the size and speed of Blackbox, then that would be impressive. But it would still only be the result of incremental improvements.

In other words, no new technology...

[ Parent ]

Cars haven't changed??? (3.00 / 2) (#52)
by bafungu on Mon Dec 18, 2000 at 11:59:28 AM EST

I defy you to step into a 1910 vehicle and drive off without much confusion. The ignition uses a switch, not a key. Can you use a crank? Will you apply the choke? Will you prime the carb? Do you know how to adjust the spark timing and fuel mixture? Can you even drive a stickshift? Keep in mind that it's nowhere like a modern stickshift; the clutch is a handle, not a pedal, and the gearshift is not an H-gate.

There are no synchros in the transmission, so you have to double-clutch to shift gears. There's no accelerator pedal; that's a throttle lever instead.

All this for a device that does nothing more than speed up, slow down, and turn. About the only thing that hasn't changed much is the steering wheel (which used to be angled almost straight up). Not much to cheer about.

[ Parent ]

Innovation (3.14 / 7) (#17)
by Simon Kinahan on Sat Dec 16, 2000 at 01:04:34 PM EST

Innovation is not good in its own right, but only when it furthers some other goal. This ought to be a statement of the obvious, but I see far too many articles going "we ought to innovate more", and little else. Why ? Whats wrong with what we've got right now ? Making things different does not necessarily make things better, and far to many people assume everyone has the same idea of better, and therefore never bother to explain. As far as I can tell from the two paragrpahs of the article that actiually say anything at all, Zorander wants a more direct-manipulation orriented interfaces and end users systems that are more programmable. Those might be good ideas, I'm quite fond of the second, but they need fleshing out and then writing. Ranting at other people about what they ought to do is pretty pointless when you only give them 10 lines worth of actual direction, and that unsupported by any logic.

Secondly, the open source "community" is not terribly good at innovation. Thats because innovative software is primarily about ideas, and ideas have to exist in people's heads before they can be implemented, and then have to be refined over quite some time. Even the development of the UI for the modern ATM (cashpoint) machine took several years of development. Open source development is coordinated by mailing list, by and large, which is not a terribly effective way of communicating anything but the sketchiest outline of an idea. To really develop anything innovative, you have to be in day to day personal contact with your collaborators, just as those at PARC or Apple were when the first practival GUIs were developed.

Don't believe me ? Show me somethine genuinely novel developed from the start as an open source "community" project. In my view, this is not only the reason Gnome and KDE are weak windows clones, its also the reason whey their GUIs are inconsistennt and unintuitive.

Simon

If you disagree, post, don't moderate
The community? Hah. (3.40 / 5) (#20)
by evvk on Sat Dec 16, 2000 at 02:10:35 PM EST

As far as I am aware, there aren't any innovative "community" projects, open source or not. There, however, are free software projects mostly development by single authors that do represent new and perhaps innovative ideas; in the field of user interfaces as well. After all, good ideas are rare and usually just "appear" to someone and it is really hard to get people over whom you do not have any control working on a project or even enhancing the idea without something practical to show to them (and even then if it is very unconventional). The open source masses will just stick to cribbing what they're used to. Infact, I see "open source/free software community" as just a bad joke. The only thing the people supposedly belonging to the supposed community have in common is that they happen to use free software. So the most of rest of the computerized world is part of some windows community? Hah. I mostly use free software (but I'm perfectly fine with commercial software) myself and even have some projects but I certainly don't see myself as a part of some joke community.

> To really develop anything innovative...

I'd rather say "further develop an innovation" and could then agree with real-life contact being very important. To me, innovation is a new idea and isn't something that is developed or engineered. But these days, anything is called innovative, even if it has been done before, so...


[ Parent ]
I mostly agree (4.00 / 4) (#29)
by Simon Kinahan on Sat Dec 16, 2000 at 08:15:44 PM EST

I agree that its the "community" part of "open source community" that causes problems with innovation, rather than the "open source" part, but its become a kind of shibboleth that bazaar-style development works well. My point was that it only works well when you know exactly what you're doing (cloning Unix, for instance), and its hard to manage this with many people when what you're doing is totally new.

I'm not sure innovation - as in newness - is terribly rare. Its the combination of new with good thats rare. I could propose a theory now that handbag manufacturers are conspiring to take over the world. I hope thats new, its certainly dumb enough, but its not good.

I'm not sure innovations always spring from nowhere. The more examples I come across, the more I'm sure that the lone genius being struck by a new idea is very rare, if not non-existant. At least 2 people have rival claims to Edison to have invented electric light, for example, one of them substantially earlier. I think new ideas generally come about from some function of need and intellectual environment. Hence the importance of close day to day contact between collaborators.

Similarly, the original idea, whatever it was, is rarely the thing which actually sells. Many people have innovative ideas, very few of them amount to anything. Some of them are just dumb, but most of them fail because of some subtle conjunction of need and ideas, just as things succeed for the same kinds of reasons. For example, the telephone was thought of by many early promoters as a "content" play (though they didn't put it that way, these people were wrong in the same way as those peddling WAP today). rather than a form of personal communication. Bell finally succeeded by careful marketing - he finally worked out what people wanted to do with telephones then sold them in a manner that made them useful for the purpose.

To pick another example, I worked with a team with an innovative idea for designing GUIs once. The original idea was OK, indeed I'm still thinking about ways of doing the same thingh, but the implementation and marketing were so poor they had been at it for 10 years and never got anywhere.

Simon

If you disagree, post, don't moderate
[ Parent ]
Scriptability (2.66 / 6) (#22)
by simmons75 on Sat Dec 16, 2000 at 05:07:10 PM EST

I still love TkDesk. I had bzip2 on the context menu the same day I saw bzip2 hit freshmeat.net. :-)
poot!
So there.

Hrm. (none / 0) (#88)
by simmons75 on Tue Dec 19, 2000 at 02:51:15 PM EST

I gotta wonder why people rated this comment down. Perhaps I should have explained what I meant. Maybe I'm just a victim of the new system and people are just rating me down because I rated them down? Hrm.

The thing about TkDesk is, even though it's ass-ugly, it's ultra configurable. Anything you can do, just about, can be configured without rewriting core code. For instance, the bzip2 example I gave: it's just a few lines in a config file, and can be re-loaded while the system is running.

Will the average Joe Blow user need scripting capability? Nah, but it'd be nice to have something on par with TkDesk that's also scripting-friendly.
poot!
So there.

[ Parent ]
Hrm. (none / 0) (#89)
by simmons75 on Tue Dec 19, 2000 at 02:53:02 PM EST

I gotta wonder why people rated this comment down. Perhaps I should have explained what I meant. Maybe I'm just a victim of the new system and people are just rating me down because I rated them down? Hrm.

The thing about TkDesk is, even though it's ass-ugly, it's ultra configurable. Anything you can do, just about, can be configured without rewriting core code. For instance, the bzip2 example I gave: it's just a few lines in a config file, and can be re-loaded while the system is running.

Will the average Joe Blow user need scripting capability? Nah, but it'd be nice to have something on par with TkDesk that's also scripting-friendly.
poot!
So there.

[ Parent ]
Open innovation (3.10 / 10) (#26)
by slaytanic killer on Sat Dec 16, 2000 at 07:24:59 PM EST

You know.. all the development environments I've used were Free Software, with the exception of:
HP-UX Fortran 77
VHDL simulator
Sun Java cmdline tools
Various OS's + Wordpad

And two of those probably are "Open Source." As for the rest, I've continued a tradition of trashing the commercial products for being inferior for pure programming & design.

There is a great deal of innovation, but not much that visually strikes the eye.. very much like the old half-jokes about making sure you get the graphical things in place before the internals, so management & investors think everything's going very fast.

In fact, it's not a joke at all. There are many companies right now sharking for investment money, creating graphical interfaces without having the backend in place. Does it slow down development in the long run? Yes, but the highest priority is not speed or flexibility but creating workarounds.

That is why people think the current state of the Linux desktop is very sad -- Gnome/KDE is actually progressing very quickly. It just doesn't show immediately. It took years for Windows to get it "right" after stealing from Apple, if they actually did get it right. Apple stole ideas from Xerox-PARC. Does either of the two have modifiable skins? Certainly not; they each provide one Look & Feel without possibility to easily modify it.

A truly intelligent company would start out from stable systems, and test out the technologies, to the point where they are capable of implementing things quickly. But that is not possible under current conditions -- Free/Open Software projects however would provide such a training place.

Some comments (4.08 / 12) (#28)
by RangerBob on Sat Dec 16, 2000 at 08:02:31 PM EST

This isn't a rant, so don't take it as such :) I'm biased since this is some of the stuff I research at work.

Sorry, but I had to give this a -1. The first problem I have is that user interface issues aren't specific to one operating system or the other. I'd mod this up if it was more of an OS neutral discussion of the human factors of computer interfaces. Problems with GUI's extend far past the Linux/free software realm. They even go past the desktop computer realm into things like digital cable and satellite systems.

Secondly, although it might be because of your Linux slant, you seem to ignore a LOT of research that's going on in human-computer interfacing. There's work at places like MIT to replace the traditional monitor/keyboard with virtual environments projected in space and seen through glasses or goggles. There's work being done in tracking eye movements, natural language interaction, and the like, to make computer use less obtrusive.

And believe it or not, most companies DO employ human factors specialists in their studies of how to design their GUI's. Remember, what works well for 20-something computer hackers doesn't work well for kids or 80 year old technology fearers. A graphical user interface also doesn't work so well for someone who's blind or has poor eyesight, so that's not always the best solution either. Just because they're commercial doesn't mean they don't also think about this stuff.

Also, just because you might not like how Windows looks or KDE/GNOME following the same ideas, it's not a dire problem that will destroy Linux or other free operating systems. Like it or not, old technology isn't always so bad. I'm pretty sure that as I use a hammer to hit things in about the same way that early humans did. Innovations generally come only when there's a big need for them. I'm not saying that current UI's and cars are perfect, but I don't think they're such supreme design mistakes either.

Your wrong about human factors analysis (4.50 / 2) (#53)
by Alhazred on Mon Dec 18, 2000 at 12:05:02 PM EST

I can tell you from first hand experience. Yes, Microsoft and IBM both have very high end human factors labs. They stand empty. I know this for a fact since my former boss was offered the job of running MS's human factors lab. She turned the job down since the company doesn't even bother to use it!

Human factors, if ever considered at all, is generally one of the very last things on the agenda in commercial software development groups. Whatever "innovations" do happen are generally the result of individual software developers or GUI development teams simply tacking on stuff that they think might be neat and letting the market decide if it works or not.

Sure MS has very set standards for its programmers to follow in UI design, but those were developed essentially entirely by trial and error over many iterations of product life cycle, and in a very ad-hoc fashion. Certainly NOT due to some kind of concerted research effort on human factors!

As in any area of technological endeavour, standards are both enabling and limiting. Within the narrow niche which today's UI's fill, standards are a good thing, but the point here I think is that they also force you into a box. That box is becoming increasingly a limiting factor in the quest to reap the full rewards for society of todays advanced data processing technologies.
That is not dead which may eternal lie And with strange aeons death itself may die.
[ Parent ]

They might not, but others do (4.00 / 1) (#62)
by RangerBob on Mon Dec 18, 2000 at 05:51:12 PM EST

I've also talked to people from IBM who do a lot of these studies. I've read a couple of whitepapers from people at Microsoft about UI studies, so someone has to be doing it. It might admittedly still be more in the lab than released in the OS, though. I never said the designers are paying attention ;) I've also talked to people who work from other commercial and federal organizations who do this type of work. My statement was not strictly about Microsoft or GUI's to the operating system itself.

Yes, standards might be limiting, but they're awfully convenient when doing things like training employees to use software. Standardization is a good thing in this case. You also can't just release a really really different UI and expect it to be a big hit. Even if they're bad, the current crop of UI's have introduced a lot of population stereotypes that will take a while to get over. It would be like rearranging the numbers on a telephone. Old habits would be hard to break.


[ Parent ]
old != obsolete (2.50 / 8) (#31)
by Brandybuck on Sat Dec 16, 2000 at 09:03:31 PM EST

Just because something is old does not mean that it is obsolete. The GUI concepts of windows, icons, pointers and mice works. It's simple and elegant. There's no reason to throw it out just because it is old technology. If there are problems with it then we can incrementally improve it (as GNOME and KDE are doing) rather than throwing it all away.

The possibility does exist that Xerox made the right decision. Apple might have been right in emulating Xerox. And Microsoft might have been right in copying the Mac and OS/2. And Konqueror and Nautilus might have been right in copying Microsoft's Windows/Internet Explorer.

I suspect we will see incremental changes to the GUI. Some tuning here, some accretion there. Maybe some trimming. But the GUI of the future will probably still have four wheels and an engine.

Just one question (3.00 / 1) (#35)
by evvk on Sun Dec 17, 2000 at 04:35:58 AM EST

What's the reason to replace command line and other good keyboard-based interfaces with mice and windows? Command line is older and it works better! (To me, the GUI does _not_ work - it is clumsy and slow.) Why can't keyboard based interfaces, like command line, be enhanced, say, with graphics? (There's xmlterm but it is not that good.) Back in the good old days of DOS there were many good (pseudo-)graphical keyboard-friendly programs. Those are mostly dead now.


[ Parent ]
The Command Line (3.66 / 3) (#41)
by Brandybuck on Mon Dec 18, 2000 at 02:25:50 AM EST

Nobody took away your command line. All unices have it. Even Windows still keeps an emasculated version of it around. And Macintosh is going to *add* one in OSX.

Here's what a GUI is good for: you can put up sixteen xterms on your screen...

Some people think visually. Others verbally. The GUI is good for one while the CLI is good for the other. Most people are somewhere in between.

[ Parent ]

Real research costs real money (2.57 / 7) (#38)
by leviathan on Sun Dec 17, 2000 at 05:57:46 PM EST

Innovation in the field of open source GUI design doesn't happen because to engage in the type of research needed to find out what a good GUI is takes a lot of money. It's not really something that can be done in the traditional, distributed, open source manner.

The best that can be done with open-source is to scavenge the research which has been done already, and is being done all the time. Now, unfortunately there's not a great deal of research into the fundamentals of desktop GUI design; most (I would guess) is currently going into finding out about the usability of future internet devices. People developing the Linux desktops have to make do with taking ideas from the desktop environments that are already out there.

Of course, Windows isn't the be all and end all of desktop GUIs, and most definitely shouldn't be regarded as such. Lots more innovative GUIs have already been developed and their influence has been felt (ROX is a favourite example of mine). As the features permeate more into different packages, you should be able to pick and choose the features you need (hopefully in sensible combinations).

--
I wish everyone was peaceful. Then I could take over the planet with a butter knife.
- Dogbert

ROX? Innovative? (3.00 / 2) (#42)
by evvk on Mon Dec 18, 2000 at 02:34:22 AM EST

Could you tell me what is so innovative about it? To me it seems just yet another WIMP desktop environment. Nothing innovative about that, however implemented and with whatever buzzwords. In general, almost no one seems to do research on alternatives to the xerox GUI paradigm. I loathe it; compare it with a pile of papers that is never in order and that you have to handle with a long stick (clumsy and slow as the mouse). Before windows became the dominant OS, there used to be some programs with nice specific graphical, keyboard-friendly UIs.

[ Parent ]
Nice specific graphical, keyboard-friendly UIs (3.00 / 2) (#45)
by leviathan on Mon Dec 18, 2000 at 09:21:52 AM EST

You're absolutely right that ROX isn't innovative in the features it gives you, as they are all taken from the PARC research, or developments done on that (the Apple research which eventually led to the Mac springs to mind). The only real thing that's innovative there is the combination in which they're put together. I suppose I'm just highlighting that it's not Windows, it's not MacOS and it's not X-like. Comparitively, it seems quite innovative.

Now, I was under the opinion that there are two UI paradigms in the world; command line, and WIMP (as defined by Xerox and the work done ever since). Can you give me any specific examples of your nice graphical UIs which don't fit squarely under the WIMP paradigm?

Incidentally to my citing of ROX is the fact that the UI it was based on was first released in 1987/88, quite early on in most peoples perceptions of GUIs (Mac officianados excepted). At the time it seemed a great breath of fresh air, and I'm glad to see the concepts it introduced are being perpetuated onto a more modern foundation.

--
I wish everyone was peaceful. Then I could take over the planet with a butter knife.
- Dogbert
[ Parent ]

Good UIs (2.66 / 3) (#56)
by evvk on Mon Dec 18, 2000 at 02:58:48 PM EST

To speak the truth, most of the UIs that I remember as good were not exactly graphical but rather text-graphical (remember, line-drawing characters and all). Except for games. Infact, some games still do have nice, simple UIs (although too flashy for applications). I could even claim that almost any program that did not support mouse had a nice UI :-).

It's a long time since I've used any of these programs but, as an example of a partly graphical program with a relatively nice keyboard-friendly UI, have a look at Scream Tracker (or the clone, Impulse Tracker). Or just about any graphical DOS program that did not really support a mouse. I can point out more examples of non-graphical programs with a good UI. Telix (or Minicom on *nix) is one such. Slrn (a news reader) and some other full-screen terminal programs have some good elements but they're a little too much configuration file and remember-all-the-dozens-of-keybindings based in an unix tradition. Why couldn't there be such graphical programs? Why not graphical lynx/links?

It is pretty hard to explain and I don't know what should I call it, but I'll call it "linearity" - the very feature of a nice UI. Consider the UI a tree with the screen as root node. WIMP UIs have lots of leaf nodes (windows, buttons, etc.) expanded (==visible) at a time and in no linear, easily navigable layout. Thus it is really hard to get to a node with the keyboard. A nice UI, on the other hand, just has a few leaf nodes expanded, all of them having the same immediate parent and moving between them is easy (e.g. a dialog with all the entries listed one above the other; and only one dialog). It is a bit like using breath first search vs. depth first search. There's just too much stuff on the screen in an hardly navigable order in WIMP. (Command line or even a unix text editor can be seen as the simplest case - only root node expanded.)


[ Parent ]
Cluttered UI (3.00 / 3) (#64)
by leviathan on Mon Dec 18, 2000 at 06:48:09 PM EST

You may well have a point there. I could point out that RISC OS, the foundation to ROX, is to this day supplied without an Alt-Tab task switcher. It's just not necessary. A commonly applied feature to minimise clutter is, if you double click on an icon which spawns a new child window using the right mouse button, the parent window is closed at the same time. Clicking right button on the close widget of a window closes it and opens the parent. Here your concept of trees extends from the root of the disc all the way through tarchives and into an editor window or viewer, and it can all be unwound again. (I can also drag and drop between the text editor and k5 browser window without saving first - kewl!)

But this isn't the place to advocate your favourite editor/OS/GUI. The nice clean RISC OS desktop has suffered somewhat since the dawn of the Internet. No matter how carefully you place your windows, you can't get a chat window, text editor and two browser windows and your mail open simultaneously and all within easy reach. So even the best designed WIMP system [that I've seen yet] can only stretch so far before it gets cluttered. I suspect a flatter text based system like you describe would have similar trouble, and probably not let you open two browser windows simultaneously.

YMMV, of course. I've yet to try out ROX myself as I've not got a box powerful enough (that's not saying much). I'm assuming most of the principles above got carried over.

--
I wish everyone was peaceful. Then I could take over the planet with a butter knife.
- Dogbert
[ Parent ]

Re: Cluttered UI (none / 0) (#78)
by evvk on Tue Dec 19, 2000 at 09:01:15 AM EST

Yes, well, all user interfaces have their strengths and weaknesses. To me the main problem with WIMP is that it is way too mouse-based and keyboard-unfriendly. I don't like using the mouse (or equivalent device) for what could be done more efficiently and more ergonomically with the keyboard. (Windows.. argh.. my wrist; no problems with the keyboard).

By the way, have a look at Ion. It is a keyboard-oriented X11 window manager with a different kind of windowing metaphor. Ion divides the screen into frames, not a stack of papers thus keeping the workspace in order. Like the page says, it has its problems -- namely existing applications (for example, gimp is utterly unusable with it) -- and could be more user-friendly, but with right kind of applications and some work, I think it could become really good.

[ Parent ]

ROX ? (2.00 / 1) (#61)
by (void *)0x00000000UL on Mon Dec 18, 2000 at 05:46:29 PM EST

I don't see what's new in ROX. There's a toolbar on the bottom as in all GUI, icons, menus, scrollbar. Nothing is new. I don't see how it is more usable. Believe it or not, Windows is still the most usable GUI.

[ Parent ]
See my posts in the other branch of this thread (2.00 / 1) (#66)
by leviathan on Mon Dec 18, 2000 at 07:21:35 PM EST

Granted, there's nothing new under the sun, but it was at least more fresh in 1988. I don't know exactly how much of this came from Xerox, or Apple, or GEM though. I haven't done the research. As to your opinion that Windows is the most usable GUI, well, everyone's entitled to one, and I ended up giving some of my reasoning as an aside.

--
I wish everyone was peaceful. Then I could take over the planet with a butter knife.
- Dogbert
[ Parent ]

Beating a dead dead DEAD horse. (1.83 / 6) (#39)
by buzzbomb on Sun Dec 17, 2000 at 08:23:56 PM EST

The answer of course is... ...whatever the preference of the end-user is. Why does UNIX need a standard UI environment? I prefer KDE, but a lot of people prefer Gnome. Both teams are willing to keep working and don't mind the duplication of effort, so more power to them AND the users of the software.

I'm Torn (2.75 / 4) (#40)
by /dev/Idiot on Sun Dec 17, 2000 at 10:15:49 PM EST

I'm torn as what to think, this is something I have a keen interest in. I am not so sure I like _this_ particular story, but I like having this specific topic coming to the surface every 6 mths or so, just as a barometer of the way people are thinking on the topic.

We started a site for betting on linux, but... (3.00 / 5) (#44)
by TuxNugget on Mon Dec 18, 2000 at 08:48:14 AM EST

it is not widely advertised, and is still in alpha. The trick is coming up with issues that are quantifiable, insuring fairness of judging, that sort of thing. At one time I was curious about using sourceforge download statistics to bet on popularity of stuff like gnome vs. kde or gnutella vs. mojonation, but they have been having a bug with these stats lately.

Our site, Linux Futures is basically a futures-market game using "tux nuggets" as currency.

Now this begs the question of why you would want the tux nuggets. I imagine they could be used for site priviledges yet to be defined, or maybe we could find some vendors to sponsor prizes for who won the most tuxnuggets (so that your starting tuxnuggets don't count). The site is not anyone's full time job. Basically it is phpweblog for the front page plus a fairly serious pile of php for the game, and is available under the GPL.

Take a look and let me know what you think. I already know the UI sucks in places. If you want to be a hero, make up a contract to be traded and submit it or email me the idea.

This is not intended to be spam, but rather discussion. If you want spam, see my diary :-)

RE: Cloing Windows Apps (3.50 / 8) (#46)
by 11oh8 on Mon Dec 18, 2000 at 09:51:50 AM EST

The Poster mentioned that much of linux [desktop] development is cloning UI or functionality of Windows apps... I agree that this isn't innovation but this might be what is needed right now. Gnome and KDE are both trying to attract users from the other OSes. These aren't always the most experienced users and so the the message being sent is "Linux gives you the same interface and features as the other OS -- so you don't need to learn something completely different -- but with more stability and a lower cost".

I suspect that once Gnome and KDE mature (and their userbases grow), they will start incorporating new features not currently found in other systems.

11oh8

Window snapping (4.00 / 2) (#99)
by bjrubble on Tue Dec 19, 2000 at 06:34:08 PM EST

This is one the biggest UI improvements I can think of in the past couple of years (you may pooh-pooh, but I love it), and I consider it instructive. I'm not really sure where it came from -- I've read it was pioneered by WinAmp, but I thought I saw it in E earlier than that -- but at the current time it is an extremely common feature in open source WMs but is still missing from the major proprietary ones.

The point I'm trying to make (which I feel was hinted at by the previous poster) is that the systems that Gnome and KDE are nominally "following" are themselves trailing well behind the bleeding edge of innovation. It's not necessary for every OSS developer to innovate more; the main advantage Linux has over proprietary systems is how quickly it can adopt innovations, and as the open systems begin to reach parity with their commercial counterparts they will (hopefully) not slow down but simply draw on the innovations that haven't yet made it to widespread commercial implementation.

[ Parent ]
Imitation vs. Innovation (none / 0) (#102)
by edibiase on Tue Dec 19, 2000 at 09:20:31 PM EST

Cloning is not what is needed right now. I've developed a (not too non-obvious) idea of "conversion" -- what it will take for people to switch from their current position to a new one. In essence, what my theory says is that people don't want something that's equal, they want something that is provably better (and by a high factor) than what they've currently got.

For example, if current compact disc technology is such that 80 minutes is the maximum time available for audio, and I create technology that lets you shove 85 minutes on there but requires a new player, which technology is going to win? Yes, my technology might be better than the standard, but is it good enough for people to want to buy new CD players to use it? Probably not, in this case.

This is the concept of a switch threshold. (I had a better name for it before, but I forget it now ;-) Yeah, my parents could probably use KDE and GNOME without a problem. Yes, Linux is more stable than Windows. In fact, Linux is more secure than Windows, too. I trust Linux to have better technology behind it than Windows.

Is my family begging me to install Linux on their machines, though? No. First of all, Print Shop Deluxe, The Sims, and every other game or program they or their friends use or have is not available for Linux. Granted, I could use VMware or Win4Lin to let them use their Windows programs, but why? If they're interested in using Windows programs, they're only going to end up with a less featureful, slower experience with it going through either of those two programs. For any native Linux programs they'd be running, they'd certainly see a speed and stability increase, but there aren't many applications for Linux I can imagine they'd prefer over their Windows counterparts.

They are your stereotypical "average user," and they are nowhere near the switch threshold. If I had a GUI that was better than Windows, and applications better than their Windows counterparts (and, for that matter, if I had counterparts in general), I could get my family to switch. The threshold would be low enough. As is, though, they have no reason to switch, and I can't blame them.

GNOME and KDE will not attract users. They might make users who try Linux stay, but there's no way my family is going to accept, "It works pretty similarly to Windows, but with less applications you use!" as a rousing reason to switch. They would, I'm sure, be more inclined to switch if I said to them, "It's more intuitive than Windows, is faster, and has mature applications counterparts that work better than the Windows programs they replace."

What we need most is innovation, not imitation.

[ Parent ]

Interaction (3.42 / 7) (#47)
by nanook on Mon Dec 18, 2000 at 10:25:57 AM EST

<ramble>

When designing any interface to a technical system, be it a musical instrument or computer or whatever, the designer should always look at the interacting faculties of the interacter, the human being. Now, the current paradigm is a keyboard and a positioning widget and this approach I think is both a result from and a reason to the current GUI WIMP-paradigm.

When you deprive a computer of a positioning device, as the mouse, then the narutal UI becomes the terminal, or TUI (textual user interface). Of course there can be menus or "graphical" widgets and the TUI is not limited to a 25x80 VT100, but rather that everything in a TUI is accessible via letters (and maybe direction arrows etc).

As the future holds different interacting devices the UI paradigm is also subject to change, but the current GUI is not going away before these things are available at the same cost as the current $10 mouse and keyboards.

Case in point: consider the touch-screen; if deployed universally don't you think that the WIMP-paradigm would change significantly? I didn't say go away, but rather change because the representation of data graphically, symbolically, is not going away and a natural representation thereof is a small picture, or a small picture combined with a written "name" or identifier. Now, I have got 10 fingers which I have total control over. When using the keyboard I have some benefit from this, thus the keyboard is at least a bit effective. The touch-screen with pressure-sensetivity could be orders of magnitude more efficient as the range of impressions would increase about that much. The interaction with the computer is then no more confined to y/n a/b 0/1 but more as a musical instrument or pencil.

This is of course not instead of the digital keyboard or any other discrete devices but as a complement, a widening of the spectrum of interaction with computers. In ten years the CPUs frequencies will be on the order of 100GHz, and then most of their potential will remain untapped if we still use the current mouse/keyborad/discrete devices.

What role does the Linux desktop play in this development? Well, we can decide that for ourselves as we are the authors. I'd like to see support for innovative input devices (touchscreens, eye-trackers, brainwave-detectors) as soon as these are launched, but this will not happen until the demand for such devices are high enough. When they arrive, I'm totally confident that the Linux/OSS-community will find novel and very interesting uses because the ultimate hacker is the best person to research interaction with computers in the same way that the ultimate musician is the best person to enhance instruments.

</ramble>

--
"I am a charlatan, a liar, a thief and a fake altogether." -- James Randi

touch screen (3.66 / 3) (#71)
by cfish on Tue Dec 19, 2000 at 12:21:40 AM EST

I used a Wacom tablet for a couple of years as my pointing device. I think the biggest problem with touchscreens is that your arms get tired in half an hour. It isn't productive to normal users. Can you imaging sitting on front of a 21 inches touch screen monitor and work for 10 hours?


[ Parent ]
The mouse.. (3.00 / 1) (#75)
by evvk on Tue Dec 19, 2000 at 05:14:36 AM EST

Not only touchscreens get your hands tired but the mouse as well. Whenever I have to use windows (or similar way too mouse-based system) for a little longer, I can feel it in my wrist. No such problems with the keyboard.

[ Parent ]
Keyboards and Graphics (4.00 / 1) (#84)
by Joshua on Tue Dec 19, 2000 at 11:17:22 AM EST

When you deprive a computer of a positioning device, as the mouse, then the narutal UI becomes the terminal, or TUI (textual user interface). Of course there can be menus or "graphical" widgets and the TUI is not limited to a 25x80 VT100, but rather that everything in a TUI is accessible via letters (and maybe direction arrows etc).

I just wanted to point something out that I think a lot of people miss. There is one thing that M$ has done rather well with their GUI. I can use windoze almost entirely without a mouse, as it has a fairly useful hotkey system. Granted, there are a few exceptions, but in general, I can do everything that I can do with the mouse, with the keyboard. It does, however, involve learning quite a few key combinations, but that's fine. This is something that all the linux GUIs that I've seen yet have failed rather miserably in. I think a GUI needs to be developed that can easily adapt to new technologies. I want my GUI to support keyboard only, mice, touchscreens, writing tablets and whatever new technologies develop over time, and I want to be able to use whichever I like, obviously tweaked for ones I use most often, but just because you don't have a mouse doesn't mean you should be forced to use 25x80 vt100 (although I think that should be an option for a long time to come).

Joshua

[ Parent ]

Windows may have hotkeys... (2.00 / 1) (#85)
by evvk on Tue Dec 19, 2000 at 11:32:11 AM EST

Window may have hotkeys and everything, but it certainly is far from usable from the keyboard. It was desgined to be used with a clumsy rodent. See the last paragraph of my another comment for more.

[ Parent ]
Windoze and Hotkeys (2.50 / 2) (#87)
by Joshua on Tue Dec 19, 2000 at 02:43:21 PM EST

I don't know about you, but I can use windoze almost as well with the keyboard as I can with the rodent. It's just a matter of getting really comfortable with it. I think windoze is a better GUI than any of that old DOS text/graphics stuff was. That shit was different in every program, worked sometimes, didn't in others, and generally was very limited. I'd love to see a better opensource windowing system that handles hotkeys as well as windoze, as about the only thing I have trouble doing under windoze without a mouse is browse the web, which can be done, it's just a huge pain.

[ Parent ]
Blah. (none / 0) (#106)
by evvk on Wed Dec 20, 2000 at 06:31:34 PM EST

Well, if you think Windows is easy to use with the keyboard, I guess you haven't used a system that is really designed to be used from the keyboard. Traveling through dialogs that have no logical, linear, order for the components with just (Shift+)Tab is a pain. Too many hotkeys are a pain --- there just isn't enough short key combinations for all the necessary to be intuitive --- the system should support easy keyboard operation without falling to even window/dialog-specific hotkeys on everything. One of the reasons I like to write LaTeX (in addition to that word processors are generally buggy bloated crap) is that I can just write the commands, not having to remember hundreds of application-specific hotkeys (or fall to slow search-and-click method), only the same editor keys I use to edit any kind of text files.


[ Parent ]
I have to disagree (3.12 / 8) (#50)
by 3than on Mon Dec 18, 2000 at 11:57:26 AM EST

I don't know about you, but my Linux desktop does not look like Windows. I use Blackbox 0.61.1...Not windows. No icons, but it supports iconic state. No graphical file manager. Two or three Eterms. Or check out Enlightenment. It's quite similar to blackbox in some ways, but it has some different features.
I think these two projects, as well as what's happening to GNOME and KDE, show you what's happening here: the linux desktop is changing much faster than windows. The windows UI has refused to integrate as standard any of the features commonly found in Linux, like multiple consoles and desktops. Meanwhile, Linux is pushing the envelope simply by allowing so much customizability.
Let's face it; a Ferrari F375 is a world away from a Model T. GUIs will mature the same way cars did, and at a much faster pace. I wouldn't be too worried about this one.

blackbox is not different (3.25 / 4) (#57)
by Spider-X on Mon Dec 18, 2000 at 02:59:29 PM EST

Sorry, but calling Blackbox different is like calling the kettle black. Blackbox does have a menu system similar to the start menu, where you have categories, and hovering over them brings up subcategories, you still have the minimize and close buttons in the upper right hand corner of the screen, you still have a title bar, still only square windows, you still use a mouse pointer to move around and interact with objects, etc, etc... . Granted there are no icons, and no "start bar" but it is very similar. Windows is just as customizable as Linux, with different window managers just as available.
Tracking Number: X00369S16
[ Parent ]
Clues Are Nice... (3.00 / 1) (#91)
by Matrix on Tue Dec 19, 2000 at 03:28:28 PM EST

No, its not. Unix WMs had the "menu hovering thing" far before windows did - look at TWM or FVWM2, both of which far predate Windows. MacOS also had something like this - if anything, Windows copied the abovementioned interfaces. The square windows and minimize, close, etc. buttons have been a feature of UIs since the original macintosh, perhaps earlier. Ditto for the mouse pointer and objects.

As for Windows customizability, please back up your claims. Providing links to some of these Window Managers would be nice. You can have different themes, this I know. But Linux WMs change a lot more than that - compare WindowMaker to IceWM, and both to Enlightenment. I've also run across a few Windows shell replacements, but none provided anywhere near enough features to be usable.


Matrix
"...Pulling together is the aim of despotism and tyranny. Free men pull in all kinds of directions. It's the only way to make progress."
- Lord Vetinari, pg 312 of the Truth, a Discworld novel by Terry Pratchett
[ Parent ]

Thanks man (none / 0) (#94)
by 3than on Tue Dec 19, 2000 at 04:07:44 PM EST

I agree with your comments in response to Spider-X's dissent...I wasn't talking just about WM environments either. The fact that windows doesn't have multiple consoles is another huge factor in the UI thing. And I've seen some products that change windows look, like windowblinds, but many less that change functionality. And it's harder to customize.
I wasn't saying that the future is here or anything, but I just wanted to point out that things are on their way, and that there are already some alternate paradigms being developed. I don't approve of this, "why isn't anything being done?" attitude. It usually comes from people who haven't done their homework.

[ Parent ]
Hmm... (none / 0) (#104)
by Matrix on Wed Dec 20, 2000 at 08:53:40 AM EST

I'm interested to see what is being done. I already know about the Berlin Project, and I think they've got some neat features... But what else is being worked on? Do you know of any web pages that talk about the kinds of things that are being considered?


Matrix
"...Pulling together is the aim of despotism and tyranny. Free men pull in all kinds of directions. It's the only way to make progress."
- Lord Vetinari, pg 312 of the Truth, a Discworld novel by Terry Pratchett
[ Parent ]

Umm.... huh? (4.00 / 1) (#96)
by Ranger Rick on Tue Dec 19, 2000 at 04:23:57 PM EST

The point isn't "we did it first", the point is that every "windowing system" has a certain number of things in common (like, uhh... windows? :), and there is no real research going on out there looking into whether that's really the best way you can go about doing things or not.

PARC did everything first, end of story. But why are we still doing the exact same thing with prettier windows 20 years later?


:wq!


[ Parent ]
Linux and the accidental user interface designer (3.87 / 8) (#51)
by Pac on Mon Dec 18, 2000 at 11:59:06 AM EST

First, let me point where I do not agree with the author.

It is factually wrong to propose that the programming language field has stopped more than 15 years ago when dear Bjarne invented us C++. Unless you believe C++ is the one true programming language Saint Ada of Lovelace always wanted us to program with, you can not ignore Java, Python, Perl (although many people would contest that Perl is involution, not evolution) as improvements that took the language field a step ahead after C++. Generalizing to software development in general, UML is a huge step ahead.

Also, the concepts behind object oriented programming predate SmallTalk by at least a decade, maybe more. PARC may be credited for the introduction of the first widely used and distributed object oriented programming language, not for the creation of the concepts themselves (see The History of Simula, LISP History and also SketchPad) .

But enough disagreement. I do agree that the current dominant GUIs are at an evolutionary dead-end. Besides useless discussions about the number of mice buttons, the right place for toolbars and the right way to close or hide windows, no real innovation has been seen for a long time.

Linux GUIs do not depart from any of the fundamental concepts behind the Mac or the Windows interfaces. While this is a necessary evil if one is to compete with the established platform, it certainly should not be seen as the final step for open-source GUIs

Let us not forget Linux competitive edge. The open source nature of the OS makes it the ideal testbed for new concepts. Computer scientists and user interface specialists can not only propose new interface ideas but also implement and test these ideas with real users, something neither Windows not any other close OS can offer.

Also, the accidental designer of the title can launch and steer his/her project today, using the facilities provided by the community. I am not saying such project can catch moment overnight. But it may well be noted by enough eyeballs and codeheads to become viable.

As is the case with any other development effort, the actual Linux GUIs will always be aimed at mainstream. The end user does not want to learn a whole new interface paradigm and strategically we want Windows and mac users to feel at home. If and when the benefits of a whole new interface become visible to the end-user, widespread adoption will certanly follow


Evolution doesn't take prisoners


C++ evolution (3.00 / 4) (#54)
by ucblockhead on Mon Dec 18, 2000 at 12:55:14 PM EST

Even if you do believe that C++ is the "one true language", this still does not mean that language evolution is dead. C++ has explanded (bloated/improved depending on your bias) quite a bit since its inception. In particular, templates and the standard template library are a fairly radical addition.
-----------------------
This is k5. We're all tools - duxup
[ Parent ]
Well... (1.80 / 5) (#55)
by Zeram on Mon Dec 18, 2000 at 02:10:42 PM EST

I disagree with the assertation that "The solid kernel and X window system provide a firm basis for new user interface technologies." Hardware changes super fast. It's a pretty well know fact that when new hardware (AGP and USB are perfect examples of this) comes out, the first drivers are usually pretty bad. Thats why there is a development kernel. You can't code what you don't understand, and you can't understand it until you code it. All good things take time. And right now is time to wait for new hardware. The reason that GUI development is stagnant is because of the hardware that it runs on. It seems logical that in order for UI design to take the quantum leap that is being talked about in the article, that interface hardware will have to become more advanced. Speech interface, thought interface, something far out like that is what is going to be needed to advance UI design.

The other thing I take issue with in that statement is the idea of the X window system being a firm basis for anything other than a headache. It is a bloated peice of crap. And before you flame the hell out of me go take a look at the sourcecode, I'll think you'll be surprised by what you see. However I really have no room to bitch, I'm not a programer by any strech of the imagination (and please no flames for this either, I know enough to know that XFree86 is severly bloated), and it works well enough. I think though, that to truly innovate in UI design the open source community needs to either scrap X all together and start from square one, or at the very least severly retool X. X is much better than that thing from Redmond, however that does not make it great. The thing is (and being a lazy bastard by nature I fully understand this) that it would be such a herculean task to completly overhaul X, much less rewrite it, that no one seriously considers it unless there is a good reason, thus Metro who's good idea is being able to work on their windowing system full time by charging for it.

I think that while this is a worthy topic, it's not reasonable to expect rapid, overnight progress. This is the sort of thing that slowly evolves.
<----^---->
Like Anime? In the Philly metro area? Welcome to the machine...
regarding X (2.00 / 2) (#60)
by zorander on Mon Dec 18, 2000 at 03:36:29 PM EST

I agree with you completely. It could be a lot better. It's bloated and slow and seeing the sze of the source packages not to mention the compile errors they produced only acted to confirm that for me. It's a problem, yes. But it is more stable, configurable, and network aware then Windows or MacOS. There may be better in other lands. I haven't examined closely many other systems than these three. But of them, I woud attest that it would be best to build something new on top of X (on a side note, I've been working for a little while on something much smaller than X which provides similar features although in a completely incompatible way. don't expect code ever because it could amount to nothing, but i know X is terrible) zorander
---- Want to get into Linux? Cheap systems available now at eLinuxBox.com.
[ Parent ]
Here we go again. (3.66 / 3) (#74)
by pwhysall on Tue Dec 19, 2000 at 03:57:06 AM EST

X sucks. We all know that.

However, it sucks a whole lot less than the competition; it's transparently network aware, something that Windows and MacOS can only dream about; it's portable to more architectures and operating systems than any other window system; and goddamnit, it works.

I know, I know. It's huge. It's got sucky font rasterisation.

But perhaps you need to understand that a lot of X's memory usage comes from some fairly aggressive pixmap caching - which helps performance a lot.

I take issue with non-programmers making blanket statements about "bloat". The XFree86 team are a fine set of software engineers, and I seriously doubt that XFree is somehow "bloated". Hell, if they really were hell-bent on bloating it I reckon antialiased (not that silly-ass Windows-style "smoothing") font rasterisation would have been in there a long time ago.

There is an effort ongoing to re-engineer the window system - it's the Berlin Project. The amount of work that's gone into this is humungous, yet they don't have anything really usable yet.

X sucks. We all know that - but it sucks quite considerably less than anything else available, it works well enough, and runs on everything from OS/2 to OpenVMS.
--
Peter
K5 Editors
I'm going to wager that the story keeps getting dumped because it is a steaming pile of badly formatted fool-meme.
CheeseBurgerBrown
[ Parent ]

The problem isn't technology (4.40 / 10) (#65)
by costas on Mon Dec 18, 2000 at 06:53:01 PM EST

It's the model. Let me explain: all the major desktop OSes (Linux included) these days follow the old file-desktop model. That is, IMHO, their failure: instead of mapping (modeling) the expectations and perception of the User onto the computer's model, we are doing the exact opposite: we take what is convenient for the computer (files, directories, users) and map them into a kludgy metaphor: files as objects, objects as information.

This is where Linux/BSD can stop taillight-chasing and truly innovate: reverse the paradigm. Humans do not think of information as existing in small, digestible objects: say I am programming and I want to lookup a function in my language of choice (Python, if you care :-): I should be able to instantly find that information, locally on my own PC, and I should also find any of my old Python work that used the same function. Say I am a business user (which I am too) and I want to look up a presentation I did for a customer a few months ago, but I'd also like to find any other information that's relevant for that customer so I can make a better presentation next time.

The existing way of doing things (separating files into directories, "projects", perhaps duplicating info left and right) is NOT the right way to do it. An attributable, expandable file system is one way to deal with this (the way that BeOS does, brilliantly), but that still doesn't shift the human-computer-model: we still have to go hunting into the drive, we still have to launch an application to deal with the information and then keep in mind where we stored our finished work. In other words, we still have to accommodate the computer's limitations rather than the other way around.

Contrast this with how the Web has solved the same problems: because of the presentation, storage, etc limitations, (and the benefit of hyperlinking and good search engines), Web design paid a *lot* more attention to usability and retrieval of information than desktop UIs have: it's now easier to find information on the Web than it is on my own computer. That is sad.

What I'd like to see on Linux, is a GUI that will start taking care of me, rather than the other way around: I want an UI that will file, archive and index every piece of information that passes through or is created on my machine --be it text OR image, audio OR video. I want an UI that will start babysitting me damn it, not the other way around :-)...



memigo is a news weblog run by a robot. It ranks and recommends stories.
Interesting (2.33 / 3) (#70)
by cfish on Tue Dec 19, 2000 at 12:13:36 AM EST

Until very recently, this is too hard to implement because of the CPU power and humongous size of the metadata. But hard drives and CPU power has, for the past few months, become excessive to normal users. Maybe it's time to start planning on a hugely resource eating filesystem.

I mean this in a good way. the industry need something to eat up resources to encourage sales.

However, I doubt if everyday users will use something this sophisticated.

[ Parent ]
Next level of organization (3.00 / 3) (#82)
by Joshua on Tue Dec 19, 2000 at 10:55:20 AM EST

Great post, I agree with you completely. I think that what needs to happen is a whole new file system, without the concepts of files and directories. Where every object on the system (and on all systems) is like an abject in an object oriented relational database. When I create a data object (or a program object for that matter), be it text, image, video or program, instead of saving it with a filename in a directory it should be given certain keys and key values, of which it can be in as many as it wants. Inheritence could be used to build certain properties of different kinds of data objects on top of already existing objects. Users should never think about what program they use to get their data, they should think about opening that data for different operations, and the OS should figure the rest out. I can envision a browser looking something like Windoze Explorer style, but with a hierarchy of keys instead of a hierarchy of objects, and a way to run queries for whatever keys that are wanted, and for queries that are often needed (like showing all new objects of type e-mail, which are to a certain user (you). That browser could then also be used to browse the data on other machines and all kinds of other data.

Anyway, that's just one of the many ideas I have kicking around in my head about this subject, which I have given a lot of thought. I definitely think the way computers work at their core and deal with data is something that we need to think more about and not be entrenched in our ways. I'm on an e-groups mailing list, Next Level Organization about this very thing. We have a few people on it as well, and we got some good discussion going for a bit, but enthusiasm has wained. All the people on it, however, are not quite as experienced as would be needed to really get a project like that going, but I'm learning more every day so who knows. If anyone is interested, please join the group and read the archives (not that much), and take the conversation in new directions, as I still want to eventually start some projects about this.

Joshua



[ Parent ]
Cairo Connection (5.00 / 2) (#83)
by costas on Tue Dec 19, 2000 at 11:13:10 AM EST

What I forgot to mention in my comment and yours reminded me of, was Microsoft's "mythical" Cairo OS. Cairo was supposed to be NT 4.0 but it was never released (instead the technology behind NT 3.51 became 4.0 and then 2000/5.0).

The specs that MS vaporware was announcing for Cairo pretty much are what we are talking about: an OFS (Object file System) that does exactly what I was suggesting, an OOP abstraction of the OS, a platform-independent VM, etc.

If you go digging on the Web for old Cairo reviews, etc, you'll see a lot in common with what MS is announcing now for .NET --with the (great) addition of XML as the underlying lingua franca. I am no fan of MS, but between .NET and OS X, I see hope in the horizon.

Can a technology like that be retrofitted on top of Linux? hell yes. I would suggest looking at Zope (www.zope.org). Zope is a completely OOP application server, written in Python and C (and extensible in Python, C/C++ *and* Perl). Zope does for the Web, what I'd like to see for the filesystem. But Zope (and the underlying Web/FTP/RPC server, Medusa) can go further: it can abstract the filesystem and represent it as an object model.

By retrofitting a Web application server underneath a desktop GUI you can combine two very well tested technologies, FAST --hint: Python has bindings for both Qt and GTK, as does Perl. The two beasts *can* be linked and quickly. If the demonstrator works --i.e. if people like it, if developer interest is kept-- the "slow" interpreted glue (Python/Perl) parts can be stripped out and replaced with C/C++.

Just an idea --and my $0.02

memigo is a news weblog run by a robot. It ranks and recommends stories.
[ Parent ]
Current Tech (3.60 / 5) (#67)
by Girf on Mon Dec 18, 2000 at 09:12:11 PM EST

It's already been said here multiple time; the reason we don't have an 'new' GUIs is because we are still stuck with your monitor/keyboard/mouse. It has also been said that this is not going to change until you get the holograms and the brainwave detectors.

However, we are not noticing that the UI is (slowly) changing. To look at your address book and your email you use a handheld device with a pen for a pointing device. To listen to your music instead of your sound card you now use a handheld device that can hold as much music as you will ever need.

And did you know that AOL has started a new service that allows you to access the Internet by telephone. Your desktop computer is slowly being marginalized. Yes, as long as you have a computer with a monitor/keyboard/etc you will still have windows, and WM, etc, etc; but there will become (soon) a time where you can do everthing you need with your wristwatch, and your watch will not have windows and a mouse...

-James deBoer

this i do not agree (4.00 / 3) (#69)
by zorander on Mon Dec 18, 2000 at 10:37:25 PM EST

I've seen too many people use the excuse "we're waiting for the hardware to catch up." This need not be the case. We have not yet fully realized the potential for what we already have. Yes a framebuffer can do more. I'm sure of it. and the keyboard and mouse, same deal. If while we sit here griping about hardware, .NET does some damage to us, will we still feel the same?

Brian


---- Want to get into Linux? Cheap systems available now at eLinuxBox.com.
[ Parent ]

But I agree fully (none / 0) (#103)
by Girf on Tue Dec 19, 2000 at 10:27:21 PM EST

.NET is not meant to exist on your computer alone, it is meant to be on your fridge, your alarm clock, the ATM machine down the street.

The hardware that will the used to support these new GUIs will not be the high tech halograms, it will be your devices you already use, but they will become your computer.

[ Parent ]

ummmmm. (none / 0) (#111)
by use strict on Wed Dec 20, 2000 at 11:10:39 PM EST

.NET, right now, runs on *windows*. it's a very good idea, and it'll blow java to pieces if it gets support on anything but windows. Of course, other than activestate, I don't think this will be happening anytime soon, and it'll fall dead with other microsoft projects like VB (relatively), ASP, etc. No one uses these things except on MS systems, and even in those environments the cost/feature ratio is so low you'd have to be wanting cheap or 'flashy' talent to get the job done. Neither of those solutions are practical and only serve a relatively small corner of the 'large presence' market. (the ones with shitloads of VC, mainly) Virtual machiens are nothign new, and neither is .NET, really, it's just the fact that .NET is not C# and C# is not .NET, and the IL between as glue give it the possibility of easily being portable.

[ Parent ]
Should, not Can (3.00 / 5) (#68)
by CAIMLAS on Mon Dec 18, 2000 at 09:38:51 PM EST

This is something that I've heard a lot of - linux should innovate and add new features that aren't available to Windows users that make it more desireable. Let me ask you a couple things.

Has Office 2000 added any additional features that are desireable for most people? Overall, is it a positive evolution, warranting the massive software bloat, excessive bugs and security problems?

Just because something can be implimented, does it mean that it should be? There is something to be said for simplicity. Arguably, most people don't use more than just a few of the features in Word processors - page formatting, spelling, text formatting, and the like. Templates, yes. But nothing much else, at least on a regular basis. My father, who uses Office 97 all day as a business owner and manager, does not even know what half of the 'tools' do. He doesn't need them, and operates quite efficiently.

If something works, should it be fixed? As far as GUIs are concerned, it's a matter of personal preferance. The look portrayed by MS Windows has been shown to be fairly popular. Why change what works? the hardware hasn't been changed much at all.

And the web server apache? It does what it needs to - serve web content. And it does it darn well. What more do you need in a web server?

What we really need to focus on is this: getting programs, such as OpenOffice, AbiWord, etc, to function opimally in parallel with their 'windows counterparts' and have them get the job done with as little frill as possible. Give people the features they need and use the most frequently, and make them work well - even better than MS's products. There's no reason for a word processor, or office suite, to take up several hundred megs of space.
--

Socialism and communism better explained by a psychologist than a political theorist.

Mac OS X imitate Enlightenment? (3.28 / 7) (#72)
by cfish on Tue Dec 19, 2000 at 12:50:54 AM EST

When I saw the Mac OS X desktop, I immediately think that the animated icons on the toolbar is an imitation of Enlightenment. Granted that OS X uses BSD; Apple DID write thier own GUI.

If I am right, the what gives Apple the right to pull Mac themes off themes.org, but freeload on BSD and imitate enlightenment?. Sure, Apple hires thousands of visual artists to make the desktop look nice. But what gives Mac people the right to claim that we are all low-life imitators?

Truth is, the community as a whole sees no wrong with imitation. We just want what works. We are not bothering anyone. We write our own stuffs. We choose a certain look and feel not because we like to imitate, but because we feel it's better.

This GUI design, if not naturally emerged for the hardware given, came from Xerox. Look at how miserable Xerox has been. It just shows that innovation doesn't mean success, but high quality imitation does.

Heh. (none / 0) (#86)
by simmons75 on Tue Dec 19, 2000 at 02:43:03 PM EST

"When I saw the Mac OS X desktop, I immediately think that the animated icons on the toolbar is an imitation of Enlightenment. Granted that OS X uses BSD; Apple DID write thier own GUI. "

Hrm, I haven't even gotten to see OS X in action yet. :-( Are you referring to the dock? If so, the dock is a direct descendent of the NeXT dock, which predates E.
poot!
So there.

[ Parent ]
And further (none / 0) (#119)
by pwhysall on Sat Dec 23, 2000 at 12:59:44 PM EST

Apple bought NeXT (or at least their IP), so they have the rights to the NeXT dock (and derivatives thereof).

So you could say that it's Enlightenment that is the ripoff merchant in this case.

:)
--
Peter
K5 Editors
I'm going to wager that the story keeps getting dumped because it is a steaming pile of badly formatted fool-meme.
CheeseBurgerBrown
[ Parent ]

Apple & NeXT (none / 0) (#122)
by migooch on Sun Dec 31, 2000 at 11:37:23 PM EST

Mac OS X is NeXTSTEP/OPENSTEP with a more Apple UI look and feel. The dock, development tools, etc. all were in NeXTSTEP/OPENSTEP. NeXTSTEP/OPENSTEP had some neat things, like Display PostScript (Mac OS X uses Display PDF), OO, and ran on the Mach kernel. Of course, just like Mac OS X, NeXTSTEP/OPENSTEP had a 4.3 BSD Unix layer with everything you could want, GNU tools, et al.

Apple bought NeXT in December 1996. You see, NeXT had been founded by Steve Jobs and other Apple employees he took with him in 1985. They created NeXTSTEP which was later renamed OPENSTEP for their NeXT line of computers, the NeXTcube, NeXTstation, and color variants of those. Later on they produced x86, PA RISC, and SPARC versions of their Operating System. The NeXTcube, NeXT's first computer was released in 1989. See any similarities in the NeXTcube and the Power Macintosh G4 Cube?

Also, if you look at Apple, it is basically former NeXT employees who run Apple. Steve Jobs, who was CEO/Founder of Apple, is now CEO of Apple, again. Jon Rubinstein who was vice president and general manager of Hardware and vice president of Hardware Engineering at NeXT is now Senior Vice President Hardware Engineering at Apple. Also, Avie Tevanian was vice president of Engineering at NeXT is now Senior Vice President of Software Engineering at Apple. He also started his professional career at Carnegie Mellon University, where he was a principal designer and engineer of the Mach kernel upon which NEXTSTEP is based, now Mac OS X.

-Michael

[ Parent ]
Packaging Problem Needs Solved First (1.66 / 3) (#76)
by edibiase on Tue Dec 19, 2000 at 07:15:05 AM EST

As I wrote (and discussed) in "Developing a More Usable Linux," I think there are some fundamental problems with Linux right now that need to be solved before there can be any hope of advancement on other fronts. The fundamental problem I want to talk about today is packaging.

You see, I was just about to write another rant in my diary when, conveniently, I came upon your article. And while I touched on several points you talk about in the aforementioned article, I feel that you did an excellent job of fully describing what I was trying to say.

However, like I said, advancement in the fields you talk about will forever be hindered unless we can get this packaging problem licked. If I have to spend time creating packages for 13 flavors/distributions/packaging systems, that's time that could have been better spent improving my program.

I'm not interested in beating this dead horse. However, I would like to say two things.

  1. I cannot code well. If I could, I would probably write this package management system.
  2. I do not have the clout in the community to push this system. Red Hat is firmly entrenched with RPM, as is Mandrake and several other distributions. Slackware has .tgz and (apparently) some new package-management systems in development. Debian has dpkg. I'd need to convince them all to adopt a standard packaging format.

Hrm, on that last one (you know, #2). What do you folks think about starting a petition to help standardize Linux? I'd be happy to create one, and post it as a submission here and maybe even at Slashdot. Would this be something you would be willing to support?

Wow... first I get a two-hour delay, then I get a cool idea for helping to standardize Linux. What a great day! ;-)

Binary packages (3.00 / 1) (#77)
by evvk on Tue Dec 19, 2000 at 08:40:14 AM EST

Having a standard packaging system for Linux is of no help; except for a standard package description file perhaps. After all, there are other computers than x86 and other OSes than Linux that well-written *nix programs run under. Bigger problems lie within package maintenance within a single distribution: 1) the binary packages are often out-of-date and 2) packages for older versions of the distribution are not maintained anymore and one would have to upgrade to whole system, usually breaking everything. Not all of us want to go through all the time. Commercial systems do not have that big problem with this. The problem with Linux it is constantly changing in small steps (the changes invisible to the user except as incompatibility induced annoyance). kernel 1.2->2.0, a.out->elf, libc5->glibc2.0, kernel 2.0->2.2, glibc2.0->glibc2.1, what next? (And something must still be missing...)

(Windows bi-annual maintenance: reinstall, Linux bi-annual maintenance: upgrade.)

I really like the source-based *bsd ports/pkgsrc system, though...

[ Parent ]

Debian (3.00 / 1) (#80)
by excession on Tue Dec 19, 2000 at 09:08:01 AM EST

Answers 99% of this email. It's constantly upgrading itself, it has an excellent package management system, coupled with APT. It's also aggresively crossplatform, i believe that woody supports all the platforms linux does, plus debian/hurd, debian/win32 and debian/bsd are coming along too.
(rpm-distro bi-annual maintenance: upgrade, while praying that you got all the dependencies etc right - debian bi-annual maintenance: go out and have a beer)
And the ports system doesn't tackle upgrades particularily well, unless you keep the ports tree itself fresh out of cvs, and then rebuild the packages.
-Thom

[ Parent ]
Not! (3.00 / 1) (#81)
by evvk on Tue Dec 19, 2000 at 10:43:30 AM EST

> Answers 99% of this email. It's constantly upgrading itself, it has an excellent package management system,

I have debian and completely disagree.
Constantly upgrading == new versions of the distro all the time that require to upgrade everything, which will then again break everything else. The packages are often old nevertheless. Debian bi-annual maintenance: apt-get upgrade and then fix the whole system by hand. (Though redhat was even worse...) I don't want to upgrade to a new version of libc everytime I install a new package as it potentially breaks my /usr/local programs... (been there done that.)


[ Parent ]
Agreed; Debian Has Flaws. Use the Source! (4.00 / 1) (#95)
by edibiase on Tue Dec 19, 2000 at 04:17:08 PM EST

Although I like Debian very much as compared to other distributions of Linux, mainly because it satisfies my goals of having most of the packages I need with the minimum amount of fuss so I can get on with my work, I definitely have to agree that it is certainly not a panacea for Linux's package woes. Though I've never had (many) problems with upgrades, the possibility exists.

As for stuff breaking your /usr/local programs, I wish that you didn't need to have them. Because, as you mention, Debian isn't always totally up to date (especially with many less popular packages), one often has to either stick with old programs or compile them by hand. This is what I meant when I said that it's best to either go completely with package management or not at all.

My solution (of course, since I'm the infamous K5 package management ranter ;-) is to make it so you can compile stuff from source and keep your system in line package management-wise. This is why I am a proponent of keeping things as automatic as possible for package creators: most likely, the people creating the package will be the people developing the program. It should be almost as easy for a developer to create a package as it is to create a tarball. Plus, the developer always has that added incentive that a package is more attractive to more people than a tarball, for reasons that I don't think need listing. The goal is to make it a gain/gain situation instead of the current loss/gain situation; developers should be saying, "Wow, this new package management format is easy to use and will let me reach tons of people," as opposed to, "Damn, this package management stuff is annoying, plus I have to create 13 of these packages to reach every Linux user."

[ Parent ]

a lot... (none / 0) (#110)
by use strict on Wed Dec 20, 2000 at 10:57:51 PM EST

of developers don't even want to package anything.. There was a slashdot thread on this yesterday, I think.

the debian project does a good job to make up for a lot of this, but a lot of people just don't care about that fringe windowing toolkit or something that's so alpha it can barely be used but it has hte 'perfect feature'

This happens on windows too, that's why you don't have installshield for putty and a lot of map packs for games come in .zip

I think a lot of the problem is that we're going too far with the package thing. We don't need packages for dotfiles that upgrade /etc/issue*, etc. That should be the admin's job or the job of the person maintaining the package that reads/uses those files (ie, getty, X, bash, etc), or the system admin.

But as I said in another post, if you want uniformity, BSD is your friend.



[ Parent ]
this is because... (1.00 / 1) (#109)
by use strict on Wed Dec 20, 2000 at 10:50:51 PM EST

you don't know how to use the system. besides, I don't think i've ever had this problem upgrading libc's with debian regardless but...

dpkg and apt provide methods to maintain source packages (yes, even ones that you didn't get from a src.deb) on a reoccuring basis so that you can easily remove and install them.

If you are upgrading libc so often, you are probably running a unstable distribution. unstable MEANS unstable!

I've had a potato system here that's been running (save moving twice) for about 2 years or so without issues.. it's based on debian 2.0, i upgraded to woody last night and this is what happened after I was done:

I turned off the monitor and went to bed.
(IOW, nothing went wrong)

Everything that was a daemon was automagically restarted, everythign that was a library got cached with the automatic ldconfig.

If there are other issues you're having chances are you're fscking with the package management. This is no different than screwing with the registry in windows or toying around with source in something as complex as GNOME -- things are going to break.

In your defense though, there have been some packages in the last few weeks with simple shell script errors, I have sent the maintainers some scathing emails IRT this, as it's not acceptable in any way, shape, or form that they did not check this stuff.

[ Parent ]
Binary _and_ source packages :-) (3.00 / 1) (#93)
by edibiase on Tue Dec 19, 2000 at 04:06:43 PM EST

Actually, evvk, your ideas of a standard package description file are pretty much what I was after (I came to that conclusion in the aforementioned article). This would allow for me to build a binary package as the developer and release it. Perhaps the package management system can figure out the minimum dependency requirements for this program. Maybe it can't, and if your system isn't pretty damn similar to mine, then you're SOL.

But then your idea can take over: just compile the package yourself, from the source, the same way the original developer did! I, too, find the ports system to be really nifty, and I think that implementing it in this way would be great. I can see it now: type "installpkg gnapster-1.4.1a-src.pkg" and watch as it figures out what you do and don't have on your system that it needs to compile, and then either compiles or goes out and gets what it needs, much in the fashion of the ports system.

However, this argues for two things that may or may not be difficult to have:

  1. A centralized package location database
  2. Some way of knowing what's installed on the system

Of course, requirement #2 references somewhat my earlier point. Honestly, I don't know how package maintainers specify what their package needs. If it's done automatically and correctly all the time, that's great; there's probably code out there that can be used to calculate this kind of thing. If it needs to be done manually, that's a bit harder.

Also, as you mention, the upgrade path is definitely damaging; I can't install many (any?) Debian woody packages on a Debian potato system. It's not that the programs wouldn't work, but it's that they were compiled for different libc versions or have dependencies of packages that might need a newer libc or that depend on still other packages that need a newer version of another package, etc. This is where the source definitely helps. Compile what you need, and you're ready to go.

The only remaining problem I see is that of determining how to reference other packages. If I compile something on my system with libc6 2.2 installed, does that mean it needs 2.2? I don't know if there's any way to determine this, and that's where the real stumbling block is, at least for automatic dependency generation.

Additionally, just to cover my ass, I think that automatic dependency generation is necessary even if we compile everything from source in this hypothetical package management system. Not many users (as opposed to developers), even experienced ones, want to be faced with some kind of compile error because they don't have a package (or a high enough/specific version of it). And as much as I hate saying it, and even though I run the risk of severe flamage for saying it, this type of thing can't be super-technical to the "common user." Sure, it can have all the options you want to show all the information you want, but if I'm content with 'pkginstall somepkg-6.6.6-src.pkg' returning "Error: this package needs someotherpkg to install. Satisfy dependency?" as opposed to "make: someotherpackage.so not found" and a cascading plume of errors, who's to blame me? I'm no neophyte, but I certainly would rather spend my time doing something productive than trying to figure out what package will satisfy another package's needs.

Automatic dependency generation is necessary even for source compiles, because it saves a lot of headaches later.

[ Parent ]

Version numbering (4.00 / 1) (#97)
by evvk on Tue Dec 19, 2000 at 05:41:13 PM EST

I think library version numbering should be done in a more standard way. For example, let us suppose a three-part version number: X.Y.Z with X.Y being the "API version". Now, versions with different X would be incompatible both ways. Versions with same X but greater Y would be backwards-compatible. Z would be a patch version. In addition, program developers should not use development-stage libraries if stable ones exist. (As I mentioned, a big problem with Linux is that everything is changing in short but many steps.) Then, dependencies could just say requires: lib-X.Y and the system could figure out what is _really_ needed.

[ Parent ]
Definitely a Good Idea; Implementation Possible? (3.00 / 1) (#101)
by edibiase on Tue Dec 19, 2000 at 08:36:59 PM EST

This makes a lot of sense, and would certainly solve the problem. The question is, will developers support it? Hopefully, with a Linux standard established, conventions like this will become common ground for developers, but there's never any guarantee that it will take, unfortunately.

After thinking about it some more, I don't know if there's any way to automatically generate dependencies for non-library programs, though. Take xcdroast, for example. Yeah, ldd reports

libgtk-1.2.so.0 => /usr/lib/libgtk-1.2.so.0 (0x40025000)
libgdk-1.2.so.0 => /usr/lib/libgdk-1.2.so.0 (0x40149000)
libgmodule-1.2.so.0 => /usr/lib/libgmodule-1.2.so.0 (0x4017d000)
libglib-1.2.so.0 => /usr/lib/libglib-1.2.so.0 (0x40180000)
libdl.so.2 => /lib/libdl.so.2 (0x401a2000)
libXi.so.6 => /usr/X11R6/lib/libXi.so.6 (0x401a5000)
libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x401ad000)
libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x401bc000)
libm.so.6 => /lib/libm.so.6 (0x40296000)
libImlib.so.1 => /usr/lib/libImlib.so.1 (0x402b3000)
libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0x402ec000)
libtiff.so.3 => /usr/lib/libtiff.so.3 (0x4030c000)
libungif.so.3 => /usr/lib/libungif.so.3 (0x4034e000)
libpng.so.2 => /usr/lib/libpng.so.2 (0x40356000)
libz.so.1 => /usr/lib/libz.so.1 (0x40381000)
libSM.so.6 => /usr/X11R6/lib/libSM.so.6 (0x40391000)
libICE.so.6 => /usr/X11R6/lib/libICE.so.6 (0x4039a000)
libgdk_imlib.so.1 => /usr/lib/libgdk_imlib.so.1 (0x403b0000)
libc.so.6 => /lib/libc.so.6 (0x403de000)
libungif.so.4 => /usr/lib/libungif.so.4 (0x404e9000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

(Interestngly enough, GTK and GDK seem to be following your naming convention, in a way -- even though I have the Debian libgtk1.2-1.2.8-1 package installed, the libs are saying, "Hey, we're version 1.2, you don't need to know any more than that!" and the dependencies on the Debian packages follow accordingly.) So, our package management system could look at this, see a few packages needed for execution of this, and set up the deps. But here's where the packager has to intervene: xcdroast isn't much use without the cdrecord utilities, so those are dependencies, too. No automatic system can figure that out.

I am still of the opinion that a common packaging format would be enough to attract developers. Many make RPM packages as is, so I don't see why even more developers wouldn't want to support a common, more far-reaching format.

[ Parent ]

But why?!? (1.00 / 1) (#79)
by excession on Tue Dec 19, 2000 at 09:01:36 AM EST

OK. So linux isn't standardised. Thank $DEITY for that. Windows is standardised - if you want Linux to have the level of community creativety that Windows has, then standardisation is by all means the way to go.
Having one package management system doesn't actually change anything, IMO - all it does is mean every distributor ends up hacking it to be compatible with their distribution. As examples, try using SuSE rpms on a RHAT system. Or Corel debs on a Debian system.
And do you think that you are really the first person to suggest exactly this?
And if you really are that worried about the packages you won't be making for the code that you can't write, there's always alien.
And who would this petition be to? And if one distributor took it up, why (sh|w)ould the rest? Which package format would you use? A new one? SLP? RPM? DEB? .tgz?
I'm sorry, but the idea is so flawed fundamentally that it isn't worth the inodes it's taking up.
-Thom
--
All opinions are mine, etc etc

[ Parent ]
::cough:: RTFA, please. (none / 0) (#92)
by edibiase on Tue Dec 19, 2000 at 03:34:34 PM EST

OK. So linux isn't standardised. Thank $DEITY for that. Windows is standardised - if you want Linux to have the level of community creativety that Windows has, then standardisation is by all means the way to go.

This is a terrible argument, unfortunately. Look at the development taking place on Windows. You can't say, "Oh, Windows is standardized, Linux is not, so if we standardize Linux it will become like Windows."

Are you asserting that standardization with regards to package specification would be bad for Linux? Can you back this claim up with facts?

Having one package management system doesn't actually change anything, IMO - all it does is mean every distributor ends up hacking it to be compatible with their distribution. As examples, try using SuSE rpms on a RHAT system. Or Corel debs on a Debian system.

Again, a virtual nonargument. There is no standard packaging format out there that is used by all/most of the distributions, so all you are doing is making a conjecture here, and not a very well-founded one at that.

If most major distributions supported and used a standard packaging format, they would build the distribution around the format. There is not much to be gained from deviating from the package standard unless there are substantial gains to going outside of it. Obviously, a package management system could be developed that would satisfy the needs of most distributors very well; when program developers begin to use this package format for releasing packages, a distribution will have little to gain and much to lose from perverting or discarding the package management specification.

And who would this petition be to? And if one distributor took it up, why (sh|w)ould the rest? Which package format would you use? A new one? SLP? RPM? DEB? .tgz?

This petition would be to the distribution manufacturers. The idea hinges upon wide acceptance; most distributions would want to use this system because the developers and users want to use this system. I don't care which package format is used, although I think positive contributions could come from many of the existing systems.

I'm sorry, but the idea is so flawed fundamentally that it isn't worth the inodes it's taking up.

I'm sorry, I guess I expected intelligent conversation and constructive ideas, not mindless flamage, which is what I ultimately got from your post.

[ Parent ]

well... (none / 0) (#108)
by use strict on Wed Dec 20, 2000 at 10:37:02 PM EST

His point was that you have to have a standardized filesystem layout before you can have a standardized package format. BSD has this down to a science. Of course, in 5 years we'll all probably be using BSD anyways, as Linux cripples under bloat and hype, and we'll have to start the whole advocacy process again. I used to think otherwise, but unless 2.4.0 stable is some kind of godsending miracle, and redhat finally releases a stable product that works out of the box instead of claiming to be the 'forefront of linux' and all the while my debian box has gone through 4 major distribution upgrades while my buddies across the room can't get XMCD installed from RPM properly, I don't think this is going to change. BSD is standardized both at a FS level and package level -- so you are right, but wrong. Linux will never standardize, and go the way of OS/2, Mac Classic and Amiga (although I have hopes for both OS X and the new A4000PPC machine). The reason? Linux is only a kernel. The debian project is probably the best example of standardization that we've seen yet, but corel did a good job of muddying that up for a short (SHORT) time. As a result, a lot of corel users are now debian users :)

[ Parent ]
Accelerated Desktop (2.00 / 2) (#90)
by asp742 on Tue Dec 19, 2000 at 03:15:47 PM EST

More support for some higher end hardware would definitely help the Linux desktop as a whole. I currently have one of the original GeForce cards in my Linux box. I am running Xfree86 4 and have NVidia's driver installed. However, I don't think enough applications take advantage of the processor and memory on the card. It would be nice if the video card controlled many of the WM's features. This would leave me with more memory and processor speed for other more important things. Animated icons, animated title bars, fancy windows should, if possible, be handled by the video card. A high-end window manager aimed and taking advantage of some of the more powerful hardware out there would attract a new crowd of people to Linux and would be pleasing to many other Linux users out there. This WM would not be the standard Linux app aimed at as many users as possible, rather it would be aimed at the crowd of people that want the latest hardware and to push their desktops to the edge. This may not even be possible or feasible, especially with companies like NVidia keeping their drivers closed source. It is just something I wouldn't mind seeing in the future ;-)

I definitely agree with the fact that people need to change their perception of computers in general. In the future they will not be large all encompassing machines in our basements, but rather specialized integrated tools built seamlessly into our environment. So, when thinking about new desktop designs it may be best to think outside of the proverbial box. Maybe some sort of smart desktop that takes note of the users of the system and what their particular usage patterns are. It will then optimize and change itself to try and predict what a user will want to do. Let's say a person comes home at 4 and loads Mozilla everyday. The desktop would then at 3:50 begin to clear resources from the rest of the system. It would load Mozilla into the background, download the users emails and wait. If the user came home at 4 and launched Mozilla, it would open immediately since it was already loaded in the memory. If the user did not make it home by 4:30 or whatnot, the desktop would unload the Mozilla from the memory and reallocate it to other applications. Just a thought.


they... (none / 0) (#107)
by use strict on Wed Dec 20, 2000 at 10:28:38 PM EST

... have this... it's been around for a long time, written by a man named paul vixie... it's called CRON. :)

[ Parent ]
Enlightenment 0.17 (none / 0) (#117)
by Rabid Penguin on Fri Dec 22, 2000 at 11:17:21 AM EST

The next revision of the enlightenment window manager is based on a graphics library that can render graphics using either OpenGL, imlib2 or Xlib. The fact that OpenGL is used as a backend may allow for hardware support. If you are interested in the current test code it can be found in Enlightenment's CVS repository.

RbdPngn

[ Parent ]
Voice Recognition + AI (3.00 / 1) (#98)
by mechris on Tue Dec 19, 2000 at 05:49:02 PM EST

I'd like to see a marriage of BeOS style file attributes, voice recognition, and AI.
On ye ole conventional GUI >windows, X/Gnome, X/KDE, etc. add an application that runs in a window and 'listens' to you via voice recognition then acts using AI. Through some initial rules and guidelines it learns how to respond to your commands. i.e. you say video and the window fills with all mpeg, avi, etc. on your system, or luanches your multimedia player or pulls up internet search results for on-line videos, or all three. If it does a good job you praise it ('good computer')...if not you scold it ('bad computer'). Eventually you could build a sophisticated system that could wean you from your conventional file manager, appliction launchers, browsers, etc.
More fundamentally I think we need software that writes itself. i.e. it gains functionallity by being aware of what its user wants. This probably involves alot more language and pshchology than computer science. Of course the fact that computers are built on axioms (+,*,AND, OR, etc) prohibit them from fundamentally 'discovering' anything, they could do a lot better job at guessing discoveries than they currently do.
plink plink

Re: Voice Recognition + A (none / 0) (#100)
by evvk on Tue Dec 19, 2000 at 07:25:49 PM EST

I have my doubts of speech recognition. There are situations where it'd be great, most notably replacing remote controllers (when one is not in reach) and other "embedded" such tasks, but I don't see it as a replacement for keyboard with traditional workstation tasks, e.g. writing. Except perhaps for some very complicated tasks but then we run into the Big Problem: the AI. The AI would have to be really good, as good as a human and I don't think we are going to have such in my lifetime. People have been waiting for a human like AI since the fifties and we still don't have it, unfortunately.

[ Parent ]
enslaving another for AI's purpose is wrong (1.00 / 1) (#105)
by glmull on Wed Dec 20, 2000 at 05:33:06 PM EST

unfortunately? i'm glad we don't have this AI. AI is not something we are going to have if you look at Zetatalk.
Zetatalk tells us what will happen in 2003.
[ Parent ]
Berlin (4.00 / 3) (#112)
by obi on Wed Dec 20, 2000 at 11:54:16 PM EST

I'm actually surprised that this hasn't come up.

Before you all go off reinventing the GUI, i believe we should first have an almost perfect "classic" windowing system, because only then we will really see the limititations of the concepts involved. It's hard to skip a couple in steps in an evolution... kind of like taking a snapshot of history doesn't always make sense, until you see the snapshot in its historical context, with all the decisions/events leading up to that situation.

So what's wrong with the current systems?

- They are resolution-dependent (MacOSX will probably not be)
- They are applications-centered, not document-centered
- They are mostly not network-transparent (X is, win32 macos isnt)
- They are or inflexible (win32), or they are flexible in the wrong place (X)
- Basically, alot comes down to this: policy should be defined at the right place.


Berlin tries to overcome alot of these problems. The policy is defined in the server... which means: the app doesn't (need to) know if the server is on a Palm, on a workstation with 4000x3000 resolution, or in a virtual 3d environment. Everything is kept as abstract as possible. Different devices have different requirements, and they are rendered accordingly. Defining the policy on the server also means, that if you change the "theme" or the server, you're sure you're changing the behaviour everywhere. Unlike with gtk/kde/windowmaker etc, where every app basically can have a different set of widgets. And for those clamoring "choice is good, different toolkits are good" - you can add plugins in the berlin server, or write a different implementation if you're up for it. You do have choice, but you also get consistency.

I believe that is more elegant than "meta-theming" or the like, where you creat collections of themes for different toolkits.

Actually this infrastructure brings about other niceties, such as superior accessability for the vision-impaired. You could imagine a couple of server plugins that output everything to braille devices using a layout adjusted for these devices or have a special interface for zooming in on windows very easily. No programs would have to be rewritten to take advantage of these things.

On top of that, what actually goes over the network is very low-bandwith (corba-calls, not huge amounts of pixel data), so remote operation (over low-bandwith networks like the internet) may become feasible again.

The other thing that is quite important is to get a good compound document model. Remember opendoc? Now just imagine that the view/editor components can be anywhere on the network...

Berlin is under heavy development, but they have been getting somewhere. I believe it's how things should have been done, but for lots of historical reasons it hasn't been done this way in popular gui's.

I think it will be hard to get off the ground, since because it's a totally different design, a simple port of common gui apllications in most cases won't do justice to berlins capabilities. no apps, no users. no users, no developers. chicken, egg - critical mass will be difficult to attain.

But I'd like to think it will be attained, because in this case open-source is clearly innovating past the cutting edge of current GUI (macos X)



Once we get to that point, we can think about totally new schemes. But I think these "totally new schemes" will be closer and easier to implement then, and it will become more of a natural transition than a revolution.


-

(http://www.berlin-consortium.org)

mmm (none / 0) (#113)
by matman on Thu Dec 21, 2000 at 03:27:59 AM EST

I would LOVE to see berlin take off. Unfortunatly, with so much work having been put into motif, gtk and qt, and those things which touch them, people are going to be reluctant to abandon so much investment... I mean, development is still heavy surrounding qt and gtk, and I think that it's going to be a fairly fresh set of developers that are going to get into berlin, as opposed to seasoned developers from other gui areas.

I hope that Berlin takes off, and that it implements theming well.. because smooth themes are what keeps me in gnome as opposed to kde :)

[ Parent ]
Widgets... (none / 0) (#114)
by evvk on Thu Dec 21, 2000 at 04:31:14 AM EST

> The policy is defined in the server... which means: the app doesn't (need to) know if the server is on a Palm, on a workstation with 4000x3000 resolution, or in a virtual 3d environment.

Correct me if I'm wrong, but to me it seems that berlin is still based on the concept of widgets and multiple windows and not highest possible level of abstraction. (The "documentation" could be clearer...) Get over it! If it does not truly want to specify policy in the applications, applications should then not be able to create widgets but instead only tell what can be done, not by what something can be done. On a workstation, I'd like my programs have full, easy, keyboard control (ok, not painting programs but I seldom use such), no "widgets" except text and such entries in "dialogs" (which would not be new windows!), exactly one toplevel window/document view (but multiple possible views), and the commands for what there isn't enough intuitive keys accessible from some list (behind a special menu key consistent between programs, of course). Please, have a look at a comment I wrote earlier.

[ Parent ]

Widgets... (4.50 / 2) (#115)
by obi on Thu Dec 21, 2000 at 10:01:43 PM EST

Well, what you're actually describing (having an even higher level of abstraction than "widgets") is in the works for Berlin. (Its called Tasketkit)

The whole point is having different levels of abstraction. You can get low level control to draw individual figures, you can just create widgets, or you can just ask to do a "task" like "choose a file", and let the tasketkit deal with that. The advantages of using the tasketkit are obvious, in that you gain more portability. But that portability shouldn't cause you to lose access to specific capabilities - you might want to actually have more fine grained control in some cases; so you just choose the level of abstraction that's appropriate.

I believe it's design gives you everything you want... So, yes we still have "widgets" but we have the basic low-level "figures" and the very high-level "taskets" too.



[ Parent ]
Hmmm... (none / 0) (#116)
by evvk on Fri Dec 22, 2000 at 02:08:15 AM EST

Well, they may be onto something but I have my doubts. What I read, taskets just seem to be intended as some kind of m$ common dialogs alike. (And this I collected from separate hits by a search engine. Berlin project: tell us what you're actually after! Is it a braindamaged WIMP GUI or a generic "application framework"?) The web used to be about content markup. Given the control of layout, look at what crap it is full of. What I want is that the application/programmer must (need to have) have only minimal control over the UI "controls" (logical crouping). And there's the issue of performance. Even without CORBA, things like GTK are not fast. (Or, dare I mention it, XUL... *brrr*) Adding even more layers, doing it all with CORBA and all the other hype standards will add considerable overhead. Will it be usable on my not-cutting-edge computer? If it will, good, but I doubt.


[ Parent ]
OOUIkit (none / 0) (#120)
by obi on Sat Dec 30, 2000 at 09:03:39 AM EST

Well, it is true that right now the thinking for taskets is for common dialogs.

But never fear, there is something that you might find even better: Berlin's OOUIkit - check it out at

http://www.bucksch.com/1/projects/berlin/OOUI/



[ Parent ]
I want a Quake desktop (none / 0) (#118)
by pmk on Fri Dec 22, 2000 at 12:11:30 PM EST

Seriously.

I want rooms of data, not file folders. I want to traverse this space by running around in hallways. My files should be objects in the rooms, sitting on bookshelves, desktops, floors, or pinned to walls. Pick up a file, it zooms bigger, and a pen appears in my hand, say, with which I can edit.

E-mail? I write it on a new sheet, fold it into an envelope, and stick it in the mail slot. Incoming mail arrives in a basket and rings a bell.

NPR is playing on a virtual radio, while CNN is on the television monitor in the corner. If I turn to look at it, I can watch it. I can pull other monitors out of a closet and have other stuff on if I want to.

I would like, but would not require, a rocket launcher with which I could delete data, televisions, and maybe also the other users.

Quake ran realistically on my 133 MHz Pentium, so don't tell me this kind of user interface isn't technically feasible.

Most of what you guys are talking about is trivia (none / 0) (#121)
by laird on Sun Dec 31, 2000 at 07:09:20 PM EST

I agree with the original message -- there's been relatively little real innovation in human interaction in the mainstream operating systems. The MacOS made some fundamental innovations over PARC's work (I've used both, and while there are obvious similarities, there are fundamental differences as well). Windows is essentially a variation on the Mac's theme. But all of them have the basic model -- run applications, edit documents in windows, load from/save to a filesystem. The "innovations" that most of the messages here describe (animated icons, OLE) aren't a ground-up rethink -- they're variations and elaborations on a theme.

The only real innovation I've seen is in the various PDA's where developers were freed from the shackles of desktop compatability.

So while Be, MS, Apple, KDE, GNOME, etc., come up with interesting variations on the theme, for the most part they're only differentiated over trivia rather than fundamental architectural approaches in how people interact with computers.

The Newton, for example, was completely object oriented, with no filesystem. Instead, there were "soups" of objects that applications could interact with and extend. The elimination of the (unnecessary) distinction between in-memory objects and persistent objects vastly simplified development. Apple made other mistakes that killed the platform (too much hype, under-delivering, over-engineering), but it did get real innovation into the hands of a few 100K people.

PenPoint was promising (until a series of MS vapor-platforms killed it off).

On the desktop, Apple tried to innovate with OpenDoc, which shifted from an application-centric model to a document-centric model, but bad execution (largely from IBM) lead to unbearable performance and irrelevance in the marketplace. And, of course, traditional appliaction vendors were not exactly enthusiastic about shifting to a document-centric paradigm instead of maintaining their proprietary document file format strategy.

Personally I don't see fundamental innovation coming from the Linux/UNIX community. There have been two opportunities: KDE and GNOME, both of which are bad copies of Windows, albeit with some of the underpinnings cleaned up. The fundamental architecture (C apps over filesystem) is too embedded in people's mindset, and there's too much inertia in too many people's heads. And the mainstream operating systems have too much to lose to attempt real innovation.

But the broader open source community could do the trick -- a lone, dedicated visionary could take the raw material and assemble it into something truly original in a way that would be impossible otherwise. With any luck the wonderful proliferation of new platforms (cell phones, PDA's, internet appliances, etc.) are creating an opportunity for real innovation.

The Future of the Linux Desktop | 122 comments (109 topical, 13 editorial, 0 hidden)
Display: Sort:

kuro5hin.org

[XML]
All trademarks and copyrights on this page are owned by their respective companies. The Rest 2000 - Present Kuro5hin.org Inc.
See our legalese page for copyright policies. Please also read our Privacy Policy.
Kuro5hin.org is powered by Free Software, including Apache, Perl, and Linux, The Scoop Engine that runs this site is freely available, under the terms of the GPL.
Need some help? Email help@kuro5hin.org.
My heart's the long stairs.

Powered by Scoop create account | help/FAQ | mission | links | search | IRC | YOU choose the stories!