Minutes from X.Org Architecture Call for 30 August 2004

[Keith Packard]

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.

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.

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.  

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.  

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.  It would then be the responsibility of those 
interested in supporting Xprint to review the proposed changes and help 
resolve issues (both present and future).

-keith


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/release-wranglers/attachments/20040830/3bf05f2f/attachment.pgp