Haiku - FreeDesktop.org cooperation proposal (fwd)
revol at free.fr
Thu May 8 09:54:47 PDT 2008
> > > 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
> way underlying structures have been implemented should not be a huge
> problem. It is not about doing cross system copy/paste operations.
> 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
6. well we don't support it yet, so it's moot.
7. selections and clipboard don't interact except through explicit copy
Seems (except Terminal's paste-doesn't-unselect) we comply already \o/
More information about the xdg