Re: libxklavier: version bump to 5.0
Hi, Le mardi 12 janvier 2010 à 18:28 +, Sergey Udaltsov a écrit : I request permission to bump the required libxklavier version to 5.0 on wiki page. The library API was changed to facilitate latest changes in gnome-settings-daemon and gnome-applets - i.e. phasing out of the indicator applet, and using notification icon (implemented in g-s-d keyboard plugin). I understand that needs evolve and I could see the feature and stability improvements of libxklavier over the years. However, the number of ABI and API transitions makes this package a real pain to handle for us downstream distributors. It would be very appreciated if you could introduce as many as possible of the changes in libxklavier in an ABI-compatible way. This library is also used by KDE and Xfce, and every time this requires synchronised updates, or even porting, of a number of packages. Thanks, -- .''`. Josselin Mouette : :' : `. `' “You did never write something helpful `- besides your trolling” -- Jörg Schilling ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: libxklavier: version bump to 5.0
It would be very appreciated if you could introduce as many as possible of the changes in libxklavier in an ABI-compatible way. This library is also used by KDE and Xfce, and every time this requires synchronised updates, or even porting, of a number of packages. I am doing my best, but probably I still need to learn how to make rock-stable ABIs. Since the requirements to applications (g-s-d in that case) change, I have to cater for new use cases... I realize that breaking interfaces is a bad habit, so I am doing that only when I have to. At least I am trying to be disciplined with sonames, so if package name includes major number (like they do in ubuntu, libxklavier15), user can have 2 versions in one system (if it is not a case, please tell me and we'll try to sort that out). Regards, Sergey ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Raising external dependency on System Tools Backends
Le mardi 12 janvier 2010, à 14:58 +0100, Andre Klapper a écrit : Am Dienstag, den 12.01.2010, 12:13 +0100 schrieb Milan Bouchet-Valat: OK to raise the dependency on the wiki? I'd also need somebody to update the jhbuild modulesets. I don't see any reasons against, especially after you've listed the issues with the current version. Let's do it. I'll update the modulesets and wiki, if this is not already done. By the way, may I get the authorization in advance to raise the dependency as needed until the stable 2.10 is released? Sounds very reasonible. Yes. As long as Milan pings someone to update the jhbuild moduleset, that's fine, yes :-) Cheers, Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New propossed GnomeGoal: Add code coverage support
Stefan Kost wrote: Am 04.01.2010 19:53, schrieb Javier Jardón: Hello, The objective of the GnomeGoal is to add code coverage of your code with GCOV [1] Good goal! I wonder how many of the gnome projects even have a test suite, which is the prerequisite :) GCov has the drawback that one needs to rebuild the package with coverage flags enabled. Just a few days ago I found http://sourceforge.net/projects/bcov/ which does not needs that. I also produces (almost) same results reports like lcov. I has some missing feature and drawback though. I plan to have a look at some of the shortcommings. bcov is now in git on sf.net and my patches have been merged. You can use bcov as a drop in replacement for gcov+lcov. It has little dependencies - give it a try! Stefan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: On Ctrl+tab
On 1/13/10 6:25 AM, Paul Davis wrote: On Tue, Jan 12, 2010 at 8:25 PM, Behdad Esfahbod wrote: Hi Jud, Thanks for bringing this up. How about: those who care come up with a replacement combination for focus navigation in GTK+, and a patch to implement ctrl+tab to change tabs, and submit that for upstream inclusion and see if we get any substantial (other than breaks back-compat)? before anyone even does that, it would be worth confirming that the OS X shortcut is Ctrl-tab and not Cmd-tab. If its Cmd-tab, then this a fix for this bug would be a nice pre-requisite: https://bugzilla.gnome.org/show_bug.cgi?id=601863 Not sure what you mean. I'm running Firefox and Thunderbird on OS X, and they use Ctrl-Tab. Cmd-Tab is reserved for application switching on OS X. I don't think there is any official Apple pack-in program that uses tabs at all. But then they do have a document-based window manager, so it's probably not a necessity. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: On Ctrl+tab
On Wed, Jan 13, 2010 at 1:47 PM, Luca Ferretti elle@libero.it wrote: Il giorno dom, 22/11/2009 alle 16.32 -0800, Sandy Armstrong ha scritto: Most users I've spoken to about this prefer ctrl+tab because it is similar to alt+tab, and can be invoked with only the left hand. Ctrl+PgUp/Down can be invoked with only the _right_ hand using right Ctrl key. Except on a bunch of laptops and netbooks where the PgUp/Down keys are not well placed or where you have to press some FN key to access them. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list -- Olivier Lê Thanh Duong oliv...@lethanh.be Phone : +32485608639 Jabber: oleth...@gmail.com ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: On Ctrl+tab
On 01/13/2010 07:47 AM, Luca Ferretti wrote: Il giorno dom, 22/11/2009 alle 16.32 -0800, Sandy Armstrong ha scritto: Most users I've spoken to about this prefer ctrl+tab because it is similar to alt+tab, and can be invoked with only the left hand. Ctrl+PgUp/Down can be invoked with only the _right_ hand using right Ctrl key. Right, but when browsing the web, you'll generally have one hand on the mouse for clicking/scrollwheeling, and so for right-handed people, having the important keyboard operations be left-hand-only is nice. -- Dan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: On Ctrl+tab
On 1/13/10 8:15 AM, Olivier Le Thanh Duong wrote: On Wed, Jan 13, 2010 at 1:47 PM, Luca Ferretti wrote: Il giorno dom, 22/11/2009 alle 16.32 -0800, Sandy Armstrong ha scritto: Most users I've spoken to about this prefer ctrl+tab because it is similar to alt+tab, and can be invoked with only the left hand. Ctrl+PgUp/Down can be invoked with only the _right_ hand using right Ctrl key. Except on a bunch of laptops and netbooks where the PgUp/Down keys are not well placed or where you have to press some FN key to access them. Keep in mind that Macbooks don't even have PgUp/down keys. You have to do some bizarre Fn+Ctrl+Shift+Up / Down to use them. And that's not nice. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New propossed GnomeGoal: Add code coverage support
2010/1/13 Stefan Kost enso...@hora-obscura.de: bcov is now in git on sf.net and my patches have been merged. You can use bcov as a drop in replacement for gcov+lcov. It has little dependencies - give it a try! Looks much better than a few days ago! One little problem: checking for libdwarf.h... no configure: error: in `/home/hughsie/Code/bcov': configure: error: libdwarf.h is required for bcov but /usr/include/libdwarf/libdwarf.h exists. This is F12. Richard. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: On Ctrl+tab
Il giorno mer, 13/01/2010 alle 08.38 -0500, Dan Winship ha scritto: On 01/13/2010 07:47 AM, Luca Ferretti wrote: Il giorno dom, 22/11/2009 alle 16.32 -0800, Sandy Armstrong ha scritto: Most users I've spoken to about this prefer ctrl+tab because it is similar to alt+tab, and can be invoked with only the left hand. Ctrl+PgUp/Down can be invoked with only the _right_ hand using right Ctrl key. Right, but when browsing the web, you'll generally have one hand on the mouse for clicking/scrollwheeling, and so for right-handed people, having the important keyboard operations be left-hand-only is nice. This case seems excessive to me. If you've one hand on your mouse, use the mouse to change tab, clicking or using the scroll wheel :P I suppose the scenario for keyboard shortcuts here is both hands on keyboard (or no ability to use the mouse). ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: On Ctrl+tab
On Wed, Jan 13, 2010 at 8:07 AM, Luca Ferretti elle@libero.it wrote: Il giorno mer, 13/01/2010 alle 08.38 -0500, Dan Winship ha scritto: On 01/13/2010 07:47 AM, Luca Ferretti wrote: Il giorno dom, 22/11/2009 alle 16.32 -0800, Sandy Armstrong ha scritto: Most users I've spoken to about this prefer ctrl+tab because it is similar to alt+tab, and can be invoked with only the left hand. Ctrl+PgUp/Down can be invoked with only the _right_ hand using right Ctrl key. Right, but when browsing the web, you'll generally have one hand on the mouse for clicking/scrollwheeling, and so for right-handed people, having the important keyboard operations be left-hand-only is nice. This case seems excessive to me. If you've one hand on your mouse, use the mouse to change tab, clicking or using the scroll wheel :P And yet, I was about to respond identically to you before I saw that Dan beat me to it. I believe that right hand on mouse, left hand on keyboard is extremely common. Consider selecting text and copy/pasting, or using ctrl+tab to change tabs, with the mouse in the content area so you can scroll, select text, etc. So while I don't have any data outside my own usage and intuition, I really don't think it's excessive, as you say. I suppose the scenario for keyboard shortcuts here is both hands on keyboard (or no ability to use the mouse). I think that's a bit limiting, but even if we were to accept it as true, we can still say that on a full keyboard, ctrl+page up/down requires you to shift your right-hand considerably away from home row, making it fairly inconvenient. Fun fun fun, Sandy ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
XDG StatusNotifier Specification: Feedback Invited
Howdy, A while ago I posed a blog entry that talks a little about the work that we're doing with what we've named Application Indicators, based upon a submitted XDG specification [2]. I realize that everyone doesn't read planet, and that it was before the holiday, so I wanted to repost here for information, and update folks on the status. http://gould.cx/ted/blog/Having_a_tidy_systray Basically our goal is to clean up the current systray and provide a consistent means of interacting with applications that choose to put items in there. This means choosing a middle ground where we provide enough flexibility for applications to do something interesting while not allowing them to go crazy. The middle ground we chose is a menu. You can read the usability rationale and approach at [2]. The spec was written by the KDE guys a while back and I believe they're going into their third release supporting it. We've worked with them and the XDG list to get this into a FD.o spec so that we don't have incompatibilities going forward. We've suggested some changes with adding menu support and have patches for KDE that implement these on the KDE side of things. We are planning to ship, in Ubuntu Lucid, both GNOME and KDE applications that work cross desktop and we have committed resources to providing upstream patches for many of these applications. To make it simple to use for application developers we've built a small library called libappindicator [1] that makes it pretty easy to create and manage the icon and the menu an we've documented how to use it [2]. Hopefully this will become part of GTK/GNOME in the future, but obviously it won't be in the 2.30 cycle. It will provide things like transparent fallback to GtkStatusIcon for support of people who choose not to run the applet (and have a notification area one). Currently, the discussion has been happening on the XDG list regarding the spec and we've got a decent implementation of the spec integrating into the GNOME Panel. The commentary by GNOME folks has been light, considering this your invitation to come over to XDG and give your suggestions. The thread subject is 'Proposing the StatusNotifier specification'. --Ted [1] Code is at https://launchpad.net/indicator-application [2] http://www.notmart.org/misc/statusnotifieritem/index.html [3] https://wiki.ubuntu.com/DesktopExperienceTeam/ApplicationIndicators signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: XDG StatusNotifier Specification: Feedback Invited
On Wed, 2010-01-13 at 21:03 -0500, Dan Winship wrote: On 01/13/2010 02:52 PM, Ted Gould wrote: Basically our goal is to clean up the current systray and provide a consistent means of interacting with applications that choose to put items in there. This means choosing a middle ground where we provide enough flexibility for applications to do something interesting while not allowing them to go crazy. The middle ground we chose is a menu. What are you planning to do with NetworkManager? That's currently the go-craziest of the notification icons, but it's generally pretty *good* crazy and it would be hard to implement that functionality with a plain text-only menu. (And what about the volume indicator? Are you just swapping that back to being an applet?) We don't plan on having everything ported for Lucid, that'd be insane on more than one level. We plan on having the notification area still in the panel for Lucid so that both protocols could be used. I believe that KDE is supporting both for a while as well. Long term, we'd like to be able to support everything that NetworkManager does. Honestly, I'd like to see those features get more available for other apps as I think there's some really good ideas in the NetworkManager menu. First round, we're only supporting the basic menu items in GTK: check, radio and image. I'm pretty busy with just that :) I forgot to mention it in my original mail, but we did set up a mailing list [1] to discuss the menuing issues. I imagine we'll be discussing a next set of menuitems to implement there shortly. --Ted [1] https://launchpad.net/~dbusmenu-list signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: XDG StatusNotifier Specification: Feedback Invited
On Wed, 2010-01-13 at 13:52 -0600, Ted Gould wrote: To make it simple to use for application developers we've built a small library called libappindicator [1] that makes it pretty easy to create and manage the icon and the menu an we've documented how to use it [2]. Hopefully this will become part of GTK/GNOME in the future, but obviously it won't be in the 2.30 cycle. It will provide things like transparent fallback to GtkStatusIcon for support of people who choose not to run the applet (and have a notification area one). Ok so if it won't be on 2.30 it will be done for 3.0 ? Why should module maintainers use this library if it isn't on GNOME infrastructure or even blessed ? I like the idea but so far it seems to me more a downstream development than upstream. Cheers Luis ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
