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
