( freshmeat ) - ( editorial by Jim Gettys )

(( editorial by Jim Gettys, published on October 31st, 1998 ))

The Two Edged Sword

Jim Gettys, Copyright 1998, All Rights Reserved - distributed by Freshmeat with permission of the author.

I lost track of X Window System during the last few years, in spite of my intimate involvement with its original development. My interests had moved from X, to audio work for a while, and then on to the Web.

For my recent work I needed business productivity tools (e.g. Microsoft Word, PowerPoint, etc.) much more than a programmer's system. While X had fine engineering software available, such routine tools as WYSIWYG editors or presentation programs were not available at reasonable prices (such as there were available often cost approaching $1000), or were not available on my home computer, or my laptop. I despaired of Bob Scheifler's and my creation ever having even basic software I saw on Windows or the Mac. Since I wanting to get my job done rather than fight a war that appeared to be lost, I started using a Microsoft desktop for most (not all) of my work a few years ago.

I find, to my surprise, that times have again changed: PC's are cheap, Linux has garnered support of ISV's who build such tools, and the market has grown large enough for PC mass market prices, and it runs on my laptop. I am surprised, amazed and gratified at the revitalization which has taken place in X software development over the last few years. I have grown tired of "blue screens", and crashed editors that leave my file locked. Due to the community's efforts, I am gratefully now in a process of reverting to my roots, despite being impressed with the smooth GUI (graphical user interface) that Windows 98 has these days (on which I happen to be composing this work, having not finished my reconversion). My thanks to all who have made this possible.

But while the current Linux environment is much better than UNIX systems used to be out of the box, it still has a long way to go.

There are Flies in our Ointment

Customization is the Foundation of Evolution

Evolution is fundamental to life. It is also fundamental to progress in computing, since the work required to start over with a fresh system is now so large.

One of the X Window System's greatest strengths has been that it is flexible enough to allow a large range of GUI's to be developed. As such, this fundamentally enabled the GUI wars that started 10 years ago, but has also allowed for its long term evolution (and possibly its survival).

We've seen overlapping window managers, tiling window managers, GUI's looking like NextStep, ones that resemble Microsoft Windows, and many others (including some new ones that make X look like a video game on steroids; it is left as an exercise to the reader to determine if this is a good or bad idea). This strength, unfortunately, is also its greatest weakness.

X applications written 10 years ago are still able to be run 10 years later, without change, and on some systems, without even being relinked (or run across the network from a system that has not been touched in many years). Some of the basic applications are over 10 years old, and look it. They were developed on a VAX lucky to have 2 megabytes of memory, often before any significant toolkit even existed. One widely used application (xterm) even predates X itself (by a month or two); it is now over 14 years old. Or the old application you want has not been touched in years, and uses an old, ugly toolkit that does not look anything like what you want to use.

Many/most of the "out of the box" X utilities in the free core of X need serious rework to get them into the 1990's; many of the CDE replacements, even were CDE available under terms that preserved Linux's attractions, are not particularly good, and are huge. I applaud the Gnome and KDE efforts to rewrite/replace these old utilities.

But if Linux/UNIX/X is ever to break out of the niche of a system for geeks, programmers and for low end servers, the X GUI has to grow up to be something your grandmother might be able to use. And grow up fast. (My mother, as non-technical as you can get, learned to use a Mac at age 75. X is now older than some of the people using it).

End users, however, really, Really, REALLY, would like applications to resemble each other. I certainly have appreciated this consistency anytime I've used an Apple or Microsoft desktop, despite being a programmer myself. It makes it much easier to learn new applications, or relearn those only used occasionally.

But while having a thousand flowers blooming is important, and during X's early development was absolutely vital, for Linux and X to have truly revolutionary impact it must somehow provide a user interface comparable to or better than that on other systems. And the user interface must be able to evolve. I want the applications running on that old machine in the corner I installed with your new GUI you building today be able to at least resemble what it will have become in three or five years.

Otherwise we'll all face the same problem over again, even if a single GUI style and/or toolkit dominates X this generation, if we want the GUI to improve with time. With X, this is actually somewhat more difficult than with Windows, due to X's network nature. You may need to use a system that has not been updated for years across the network. In this case, the old shared libraries never get updated with new ones.

X was designed with a clear separation between "window management" and applications themselves. This has allowed the wide range of X Window managers to be built, including ones that resemble Microsoft Windows, NextStep, and other X specific window managers, including a number of very nice new ones. We clearly succeeded in our attempt to enable experimentation and evolution of window management.

