Desktop normalization

[Marcin Krol]

On Wed, 25 Nov 1998, Davide Bolcioni wrote:

> Agreed. I see a few possible approaches to solve the problem:
> 1) provide a standard set of services application writers can use, i.e.
> a single fully specified API (Macintosh or Windows; Linux might still
> have different implementations but their compatibility might be an
> issue);
> 2) provide a set of services application writers can use to discover at
> launch time what services are available, so that applications can make
> use of what they recognize;
> 1+2) provide a standard subset which includes common services and the
> means to find out what extra services are there;
> 4) provide a configurator like linuxconf, which knows everything about
> the configuration needs of every installed package (in principle) and
> does all the necessary work.

<agree and snip>

> Writing another (1) would be definitely non-trivial, it seems to me, and
> besides is exactly what Gnome and KDE are already attempting to achieve.

Not a good idea. Besides there are already too many toolkits. 

> Writing a proxy (1), an API which abstracts existing desktops, might
> prove very challenging from the design point of view (meaning that it
> might have to change many times before it gets right, the best way to
> scare application developers away).

Make it Linux way - odd number version until it gets practical.

> I must say I am attracted by the notion of (2), mainly because I have
> seen it suggested on Usenet but found otherwise very little about such
> an approach. The problem with (4), of course, is that writing the
> configuration program becomes a monumental task and keeping it up to
> date even more so (although XML might definitely help with this): the
> approach does not seem to scale well.

I'd go for your 1+2 for reasons of backward compatibility and as temporary
solution plus new abstraction layer (a little like HTML) - no current
solution is excluded from the start, they would just "evolve out" with
time. IOW, allow old solutions and promote new generic and extensible
one. 

> > compatibility between distributions tailored for desktop machines.
> > Otherwise you get anarchy on the level of UI, and that is what new users
> > hate most.

> Does this mean describe "left click should be select, middle click
> extend, right click paste" or does this mean "call CloseWindowEx() to
> close window" ?

Yes, but only as modifiable default. Or maybe during installation of new
wm various settings would be imported from
/etc/opt/gui/generic/semantics.conf on request, overwriting them if user
asks for it, etc.

> > practical chance to work 100% correctly), so he says "screw it, let end
> > user integrate it". Which end user hates to do, because time spent on
> > configuring machine is from user's POV wasted.

> The point (2) above might boil down to writing an interface against
> which installation scripts could be written, except that instead of
> doing it at install time you do it at launch time - because in a system
> where components are updated separately, you might need to redo the
> installation if a component you depend on is updated, so you have to
> introduce trigger scripts and so on. Doing it at launch time might be
> better, caching the results in a dot file for performance if necessary.

I meant kind of wrapper rather or new abstraction layer, but if your way 
were more practical, I'd go for it.



 Marcin Krol

-----------------------------------------------------------------------------
Hiroshima 45                   Tschernobyl 86                      Windows 95