[Xpert]Re: Xpert digest, Vol 1 #2013 - 11 msgs

[Joseph Pingenot]

>From: Lukas Molzberger <[EMAIL PROTECTED]>
>(3. It should be possible to configure XFree over a dialog that is intergrated 
>in Gnome and Kde.)

I think what he means here is resizing the screen *without* going to a
  virtual screensize.  One can resize the screen via keys or via a GUI
  (e.g. wmxres), but the problem is that it's a *virtual* screen then,
  and, instead of acting like a full screen, one scrolls around on the
  larger "virtual" screen.
What would be nice is a way to have X not make the new screen res virtual,
  but actual.  :)
BTW, what Xlib calls are involved to change screen resolution?  I couldn't
  find one in the manpages, so far as I can tell.

-Joseph
-- 
[EMAIL PROTECTED]
"We're moving toward a world where all the capabilities of the Internet are
 reprocessed through a single filter, with Microsoft's business plan behind
 it."  Mozilla's Mitchell Baker, http://news.com.com/2100-1023-941926.html
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert

[Xpert]Questsions on current status and future

[Joseph Pingenot]

Hello.

I'm somewhat new to in-depth X-ness, but I've been following a usenet
  thread, and the following post came up:
[I apologize if my in-depth-newbieness shows through; please be patient :]

"I wish X11 were good enough I could resolve 2 real world problems my company
is having with it's use.

1)  Some older custom written (contractor) X11 apps served from a Big Endian
OS that pukes when Xinput can't provide a Big Endian response back from an
X86 Linux boxen.  There is no source code, and the contractor is no longer
in business.  The app has no commercial equivalent.

2)  With a fixed 60ms delay between remote sites, a Remote X11 Client/Server
application takes almost a second per mouse (xinput) selection for a
database app just for a menu response to manifest itself at the display.
The same app locally is instantaneous.  The problem is bi-directional
because X11 is non-asynchronous multiple transactions with it's X11
client/server handshaking (font, colors, geometry, xinput, menu population,
etc.).  At 60ms per handshake, it adds up to unacceptable application delay.
The solution seems to be only to access a remote Windows 2000 Terminal
Server (using ICA/RDP) that has a local proximity X11 server to the X11
application host, and deal with a single compressed stream of  ICA display
data across the WAN."

It got me thinking about X over long distances and how much it *can* be
  a pain.
I then thought of an idea: what if the widget libraries, instead of
  being local to the client, were also made available local to the server?
  That is, the client makes a request through X to load widget library
  WidgeLib, and then only asks the library to draw things through the
  X interface.  Sort of like Button(x, y, text) or whatever.  Then the
  button drawing is all local to the server, not over the link.

As an aside, what all is being done to make X work better over long
  distances?  And what is being done for native security, not only
  encryption over the link, but also for authentication?

Thanks, and I hope the ideas/questions aren't too silly.
  
-Joseph

-- 
[EMAIL PROTECTED]
"We're moving toward a world where all the capabilities of the Internet are
 reprocessed through a single filter, with Microsoft's business plan behind
 it."  Mozilla's Mitchell Baker, http://news.com.com/2100-1023-941926.html
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert