It is bad, because X's "virtual" window concept is a very convenient
way of doing things, and because the decision to chop pixel
coordinates to 16 bits is completely arbitrary -- Xlib in fact allows
you to pass in 32 bits, but this gets truncated to 16 bits by the time
the server gets it. It's just plain silly that it's not 32 bits all
the way through.
> > Mosaic does, which is lay out as much text as possible in the window
> > and then give you convenient automatic inlined hyperlinks to the
> > remainder of the text, partitioned into window-sized chunks. Then
> > tell me who's making fatally flawed decisions.
>
> Hmmmh, no offence, but I think that's not not the correct way to
> solve the problem.
I agree that ideally we should be doing the scrolling ourselves, but
like I said, that has a number of concomitant effects that we're not
willing to accept right now.
> Btw, have the current x-clients implemented non-blocking transfers?
> It should be implemented in the common code, maybe it already is.
> It's really too bad that we don't have the time to support erwise
> (three of us are working almost full time at a software company, and
> try to get on with our studies as well). Maybe in the summer ...
I sure would like to have non-blocking I/O... I have looked at the
Erwise code for this, and am thinking about stealing a lot of your
changes, but haven't had time yet......
Cheers,
Marc
-- Marc Andreessen Software Development Group National Center for Supercomputing Applications marca@ncsa.uiuc.edu