Re: Desktop normalization (fwd)
[ My appologies, the message that Marcin is replying to should have
been sent to the mailing list but I forgot to change the headers in
elm (hey it was 2am ;-). Nonetheless, I'll try to clarify somethings
which only make sense with a copy of my message.
On a related note, I replied to another's message last night too and
also forgot to direct that to the mailing list. Could that person
(whose name escapes me) kindly forward that to the list, since I
don't keep copies of most of my mailings? ]
I was deep in meditation when Marcin Krol awoke me by saying:
>
> On Tue, 24 Nov 1998, Aaron wrote:
>
> > > Who said standard *prevents* you from doing so? I am last one to consider
> > > conserve-it-in-the-plastic MS approach. Just implement modifiable
> > > standard. Irreplaceable standard - that is the problem definitely.
>
> > As I implied however, one purpose of a standard (and a primary motivation
> > of the LSB project) is to give potential developers a "still" target, if
> > you will, rather than a "moving" target.
>
> Yes. Problem is, what you propose gives developers multiple targets. Even
> one moving target is still better than whole bunch of targets, some
> stable, some moving.
No necessarily. What I propose is that we be very careful to maintain a
stable target where necessary. I don't think the abilitiy of inability of
the window manager from doing (for example) windowshade or providing for
an icon box (rather than putting icons in the root window) warrant a stable
target, because they are independant of the actual application, and are
completely within the realm of user preference. In other words, the application
doesn't need to know that its window is windowshaded, or where its icon
has gone; however it does need to know how to perform drag and drop and
may need to know how to dock itself (whether docking be in a toolbar or in
some sort of "active desktop" [parry the thought], etc). That's why I
say these services should be standardized. But standardizing a "look and feel"
(which is generally understood to be independant of application/GUI interaction)
is not beneficial.
All window managers provide the same services to an X application. With
the exception of Motif hints, which may be ignored by non-mwm window
managers, an application simply talks to the generic window manager as
defined in the X protocol. A window manager, by necessity, must be
able to implement the requests sent to it from applications.
The contraversial part is the Desktop Environment, since this is not
per se the window manager, and is not standardized. However, to choose
one type of Desktop Environment (e.g. KDE) over another is a poor
idea. Rather, we should define the basic services which all desktop
environments must implement, and maybe some extended services which would
be optionally implemented. Then, once KDE and GNOME and whatever else implements
the standard API, its still up to the user which one he/she wants to use.
Then, application developers don't need to directly access CORBA services
to write a GNOME-compliant application, because there will be a standard
API on top of these GNOME services, and the application writer can access
services like DnD by making a call, such as drag(), which will work
across environments. It'll be up to the environment developers to implement
the API in their native services.
This wouldn't preclude application writers writing environment-specific
services, but it would greatly encourage them to write standard-compliant
services. In other words, the application could still access DnD via GNOME-
specific protocols, but the developer will probably choose the standard
protocol so that non-GNOME users can use the application in the same way.
>
> >If we were to supply such a
> > standard [f]or GUI development, and at the same time encourage users to
> > disregard it, we would be defeating the whole purpose of the standard.
>
> In mission statement I read that purpose of standard is increasing
> compatibility.
But if the standard leaves room for its disregard, whatever its purpose
is, it is not well served. If we say "KDE is the standard, but if you
don't like it, use GNOME", then what have we gained with a standard? I
say KDE (or even GNOME) are bad choices for inclusion into a GUI standard
because they are implementations not interfaces. If, in response, you say
"then change the environment you use," then I am not standards compliant.
If the standard itself says "you can change the environment you use" then
I'm confused because it is telling me to disregard itself. Although I've
used KDE and GNOME in this argument, what really frightens me is
a standard window manager (which KDE as a standard would imply, as I
understand it, since it requires kwm). Let's face it, in the Unix world,
people use different window managers, even if a few are more dominant
than others. I view this as an asset, and I am happy that the X protocol
was developed to accomodate this. I think it would be horrific to throw
that asset away in the name of ease of use. Ease of use itself can be
ccomplished via other means, and I don't think belongs in a standard at all.
As you cite, the purpose of the LSB is interoperability and compatibility.
These things may contribute indirectly to ease of use, but primarily they
contribute to ease of development. As I understood it, the motivation
behind the LSB was to encourage a higher level of development and support,
especially from commercial concerns, by making development easier via
interoperability and compatibility. Where GUIs need these two things,
IMO the desktop environment services, a standard should cover it. Where
they do not, IMO window managers, look and feel and ease of use, a
standard is not necessary and actually becomes a deterrent to the end
user.
> > Certainly standards should be modifiable, but not unilaterally.
>
> Well, if you modify your desktop then you definitely modify
> standard unilaterally.
Only if the desktop is standardized, which is why I am opposed to
standardizing the desktop.
>
> > A standard,
> > at any one point in time should be solid and immobile;
>
> Not necessarily.
Well if it's not than it is not a standard. As a developer, I should
be able to print out a copy of LSB ver X.Y.Z and code an application
which will run on all LSB X.Y.Z-compliant systems. If that's not the
case, then what do I gain by even looking at the standard?
>
> >otherwise what's
> > the point?
>
> Interoperability.
Which cannot be achieved if there is not a solid standard.
>
> > > Not at all. Just having default wm and standard xclock does not prevent
> > > you from replacing them, does it.
>
> > Ahh, but a "default" wm and a "standard" wm are two different things. However, I
> > don't think it's in anyone's interest to attempt to mandate either
>
> It is in everybody's interest to point at interoperable default.
No, when interoperability is the goal, a standard, not a default, is
warranted. Defaults imply that the default may not be what's there. Standards
imply that no matter what, the standard is there. I just don't think that
ease of use and look and feel issues are interoperability issues. I agree
with the original poster's intent, that a standard API be developed to
access services common to desktop environments like GNOME and KDE. What I've
been disputing with is some folks idea that we should go further and
actually standardize on a specific environment and window manager.
>
> > (for instance, fvwm2-95 may be better for beginning users who
> > are accustomed to a Windows interface, but mwm may be better for users
> > accustomed to Solaris, etc). The standard wm is best left to the free market.
>
> Even then many people want to use different desktops. Then developers
> will make compromise, which leaves those other people on the ice - either
> employ this de facto standard or don't use app. That's MS way.
No, because there's nothing inherent in a window manager which demands
application compatibility. All window managers have to understand all
applications; otherwise it's not a good window manager. The question
is the additional services not specified by window manager. What I gathered
was that you proposed standardizing on a window manager/dektop environment
for the sake of ease of use. I think that may have been an incorrect
conclusion and from your comments, I think we probably agree on more
points than we disagree.
>
> > > > This is exactly what has turned
> > > > many away from Microsoft and Microsoftesque (new word ;-) products,
> > >
> > > Frankly, I do not see many people doing that. If anything, it is reverse.
> >
> > Well I'm afraid I do see many people doing that. I'll take a leap of faith and
> > say that most of today's Linux users were previous users of DOS/Windows.
>
> > Nonetheless, your statement belies a more serious misconception, IMHO; that
> > we should borrow from the success of Microsoft by doing what Microsoft does.
>
> I don't know how exactly you define borrow; however we definitely need
> to learn from it's success and from mistakes of traditional Unix vendors.
I agree. But just because Windows does something and Windows is popular is
not a good argument for Linux doing it. I think there are many weakenesses
in the Windows UI and in applications' interaction with that UI, and I think
to emulate the ideas present in the win32 UI would be at the least a
poor idea, at the most a disastrous one (disastrous for LSB and thus for
Linux, since I think the success of Linux is affected by the success of
the LSB).
>
> > In fact, I'll wager that the blossoming of Linux is in a large part due to
> > the fact that there are different motivations and different ideas behind
> > the movement.
>
> >If we begin to adopt the techniques of Microsoft (specifically,
> > by catering to the lowest common denominator by mandating user interface at
> > the expense of customizability and control), then we weaken the foundation
> > of Linux's success.
>
> But lsb at all *is* such denominator, isn't it? Call for participation:
> "The application of the standard will be that any program that runs
> successfully on the reference platform can be expected to run on all
> Linux systems. If they don't, the distribution creator must either fix
> a problem with their own distribution, or convince us that there's a
> bug in the sample distribution which violates the standards."
>
Yes, the LSB will define a LCD which applications developers can expect
to be present, but it doesn't (or shouldn't) do this at the cost of limiting
advanced options. Mandating a user interface limits my ability to extend
it. If the standard says that iconized windows must go to an icon box, then
I cannot have them go to the root window without violating the standard.
On the other hand, if the standard says that applications may be "docked" via
a standard interface, without passing judgement as to how it will be docked
(maybe in a root window, maybe in a taskbar, etc) then I think that's
acceptable.
> I am not calling for favoring some solution. I just recognize the need
> that would allow creating such standard that would allow developer to
> develop single package which ideally would run in all Linux environments
> (maybe even with X or Berlin instead of it for example).
I think this can be accomplished by standardizing on GTK. Let's leave it
up to GTK to worry about implementing a Berlin-compatible adapter. For
the time being, X is the the standard low-level windowing protocol. Making
GTK the standard toolkit (that is, the runtime libraries are gauranteed
to be available on any Linux system with GUI capabilities) I think is
a good idea. It's the most common (AFAIK) open source toolkit, it's
pretty much language-independant, since it's in C and there are many
bindings to it, and it's pretty comparable to Motif (the commercial
defacto standard, but one which is invalid for inclusion into an LSB
graphical toolkit standard).
Notice that this does not affect the desktop environment issue at all,
nor should it. Desktop environment services should be available as a
different component of the standard, and really shouldn't be OS-dependant
at all (as I suggested in my other "lost" mailing). I wouldn't place
such a standard into the LSB, because it should be developed to be
applicable to all OSes (even if it is only realized on Linux). In my
other mailing, I called this GUISE (GUI Standard Environment) because it
was a witty (IMHO) acronym ;-). GUISE would be careful to define standard
environment services, in the most abstract way as possible while still
retaining meaning. LSB would therefore only state that it adopts GUISE as
a GUI environment services standard. Conceptually, Windows or MacOS or
Be could adopt GUISE as a standard as well.
>
> This does not extinguish competition between various vendors and
> solutions. If anything, they are afraid of competition right now - in fear
> of alienating user base.
Exactly, and any standard which would do that (read, is too contraversial)
will be roundly ignored by the vendors and thus will be meaningless in
the real world.
> They have to choose some subset of users, or
> develop for multiple groups. Consider Netscape linked statically with
> Motif and dynamically with Motif for those who don't have it and for those
> who have it.
Correct, Netscape knows that on Linux, Motif is not gauranteed to be there.
If GTK were the standard, Netscape would at least know that it is
gauranteed to be there, therfore no need to statically link. It still has
the option of using Motif because there would be nothing in the standard
which precludes Motif. In this case the standard wouldn't say "you must
use GTK", rather it says "you can use anything, but GTK is gauranteed to
be available".
Similarly, GUISE would not say "the top left titlebar button must bring
up a menu with a fixed set of options in it". Rather it would state that
those options must be provided, somewhere, somehow by the environment/
window manager. For instance, GUISE might state that an application must
be able to be "Closed", "Deleted", or "Destroyed" and that those things mean
certain things. How a window manager provides those services is irrelevant to
the standard, and best left to the implementors of the window manager.
>
> > > Statistically your opinion is rare.
>
> > I don't think so. After using mwm for a year, I know many friends at school
> > who are eager to use fvwm or Afterstep or even twm.
>
> If Linux makes it to headlines, it means it moves out of it's traditional
> niches; so requirements change. Rules of game are no longer like
> they used to be.
Well we have the option of changing the rules to what we *think* they
will be, or we can let history take its course and the rules will change
to what they will be by themselves. If Linux making it to the headlines means
I have to suffer needlessly, then it can stay on Slashdot. We *must* avoid
"selling out" to the headlines. Linux has garnered attention specifically
*because* the rules governing it are different from the mainstream. If
we change those rules to the mainstream rules, then Linux loses its appeal.
>
> > > Priority one for most users is working out of box.
> > > Customization is long down the list of priorities.
>
> > I would dispute this. While it is very important that a system work out
> > of the box, what keeps a user using it is how well the system works period.
>
> What keeps user is low initial cost and investment of work into solution.
I don't think so. Low initial cost is what gets the user there in the first
place. Permanent usability and extensibility is what keeps the user there.
In other words, the "Tocal Cost of Ownership" as Microsoft likes to toss
around. In my opinion, Linux right now offers a better TCO than Windows,
which explains its growing popularity among desktop users and enterprise
users alike. Standardized Linux offers even better TCO, as long as its done
right. Needlessly limiting options (especially those the current user base
has grown fiercely accostumed to) reduces TCO. A user may say "why not
install Linux, it's as easy to use as Windows" at the beginning, but later
on may think "why did I install Linux, it's just as limited as Windows?"
That's a situation I think is very important to avoid.
> That's what fills Bill's pockets: ease of installation and constant
> need for correcting PC. Famous Wintel maintenance costs. That's human
> psychology: once you invested a lot of work into something, you
> tend to regard this solution as better than other ones.
Which explains why I'm defiant of movements to standardize a single
environment/window manager. I'm used to fvwm2 with GNOME. I don't want
kwm with KDE to be standard. I want the two to be interoperable, to
please all sides. Standardizing on a GUISE-type standard could achieve this.
Standardizing on a single look and feel most definately will not, and will
probaly anger users all around.
> I am not claiming we need to act the way MS does; we only need
> to take into account mechanisms that made it successful.
>
> > I
> > think that includes customizability. A user is happier with a system they
> > know, and have the oppurtunity to tailor it to their specific desires and
> > needs.
>
> But not at cost that is too high. Traditional Unix way is simply
> too expensive.
I don't think so. Traditional Unix has never had a desktop environment,
fractured or otherwise, which impeded its growth. Thus the developement of
CDE, and later KDE and then GNOME. This is uncharted territory in the Unix
world. We can do this the right way (by standardizing an API to services)
or the wrong way (by standardizing the environment and window manager).
For all its faults, traditional Unix has been around for over 20 years, and
is right now actually increasing in accpetance (thanks to Linux). There is
something to be said for that. Let's make sure we don't throw the baby out
with the bathwater, to coin a phrase.
>
> > To again use my school as an analogy, mwm is provided as the default
> > wm to allow entering students (most of which have never used Unix at all)
> > to actually use the resources in a sane way, and to allow for an introduction
> > to those resources in a universal way. However, to deny students the ability
> > to modify their environment to suit their own preferences would be a tragedy.
>
> There is no need to do that.
Then I am beginning to think we agree here.
>
> > "Out of box" experience lasts for about a month, I'd say, and that's about
> > how long it takes many people to realize how poor a design Windows is.
>
> People love novelty, so they want to keep installing new things and don't
> want to fight it each time. They want to install 10 things, want it to
> work out of box, try it, then throw away 8 or 9 and stay with one or two
> of choice.
>
Yes, but this doesn't speak to the underlying system. Most people don't
like having to upheave the underlying system. Even Windows 98, which I dare
say is not *as* popular as Windows 95 was, is not that much of a change
from Windows 95. In fact, Windows has always been bogged down by the
installed base clamouring for backwards compatibility. I say bogged down, but
I sympathize with this sentiment. If something works, don't change it until
absolutely necessary. fvwm2 works for me. Don't make me change it, because
I don't see kwm or mwm etc as absolutely necessary.
> > Yes,
> > it works out of the box, but when it's time to graduate from beginning user
> > to experienced user, there's nothing there to allow that transition.
>
> wrt Windows, yes.
>
> > That's why I would place "out of box" usability as a burden to the distributor/
> > vendor, and I'd say that 99% of that burden can be filled with default
> > configurations, as the distributor/vendor sees fit.
>
> Unfortunately no. Someone wrote on freshmeat editorial: try to take
> ten rpm's, convert it with alien and run it on debian without any
> change. I have fought 'alien' many times, and frankly I find such
> work a waste of time. I would hate to see repeat of this when
> it comes to GUI.
Well this is a different problem. Package installation should, IMO be
standardized for the exact reason you mention. But this doesn't speak
to the runtime interoperability of the application. All that is needed is
to define a base standard of GUI services. Most of this is inherent in
the native protocol (X) and the toolkit in use (GTK). Other services can
be abstracted from the native protocol, even the native OS. There's no
reason to mandate how they are implemented (not just codewise, but
GUI-wise). One need only look at Java (especially the Swing library) as
a good starting point for efforts such as this.
>
> > But forming a standard
> > may fill the burden, but damages the underlying strength of the product.
> > Some have posed the argument like this: supply the "standard" environment,
> > and allow the user to change it. But how can developers be expected to
> > know what to develop for if even the standard is no gauranteed to be what's
> > in use? Labelling, for instance KDE the standard is misleading to the
> > developer if most people use, for instance GNOME or GNUStep.
>
> Favoring some particular solution is dangerous and unnecessary indeed.
>
> > > I am really sorry to say that, but you are proponent of taste, not
> > > usability.
>
> > If allowing me to modify my environment means that I can be more
> > productive (which, IMO, it does), then you better believe I am a
> > proponent of usability.
>
> For you. Not for vast majority of users. Vast majority just wants
> it to do the job on ACCEPTABLE level. Sophistication is hardly
> popular.
I reject this. I think the vast majority likes to customize. The problem
is, with Windows, for instance, there is limited ability to customize.
People tinker with background, system colors, sounds, etc all the time.
The fact that they don't tinker with the overall look and feel of their
GUI is baded on the fact that they can't. In Unix-land one can tinker
with this, and it has become a popular past time for many users. To
assume that "Joe Sixpack" is somehow less apt than we is wrong. Most of
us didn't know Unix at all while we were growing up (most of us younger
Linux users, anyways), yet here we are. I think that a vast majority of
users of any OS follow stages of usage:
Beginning User - the user has little or no experience with the OS, and
obviously won't want to customize it because he/she wants to learn the
basics first. Perhaps the user has used other OSes, and brings with
him/her some stereotypes which, at this level, are best fulfilled by
the OS configuration, in order to be more familiar with the user.
Intermediate User - any beginning user who uses the OS long enough will
graduate to an intermediate user. This means they are familiar with the
OS, and have learned many of its nuances particular to that OS. The
user is ready and fully capable of experimenting with things which
contradict those stereotypes which once were fulfilled by the OS.
For instance, rather than having the steroetypical titlebar which
looks like a win32 titlebar (with the buttons arragned thusly),
the user may begin to experiment with different titlebar button layouts,
or even different titlebar styles (in the case of E, this can be
done ad infinitum). The user can be safely introduced to ideas never
present in the other OSes (pagers and virtual desktops, for example).
Advanced User - most users probably wont make it here, but some will. These
are probably the ones who hacked around with stuff and experimented and
learned the underlying ideas behind things. They know how to administer
most things on their system without help from third parties. By this time,
they have a configuration that will probably change very little and in
increments, because they are happy with it: it is theirs, they made it
and they maintain it.
Now, certainly Linux is not yet the best OS for dealing with beginning
users. I think it is one of the best for dealing with intermediate
users, and it definately excels at dealing with advanced users. I'm very
interested in making Linux easier for the beginning user, but I'm also
very vigilant that in doing so, we don't unnecessarily limit its value
to the Intermediate and Advanced users.
>
> > > >The idea that people should be
> > > > able to customize more than just their screensaver and desktop colors is
> > > > one not to take lightly. Unix uses are used to customizing everything,
> > > > from their emacs modules to their shell aliases/functions.
> > >
> > > If so, what is the point of standardization at all? Why not leave *all* to
> > > end user?
> >
> > Exactly my point. ;-)
> > Standardization should never be its own motivation. It is a necessary evil,
> > IMO, and should only be employed when the benefits outweigh the costs.
> > I don't see how mandating a user interface provides more benefits than the
> > costs of alienating users (users who have become accustomed to Linux [and
> > Unix in general] providing for extensive customizability).
> >
> > > Everyone needs usability out of box to a certain extent. Where
> > > this extent is depends on personal taste. You are entitled to your taste.
> >
> > Apparently I am not, if a standard is going to tell me exactly how I'm going
> > to do things.
> >
> > > But the problem is that if LSB sets tradeoff between working out of box
> > > and customization to be skewed too far in the direction of customization,
> > > relatively few people will want to use it.
> >
> > But I don't think out of box usability is the intent of the LSB.
>
> Mission statement:"The goal of the Linux Standard Base (LSB) is to develop
> and promote a set of standards that will increase
> compatibility among Linux distributions and enable
> software applications to run on any compliant Linux
> system."
Nothing in that speaks to out of box usability. Let me clarify, by out
of box usability, I am referring to Linux itself, not applications. Vendors
are under strong pressure to provide for out of box usability in Linux, because
otherwise potential new users will be lost. Application developers are
also interested in their own applicaions' out of box usability for the same
reasons. The LSB was set, AFAIK, to provide a common and standard framework
for allowing application developers to develop easily interoperable and
compatible applications. It is still up to the developers, however, to
actually do so. I don't see how allowing users to alter their window manager
and desktop environment restricts this, as long as a standard for such
services is defined. Window managers have such a standard within the X
prototol itself. Desktop environments do not, and a GUISE-type project could
supply them with one. Lets not follow CDE's and KDE's examples and integrate
that standard within a single toolkit, instead we should develop such
a standard as a completely seperate API (as GNOME has tried to do) which is
window manager, toolkit and window system independant.
>
> >But not a standard on look and
> > feel, but rather a standard on services provided by the environment.
>
> Agreed.
Here is my evidence that in fact, we agree on all the important issues in
this discussion.
>
> > I'm
> > just wary that in the process of standardizing these GUI services, we
> > get tempted to drag in specific implementations of those services,
>
> No specific implementations. It's not only about holy wars; it's about
> legacy code. Suppose app developers write for some generic UI
> specification; then if some day berlin matures enough, there won't be as
> many legacy problems (ideally no problems) in moving old software to new
> environment.
Yes, but there are two components to the application: the desktop environment
services and the toolkit services. Toolkits are, currently, very coupled
with the window system underneath. There is no reason that the desktop
environment services need to be. Therefore, both the desktop environment
API and the toolkit would need to be ported to the new window system.
Philisophically, I don't see a problem with this, but I think it's more
likely that something like Berlin would have to make itself X-compatible.
>
> > rather
> > than interfaces (for instance, if we specify that the GUI provide a means
> > of performing Drag and Drop [according to some standard, such as xdnd],
>
> Oh yes. One thing that is CRITICALLY necessary is universal drag and
> drop. I do not especially miss it; casual users miss it.
I miss it for some things. Surely it can be overused, but when used properly
it makes for a much nicer and more efficient environment.
>
> > > I've had such experiences with
> > > users for which I installed Linux (for free). "Why is not there one way to
> > > do it"? "Because it is assumed people will do it different ways". "I don't
> > > care HOW it is done, I only care to get it done".
> >
> > Well, I think how it is done is a very important question. To disregard this
> > is to throw away all the reasons to even use Linux. No doubt that Windows
> > can do most of what most people require of it.
>
> > However, the fact that Linux
> > can do most of that, and do it better, is a strong endorsement.
>
> Correct. But that does not invalidate view that linux needs to be able
> to do most of what most people need. IOW, linux needs also to be able
> to do what Windows do - and more. Linux capability has to be superset
> of Windows capability, not unrelated set of capabilities.
Agreed. But in providing those capabilities, we needn't throw out those
capabilities which are not in the subset. For instance, Window may have
a single look and feel, but there's little reason Linux needs to be
limited to that. In fact, there are lots of reasons it shouldn't be, the
least of which is that the current user base demands that capability.
>
>
> <snip>
> > > >I hesitate
> > > > to say which environment or window manager is in greater usage, and to base
> > > > any standard upon one which is not (or just barely is) is to upheave the
> > > > entire process and at the same time lose credibility where it counts:
> > > > the users.
>
> > > You can not loose more credibility in eyes of user than in the
> > > case when product does not work out of box.
>
> > Certainly you can. There are many users who have already taken the system
> > out of the box. If we throw away their concerns, then we must ask ourselves
> > what audience are we providing for? We may attract new users, but if
> > in the process we alienate old users then we are playing a dangerous game.
> > Windows is good at attracting new users (mainly because it's what comes up
> > when they start their computer out of the box), but I think it has a poor
> > track record at keeping their interest.
>
> > Most Windows users will tell you
> > why they use Windows, not because it's enjoyable, but because it's the
> > only option they see available to them.
>
> Then our experiences are different. IMHO more than half of users enjoy
> Windows for one purpose - ease of use.
Nah, lots of things have ease of use: OS/2, MacOs, etc. I suspect that had
OS/2 been on 90% of all new computers as the default OS, Windows would be
dead, because they both were about as easy to use. The defining factors is
that Windows is preinstalled, and most applications require it. Take those
two facts away and the the OS world would be alot more hetergenous. I still
stand by my assertion that most (continuing) Windows users use Windows because
they see it (justifiably or unjustifiably) as their only option. I haven't
talked to very many people who use Windows on a regular basis that are
overwhelmingly satisfied with it. Nonetheless, one can't argue that most
Windows users wouldn't like to alter their look and feel, since it is
almost impossible to do so (yes you can replace Explorer.exe but that has
a whole slew of problems, and is not generally a solution most people know
about).
> Less tweaking necessary. If that
> means lower productivity, so be it. Solutions change so often that
> realistically user does not even need to maximize productivity, because
> before learning curve saturates user jumps to a new version or new
> application. What's the point of learning something in depth if tomorrow
> it will be thrown away and replaced with something different? Low initial
> learning cost is what is most important in environment that changes
> frequently.
But once a user has customized their environment, they rarely change it.
There is nothing in customizing an environment which would make specific
applications more productive. Rather it makes the overall usage of the
OS more productive and efficient. These things, I submit, do not change
readily once a user is satified with them. If a user is satisfied with
the default configuration, then great; but if not there should be some
leeway for modification. In Windows there is leeway, but it only is
in little things: the color of the windows, the wallpaper, the resolution,
the sound scheme, etc. These things do little to actually alter the
behaviour of the window manager, just how it looks. I submit that there
is nothing wrong with allowing the user to alter the behaviour of
his/her environment, as long as the end result is the same (e.g. who
cares where my iconized windows go, as long as they are iconized and
can be uniconized? who cares if I want to windowshade a window? who
cares if I want to switch to a different screen in my virtual desktop?
etc. etc.)
> > > > A company which expects KDE will be encouraged to
> > > > write KDE-only features into their product, because they will falsely
> > > > believe that everyone can handle that functionality.
>
> > > A company that is so clueless deserves to die.
>
> > To accept other than my presumptions is to place a burden on companies
> > so large that they won't be able to meet it anyways. For instance, let's
> > say that, although X11 is the GUI standard for all Unices,
>
> What if you want to swap to different GUI? Is not X11 a bit like Windows -
> you stick with it because you have to?
Yes, and there definately is a point at which one must say "this is how
we are doing things." The native window system is such a point. The
functionality of the window manager, IMO is not such a point, so long as
it supplies the standard services I've been talking about. Likewise for
a desktop environment.
> If there were kind of HTML for user
> interface, moving to different GUI would be more practical, kind of like
> having new browser does not mean that all web pages on whole internet need
> to be rewritten. Some features will gradually evolve out, that's all.
Yes, and what you are speaking to is a standard protocol. X is a standard
protocol, like HTML. We cannot allow ourselves to micromanage how developers
use X in their applications, just as it would be unconsionable [sic?]
to standardize how web authors use HTML to product their content. We need
to make sure we are standardizing protocols and not the usage of those
protocols.
>
> >a company is
> > in the mindeset that somewhere, someone may not be using X11, but rather
> > may be using Berlin and therefore they must place parallel efforts in
> > developing for *both* protocols.
>
> Purpose of standard I ask for is exactly what would eliminate such need.
Yes and we have such a standard in mind: X, because it is the de facto standard.
But when we are talking desktop environments, it's not so clear because there
is not a de facto standard. Furthermore, X is a protocol with many
implementations (XFree86, Accelerated X, etc). KDE is an implementation of
a proprietary (in the sense of non-standard) protocol, as is GNOME. What
we need is a basic standard protocol which KDE and GNOME and anything else
can implement with the most leeway possible while adhering to the protocol.
I think this is what the original poster in this thread was getting at.
>
> >Well, demanding such from developers is asking
> > a little too much, I think.
>
> Then take a look at what you propose: it is exactly variety of protocols
> for developers what your proposal effects in!
Not at all! I merely ask that I be free to choose the implementation of
a standard protocol which best suits my needs and desires.
> > The fact is, they are doing just that; and slowly, but surely, these issues
> > will be addressed. If Red Hat discovers it can increase its user base by
> > supplying a simpler default configuration, then I assure you they will do
> > it.
>
> > I myself cannot attest to Red Hat's current default wm configuration
> because
> > I happily altered it to my own before ever even typing 'startx'.
>
> Me too. Problem is, this is not solution for casual user - and this is
Yes, but we can leave it up to Red Hat to determine the default configuration
for the beginning, casual user.
>
> > > > These are good things, IMHO.
>
> > > It's like every diagnosis in social science: some do, some don't. Depends
> > > on taste.
>
> > Well this can be said about anything, but I think it's more of a
> > filibustering argument than anything.
[ Here I used an underwear analogy, that I could function wearing underwear
a size or two too small, but I wouldn't be able to function to the best of
my ability. ]
>
> No, it's only suggestion that UI *is* like underwear - very personal
> thing. But nevertheless, mass production here is still necessary. Few
> people are going to sew their own. 8-)
No, but few people are going to accept a one-size-fits all policy. If that's
the policy in effect, they probably will purchase another brand which has
more options available to them.
>
> > Nonetheless, if you're suggesting that
> > people don't want to be able to choose their own interior decoration, I suggest
> > that taste or not, you're on the losing side of the argument.
>
> Not in as big extent as you think they are. Few people actually want to
> carve every detail in their interior decoration. They settle down
> compromise between customization and using massively produced
> off-the-shelf things.
Yes, but you'll rarely step into two houses decorated the same with the
same furniture. Likwise, why should all dektop environments be carbon
copies of some lofty standard? If the furniture is analogous to the
features of the desktop environment, then let people decide what
features they want to use and how they want to use them. As long as we
know that everyone will have a chair and a bed and a kitchen, who cares
what they look like or how one uses them to achieve the ends they were
intended for. If an electric stove cooks the food and a gas stove cooks
the food, all we are concerned about is that the food gets cooked. Its
up to the owner of the house which type of stove he/she wants to use to
cook it.
> > But there is a such thing as software that is "mature." LaTeX, for example,
> > is mature.
>
> ..and dead on mass market.
That's irrelevant to my arguement. Even popular technologies like Microsoft
Word are mature. Sure, the file format keeps changing (intentionally), but
a user of Word 95 will still be able to use Word 98 with little new instruction.
That's because it's a product that's been around and has had the time to
incorporate feedback and learn what works and what doesn't. KDE and GNOME and
I even say CDE do not have the maturity necessary to extract a definitive
API from, IMO.
>
> > Xlib is mature.
>
> ..and everything important happens elsewhere.
>
> > The Linux kernel is mature.
>
> Most of it, yes - but still in constant development. I'd say
> that major factor in linux success is ability to provide *both*
> stability in even-numbered versions and rapid development in odd-numbered
> versions. But this stability is a stability on the edge of change - "when
> new stable kernel?".
But when I start up the system, I can expect certain things to happen.
There are always experimental and developmental components in software, but
there will inevitably be certain components which have stood the test of
time, and that we know should be there. I just don't think desktop
environments have had the chance yet to develop such components. (Yes we
know DnD should be there, but what about application docking?)
> > If one desktop environment becomes dominant, then it will become the
> > standard. If one doesn't, then there is no place for a specific one in
> > the standard. Again, the services provided by the different environments
> > certainly warrant standardization efforts, once those services are deemed
> > important and their interfaces mature enough to extract the necessary
> > information for investigation and development of the proper standard.
> > As for the desktop being an add-on, I wouldn't put it those terms. I would
> > say that there are different components to an operating system, and one
> > of those components is (by necessity) a user interface.
>
> And thus there needs to be some abstract definition of it. Developer
> writes single package, drops it in, and it comes out on every desk
> in various flavors, being consistent with particular flavor.
Again we agree. This abstraction needs to be defined in terms of a protocol,
with very little guidelines as to how the protocol is implemented.
> But it's not about me - it's about linux vs. public.
Let's make sure the public doesn't win at the expense of Linux. I think,
if handled properly, both will win.
--
¤--------------------------------------------------------------------¤
| Aaron Gaudio mailto:icy_manipulator@mindless.com |
| http://www.rit.edu/~adg1653/ |
¤--------------------------------------------------------------------¤
| "The fool finds ignorance all around him. |
| The wise man finds ignorance within." |
¤--------------------------------------------------------------------¤
Use of any of my email addresses is subject to the terms found at
http://www.rit.edu/~adg1653/email.shtml. By using any of my addresses, you
agree to be bound by the terms therein.
Reply to: