Re: [Xpert]XFIXES extension proposal
Around 16 o'clock on Dec 6, Juliusz Chroboczek wrote: > Thanks. The performance issue is clear. What's the semantics problem? One obvious issue is that transfering selection owner would allow only a single application to track the selection contents. Another involves targets with side effects (DELETE, INSERT_SELECTION and INSERT_PROPERTY). These couldn't be correctly executed by a secondary agent. A third is that the external agent would have to understand the data format and content of every possible selection target to avoid losing the format of interest between two clients. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]XFIXES extension proposal
KP> PRIMARY semantics don't really permit that, and it's a large performance KP> problem for some selection types (ever done cut&paste in the gimp?); to KP> fully support selection content, you'd have to fetch every possible KP> representation of the data and store it in a separate agent. Thanks. The performance issue is clear. What's the semantics problem? Juliusz ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]XFIXES extension proposal
Around 21 o'clock on Dec 3, Juliusz Chroboczek wrote: > Why can't klipper take the ownership of the selection, as xclipboard > does ? PRIMARY semantics don't really permit that, and it's a large performance problem for some selection types (ever done cut&paste in the gimp?); to fully support selection content, you'd have to fetch every possible representation of the data and store it in a separate agent. Also, 'klipper' doesn't generally advertise PRIMARY; one of it's many uses is as a passive "assistant" where it monitors the contents of PRIMARY and suggestions actions based on them -- select 'http://...' and klipper offers to launch mozilla for you. For that operation, it just wants the contents in text form, but prefers to leave the actual selection resident in the original application. Remember that one of the chief benefits of selections is that the data doesn't actually get transfered through the X server until it's requested, so applications are free to advertise selections for things which will probably not ever be copied to another client. > (I'm not arguing against this extension, as I think that making > client-visible state changes observable is a Good Thing. Just idle > curiosity.) I've struggled with the current protocol for 15 years without this notification; there's no doubt in my mind that it's a good idea. I'm not the originator here either, although I'm a bit fuzzy as to whether it was Havoc Pennington or Owen Talyor that suggested it a couple of weeks ago. One of the problems of doing design meetings via IRC is that you don't automatically get a permanent record. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]XFIXES extension proposal
KP> Applications like the KDE 'klipper' monitor selection contents to save KP> them and also perform actions based on them. Right now, this happens by KP> having these clients contantly polling the selection. Why can't klipper take the ownership of the selection, as xclipboard does ? (I'm not arguing against this extension, as I think that making client-visible state changes observable is a Good Thing. Just idle curiosity.) Juliusz ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]XFIXES extension proposal
On Sun, Dec 01, 2002 at 10:04:40PM -0800, Keith Packard wrote: > Around 21 o'clock on Dec 1, [EMAIL PROTECTED] wrote: > > > No joy. :-( Poking around in xc/lib/Imakefile, I saw a conditional > > with BuildXFixesLibrary, so I added " #define BuildXFixesLibrary No" > > to config/cf/host.def and tried "make World" again. Still no joy, > > but the breakage is slightly different: > > $ rm xmakefile > $ make World Ah, I see. Thanks. Is this something I would have known if I knew more about the innards of imake? > should fix things. You'll want to leave Xfixes disabled; it won't be > included in XFree86 4.3 as it really isn't ready yet. Okay. I understand that CVS is you-pays-your-money-and-takes-your-chances grade software, though, so I'm prepared to be a crash test dummy. I've got a working 4.2.1 installation around here somewhere if I need it. In any event, thanks again for the tip. K -- "It's kind of fun to do the impossible." -- Walt Disney ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]XFIXES extension proposal
Around 21 o'clock on Dec 1, [EMAIL PROTECTED] wrote: > No joy. :-( Poking around in xc/lib/Imakefile, I saw a conditional > with BuildXFixesLibrary, so I added " #define BuildXFixesLibrary No" > to config/cf/host.def and tried "make World" again. Still no joy, > but the breakage is slightly different: $ rm xmakefile $ make World should fix things. You'll want to leave Xfixes disabled; it won't be included in XFree86 4.3 as it really isn't ready yet. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]XFIXES extension proposal
On Sat, Nov 30, 2002 at 07:29:12PM -0800, Keith Packard wrote: > We've been working around various problems with the core X protocol for > about 15 years now. I think it's time to build an extension that includes > small changes that fix big problems. Cool. [...] > I've stuck these features into a new XFIXES extension and included that in > XFree86 CVS so that others might see the code and specification and test > whether they solve the issues they're supposed to. This does not represent > any endorsement by the XFree86 project or it's members (other than me), nor > any assurance that the extension will be included in future XFree86 > releases. I updated CVS tonight (1 December 2002, about 01:00:00 UTC). "make World" says: [...] cleaning in lib/Xfixes... make: Entering an unknown directory make: *** Xfixes: No such file or directory. Stop. make: Leaving an unknown directory make[2]: *** [clean] Error 2 make[2]: Leaving directory `/home/kwall/X/cvs/build/lib' make[1]: *** [clean] Error 2 make[1]: Leaving directory `/home/kwall/X/cvs/build' make: *** [World] Error 2 No joy. :-( Poking around in xc/lib/Imakefile, I saw a conditional with BuildXFixesLibrary, so I added " #define BuildXFixesLibrary No" to config/cf/host.def and tried "make World" again. Still no joy, but the breakage is slightly different: $ make World [...] cleaning in programs/Xserver/xfixes... make: Entering an unknown directory make: *** xfixes: No such file or directory. Stop. make: Leaving an unknown directory make[3]: *** [clean] Error 2 make[3]: Leaving directory `/home/kwall/X/cvs/build/programs/Xserver' make[2]: *** [clean] Error 2 make[2]: Leaving directory `/home/kwall/X/cvs/build/programs' make[1]: *** [clean] Error 2 make[1]: Leaving directory `/home/kwall/X/cvs/build' make: *** [World] Error 2 My build tree is a shadow tree created using lndir, if that makes a difference. Kurt -- If two men agree on everything, you may be sure that one of them is doing the thinking. -- Lyndon Baines Johnson ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]XFIXES extension proposal
On Sat, 30 Nov 2002, Keith Packard wrote: > Around 0 o'clock on Dec 1, Boris wrote: > > > What XFree *really* needs is much more data compression when sending data > > to a remote display > > I'm doing some packet level analysis of this problem; at ethernet speeds, > most X applications spend a lot more time waiting for round trips than > they do waiting for space on the wire to transmit more packets. > > The only time this isn't true is during image transport, so some kind of > image compression is clearly indicated. > > The kind of image compression (essentially PNG vs JPEG), it's interactions > with Render and shared memory are still unresolved issues my view. > > > The X protocol uses alot of Bandwidth when dealing with *alot* of clients. > > That's not always true; applications sending a lot of images do consume > some transient bandwidth, but many applications can be easily run with > 128Kb or less of bandwidth. X applications are often very dependent on > network latency for reasonable performance though, much of that dependence > can be attributed to "sloppy" code in toolkits which don't always > carefully avoid every round trip possible. > I never quite understood why lbxproxy had to be run as a seperate puedo server. It would be much nicer if Xlib could detect if it was present the (extension on the Xserver) and enable it if present when not talking to a local server. James ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]XFIXES extension proposal
On Sat, 30 Nov 2002, Keith Packard wrote: > Around 3 o'clock on Dec 1, James Hawtin wrote: > > > The only problem with the fixes extension will people use it, as they > > will have to write the code twice so it supports "legancy" ie not Xfree86 > > systems. (thinking of selection tracking here) > > That's been the argument against such extensions over the last 15 years, > and it's certainly valid as far as it goes, but I think we can now look > toward more rapid adoption of extensions in the general population, > certainly rapidly enough to provide incentive for application developers > to support the new mechanisms in addition to the old. > But that should not be a reason not to try it, Look how long uuencode lasted on usenet, along came yenc (which many people didn't like) and within 2 months 75% of the traffic changed! Various venders have tried extisions some stick and some don't (News (fail) GL(success) , DPS(limited success)). I think however, that Xfree86 is the perfect place to try introduce those changes, its user base is not affraid to try something new and is quite large, and its code is freely available. Better to do it now than to look back in another 15 years and go, hay I which this core problems would be fixed ;-) James ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]XFIXES extension proposal
Around 0 o'clock on Dec 1, Boris wrote: > What XFree *really* needs is much more data compression when sending data > to a remote display I'm doing some packet level analysis of this problem; at ethernet speeds, most X applications spend a lot more time waiting for round trips than they do waiting for space on the wire to transmit more packets. The only time this isn't true is during image transport, so some kind of image compression is clearly indicated. The kind of image compression (essentially PNG vs JPEG), it's interactions with Render and shared memory are still unresolved issues my view. > The X protocol uses alot of Bandwidth when dealing with *alot* of clients. That's not always true; applications sending a lot of images do consume some transient bandwidth, but many applications can be easily run with 128Kb or less of bandwidth. X applications are often very dependent on network latency for reasonable performance though, much of that dependence can be attributed to "sloppy" code in toolkits which don't always carefully avoid every round trip possible. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]XFIXES extension proposal
What XFree *really* needs is much more data compression when sending data to a remote display. It seems XFree is being used more and more for diskless clients and to display remote screens. The X protocol uses alot of Bandwidth when dealing with *alot* of clients. - Original Message - From: "Keith Packard" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Cc: "Keith Packard" <[EMAIL PROTECTED]> Sent: Saturday, November 30, 2002 10:19 PM Subject: Re: [Xpert]XFIXES extension proposal > Around 3 o'clock on Dec 1, James Hawtin wrote: > > > The only problem with the fixes extension will people use it, as they > > will have to write the code twice so it supports "legancy" ie not Xfree86 > > systems. (thinking of selection tracking here) > > That's been the argument against such extensions over the last 15 years, > and it's certainly valid as far as it goes, but I think we can now look > toward more rapid adoption of extensions in the general population, > certainly rapidly enough to provide incentive for application developers > to support the new mechanisms in addition to the old. > > > As kludges exist for some of these fixes, a compatibility library could be > > made so people who wrote code in the "new" way, would have some kind of > > support on other systems, but still could write things "clean", in the > > case of selection tracking, it would do the polling, but return events as > > if the XFIXES was there. > > Perhaps that would be possible at the toolkit level, but down at the > protocol library level, there's no flow of control to manage timeouts and > the like. As XFree86 doesn't really have control over the dominate > toolkits, we'll have to see what those groups manage to implement, > although we might give them some suggestions. > > Keith PackardXFree86 Core TeamHP Cambridge Research Lab > > > ___ > Xpert mailing list > [EMAIL PROTECTED] > http://XFree86.Org/mailman/listinfo/xpert > ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]XFIXES extension proposal
Around 3 o'clock on Dec 1, James Hawtin wrote: > The only problem with the fixes extension will people use it, as they > will have to write the code twice so it supports "legancy" ie not Xfree86 > systems. (thinking of selection tracking here) That's been the argument against such extensions over the last 15 years, and it's certainly valid as far as it goes, but I think we can now look toward more rapid adoption of extensions in the general population, certainly rapidly enough to provide incentive for application developers to support the new mechanisms in addition to the old. > As kludges exist for some of these fixes, a compatibility library could be > made so people who wrote code in the "new" way, would have some kind of > support on other systems, but still could write things "clean", in the > case of selection tracking, it would do the polling, but return events as > if the XFIXES was there. Perhaps that would be possible at the toolkit level, but down at the protocol library level, there's no flow of control to manage timeouts and the like. As XFree86 doesn't really have control over the dominate toolkits, we'll have to see what those groups manage to implement, although we might give them some suggestions. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]XFIXES extension proposal
On Sat, 30 Nov 2002, Keith Packard wrote: > 2) Selection Tracking > > Applications like the KDE 'klipper' monitor selection contents to save > them and also perform actions based on them. Right now, this happens by > having these clients contantly polling the selection. > > The proposal is to have a event delivered whenever the selection changes. > Oh yes to this one! I rember back in the openlook(XView) days writing a program to move selections between x and openlook. It was an absolute pain having to poll it. Which I did every second! The only problem with the fixes extension will people use it, as they will have to write the code twice so it supports "legancy" ie not Xfree86 systems. (thinking of selection tracking here) As kludges exist for some of these fixes, a compatibility library could be made so people who wrote code in the "new" way, would have some kind of support on other systems, but still could write things "clean", in the case of selection tracking, it would do the polling, but return events as if the XFIXES was there. James ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]XFIXES extension proposal
We've been working around various problems with the core X protocol for about 15 years now. I think it's time to build an extension that includes small changes that fix big problems. Such an extension would be limited to problems with existing core functionality that can be easily fixed in the server but for which client side workarounds are kludgy or broken. I've got three proposed problems and fixes implemented already and would like to hear other issues of interest to the community. 1) XEMBED error recovery The XEMBED specification http://www.freedesktop.org/standards/xembed/html uses nested windows to place one application window within another. One of the authors (Owen Taylor) brought a problem with error recover in this model to my attention and proposed a solution. The problem is caused by how SaveSet processing is done within the X server during (abnormal) client termination. Normal SaveSet processing reparents (embedded) windows to the nearest enclosing non-client window. In an embedding environment, that will be the window manager frame holding the embedding application. The window manager won't expect new windows to suddenly appear in this context and (generally) ignores them and goes about destroying the frame which takes the embedded application window along with the frame. The proposal is to select the root window as the SaveSet target window so that the window manager simply sees them as regular windows. A further refinement is to permit these windows to remain unmapped instead of suddenly popping up on the screen. 2) Selection Tracking Applications like the KDE 'klipper' monitor selection contents to save them and also perform actions based on them. Right now, this happens by having these clients contantly polling the selection. The proposal is to have a event delivered whenever the selection changes. 3) Cursor Image Echoing Applications like VNC or screen magnifiers work by duplicating the contents of the screen, but cannot succesfully track the cursor image in the duplicate screen. This makes the forwarded environment harder to use as the cursor image often contains significant semantic content -- like the precise location of window borders or application state like busy/idle. The proposal is to have an event reported when the cursor image changes and a request to fetch the current cursor image. I've stuck these features into a new XFIXES extension and included that in XFree86 CVS so that others might see the code and specification and test whether they solve the issues they're supposed to. This does not represent any endorsement by the XFree86 project or it's members (other than me), nor any assurance that the extension will be included in future XFree86 releases. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
