[ 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:[EMAIL PROTECTED] | | 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.
