That's true, using freenx to access a whole desktop works well with xfce and no sound. I can't imagine it working so well if trying to run gnome-shell, sound etc remotely.
I get the impression a lot of the current desktop infrastructure doesn't make sense when accessed remotely, eg if I ssh'ed into a machine what could I usefully do with nm-applet or a lot of other desktop infrastructure? A lot of the desktop is already beyond the reach of X. On 9 Nov 2010 22:26, "Lennart Poettering" <mzerq...@0pointer.de> wrote: On Tue, 09.11.10 23:14, Miloslav Trmač (m...@volny.cz) wrote: > Lennart Poettering píše v Út 09. 11... Oh, of course you can blame X for that. There's simply no sane way how to get a "parallel" connection for D-Bus/GConf/ICE/PA/whatever to the main X11 display connection. Something like that has been tried a number of times, but in some way or the other it just failed in the end. It's a can of worms. Really, for example in the GConf case I know that Havoc spent quite some time to design the IPC so that it could be used alongside X11 on the network, but eventually gave up on it. I think it is fundamentally wrong to ask us to support setups where you might or might not share $HOME, might or might not share the D-Bus session bus, might or might not share the D-Bus system bus, might or might not share PA, might or might not share GConf, might or might not share X11 displays, in all combinations over the network at all times. Complete flexibility like that is not only impossible to manage or test, but also inherently slow. For example: if you say the D-Bus bus should be shared across the network, but $HOME shouldn't, then applications could not refer to files anymore in the bus protocols, which would basically require them to pipe everything through a bus, which is a textbook example how to make things slow. Of course, it's easy to assume that all the building blocks we build our desktop off would be completely independent black boxes, but turns they aren't, and are deeply integrated these days. The pixel-scraping approach is the only thing that in the end makes sense, since you have a very clear idea of what you share, and what you don't share, and what you share is only at the very very end of what you do, i.e. the last step of presentation of the app to the user. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/de...
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel