Minutes from X.Org Architecture Call for 30 August 2004
keithp at keithp.com
Tue Aug 31 10:46:55 PDT 2004
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
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
> 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
> 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, XtNisPrintShell, &isPrint);
XtGetValues (shell, args, 1);
and you will know whether the shell is a print shell or some sub-class of
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
> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 228 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/release-wranglers/attachments/20040831/511214bc/attachment.pgp
More information about the release-wranglers