On Fri, Apr 3, 2009 at 7:53 AM, Brian J. Murrell <[email protected]> wrote: > I hope you accept this in the constructive nature that I'm sending it > in. I'm only sending because I hope it help you understand a possible > use case and see if Xpra can or wants to fulfil it.
Sure. Xpra scratches an itch for me, and hopefully for other people too. But I won't be offended if you have different itches :-). > Audio from my laptop came to my desktop machine via the magic of > pulseaudio because applications on the laptop linked with the pulseaudio > libraries would read a value out of their X "root window" to find out > which pulseaudio server to connect to. Really? Wow. We could support this somehow I'm sure, though it's not obvious to me what the best way is. With some work, we could spawn a pulseaudio server along with Xvfb, then capture the audio sent to it and forward it over the xpra connection. This would be reliable, would take a fair amount of magic, and might not end up with very smooth playback if the audio data is fighting with window redraws on the network connection. With not much work at all, we could drop a similar root window property into the Xvfb when we connect, but that would only work on local networks where the apps can make a direct connection out-of-band to the client's pulseaudio server. (But it would use pulseaudio's network code, which is surely better suited to audio than xpra's.) > Also, magically (and I'm not sure how TBH) all of my desktop theme > settings applied to the applications running on the laptop when > displayed on my desktop. GTK+ does some sort of magic with root window properties too, like pulseaudio, that I don't entirely understand. I would be happy to have the client just send those over when it connects (I would love this feature myself); it just needs someone to figure out what weird undocumented mechanism GTK+ is using to do this. (I assume you're using GTK+. If not, then apparently whatever toolkit you're using has the same feature, and the same comments apply, it's just that I already know GTK+ does this.) > With xpra I lose much of this. I lose the pulseaudio magic as well as > the themeing magic, as well as the ssh agent forwarding. ssh agent forwarding is tough -- by design, when you disconnect, the agent forwarding goes away. So any apps that persist over disconnections would need some way to reconnect to the new agent when you reconnect. The solution would probably be to write a proxying ssh agent, just like xpra proxies the X connection. This is actually less work than one might think (the ssh agent protocol is very simple, and allows for all kinds of cool hacks), but making the UI simple is tough -- xpra could arrange for any programs *it spawns* to have access to the special proxying agent, but it has no control over programs you start directly with 'foo --display :100'. > As much as I love the persistence aspect of Xpra, losing the seamless > integration of the applications from my laptop to the services on my > desktop is just not going to work for me. > > Any thots on all of this? Is Xpra just not going to fit the bill for me > (ever)? We can write code to do whatever we want. It's just a question of going through different features and doing some work for each of them, and finding the time/manpower to do it. -- Nathaniel _______________________________________________ Parti-discuss mailing list [email protected] http://lists.partiwm.org/cgi-bin/mailman/listinfo/parti-discuss
