Minutes from X.Org Architecture Call for 30 August 2004

[Keith Packard]

Around 16 o'clock on Aug 31, Roland Mainz wrote:

> One simple question: The option of putting XawPrintShell into a seperate
> library has already been _REJECTED_.

Yes, I know you are strongly opposed to such an architecture, but I still 
haven't seen anything but rhetoric in support of that position.  I assert 
that we will be able to find a clean and straightforward way to split out 
this functionality into a separate library.  I further suggested that the 
burden of proof here lie not on you, but on those interested in such a 
split.  With two implmentations in hand, we will be able to work together 
to choose the best implementation that solves both the technical problems 
and the political problems.

> 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).

The same is true of changing the major library version number; we will 
have on-going support issues for the forseeable future.  The question is 
which solution will cause less trouble down the road.  I believe that a 
system which provides for a single library for each bit of code is better 
than a solution which duplicates all of the existing Xaw code in two 
libraries.

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

I think we all understand your position in this matter, and I want you to 
know that I will not railroad my own ideas through the X.org release 
process.  Given your strong objections to this architecture, I expect 
we'll need a credible implementation that satisfies your goals along with 
those of the rest of the community.

However, I am as opposed to adding libXp dependency to Xaw as you are to
splitting the functionality into a separate library.  I suggest that we
must present working implementations of both architectures to the community
and see which one gains favor.  Simple assertions by either of us are
not sufficient.

> 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.

This is incorrect.  The Athena widget set used to include the Clock,
Mailbox and Logo widgets.  Those were pulled out of the library and placed
into the applications which used them.

I've created libraries of add-on widgets that interoperate with the Xaw
library myself including an interesting Geometry manager (Layout). One of
the goals of the Xt design was that widgets from different libraries could
be successfully mixed together in a single application.

That Motif couldn't manage to work well with Xaw wasn't Xaw's fault, but
rather a reflection of some extremely poor design practices in Motif which I
would really rather not see replicated in Xaw at this point.  The Xprint 
architecture in Motif represents yet another in a long sequence of 
abstraction-breaking data-revealing headaches.

> > 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 ?

The parent Initialize method would set the value in its instance record
so that the correct value would be reflected to applications.  The key is 
that XtGetValues is *defined* to leave values which aren't present in the 
widget class (or ancestors) unchanged, so you need only do:

	isPrint = False;
	XtSetArg (args[0], XtNisPrintShell, &isPrint);
	XtGetValues (shell, args, 1);

and you will know whether the shell is a print shell or some sub-class of 
print shell.

I don't doubt that there could be some problems in translating some of 
your grand plans into similar terms.  We can only know that when we see 
the code.

> 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.

This is precisely why there isn't Xft or Render support in Xt or Xaw at the 
present time.  Instead, each sample application which uses either of these 
libraries was changed to directly access the appropriate functionality so 
that the existing libraries could remain unchanged.  Xt (in particular) is 
considered to be a legacy library by many linux distributions, included 
almost entirely because Mozilla specified its original plugin architecture 
to use it.  Changes to libraries of this age should be done with extreme 
care and respect to the hundreds of ancient and unrepairable applications 
which use them.

> The number of people who do not WANT Xprint due political reasons can be
> counted here with one hand.

The total number of people engaged in this debate is small, but each is 
representing views and aspirations of a much larger community.  Please 
don't write us off as the lunatic fringe; some of us have rather a lot of 
history with this particular issue.

> 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.

The same status was afforded both XIE and PEX for a long time, but is no
longer true as those systems never gained widespread support.  In fact,
Mozilla was linked against XIE for the longest time, causing vendors to
ship that library even though the functionality could never be used.  

That's what we're trying to avoid here -- an artificial dependency for 
functionality which will never be used and which we plan on replacing in 
the near 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/20040831/511214bc/attachment.pgp