There are several remaining serious design problems, as the GUI style in X applications is only partially in the window manager:

part of what composes a GUI style is bound up in applications programs (as a toolkit)

applications need to interact with each other (which has gone under the term "Inter Client Communications Conventions").

applications and GUI's must be able to evolve

X resources are another attempt at allowing customization that may span time and different toolkits, but have historically been less successful than window managers. How much of this is the approach taken, and how much the result of the GUI wars is not clear to me. In any case, we need a single customization mechanism, that can span both toolkits and time.

The difficulties of matching GUI styles can mostly be handled by shared toolkit libraries, which can hide some of style problems from applications, and handle conventions of interactions between applications, and I would hope, share a single customization mechanism.

So how do we solve this problem and provide a pleasing "out of the box" experience (for your grandmother)? And without throwing the baby out with the bathwater (losing X's characteristic malleability that has allowed so many UI styles to be built, and allow its long term evolution)? And do so such that five or 10 years from now we don't have to do it all over again? And that when a piece of software is installed I don't need to go edit some obscure configuration file somewhere?

At the moment, for better or worse, most commercial X software is Motif based. In the short term, many/most commercial applications will arrive on Linux with the GUI style, whether we like or or not. I've never been fond of Motif (big, bloated, slow, and not particularly pretty). One solution would be (for applications and toolkits themselves) to adopt that style guide, and be done with it. But there goes the baby with the bathwater, and I'd hardly call this a long term solution.

But how do we get even an approximation of a uniform style across toolkits?

I believe there will have to be serious, coordinated work on customization (sometimes called "themes" in some toolkits) in all the various toolkits people are building, so that I can choose the style I like without having some applications appearing in one GUI style, and other applications in a different style. Such customization also helps solve both internationalization needs and the needs of people with disabilities (like your (grand)mother who needs big type on the screen).

There is No "One True Way"

Your religion is not my religion. Today's toolkit in one language gives way to another in another language tomorrow. The style of five years from now won't be the same as the style today. One size does not fit all.

You aren't going to get the thousands of existing applications to be rebuilt against N different toolkits to get this consistent style. Those who fail to learn from history are doomed to repeat it. Look where the GUI wars got either OpenLook or Motif.

As a result, I believe that any toolkit that does not allow full customization or cannot be customized to look like the other toolkit's default style should be considered broken. The sooner people accept the premise that all toolkits should be configurable to closely match other styles (and future styles) as a minimum of all future X toolkit development, the better, and that the less grief we will all have.

For then, five or ten years from now, you will be able to make that old application (possibly on that old machine in the corner on the network you haven't touched in years) have a style that at least slightly resembles the truly wonderful new GUI style you are all developing. (Rather than today's amazing clash between the new applications and some of the old.)

Of course, we will find that some GUI idioms are difficult or impossible to map to a different style, but at least most applications will be able provide the same basic style. I am speaking here of the typical menu/dialog box toolkit based application, rather than the small minority of applications that are essentially entirely user interface (e.g. graphics editors).

Serious work is needed on GUI customization, particularly when new applications are installed, needs serious work and standardization across window managers. Manually editing yet another obscure .rc file to add the latest application I installed to a startup menu is not my idea of being "user friendly". I should be able to change window managers and have the applications change to match.

So we'd better revive serious work on the ICCCM (Inter-Client Communications Conventions) so that the applications, even if built with different toolkits, can inter operate well, and some (preferably a single) resource mechanism is essential for customization.

Modularity

We should also exploit one of X's strengths, insufficiently exploited in most existing toolkits: the ability to embed an application in a subwindow should be routinely exploited, rather than just by window managers. Any simple text window ought to be able to be my favorite text editor, not yet again a different editor with different bindings that I don't like or know. Software should be designed to be modular; I should be able to embed almost any application into my application.

The sooner toolkits allow me to embed my tool into an application easily, the sooner I can have my editor (or other tool) where I want it, rather than the silly braindead one that isn't what I want, or need, or know how to use. And a single instance of an tool may be able to handle many applications simultaneously, rather than consume lots of system resources. Conversely, as an application developer, it means having to write less code to build my application.

This is the only way to avoid huge, bloat-ware applications in which, for example, I face a different text editor for each application. And it means I should be able to use my new favorite tool in the old application.

WIMPy Interfaces Are Not the Future

Audio is becoming more common in real world applications. X is network transparent; there should be an analogous audio server. Believe me, it is best if it is an independent server, rather than an X extension; the reasons are too long for this message. There have been several prototypes built (including one I helped build); one should be fleshed out and become "standard"; or your network transparent window system will be very quiet. The Internet is finally becoming ubiquitous, so if the current local audio only situation continues, you've missed one of the major points of what X was about in the first place.

WIMP (Windows, Icons, Menus, and Pointing) graphical user interfaces typified by Windows of any flavor are not the final word. GUI's may become the minority computer user interface. Hands free interfaces are already of serious interest due to recent improvements in speech recognition, much faster machines and cheap memory. Some of us (e.g. Bob Scheifler, Keith Packard, Richard Stallman, and many others) have been forced into the the brave new world of speech recognition to control their applications due to carpal tunnel syndrome. Speech recognition technology is already entering the retail mass market, and will continue to improve. User interfaces must be usable from speech recognition systems (and without having to retrofit each application). While Xt has enabling facilities for such helper applications to be built, other toolkits may not, and toolkit developers need accept this as a goal. And if we want a mass Linux/X market, there should be a single facility, rather than one that differs between each toolkit.

The next logical step beyond hands free interfaces are eye free user interfaces. Here, I mean the ability to use many or most applications without looking at them. I'd like to use the Web in my car ("Go to the Boston Traffic page; read me the page"), but I sure want to leave my hands on the steering wheel (which is why Cell Phones are causing traffic accidents). By proper use and/or augmentation of ICCCM conventions, and by good exploitation of X's selection mechanism to be able to get the contents of a window in something other that "bits", it should be possible to build X toolkits which would enable eye free use of many or most GUI applications.

Such work will also enable a new class of devices and applications (I like seeing Linux running on 2 AAA cells in a hand held device at 200 mhz), where keyboards don't fit well or at all, and while there might be a screen, it isn't what you might call large. I'd like to be able to use many applications in new environments without a rewrite. The blind will also thank you for this work, even if it is done for selfish motives. As the user base gets large, the need for disability access becomes more and more acute (and painful to retrofit). Windows and MacOS both left this to very late and are having trouble retrofitting the needed functionality. There is much to learn from the Microsoft and Java accessibility work that should go into new X toolkits. And again, we need a single mechanism, rather than a mechanism per toolkit, if at all possible.

We should look forward to the future as well as to the past.

Web Integration

A part of X's fundamental vision and the Web's are similar. You should be able to get your work done anywhere, anytime, from anywhere in the network.

From a user's point of view, there should be little or no difference between local resources and the Web (a very different statement than "the Web should become part of the operating system"). So don't presume that just because a given application has had its own X GUI user interface that it should have an X GUI in the future. Often applications are better integrated as part of the Web, available anywhere, from any desktop, rather than as independent applications. As the Web's functionality matures, more and more applications should be able to be built in this universal fashion.

Application developers should ask themselves today when building any application if it might better be implemented using Web and its technologies, than in X. Sometimes it should, and sometimes it shouldn't. But if you haven't asked yourself the question, you may make the wrong decision.

Java Blatherings

I should set another thing straight while I'm blathering on. While I never believed extension languages were the panacea that the NeWS advocate claimed ten years ago, my own biggest problem with NeWS was the choice of PostScript as the extension language. (I'm an old Forth programmer myself; I understand both the strengths and the weaknesses of such languages.) James Gosling (author of NeWS) learned the lesson. His language is called "Java". He even worried about the protection model seriously this time. You might have even heard of him and it by now. :-) How should Java play in the X world? Client side only? an X extension? And meet the other goals noted above? I'm not sure. But it is well worth thinking about.

Copyrights

Copyright law is intended to serve the social goal of enabling an author to be rewarded for their efforts, thereby encouraging intellectual activity. One of copyright's unique qualities is that, in effect, you are writing the law when you write the copyright. Without copyright law, it clear that there would be much less intellectual effort of any kind, as authors need to eat.

But rewards can take many forms: satisfaction, getting contributions from others, leveling a competitive playing field, and so on, rather than being monetary. I have no problems with anyone deciding that their effort should have a monetary reward. Charging for software is not evil; it may be the only way to fund an activity that we need done. This is basic economics.

As the drafter of the original X copyright, I've given this some thought. My analysis in 1986 was that the X copyright was the most likely way to achieve the goals of the X project and the goals of Project Athena (exploiting computing in undergraduate education): what we needed were applications; the base technology has no value with out them. I think that X succeeded until toolkits that people depended on started sporting copyrights and licenses that meant that any application might owe royalties to someone. At the time, there were only a few toolkits that were high enough quality to build serious applications. This is clearly no longer the case.

I'm not a fan of the GPL. It can have the effect of inhibiting commercial support and enhancement of a system. For example, a vendor may see making bug fixes and/or minor enhancements worth funding if they can temporarily benefit. In the long run, not having to fix the same bug or reintegrate the enhancement in the next X release generally caused most of this development effort to be given back to the X community. But there may be circumstances in which the (L)GPL may be most appropriate and there are times when an even less restrictive copyright (e.g. X or BSD) is more appropriate, and for a commercial software vendor, a highly restrictive copyright may be appropriate. What is appropriate is ultimately the author's business (unfortunately, some authors never consider copyright before release).

