Haiku - FreeDesktop.org cooperation proposal (fwd)

[François Revol]

> > > 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.