On Tue, 09.11.10 23:14, Miloslav TrmaÄ (mitr@xxxxxxxx) wrote: > Lennart Poettering pÃÅe v Ãt 09. 11. 2010 v 23:07 +0100: > > I think you aren't even aware how broken this "mix and match" network > > approach of classic X11 is. The semantics of D-Bus and other IPCs in a > > distributed X11 session has never been clearly defined, and all kinds of > > integration between apps mostly just vanishes if you do this, or will > > behave weirdly. > Well, isn't that mostly the fault of D-Bus, GConf and other relatively > recent inventions that they decided to ignore this use case of running > desktop applications? In the far past, IPC mechanisms somehow managed > to cooperate with X (e.g. ICCCM, XSettings) - admittedly with > lower-level functionality. > > (The decision to ignore remote applications may have been correct - > that's beside the point: You really can't blame X for things D-Bus/GConf > didn't do; and the fundamental semantic problem of "should this setting > refer to the machine this process runs or to the machine it is > displayed" does not ever go away simply by changing the remote > communication protocol.) 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@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