We build on each other's shoulders. Therefore, the toolkit (and library) questions that faces UNIX/Linux and Open Source development can get complicated, since the copyright and/or licenses of what we depend on may affect what rights we have over our own intellectual work. I am therefore concerned that the base system not restrict what I can do with my intellectual effort.

Software authors need to understand basic copyright and license issues both for their own software and software they depend on.

Given the experience of X's previous history, and the copyright/license of the basic Linux system environment, I strongly believe that any "standard" toolkit should be fully unencumbered in the X/BSD or LGPL sense, or it may in the long term defeat development of applications that we all want and need.

Is This a Utopian Dream?

All this is hard. It may sound utopian. And choosing a "default" style that most naive people can use is very hard. Various groups will have to cooperate (e.g. LessTif, Enlightenment, TK, KDE, Java toolkits, Gnome). There will need to be "standards" work for resource customization, installation of software and the ICCCM extensions for interoperability. It is more things to do, on top of building a GUI, which is already known to be difficult. Building the tools to set up different toolkit's customization to present a unified GUI "style" will be hard, painful grunt work. And end users must be able to set styles without being a X resource guru. It will be a challenge to all involved. But it is all absolutely essential for user interfaces to be able to evolve and thrive. The energy I see in this community makes me believe it can be done.

Or we can get out our swords, fight each other for a while, and end up falling on the swords, as happened in the UNIX GUI religious wars of ten years ago. And the GUI fundamentalists will win again. Been there, done that, and I guarantee it hurts. And Linux/UNIX/X will remain in niches, and never achieve what it should.

I prefer plowshares to swords, myself.

Jim Gettys, October 30th, 1998

[ add comment ]

(( 21 comments ))

In this article are many ideas.
Especially the GUI is one thing, i thought about
very long time. Perhaps most of the linux community
didn't know it, but look across the borders.
My favority OS is AmigaOS with it's fantastic MUI
(Magic User Interface) ... here you have a complety
GUI-driven configuration tool, that give you the power
to edit styles (Xresources) in a graphical way.
That was/is fantastic, MUI was started developing 6
years ago, and its the leading GUI-Kit, there
are so many ideas in this concept, that shouldn't die
the way amiga does.
But how about letting the user completely decide the feel about his desktop and the "thousands" :) of Applications. Input-types aren't only mouses and the way
applications represent their menu's can be differ from popup's
(like in Gimp), normal bars (default in many Desktop-OS)
, new menu-gui'ed concepts.
For those that don't know anything about Amiga/MUI -
www.sasg.com

plex/tek @ 10:36 - 10/31/98

Jim has a few good points. It seems, more and more every
day, that Linux is heading towards a GNOME/GTK desktop.

I salute Enlightenment -- it's philosophy is total configurability. And GTK is nearly like that also.

I don't want to see Linux get too user friendly. If this
happens it will distort the whole balance of the operating
system. There will be a too large end-user base and too
few programmers. What makes Linux great is that everyone
codes. Everyone has something to contribute.

I don't like to think of Linux users being in niches, but
rather Linux itself being a niche.

Even if GTK becomes the default/only toolkit, people will
still want to be different. It's the two driving forces
of culture: wanting to be like others and wanting to be
different.

It's an endless struggle.

crum @ 12:49 - 10/31/98

I mostly agree with this editorial. I think that people who also agree should take a look at
"www.berlin-consortium.org" These people just started up from the ground to provide a new,
fast GUI-enviroment for Linux/GGI. One of the things this project is trying to reach is
also modularity so you will be able using your favorite text-editor in every app where typing
is needed. Check it out and help them with suggestions ;-)

Rowan @ 12:58 - 10/31/98

One thing that seems to be consistently overlooked in the Linux GUI projects (but not by Microsoft or ISO or W3C or IETF or IBM or Netscape or Apple or Oracle or SAP...or any other major creator of standards these days) is Unicode/ISO 10646. This is a big mistake.

