Re: Desktop normalization (fwd)
On Wed, 25 Nov 1998, Aaron wrote:
> I was deep in meditation when Marcin Krol awoke me by saying:
> > > 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,
No. This detail is not what is "absolutely necessary"...
> 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
... but universal drag and drop *is* absolutely necessary in GUI area.
> 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.
Yes! That's what I want - universal, interoperable solution.
> A window manager, by necessity, must be
> able to implement the requests sent to it from applications.
> 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.
I'll go even further - what about future desktops? There is no
reason really to assume that development here will cease. If
anything, it will be opposite. So it is important not to include
something that would result in future kludges resulting from
legacy of present compromises.
> 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.
Which they may extend at their own risk, a bit like browser manufacturers
implement their own extensions, and market decides which ones stay
and which ones go away with time.
<snip>
> 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.
I am not sure about this. Take a look how internet flourished when Web
became easy to use. Ease of use (or easy integration maybe) does need to
be taken into account - just not ease at any cost.
> 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.
If so, there is also need for some body that would work for ease
of use on the other end - at user's. This hypothetical
body and LSB are not necessarily mutually exclusive.
> 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.
Well, it does not necessarily have to be LSB who covers this - as long
as *someone* does it.
> > > A standard,
> >
> > 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?
A good start, common grounds. Really - take a look how internet
"standards" are worked out. But they will not emerge out of void,
there is central RFC database, isn't it.
> > >otherwise what's
> > > the point?
> > Interoperability.
> Which cannot be achieved if there is not a solid standard.
Not at all. Take a look how gradually MIME evolved "in", while
uuencode approach "evolved out". But someone had to actually
sit down and write at least rough guidelines in RFC.
> been disputing with is some folks idea that we should go further and
> actually standardize on a specific environment and window manager.
That would be against "unix spirit", so to speak - take various pieces
and integrate them into working solution.
Problem is, the cost of integration became too high - a number
of possible connections between n packages is n*(n-1)/2. With
low n, it's not a problem. However, take a look at sheer number
of packages in latest Debian or Slackware. Of course nobody
needs to integrate each package with each package, but
row of magnitude of this problem remains.
> 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.
No. That's Windows way: interoperability via monopole. We do not
need Windows way, but we do need something that would provide
at least acceptable cost of integrating various pieces into
working solution, something "intermediate". Your proposition
of XML as configuration means could provide it.
> 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).
It would be disastrous idea - users are more and more turned
off from "monolithic" approach. However, problem is the cost of Unix
integration. If it's too high, users will still choose suffering Windows
faults.
A basic example: Install LyX, load document, preview it. There
is "show document (ghostview)" option in File menu. But I did
not install ghostview, I installed gv. I prefer choice, so I made
choice, but now if I want to use LyX and postscript viewer I am
left with no choice but to use ghostview. That's Windows way.
Why is there not document.preview(postscript) of document
object called, with preview method being polymorphic, sending
ps into gv or ghostview depending on what is installed?
<snip>
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.
Yes. We do need Guise, preferrably object oriented. I thought about using
ILU - it can generate code in C++ and Python, it has something called ISL
(Interface Specification Language). The other method is to use XML, but I
am not expert on XML.
Marcin Krol
-----------------------------------------------------------------------------
Hiroshima 45 Tschernobyl 86 Windows 95
Reply to: