Minutes from X.Org Architecture Call for 30 August 2004

[Roland Mainz]

Keith Packard 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 and others in the Xorg arch phone conference did list more than one
non-rhethorical reason why this should be avoided. But it seems that you
are simply ignoring that part and stamp even those technical issues as
"rhetorics". Oh well... ;-(

> I assert
> that we will be able to find a clean and straightforward way to split out
> this functionality into a separate library. 

This may be your plan for that but I am NOT going to support that. I
hoped I made that CLEAR in the phone conference.
And I explicitly said that the choices for the Xorg arch board election
should NOT include this option. *POINT*

[snip]
> > 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.

Splitting off the XawPrintShell causes more trouble than you are
claiming here. Did you ever thought the consequences to the end,
including functionality like print preview etc. ? Your comments indicate
that you didn't do that yet...

And: If XawPrintShell gets moved to a seperate library then I am going
to DEMAND that the same should be done with the parts of libXaw which
depend on the SHAPE extension. Same rules, same consequences for all -
as you said. I am now taking you by your own words.

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

The only objections are coming from your position, with a little bit
support from Redhat staff.

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

Invalid argument.
These are application-specific widget classes, no core widget classes.
See below.

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

"printing" is a _core_ application functionality and belongs to the
_core_ Athena widget library (=libXaw.so) and _nowhere_ else. The widget
classes you have listed above are mainly application-specific classes
and have nothing to do with core functionality like printing. Any plan
to split off the print widgets contradicts the idea of making printing
easier - you are turning that idea ad adsurdum via making the print API
in libXaw very painfull to use.

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

Again, the Motif desingers tread printing as _mandatory_ core
application feature Otherwise the XmPrintShell would sit in
libDtWidget.so (CDE's core widgets) where it obviously doesn't reside.
It's an important design choice and NOT a "poor design practice". Yes,
parts of Motif are _UGLY_ but this parts isn't the one of them.

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

Umpf... that design fails when the print shell is being used in print
preview mode. The other core widgets need a Xt widget class pointer.
That's a requirement. Sure, we can call |dlsym()| for that but I am not
sure whether all platforms really support that...

BTW: We are talking about a "Sample Implementation". Why has a sample
implementation that compliciated ?

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

It wasn't Mozilla. It was NS4.x's plugin architecture which was
reimplemented into Mozilla. And we are talking about libXaw.so and NOT
libXt.so. And we are also NOT talking about making the whole tree depend
on Xprint - we are talking ONLY talking about making libXaw.so depend on
libXp.so, one of the smallest X11 extension libraries around.

In the bump from libXaw.so.6 to libXaw.so.7 the Athena widget library
was made depend on the SHAPE extension parts in the libXext.so library.
And now we are in the progress to make it depend on libXp.so (for the
logical consequence of adding printing support to libXaw.so) - which is
NOT differently from the issue with the SHAPE extension.

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

Right. But the last changes to libXaw.so are only one year old - and
therefore this argumentation really does not apply to libXaw.so.

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

Having a history of what particular issue ? Xprint, libXp.so or turning
the Xorg Foundation into the Keith-Packard-one-man-show ? =:-)

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

You are talking about PEX and XIE which are really dead since a long
time. But Xprint isn't. And Xprint will be around for many many years,
regardless whether you like it or not. And permanenetly annoucing it's
"death" in your various talks won't change that either.

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

Replaced by WHAT ? By CAIRO ? Well, then you can only be kidding since
the current design of CAIRO doesn't seem to have learned the mistakes of
the past. It's printing code still uses the 20year old design of being
an unidirectional wrapper for PostScript code (and PDF, too). Please
read my reply to Owen Taylor in this thread before making such
"annoucements" (which won't be approved by the Xorg arch board in the
forseeable either).
And: Xprint will VERY likely be around in the next 10+ years.

----

Bye,
Roland

P.S.: Keith, you said in the Xorg arch phone call that java doesn't
depend on libXp.so - somehow the reality looks differently (same applies
to Sun's version of java):
-- snip --
% ldd /usr/lib/BlackdownJava2-1.4.1/jre/lib/i386/libawt.so
    libmlib_image.so => not found
    libjvm.so => not found
    libXp.so.6 => /usr/X11R6/lib/libXp.so.6 (0x40276000)
    libXt.so.6 => /usr/X11R6/lib/libXt.so.6 (0x4027e000)
    libSM.so.6 => /usr/X11R6/lib/libSM.so.6 (0x402d2000)
    libICE.so.6 => /usr/X11R6/lib/libICE.so.6 (0x402db000)
    libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x402f2000)
    libXtst.so.6 => /usr/X11R6/lib/libXtst.so.6 (0x40302000)
    libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x40308000)
    libm.so.6 => /lib/libm.so.6 (0x403d6000)
    libdl.so.2 => /lib/libdl.so.2 (0x403f8000)
    libjava.so => not found
    libc.so.6 => /lib/libc.so.6 (0x403fb000)
    libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x40532000)
    /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)
-- snip --

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