These days, the "platform" is the Net, and the local language of the platform is *any arbitrary combination of any of the world's languages*. WindowsNT, MacOS X, Java, HTML 4.0, XML, WindowsCE (even palmsized)...are all pure Unicode. All strings and all string APIs are pure Unicode. Internally, everything is Unicode, with the option of converting from and back to non-Unicode encodings, where needed for backward compatibility.

I agree with Jim that Linux needs a set of GUI standards so that all apps built on those standards will smoothly interoperate. Since these apps may be spread out around the world, the standard encoding for all strings and text APIs MUST be Unicode/ISO 10646. The "default encoding" on all Linux boxes should be Unicode so that all Linux apps built on the standard GUI on all Linux boxes in the world will work together transparently. (Even on a box that is lacking a font to display Chinese, the data isn't munged, the regex APIs still work, and the data can be correctly processed and passed on.)

Imagine a "worldwide web" in which every country used a different, incompatible JPEG encoding format, and you had to ask, app by app, whether that app supported the one(s) you personally needed. How much trouble would that cause? And yet text is an even more important data type than JPEG. (At the last Perl conference, Larry Wall said Unicode support was now his "#1 priority". Unfortunately, it won't be as good retrofitted as if it had been designed that way from the start.)

If you see any work being done on a "standard Linux GUI" that is based on non-Unicode strings and chars, ask them to change it to pure Unicode before it's too late. Text data needs to be smoothly, transparently, and universally tranferable from any app to any other app, anywhere in the world, without each app developer having to know all the arcane details encapsulated by Unicode APIs.

Microsoft is showing that they see this clearly. Likewise IBM, Apple, Oracle, SAP and the creators of Java, HTML, XML, Perl.... What about Linux?

Tony @ 14:40 - 10/31/98

This was a very good article, and I agree with most of the points he mentions in it. We need to get rid of old toolkits like Athena, Motif, OpenLook/OpenView, Qt (heehee), and the numerous other little ones floating around. I want all my desktop app's to look the same; my Netscape's should look like my GIMP's, etc. I especially like the WINGs toolkit that Window Maker uses; all my themes for Window Maker are reflected by the WINGs-ed program. I'm not saying that any one toolkit is perfect, but if we could get them to all interoperate and read from one unified themes set, then all the apps would look basically the same, and life would be much happier for me. :) I'm not saying kill the authors entire GUI in favor of my deathly looking purple one, but just make their application look seamless with my desktop, my root menu, my whatever.

$0.02
jason gill

iota @ 14:54 - 10/31/98

I think that X needs to become extremely user friendly for linux to break into the personal pc market, or even the corporate desktop market. I read the comment that said if Linux becomes too user friendly, the power would be lost. My question is why does the power have to be lost? The problem with Windows NT is that it restricts most of the configurationt tools , and all of the kernel source, etc., so that no one can edit their system well. If we hide that under the GUI of X, but leave the power of configuration there, we can make X as user friendly as we want. Just because in the past GUI means less power, doesn't mean it applies to the future.

Michael Bernstein
sjester@b4b0.org

michael bernstein @ 15:28 - 10/31/98

Yup, there will always be people who want to be different. I know I personally want GNUstep, or generally NEXT style!

Scorpion @ 16:27 - 10/31/98

A long read, and well worth it.

Martin Vermeer @ 16:42 - 10/31/98

Please note: there are 2 forms that unicode can take. The first is the one used by Microsoft. All characters are encoded as 16bit entities. This requires that all apps and the os either have 2 interfaces (ascii and unicode) or you have to replace all apps and os interfaces all at once.

The second form was developed by Bell Labs and is called UTF-8. This preserves 7bit ascii as it self and has meta encoding for the rest (the 8th bit is then set in a multi-byte format). This form lets you keep your current interfaces, text files etc and can be phased in over time.

Please DON'T request unicode without add the phrase 'as encoded by UTF-8'

Drew Sullivan @ 17:23 - 10/31/98

One thing we *have* to try hard and achieve is backwards compatibility. X has tons of very useful, simple tools. I question the feasibility myself, but perhaps whenever these toolkit wars are over or whatever, the other toolkits should be ported such that they are a wrapper to this one? Including Athena, Lesstif, etc?

That way, all of the apps look the same and don't require much more than relinking (knock on wood).

Yeah, yeah.. Many of the libs are a little too low level to be a wrapper, especially a wrapper around a library that supports themes... But a man can dream, can't he?

Lally Singh @ 18:19 - 10/31/98

another point Jim's article brings up (without belaboring) is the true sense of culture and history behind X and UN*X. not only are the tools old (why have they lived so long?) but the authors are accessible and still take a personal interest in the continuing development of projects they started before some of today's star developers were even born (is X older than Raster?). thanks for an excellent essay!
--sean :-)

