Official protest against bug 1060 / was: Re: Away forafewdays...

[Roland Mainz]

Jim Gettys wrote:
> > > Some of us work on footprint sensitive devices where adding
> > > more code isn't a viable option. (nor do we have printers anywhere
> > > nearby our iPAQ's).
> >
> > Erm... remember that the server side of Xprint is just a simple Xserver
> > ?
> 
> Which I don't have space for.

Umpf. The Xprt server runs _remotely_. On the print server. You likely
don't plug the printer directly into your PDA, do you ?

> > Two years ago we demonstrated at the University Giessen that Xprint is
> > VERY well suited for PDAs since all memory intensive stuff is done on
> > the server side - which can be accessed via _remote_ X11 on a seperate
> > machine.
> 
> Doesn't help my user base: neither Qt (Opie) or GTK+ (GPE) are
> Xt based.

1. So why are you suddenly worrying about the detail that libXaw depends
on libXp ? Somehow your argumentation is not logical nor is it
consistent.
2. Xprint support for Qt is under development. And you forgot Mozilla.
And Eclipse. And StarOffice. And all applications based on Motif and
LessTif. Just to name a few applications which support Xprint.

> > > I personally don't want to have to have an Xmu/Xmuu situation
> > > have to develop for the library, to avoid picking up the depencency,
> > > to recover space we literally don't have.
> >
> > We are talking about less than 25KB of code on x86, on ARM Thumb it's
> > even smaller. There are bigger things to complain about than a
> > self-contained X11 extension library which has no other dependicies than
> > libc, libX11 and libXext (which are always loaded anyway).
> > And libXp.so is likely loaded anyway by other applications, too. You are
> > worrying about the wrong things. Or at least about the wrong library:
> > Between X11R6.0 and X11R6.7 libX11 grew by a few _hundred_ kilobytes.
> > libXp.so is only a fraction of one _hundred_ kilobyte.
> 
> Yes, and I've managed to get much of that bloat back out; some of those
> changes are in the modular tree, so you may not have been aware
> of them.

Yes... likely... but it doesn't change the fact that there is lots of
stuff which could be "done" to save more code in libX11 than even a few
dozend copies of libXp.so could waste.
Hint: Did you ever thought to compile with gcc's "-Os" switch instead of
"-O2" on Linux to save code space ? Even that little compiler switch
saves more code in libX11 than the whole libXp.so library wastes in
memory.

> The question in this case, is where the burden of effort
> should lie. You do make the case it is much smaller than I realized.

I am still wondering why people are making such a giant noise about that
little extension library. We are talking about a X11 client side
extension library which is one of the smaller ones. Did anyone complain
about the size of the RENDER client side extension library yet ?

> (BTW, strongarm doesn't have thumb, so given my current build
> environment, that doesn't help, unfortunately).

I was only listing an example. Sure, plain ARM code is bigger but the
difference is not THAT big.

> > > So some of us would have to do additional work to remove the
> > > dependency; I believe that it is incumbent on you, the person adding
> > > functionality, to make it possible to build without the requirement
> > > of picking up the dependency.
> >
> > What about turning off the building of libXaw-based applications then ?
> 
> With it packaged into Xaw, if a user loads any such application,
> they are forced into the dependency, a dependency that no-one was
> unfortunately aware of until you were unavailable. 

I annouced that change in all places which I could imagine about. I
can't really do anything when noone reads the emails, newsgroup postings
and IRC comments.

> This means that
> any/all existing applications pick up the dependency if that
> widget is added to the library.
> 
> The bigger issue than size, or modularity, or whether we should be
> maintaining Xt based clients in our code base, or any of the
> other reasons is that there is *no* community consensus around
> Xprint.

1. Erm... hint: There are lots of people working actively on Xprint.
Just an example: I did not wrote XawPrintShell, I only did the testing,
collected the review comments and committed it to the tree.
2. If such a consens is required I suggest to BACK OUT lots of stuff
which was added between X11R6.6 and Xfree86V4.4.0RC1. Many changes and
dependicies were silently added without any complains.
3. I already that that the development on libXaw should be continued. At
least I and a few others are very interested in that. And it doesn't
sound like OpenSource if people are not allowed to enhance the code.

> Lacking this consensus, making it required
> would be a mistake.

libXp.so is already REQUIRED by external(=not in the Xorg tree)
applications. You cannot make a Unix/Linux distribution without it. And
these libraries and applications which depend on libXp.so will be likely
used for the next twenty years. Or even forever.

> Many people have strong opinions that
> it is the wrong long term way to go. (myself included, to be
> completely frank).

AGAIN: What is the problem with adding a dependicy to a self-contained,
very small X11 extension library which only depends on libX11, libXext
and libc. Even if the future shows that Xprint was the "wrong way" it is
HARD to belive that building libXp.so will cause problems.

Please explain which problem do you see with BUILDING libXp.so in the
future. 

> The fact that neither GTK+ nor Qt have
> adopted it makes clear the lack of consensus.

See my comments above about Qt (and I also listed a bunch of other
applications which support it). GTK+ never got Xprint support since
since authors thought "... that GnomePrint will rule the world and
evaporate any other print API..." (funny.... last thing I heared was
that the GnomePrint rendering API is now be depreciated... =:-) ...

> We *also* have strong opinions that people should be able to get their
> code out, so that (eventually) competition in open source can make
> clear which way things should go.
> So we *really* do want to see your
> work on Xprint available, and appreciate the hard work you have
> put in on it to make it viable, which it has not been in the past.
> 
> So we are open to any solution (and held open the bugzilla bug
> to enable do so even to the last possible moment, on the hope
> you might become available), in which Xprint is
> optional.  Making the toolkit widget a separate library has
> that property. In your previous mail you said this won't work,
> care to explain why?  Is there something that we, without
> understanding Xprint intimately as you do, are missing?

Xaw widgets needs to know about pagination. And they need to know about
things like "cursors" (just one example from Motif: The text widget
cursor should really not BLINK when the widget gets printed.). The
behaviour of the widgets need to know whether they operate within a
print shell context. Right now there is no such dependicy between the
XawPrintShell widget and the other widgets - but when the other widgets
gets enhanched they need context information from each other. Having
XawPrintShell within a seperate library will make it at least difficult
- or simply impossible.

And: Jim - you are so concerned about memory consumption... are you
actually AWARE putting XawPrintShell into a seperate shared library will
even WASTE more memory than neccesary ? Depending on the OS page size
you are wasting LOTS of memory (you need more memory pages and you need
extra heap space for the shared library context data) than having
XawPrintShell within libXaw.so ...

----

Bye,
Roland

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