> > > Today I'm using mainly Ubuntu and I have been working on the > > > freedesktop.org clipboard specification. The current version > > > should > > > be > > > more general than some older editions. Iirc the clipboard > > > management > > > in > > > BeOS was fairly simple, so it might be possible for Haiku to > > > respect > > > the > > > specification (at least to some degree). Please give me your > > > opinion > > > on > > > the matter. The current version is available from > > > http://lists.freedesktop.org/archives/xdg/2007-November/008985.html > > > > > > > I'll have a look at the specs, but for now here is a glimpse of how > > Haiku handles clipboards: > > The specification describes how clipboard should appear to user. So > the > way underlying structures have been implemented should not be a huge > problem. It is not about doing cross system copy/paste operations. > Such > might be useful for some remote desktop systems. This specification, > however, is about providing a consistent user experience between > different desktop platforms.
Oh ok, didn't read through it, and I recall seeing implementation talks on the ml... still it could be interesting to standardize non-text format for clipboards I suppose... As for user actions besides Alt-C,Alt-X and Alt-V there is not much standardization yet in Haiku... Alt is the default shortcut key in BeOS, but can be swapped with Ctrl, but that's bad cause Ctrl-C means SIGINT ;) We don't have a concept of primary or secondary buffer, just a single one, and it's explicitely set from the shortcuts, no implicit copy-when -selected, at least I don't recall any app doing so. Oh right, the Terminal app itself handles pasting the current selection onto itself from right click, but that's about it. So we have explicit copy/paste only except Terminal's own stuff, but that matches the specs. Also, since the clipboard is managed by the registrar server, quitting applications doesn't remove the data, so in that respect we do follow the specs already too :) As for URL handling, well we have Firefox which does that of course... Some applications have custom context menus including a "Copy", "Select All" items for any selection not only urls, but that's app-specific, nothing common yet. But that's optional. So point 1, 2, 3 seems ok. 4 should be ok as well. Our default BTextView class which is used almost everywhere text is entered handles pasting at carret, and replacing selection. Other places are usually development editors with their own editor canvas, but they follow the same principle. Only the Terminal app doesn't unselect the selection on explicit (or implicit either) pasting but that's actually more convenient this way I think, and it's easily changed. As for 5, since we handle clipboard inside a server there is no concept of "pointer to app" for that. But it behaves as if a clipboard manager was always present to copy data to itself. It is actually even possible to have the clipboard maintain the signature and pid of the last writer to it by adding fields to the message though. 6. well we don't support it yet, so it's moot. 7. selections and clipboard don't interact except through explicit copy /paste. Seems (except Terminal's paste-doesn't-unselect) we comply already \o/ François. _______________________________________________ xdg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xdg
