Re: (no subject)
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 writing a new desktop, whose behavior is meant to be defined by these specifications? Does it do the intended lookup via mimeinfo.cache? As Waldo wrote a new desktop can provide its own xdg-utils implementation at first and/or merge their thing in the main version. However I am confident that this will consolidate into a shared specification as well, so from some point on there would be a single xdg-mime implementation sufficient for all desktops following that spec. New desktops would then be advised to also implement this spec rather than to extend/replace xdg-mime Cheers, Kevin -- Kevin Krammer [EMAIL PROTECTED] Qt/KDE Developer, Debian User Moderator: www.mrunix.de (German), www.qtcentre.org ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: xdg-mime (Was: (no subject))
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 from an application point of view. To achieve that, I would like to add to xdg-mime a way to install shared mime-spec compliant mime-type definitions. For desktop's that don't support the shared mime-spec yet (KDE 3, old Gnome versions) xdg-mime could then convert it into the legacy format required by those environments. I think I can manage the KDE3 part, but it would be of great help if at least one GNOME developer would also participate in Portland Project activities. Cheers, Kevin -- Kevin Krammer [EMAIL PROTECTED] Qt/KDE Developer, Debian User Moderator: www.mrunix.de (German), www.qtcentre.org pgpzjFCRsFhyB.pgp Description: PGP signature ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
An addition to the clipboard specification
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 handling PRIMARY. [1] http://freedesktop.org/wiki/Standards_2fclipboards_2dspec [2] http://bugzilla.gnome.org/show_bug.cgi?id=333514 Thank you. --Toni Ruottu signature.asc Description: This is a digitally signed message part ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: An addition to the clipboard specification
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 consistent way of handling PRIMARY. I agree with his item #3, but I strongly oppose to #4. If you require that functionality, it's fairly simple to run a PRIMARY-CLIPBOARD synchroniser program. As for #1, it should be clear that's in response to mouse-events. Keyboard events (as in shift+left when making a selection) should not set the PRIMARY. This effectly makes PRIMARY a mouse-only entity and CLIPBOARD a keyboard-only entity (not considering clicking on cut/copy/paste menus). This is, of course, my strongly biased opinion, based on how I currently use it. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org thiago.macieira (AT) trolltech.com Trolltech AS GPG: 0x6EF45358 | Sandakerveien 116, E067 918B B660 DBD1 105C | NO-0402 966C 33F5 F005 6EF4 5358 | Oslo, Norway pgpezygkceTdx.pgp Description: PGP signature ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: An addition to the clipboard specification
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 way_ operation CLIPBOARD - PRIMARY. If you take some time to think how this affects different use cases it doesn't seem to block any important use cases, while it helps a lot in some cases. Not least importantly usage of copy url in Firefox web browser. This effectly makes PRIMARY a mouse-only entity It is not a mouse-only entity! PRIMARY is an implicit user selection entity. #4 makes it work implicitly also in explicit copy/paste use cases, which helps user and makes the feature even more implicit. and CLIPBOARD a keyboard-only entity (not considering clicking on cut/copy/paste menus). CLIPBOARD again is an explicit-only entity, which can be triggered also by clicking copy/paste buttons with _mouse_. This is, of course, my strongly biased opinion, based on how I currently use it. 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 idealistic reasons. --Toni Ruottu signature.asc Description: This is a digitally signed message part ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: An addition to the clipboard specification
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 idealistic reasons. 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 destination (sets PRIMARY again), Ctrl+V (pastes CLIPBOARD). If selecting with the mouse set the CLIPBOARD, then the above operation would have resulted in a no-op. And the reason the above behaviour should be kept is that this is what people coming from that other operating system expect. Those who didn't use X11 in the old days aren't used to the behaviour you describe. If everything they select with the mouse turns into a Copy-to-clipboard, they'll be very annoyed. I'm still trying, though, to come up with a good use-case where clipboard-to-primary transfer would be a bad idea. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org thiago.macieira (AT) trolltech.com Trolltech AS GPG: 0x6EF45358 | Sandakerveien 116, E067 918B B660 DBD1 105C | NO-0402 966C 33F5 F005 6EF4 5358 | Oslo, Norway pgp0MktCnbC9u.pgp Description: PGP signature ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: An addition to the clipboard specification
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 destination (sets PRIMARY again), Ctrl+V (pastes CLIPBOARD). Then you will be happy to know that my proposal (, mr. Weinbergs original proposal and the legacy way) serves your use cases perfectly. If selecting with the mouse set the CLIPBOARD, then the above operation would have resulted in a no-op. And the reason the above behaviour should be kept is that this is what people coming from that other operating system expect. Those who didn't use X11 in the old days aren't used to the behaviour you describe. If everything they select with the mouse turns into a Copy-to-clipboard, they'll be very annoyed. Yes. That's why I didn't suggest it in first place (and neither did Weinberg). :-) I'm still trying, though, to come up with a good use-case where clipboard-to-primary transfer would be a bad idea. Okay. I hope that such does not exist. I also hope that, if one exists someone will find it and bring it up. :-) --Toni signature.asc Description: This is a digitally signed message part ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
