Michael Nagel, I have read carefully your comment and I think you are right for the non-static data and it might be also complicated to deal with the history of clipboard managers and this kind of data also... We could have a history per clipboard type, the text history would have more items than bitmap type, etc.
But there is some problems with the clipboard manager workaround : Parcellite -> it is not a Gnome application (does not use gconf, stay in the notification area, etc) and it is not going to be maintained anymore (see parcellite website) Glipper -> dead for three years, and it is written in the mailing list of the project that it won't be maintained anymore If we want to have a clipboard manager integrated to distributions, the first thing to have is maybe a well maintained application for that first ? I think we should continue the development of Glipper because it is written in python and it is easy to patch, maintain and it is also a real gnome application. Plugins are also very easy to add. Is someone interesting in making a fork or something about Glipper ? Once we have a maintained clipboard manager, we could add more features like the ability to manage different kinds of contents of the clipboard. 2010/5/24, Michael Nagel <ubu...@nailor.devzero.de>: > Making the xserver the owner of all content is pretty much the same as > using a clipboard manager and making that the owner of all content. > There are working clipboard managers ready to be installed from the > repository -- namely klipper, glipper and parcellite . they are the more > or less official workaround as suggested by collin watson (see comment # > 207 ) why none of these clipboard managers is installed by default goes > beyond my understanding. > > There is one problem with these clipboard manager that causes problems > with programs like e.g. the gimp and other, that is quite hard to fix > properly. > > When exporting some lines of text to the clipboard the suggested > approach (just grabbing it when it is exported) will work just fine. > With binary data like images the problem gets more complicated because > now you have a lot more data and it potentially contains lots of > troublesome bits (nullbytes and the like) that must not crash nor > confuse your clipboard manager. but that is pretty much solved by > current clipboard mangers, too. > > The real problem is about nonstatic data. In the above examples the > content was present in the source application and you only had to copy > it away from there. The clipboard offers functionality to create the > data on demand. For example you could work on some vector graphic in > inkscape and copy and paste the data to gimp where it would arrive as > pixel data. The pixel data is only created when you paste it somewhere. > So you can copy a hundred times and paste only the last copy, then only > that version will be converted to pixel data. That is the clipboard > basically asks your application to provide some content and it is up to > you if you answer with some existing data or generate some new data just > to satisfy that request. When that generation is expensive it is not > practicable to do it every time something is offered to the clipboard > but only when something is requested from the clipboard. But a clipboard > manager basically request the data every time some data is offered to > the clipboard invalidating that optimization and causing a lot of data > to be generated and transferred. > > That overhead might be tolerated, too. But to further complicate matters: > When exporting something to the clipboard you don't export something fixed. > Fixed means you already decided about what to export (although you might not > yet have created it yet -- see above). No, you say that you offer "plain > text", "rich text", "binary data" or "a nice picture". When pasting the > application does not request the "contents of the clipboard" but says it > understands "plain text", "vector graphics", "binary data" and "wave > sounds". Now some arbitration takes place and the applications agree on > transferring "plain text" (or "binary data" whatever is better for some > definition of better). Thus it is not even clear what a clipboard manager > should grab when an application offers some data for export to the > clipboard. It might grab all the offered datastreams but that obviously > means some heavy overhead... > > One thing gnome does is to offer a clipboard manager where your > application can store the things it offers to the clipboard when it > exits. Control over the clipboard is then transferred to that clipboard > manager. That way no data is lost and data is only copied when your > application exits, minimizing overhead. This means each and every past, > present and future application must be extended to make use of that > manager (opt in instead of opt out or forced use of the manager). That > is not gonna happen. Furthermore it will not work for crashing > applications... > > Conclusion: Why not go with a clipboard manager that grabs everything? > And then working around the performance bottlenecks by stopping certain > transfers from happening? You could offer an API to application to mark > certain exports as not relevant for the clipboard manager and you could > blacklist certain offerings in the clipboard manager for some cases > where you cannot modify the application. You could even display a shiny > notify-system message telling the user: "what you just copied will not > be available permanently. Paste it now before closing that app!" That > manager would support legacy applcation and should be installed by > default so no user is bothered with this bug ever again. > > How to implement: Patch glipper/parcellite to grab everything, offer > some blacklisting to mitigate bottlenecks and talk to someone at > canonical to include it in the default install... > > -- > MASTER Copy-Paste doesn't work if the source is closed before the paste > https://bugs.launchpad.net/bugs/11334 > You received this bug notification because you are a direct subscriber > of the bug. > -- MASTER Copy-Paste doesn't work if the source is closed before the paste https://bugs.launchpad.net/bugs/11334 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a subscriber of a duplicate bug. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
