Re: X11-2.1.1-pre1.pkg
Re: X11-2.1.1-pre1.pkg
- Subject: Re: X11-2.1.1-pre1.pkg
- From: Rachel Greenham <email@hidden>
- Date: Tue, 11 Dec 2007 20:40:35 +0000
Jeremy Huddleston wrote:
I have put together a new package. Would people please test it out
and give feedback on it.
re: XDMCP...
Xquartz -query works now - used to just exit on login for me. But the
manner in which it works now might illustrate why it used to have a
problem. I have two monitors, and the new desktop opened up covering
both monitors. Which wasn't quite what I wanted.
Then I tried to use Spaces to move it to another desktop... and
increased my understanding of what Xquartz is, as the desktop moved but
the gnome panel remained behind on desktop 1!
(Yes I get it now, I was just a little slow at first. :-) It also
explains the desktop-stretched-across-two-monitors of course.)
So to Xephyr... which *almost* works. It *does* work, but:
I get the default X mouse cursor overlying the proper mouse cursors as
defined on the remote host. The whole time.
With -fullscreen, again on a two-monitor setup, the window opens filling
both screens with one stretched-out desktop. In case I didn't state this
clearly enough when I last reported that this was happening:
THIS IS NOT GOOD.
It's ugly and unusable. It's understandable for Xquartz, by the nature
of what it is, and what it does; but Xephyr runs in a window; it should
be possible to set that window up with sensible default fullscreen
behaviour in the Mac environment if the -fullscreen commandline option
is given. If any other Mac application has a fullscreen option, eg:
itunes, quicktime, other movie players, they're smart enough not to
stretch the picture across both screens. Can't Xephyr be the same?
We could really do with a way of saying, "open for just one screen" -
maybe a little dialog like the Quicktime Pro Present Movie dialog when
you have multiple screens, to select which screen to open, and fill the
screen, on. Or even just a big X and a message along the lines of "click
to select screen for fullscreen mode". If the user chooses the primary
display, 'fullscreen' should presumably continue to exclude the menubar
area, but if they choose any other display it obviously should not and
should be actually full screen.
Or there's -screen, but can that be combined with -fullscreen? Not
really, what you get if you give, say, -fullscreen -screen 1680x1050 is
the window opening at 0,0 (top-left of the main screen, which on my
setup is the one on the *right*), but still being both-screens wide, as
is the remote desktop size. So in my example, the window extends a whole
screensize off to the right of my rightmost monitor.
Basically, support for macs with multiple displays is really quite
broken! :-) God knows what would happen if the screens were different
sizes - which as we know OS X itself is entirely happy about. User
*expectation* for Xephyr -fullscreen is surely that it will fill *one*
screen? (It was mine anyway.) Alternatively (and probably more clever
than I really want), it could open a window each for each screen, and
arrange the remote desktop xinerama multiple screen accordingly. That's
probably really hard though, and of course depends on the remote system
being xinerama-aware, and it's not even what I want; just want *one*
screen filled. That would be the logical default. :-)
Also, with -fullscreen could we lose the window title bar yet? We can
still move the window with exposé/spaces, but assuming the above issues
are fixed and we get a -fullscreen that behaves on a multi-display mac,
it would be nice if it could actually be fullscreen. The Aqua window
furniture isn't necessary in that instance. (I think Xephyr -fullscreen
on linux loses its titlebar and window furniture, so it's definitely
going to be part of user expectations.)
One more thing. :-) Xephyr homepage says:
"Unlike Xnest it supports modern X extensions ( even if host server
doesn't ) such as Composite, Damage, randr etc (no GLX support now)."
xdpyinfo in the remote machine logged in using xephyr does not report it
has the COMPOSITE extension. DAMAGE is there though, and RANDR, and in
fact so is GLX despite the above quote. (glxgears fails though, with
"Error: Couldn't get an RGB, Double-buffered visual".)
But no Composite. This is more of a wishlist item, but one day Compiz
Fusion should work through this, right? :-D
It's quite funky at the moment dragging a slightly-transparent
gnome-terminal around the linux desktop and the way the backdrop behind
it lags like it's being lensed, but I suspect it's not deliberate (and
only noticeable as I'm using it over wifi right now. Normal use would be
through gigabit.
It's getting there though, isn't it? :-)
--
Rachel
_______________________________________________
Do not post admin requests to the list. They will be ignored.
X11-users mailing list (email@hidden)
This email sent to email@hidden