On Friday 14 April 2006 00:44, Rodney Dawes wrote:
On Thu, 2006-04-13 at 21:07 +0200, Kevin Krammer wrote:
In case you are referring to xdg-mime from the xdg-utils package, it does
whatever the running desktop's utility does :)
I am referring to that, yes. But what does it do, if one is
On Friday 14 April 2006 09:26, Bastian, Waldo wrote:
Yes, that's a good point. The shared mime spec is definitly where we
want to go and it would be an ill-adviced decision for a desktop to come
up with a different way. Xdg-mime is in the first place a way to speed
up that transition process
Hi
I'm hoping Freedesktop.org clipboard specification/explanation [1] could
be extended to cover the behavior described in a bug report [2] filed by
Zack Weinberg for GTK+. The description doesn't conflict with the
current specification in any way, while it gives a sane and consistent
way of
Toni Ruottu wrote:
Hi
I'm hoping Freedesktop.org clipboard specification/explanation [1] could
be extended to cover the behavior described in a bug report [2] filed by
Zack Weinberg for GTK+. The description doesn't conflict with the
current specification in any way, while it gives a sane and
Hi, and thanks for your response.
I strongly oppose to #4. If you require that functionality,
it's fairly simple to run a PRIMARY-CLIPBOARD synchroniser program.
You got it wrong. It was not about synchronizing! Synchronizing would be
a _very_ bad thing to do. The described way was a _one
Toni Ruottu wrote:
The description in bug report is the historical way. You may still tell
us why your way is better and why the old way would block it. Usability
reasons are more important than legacy reasons. How ever usability
reasons are also more important than custom usage habbits or
Hi again.
My usage is that I do use them as two separate entities. When I select
with the mouse, I will paste with the MMB. When I Ctrl+C, I Ctrl+V.
This is especially interesting when using the clipboard to replace stuff:
select with mouse (sets PRIMARY), Ctrl+C (sets CLIPBOARD), select
