Re: WM SPec purpose (was: Re: wms offsetting XMoveWindow() coords)

[Nathan Clemons <nathan windsofstorm net>]

On Wed, 29 Sep 1999, Paul Warren wrote:

> On Wed, 29 Sep 1999, Tim Janik wrote:
> > On Mon, 27 Sep 1999, Nathan Clemons wrote:
> 
> > i think part of the problem you outlined is due to people (me included) being
> > lazy in structuring replies on the spec. it'd be nice if the Subject: lines
> > would identify the _NET_* properties in question, and if several replies would
> > be formed from a draft for different issues (e.g. properties being discussed).
> 
> I think that this is a very good point.  Sensible trimming and
> re-subjecting would help things a lot.
> 
> > overly complexify window manager implementations (e.g. basing it on
> > CORBA) and introduce new dependancies for them (be that MICO or ORBit,
> > one side will definitely be unhappy, not to mention third party app writers).
> 
> I think that the decision to use CORBA or hints should be a purely
> technical one.  I believe that a very important role of this spec is to
> improve the overall feel of Desktop Environments.  If CORBA offers
> significant technical advantages over hints, then we should consider it.
> Does it?
> 

We have two contradictory considerations here: technically superior
ideology and acceptance. If it is technically superior but is not
accepted, then this spec has _failed_. If it is accepted but is not as
technically well-done as it could be, we have gathered people under a
banner that can later have revisions incorporated into it. Most window
managers do not include CORBA, and we should not assume that any window
manager authors want to support it. As the case is, as good as CORBA may
be, I don't see but very few of the people on this list advocating it, and
several of the authors decrying it's use.

Frankly, I don't think CORBA is an acceptable option to the populace. WM
Authors only may correct me if they feel otherwise. We don't need to
convince either GNOME or KDE, we need to convince the WM authors, and in
my opinion that is (*at least currently*) a lost battle.

> > as far as window manager customization goes, specification of an all-doing
> > protocol that would allow an application provided GUI (e.g. a GNOME capplet)
> > to control all of a wm's behaviour aspects and configuration, is definitely
> > beyond the scope of this spec.
> > we'll get nowhere discussing this all over again, and the protocol would
> > never cover all wms' requirements. if people insist on such a thing, they
> > are better off starting a new spec project for that purpose only and not
> > holding off production of this one.
> 
> If you are refering to what I suggested some time ago on this list, then I
> think you missed my point.  An all-doing protocol controlling all aspects
> of a WM's behaviour is clearly ridiculous - it removes all the advantages
> of being able to choose your own Window Manager as all wms' features must
> be a subset of the features defined in such a protocol.
> 
> All I am saying is that we should define how a fully compliant window
> manager should present its configuration utility.  Should it provide
> capplets for configuration?  Or, if it is providing its own configuration
> tool, how does it tell Gnome/KDE what this tool is, so that when you hit
> "run config tool for this WM" it Just Works.  IMHO this should Definitely
> be in the spec.  If we don't address this, then all we have done is
> rehashed the existing hints into something less broken, rather than
> addressing the bigger picture of making Window Managers integrate well
> with desktop environments.
> 
> yours,
> 
> Paul
> 

In my opinion, and I do not necessarily feel the spec should cover this, I
still believe we should have something along the lines of a GNOME .desktop
file for WM's that specify the name of the WM, the wm executeable (with
full path), the current version, compliancy to the spec, and the wm config
executeable (with full path, or NONE). If the WM authors do not adopt
this, someone else can _VERY_ easily create this themselves, and perhaps
even include it in the RPM's, etc.

--Nathan

-------------------------------------------------------------------------
Nathan P. Clemons                       "Peace favor your code."
nathan@windsofstorm.net                 ICQ: 2810688
IN CONSTRUCTION:                        http://gnome.windsofstorm.net
-------------------------------------------------------------------------