Minutes from X.Org Architecture Call for 30 August 2004

[Roland Mainz]

Keith Packard wrote:
> 
> Around 14 o'clock on Aug 30, Paul Anderson wrote:
> 
> > Keith: The vendors who don't want to be dependent upon libXp
> > need to put some resources on this so that changes to Xaw
> > related to this functionality don't necessarily depend on
> > libXp.
> >
> > (Keith will send out a note to the board further elucidating
> > some of the potential architectural possibilities he discussed.)
> 
> Ok, so the basic position is:
> 
> 1)      Xprint support is partially implemented in Xaw today
> 
> 2)      Some people prefer no Xprint dependency in Xaw
> 
> 3)      X.org plans on shipping the Xprint support for Xaw (either 6.8 or
>         later)
> 
> The current Xprint support in Xaw can be trivially split out into a
> separate library (we have a proof-of-concept today).  However, Roland
> asserts that such a split will hamper his future Xprint/Xaw plans.

One simple question:
The option of putting XawPrintShell into a seperate library has already
been _REJECTED_.
And I thought I made it clear that I am not carrying the extra wheight
of a misdesign which puts XawPrintShell into a seperate library just
because some people rant loudly against that without coming up with
valid reasons why Xprint support should NOT be part of libXaw. And a
seperate shared library just for one widget class is a waste of time and
resources - and a nightmare from the maintaince-"point of view". And it
has already been said: One such a design has been chosen there will be
NOT WAY to undo that without new pain (like breaking binary
compatibility).

So why are you now coming up with that issue again ? Was the whole phone
conference for /dev/null ? ;-(

> I suggest that Roland should be encouraged to finish up his Xaw/Xprint
> implementation using the current (Motif-derived) architecture and that
> parties interested in ensuring that Xaw not depend on Xprint would be
> responsible for finding a way to make that work which isn't (too)
> objectionable to Roland.
> 
> This places the burden for removing Xprint dependencies from Xaw on the
> people interested in seeing that happen instead of on the people adding
> Xprint capabilities to Xaw.
> 
> However, it places a responsibility on the Xaw/Xprint enthusiasts to review
> the proposed split architecture without prejudice.  We accept that Motif
> didn't do things this way, but there shouldn't be any reason it "cannot"
> work given that Xaw was designed with strong separation between widgets,
> unlike the Motif toolkit where widgets are very tightly interdependent.

In libXaw the widgets tightly depend on each other, too. Moreover: In
all the history of the Athena widget sets the core Athena widgets were
kept together in the libXaw library and noone ever thought to modularise
the library into one-shared-library-per-widget-class.

> For example, the circular dependencies discussed in the arch call today
> could be eliminated by having Xaw expose a function which XawXp would call
> to 'register' the printer widget class record; by default, that would be
> 'null', but the printer shell class widget initialization procedure would
> call the Xaw function from which all Xaw widgets would be able to discover
> whether their parent was a 'print shell' widget.

That makes it mandatory that the register function MUST always be called
before libXaw widgets are used. Quite difficult in the case of
subclasses or similar stuff.

> Alternatively, the parent widget could simply expose a value which could be
> detected by underlying widgets via XtGetValues.  We could even create an
> Xaw helper function to return this value.

... and how should this properly work when someone creates a subclass ?

libXaw was always and will always an all-in-one library. Why should be
there an exception ? Your proposal completly ruins the design and makes
it far more compliciated - at some point the print support will be
unuseable (some people think your are on the best way to ensure that
noone can really use the code =:-) - or better: No longer understandable
because of the mis-designed attempt to keep Xprint support out of the
library with all force.

Keith:
I really doubt that you would complain about a new library dependicy if
someone would add libXft support in the libXaw - or something which uses
the RENDER extension.

> These represent off-the-cuff solutions for one of the stated problems, and
> not a reasoned architecture (which isn't possible, given the lack of a
> complete Xaw/Xprint implementation).  I suggest that any other issues
> discovered in the complete Xaw/Xprint implementation could be resolved in
> similar fashion.
> 
> Again, with X.org support for the Xprint standard, it seems incumbant on
> those interested in supporting systems without Xprint to propose solutions
> which yield that result.

The number of people who do not WANT Xprint due political reasons can be
counted here with one hand.
And we are NOT talking about Xprint in general: We are talking about
building libXp.so, a shared library which is build by DEFAULT in the
Xorg releases since 1994 and mandatory for todays systems. Please STOP
mixing things. Sometimes I have the feeling that debating with you is
like talking against a wall (which has quite good rhetorical talents...
:) ... ;-(

----

Bye,
Roland

-- 
  __ .  . __
 (o.\ \/ /.o) roland.mainz at nrubsig.org
  \__\/\/__/  MPEG specialist, C&&JAVA&&Sun&&Unix programmer
  /O /==\ O\  TEL +49 641 7950090
 (;O/ \/ \O;)