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
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 cutpaste 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
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
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
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, 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
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, 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
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
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