sean @ 18:50 - 10/31/98

It's about time someone got the point across that all gui toolkits should be *fully* configurable in appearance because not everyone uses motif or wants a kde desktop. I applaud the many kde developers for taking the time to program nice gui's to programs but unless I can plug in my own gui toolkit and make the widgets look the way I want, it was all a waste of their time.
It's be nice to have a generic widget library and just be able to drop in any widget set we like, somewhat like how there are now several Xaw dropin widgets to provide gtk and NeXT looks.. What if we took this concept to the extremes and had everything use this new widget library ? then I could just drop in the right lib and suddenly my whole desktop matches. (It's looking pretty bad with 5 different widget sets)

Mike Baker @ 21:18 - 10/31/98

All this natural language interfaces including speech recognization is not going to help those who are deaf.

Alex Buell @ 22:16 - 10/31/98

A couple of directions to go: rewrite toolkits to provide support for Raster's themability for GTK (Raster, *please* don't do a drastic rewrite for a while! :^) and provide support for LibWMaker for toolkits.

My reasoning for LibWMaker: it would be nice if other windowmanagers (such as MLVWM, the Macintosh-Like Virtual Window Manager) also supported LibWMaker; it would add another level of flexibility.

I also personally support a movement toward supporting either KDE or GNOME (or both; heck, I don't care :^) by making wrappers for other toolkits. It would be nice if this functionality were transparent to the user... :^)

simmons75 @ 22:46 - 10/31/98

Unicode is not a panacea -- it's just one more (huge) charset, just like Esperanto is one more (kludgy) language. X (itself, not most of X applications) has *good* support of multiple charsets and language-specific input methods, something that most other system lack, and replacing that with Unicode-only will be a mistake. All systems that are mentioned as "pure Unicode" by Tony already have large kludges to achieve the same goal of supporting languages and their charsets well (Unicode has nothing that can help to design or even choose input methods or choose language-specific processing routine for, say, hyphenation of the piece of text because Unicode text contain some characters that belong to multiple languages at once, with different processing rules). Texts, do Unicode-promoting people like it or not, are written and stored in local charsets, and while software can benefit from generalized way of declaring/implementing language-specific routines and semi-backward-compatible way of creating texts with language *and* charset declared for some parts of documents, Unicode solution is "languages do not exist, we have a way to draw any sequence characters, and everyone should be happy with that". Being Russian (using cyrillic "jcukeng" keyboard and koi8-r charset), I am definitely not.
This is the area where a lot of improvement should be done in X-specific, network-protocol-specific (whatever IETF means, last I have seen, Unicode/UTF-8 is _not_ used in protocols where their standards pretends that it should be used, however MIME charset declaration is alive and well), and other libraries, and replacing everything by Unicode will be just an easy way to sweep the dust (and there is a lot of dust there) under the carpet.

Alex Belits @ 02:15 - 11/01/98

I don't think that we can use the web or some other apply without help of eye. With eye I can browse
content in random way & fast locate position that I want. I can't find any way, that we can receive message from outside of our body in random way that we wish. Maybe, brain wave!! :)

Dolphin @ 04:43 - 11/01/98

There's a very important aspect of themes that many (perhaps even
most) people that I've seen contribute to discussions like this don't
appear to understand: appearance isn't the only attribute of a user
interface that should be customizable. Indeed, it may not even be the
most significant.

A user interface is composed of two basic components: look and FEEL.
The latter is, I think much more important in general. It's also the
part that's a lot harder to generalize. But for themes to truly work,
you must be able to generalize the feel of the user interface.

Take menus, for instance:

On the Macintosh, the menu is an ever-present entity at the top of
the screen. It's always visible and the fact that it's there
means that real-estate in individual windows needn't be used for
menus. The contents of the menu bar changes depending on which
application is the active application. This has certain
implications, namely that it becomes difficult if not impossible
to implement 'focus-follows-mouse'. The menu is used by clicking
the left (or only) mouse button on it. The menus are
'spring-loaded' so that if you release the button they disappear
(or, if you're over a menu option, the menu option is activated).

Under Windows (and most X toolkits), menus are located at the top
of each window. Focus-follows-mouse becomes a non-issue, but the
menus become somewhat harder for the user to target, since the
user must use both vertical and horizontal positioning instead of
horizontal positioning alone. The left mouse button is used to
activate a menu, but it needn't be held down to proceed: only when
it's released over a menu item or clicked over a menu item does
that item get activated.

On the Amiga, the menu (at the top like it is with the Mac) shows
up only when the right mouse button is active. The right mouse
button functions the same as the left (only) mouse button does on
the Mac: the menus are spring-loaded in the same way. But because
menu operation doesn't occur until the right mouse button is
pressed, focus-follows-mouse is not a problem.

Under XView (OpenLook) within X, the menus are actual buttons that
appear at the top of the application's window and are activated by
the right, not left, mouse button. The left mouse button
activates the 'default' action for the menu button in question.

And that's just the menus. The 'feel' is quite significantly
different between these different user interfaces.

I haven't taken a hard look at GTK+ in terms of how it handles themes,
but I suspect it allows customization of the look of the toolkit but
not the feel (or that any customization of the feel is relatively
limited. How, for instance, would one implement a theme which gave
you Macintosh-style menus?). I hope I'm wrong about that. But
regardless, here's my view of how this situation should be handled:

1. The entire user interface itself should be abstracted. Right now,
most toolkits (GTK+ included?) are written with a particular look
and feel in mind. That needs to be ditched. Instead:

a. the user interface itself needs to be defined in an abstract
manner. For instance, we all know that one element present in
almost all user interfaces is a menu. The logical
characteristics of this and other elements need to be defined
(what data does a menu contain? What purpose does it serve?).

b. a user interface protocol needs to be defined which reflects
the outcome of (a). Ideally, the protocol would be one which
could be used over a network. The purpose of the protocol is
to make it possible for the application to specify which user
interface elements it wishes to use and what actions are to be
taken when those elements are activated by the user. The
protocol would obviously need to be extensible, so that new
user interface elements could be added as needed. It should
also define a data interchange subprotocol to make drag and
drop (or other data transfer operations at the user-interface
level) possible.

c. the protocol defined in (b) would then be embodied in one or
more APIs (different languages have different APIs and the
resulting APIs might thus be quite different between
languages. But because they all end up ultimately using the
same protocol, the end result is that they would all
interoperate with each other properly.

2. Decisions would have to be made about how best to transform the
abstraction above into reality such that different looks and feels
could be specified by the user at will. Obviously toolkits would
then have to be implemented which yield different combinations of
look/feel.

3. It should be possible to implement the protocol, APIs, and
toolkits mentioned above on top of any sufficiently expressive
windowing system. I don't see offhand why X wouldn't qualify.

I have no idea how one would go about converting a toolkit which
operates at a relatively low level (such as Xt/Athena) into something
which talks a high-level protocol such as what I propose above.

I *can't* be the first person who has thought about this along these
lines. Is there any work in progress which embodies the methodology I
describe above?

Kevin Brown @ 05:01 - 11/01/98

The thing that X is now missing but needs a lot, is server-hosted toolkit. NeWS with Postscript probably wasn't the best idea possible, and without reliable and efficient Java VM, Java is unlikely to be the best solution either. X needs something else, be it interpreter in the server or some intermediate process, working always on the X server's host and talking to local server using X protocol and remote clients using high-level protocol. The "fallback" mode where application runs with X server that does not have such server-hosted toolkit will be to run intermediate process on client host or load the shared library that converts high-level calls into plain X protocol. With servers that support such thing the application will be able to upload significant part of UI into the server using some language that defines widgets' behavior and talks to the client using high-level protocol provided.

That will fill the gap between X applications (fast if running locally, with a lot of control over the interface) and HTTP-based ones (slow if running locally, but insensitive to delays caused by slow links, poor presentation and customizability).

Java tries to do that, but the problems are:

1. Bloat. It's hard to overbloat Motif but JDK did it. Yes, Java is a lot more than GUI, but if I need *that* just for remote GUI, I'll rather do something else.

2. No reliable implementation. I will believe that Java is reliable when Linux port will stop crashing and FreeBSD port will stop reporting free() of unallocated memory -- something that I assume is covered up by Solaris' libc "tolerant" memory allocation mechanism (not that it was long time since I have last seen Java application crashing on Solaris).

3. With all "advanced" development in networking with Java, not later than a week ago I had to explain to Java programmer that the protocol, he proposed to use between native (written in C or C++) server and Java client is insecure. Whatever bad can be said about X security (that is mostly a moot point now because ssh seems to do a fine job with handling secure X sessions given that environment doesn't have already compromised parts), poor [re]implementations of network protocols in Java programs give me chills.

4. License.

ActiveX-like packaged library binaries, transferred over the network are a horrible solution from the security standpoint, and platform barrier, nonexistent in X, will appear in full glory. However C source, written according to very strict rules (not more strict ones than ones imposed by Java, just to make them work on anything with minimal libc subset plus standard toolkit library), transferred to X server's host, compiled there and running in a sandbox (temporary userid, chroot, etc.) may be well suitable.

Nice interpreter may be even better, but in any case toolkit library should be suitable to provide usable GUI, and high-level protocol that server-hosted toolkit[+application] uses for its client should be multiplexed with X protocol or at least be handled with the same primitives (display, screen, host and security), X protocol uses for itself.

Alex Belits @ 09:59 - 11/01/98

I gotta say, I mostly dissagree. Sure X and most of the toolkits are ancient, but they are still of very high quality....

Motif may be old, but it is still the best toolkit on the market. And it follows current standards by using x resources and being ICCCM compliant. I have seen more then one toolkit come out that didn't follow one or the other, or both,...and whenever they do that, they miss out on very important aspects of X.

Graphical desktops are all well and good, convinient, but I think the man hours spent on those types of things would be better spent working on a way to create interactive programs with the current X standards and toolkits. That way all programs created with any toolkit smart enough to comply with the current standards can work as a whole to create a complete user system. Users and system developers can missmatch applications to create the system they like and still have all thier application be able to work nicely together.

All of this can be done with current standards and a few GUI programming style guides. Programs can be written that will do your X resources for you if your to lazy. New GUI interfaces can be made with global resources in mind...naming conventions etc...

Granted the above will not work flawlessly, but it is much better then the alternative...a major fragmentation of widget and program design even worst then it is now (it is getting much worst) so that you will have all sorts of groups of programs that work with each other, but nothing else...a mass of different resource file formats, and no way to make sence of it all...

If you need a new standard like drag and drop, then you create one and see how the world reacts...This seeming lack of interest in adhering to the old, and still completely useable, standards is going to bite us in the ass very soon, and very hard.

In my opinion, only toolkits that adhere to the X resource file, editres, and ICCCM protocols are promicing as development platforms. Toolkits like Gtk for example, that do not follow these guidlines and protocols, are not good for the X world as a whole,...and only serve to add to the current problem.

jik @ 00:01 - 11/02/98

Something which should not be overlooked is the changes happening over at mozilla.org, towards an XML, RDF and Style Sheet based UI. I personally feel that something along these lines, which is heavier weight than HTML forms, but lighter than X, is where user interfaces are going. XML/XSL or HTML/CSS2 (or whatever), are designed around the concept of seperating interface from implementation. In terms of UI's this means to seperate the actions/state represented from the visual details (colours, borders, etc).

Maybe there's scope for a User Interface Markup Language? This would be a really powerful tool for open source software in general, especially if it could be rendered at a low level by any windowing system (Windows, Mac, X11 etc), since it would allow applications to be developed that could be built for many platforms without source code changes. This also addresses the problem of speech based UIs to some extent.

The role of the toolkit is then reduced to the rendering of simple widgets, and the toolkits could be as interchangable as window managers. Maybe Java based widgets so they can be downloaded and run on any machine.

Something that does need addressing (in terms of XML or style sheets) is the standardisation of input models, so that the same keys always cut&paste or whatever. Something like a default interface object model (like the DOM), with user defined keybindings in a stylesheet like file?

Just some random thoughts,
-Jeremy

Jeremy Lea @ 10:26 - 11/02/98

I totally agree. The number of different (incompatible!) toolkits is becoming stupid. The fact that I can only compile program 'Abc' if I have toolkit A, and program 'Def' with toolkit 'D' reminds me of how that big proprietary company in Redmond operates. "What do you want to do today (so long as you use my stuff.)" The best thing about Unix/X is I am not forced to get anything from anyone to run program 'Xyz.' Ok, the common libraries may be out of date for what people want today, but is going off in six different directions a better solution. I don't think so.

I have noticed the latest README file are easy enough and the 'config' files are getting to close the point where my grandmother could perhaps compile something from scratch, but heaven help her if she needs a different version of library Abc.

A possible, short term, solution to the problem is in the coders lap. If you want to use a specific function call, from toolkit 'Def', include it and any needed source in your program. I know there is drawbacks to this, but if everything is self contained, my grandmother may have a chance, otherwise she'll pack her bags for Redmond.

Long term, the different toolkits have to come together in some working solution or perhaps the one with the shrewdest tactics may win, and in that case we all lose.

CMD

Mombo-Man @ 16:53 - 11/02/98

[ back ]