Re: Using the Unicode ellipsis (…) instead of three periods
On Mon, 2012-12-03 at 19:09 -0500, Jeremy Bicha wrote: I think it's time that we move away from using three periods (...) to represent the ellipsis and instead use the Unicode character (…). We've been trying to do this on the Unity Indicators and I wrote a small automake fragment to test for them. It's a little bit hacky, but it works and makes sure we don't regress. I'd love for it to get used and improved in other projects. http://bazaar.launchpad.net/~indicator-applet-developers/indicator-session/trunk.13.04/view/head:/tests/Makefile.am.strings --Ted signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
OT: Unity handling of Application menus (was: Re: GNOME Goal Proposal: Port to GMenu)
On Thu, 2012-04-26 at 10:23 -0400, Jeremy Bicha wrote: On 26 April 2012 10:10, Jasper St. Pierre jstpie...@mecheye.net wrote: And I thought that desrt and Colin worked very hard to have this work with Ubuntu. I remember Colin talking about how hard this was because of integration between GNOME 2, GNOME 3 and Unity. Unity supports GMenus as a replacement for the traditional File/Edit/View menus, but I don't think it works as an addition at this time. No app does that yet anyway. Slightly off topic for the GNOME lists, but just to clear up any confusion. In indicator-appmenu we watch for applications that both application menus and window menus and display both in the Unity menu bar. So an application that has both would get something like: [Application Name] [File] [Edit] But then, perhaps obviously, if there are no window menus only the application menu will be shown (and vice-versa). It's true that not many applications do this, so bloatpad was the biggest test case, but that's the idea :-) While there are few today, our goal here was to ensure that as new applications are developed it is expected that they'd use GMenuModel instead of traditional GTK menus. We expect that some developers would want to target the Ubuntu 12.04 release via myapps[1] and we want those applications to work for the full lifecycle of the release. We want to encourage usage of GMenuModel in all applications, much better than the Dbusmenu parser we have for the traditional menus. --Ted [1] http://myapps.developer.ubuntu.com (slow today, sorry) 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: OT: Unity handling of Application menus (was: Re: GNOME Goal Proposal: Port to GMenu)
On Thu, 2012-04-26 at 11:54 -0400, Jasper St. Pierre wrote: On Thu, Apr 26, 2012 at 10:53 AM, Ted Gould t...@gould.cx wrote: While there are few today, our goal here was to ensure that as new applications are developed it is expected that they'd use GMenuModel instead of traditional GTK menus. We expect that some developers would want to target the Ubuntu 12.04 release via myapps[1] and we want those applications to work for the full lifecycle of the release. We want to encourage usage of GMenuModel in all applications, much better than the Dbusmenu parser we have for the traditional menus. Does GMenuModel support window-specific menus? GMenuModel supports menu structures, what specifies what type of menus those are is the GtkApplication object. So if you want to create window menus you'd build the model and set it on the application window using gtk_application_set_menubar(). --Ted 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: [gnome-settings-daemon] datetime: Remove datetime D-Bus mechanism
On Fri, 2012-01-20 at 12:37 +, Emmanuele Bassi wrote: the dependency is not on systemd - it's on a DBus API. systemd provides one implementation of that DBus API. I think that this would be more apparent if the DBus interface descriptions were maintained outside of the systemd codebase. If they're maintained inside the systemd codebase, for all practical purposes you're depending on a particular version of systemd to provide the version of the interfaces you support. They will change, if the only way to express this change is through a systemd version number, you're depending on systemd. It seems to me that this would be a good usage of Freedesktop. I'd be happy to maintain such a repository if people would be willing to use it. --Ted 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: [gnome-settings-daemon] datetime: Remove datetime D-Bus mechanism
On Fri, 2012-01-20 at 10:22 -0500, Ryan Lortie wrote: On Fri, 2012-01-20 at 08:59 -0600, Ted Gould wrote: I think that this would be more apparent if the DBus interface descriptions were maintained outside of the systemd codebase. http://www.freedesktop.org/wiki/Software/systemd/timedated I won't comment on if you accept this as being sufficiently divorced from systemd or not... From the wiki page: systemd 30 and newer include systemd-timedated I would conclude that any dependency on that interface is a dependency on systemd version 30 or newer. Therefore, GNOME has that as a dependency in 3.4 on systemd 30. To be clear, I don't think that's a problem in how the page is written, I think that's a reality of where the interface is defined. --Ted 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: [gnome-settings-daemon] datetime: Remove datetime D-Bus mechanism
On Fri, 2012-01-20 at 23:20 +0100, Lennart Poettering wrote: On Fri, 20.01.12 08:59, Ted Gould (t...@gould.cx) wrote: It seems to me that this would be a good usage of Freedesktop. I'd be happy to maintain such a repository if people would be willing to use it. Yeah, it's a great use of fdo, and that's why I put it on fdo. Just to be clear, you'd be happy if the interfaces were moved to a different repository that was versioned independently of systemd? And then systemd could depend on a particular release of those interfaces. So then, for instance, GNOME could say it depends on release 45 of the interfaces and a particular version of systemd could implement that version of the interfaces. If you're happy with that, I'm happy, let's set up a repo. --Ted 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: [gnome-settings-daemon] datetime: Remove datetime D-Bus mechanism
On Fri, 2012-01-20 at 23:48 +0100, Lennart Poettering wrote: On Fri, 20.01.12 16:29, Ted Gould (t...@gould.cx) wrote: On Fri, 2012-01-20 at 23:20 +0100, Lennart Poettering wrote: On Fri, 20.01.12 08:59, Ted Gould (t...@gould.cx) wrote: It seems to me that this would be a good usage of Freedesktop. I'd be happy to maintain such a repository if people would be willing to use it. Yeah, it's a great use of fdo, and that's why I put it on fdo. Just to be clear, you'd be happy if the interfaces were moved to a different repository that was versioned independently of systemd? And then systemd could depend on a particular release of those interfaces. Honestly, I don't see why. The wiki is just fine. The interfaces are versioned independently of systemd (that's why their interface names and object paths contain version numbers (currently at 1). And those version numbers are specific to the API, and entirely unrelated to systemd. It's basically how D-Bus versioning is generally accepted to work). I already maintain a ton of stuff, and I try to keep maintenance burden and bureaucracy small for myself. Hence the Wiki, and not a complex standards process and a git repo. All API versioning we need should be done within the D-Bus interface itself (where the right place is for it anyway) and all documentation versioning by using the history functionality of the wiki. I guess that I don't see that as adequate (hence why I suggested something more formal). One way that I had thought this could work on the Debian packaging side of things would be using the Requires/Provides labels in the package. So then something like systemd could provide freedesktop-system-interfaces-45 and GNOME could require that. There could also be other providers and users who wanted to switch would then get their choice. Pulling the version number from the wiki for all the different interfaces would make that complex and burdensome to maintain for the packagers involved. Which is why I suggested something with a more stable and uniform release process. --Ted 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: [gnome-settings-daemon] datetime: Remove datetime D-Bus mechanism
On Sat, 2012-01-21 at 01:07 +0100, Lennart Poettering wrote: On Fri, 20.01.12 17:08, Ted Gould (t...@gould.cx) wrote: I already maintain a ton of stuff, and I try to keep maintenance burden and bureaucracy small for myself. Hence the Wiki, and not a complex standards process and a git repo. All API versioning we need should be done within the D-Bus interface itself (where the right place is for it anyway) and all documentation versioning by using the history functionality of the wiki. I guess that I don't see that as adequate (hence why I suggested something more formal). What could be more formal than a machine readable interface definition as it is included in the Wiki page? I was more referring to formality of process rather than how the interface is specified. I imagine there won't be many versions of the interfaces, but there will be of the tools (like systemd) that implement them. One way that I had thought this could work on the Debian packaging side of things would be using the Requires/Provides labels in the package. So then something like systemd could provide freedesktop-system-interfaces-45 and GNOME could require that. Right. What could be a better identifier for an interface and its version, than, well, the interface name which includes the version? i.e. use org.freedesktop.timedate1 for that. And if you don't like the dots, then replace them by dashes or so, for use by your package manager. There could also be other providers and users who wanted to switch would then get their choice. Pulling the version number from the wiki for all the different interfaces would make that complex and burdensome to maintain for the packagers involved. Which is why I suggested something with a more stable and uniform release process. I am not sure how better to achieve uniformity and stability than by by using the version information that is embedded in the interface definition itself? I am sorry, but you explicitly *don't* want another level of naming or versioning here, because then you'd have to maintain multiple versioning streams for the same stuff, and that'd suck. So, let's use a simple use case. For what ever reason, it is decided that one of the interfaces needs a new property. I'm guessing that you'd expect that the interface name wouldn't change as it would be backwards compatible. Now GNOME Control Center comes along and needs that new property to implement their interface. How should G-C-C express that requirement? --Ted 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: GNOME Online Accounts extensibility
On Mon, 2011-10-10 at 11:10 -0400, David Zeuthen wrote: Either way, I don't get why you are so concerned about whether GOA can be extended. If you buy into the idea that apps will always need to have a separate panel for non-mainstream accounts then... then the app can provide the extension point and config-file merging from ..d-directories. For me, and I'm guessing a few others, we were confused at the scope and the problem that GOA was trying to solve. Not as much concern and more confusion. Thanks for explaining it. --Ted 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: Dynamic help menus for 3.2
On Mon, 2011-10-10 at 09:08 +0200, Tomeu Vizoso wrote: On Sat, Oct 8, 2011 at 16:19, Ted Gould t...@gould.cx wrote: On Fri, 2011-10-07 at 18:22 -0400, Shaun McCance wrote: That actually works as well in my prototypes, but it might not be in good enough shape for 3.4. The interaction with a text entry in a menu is really hard in GTK+. GtkMenu just wasn't designed to do that. Yeah, it wasn't. We have an implementation in our IDO library, you're welcome to use. If there's interest we can look at how this could move into GTK+. Guess it would be better if applications wouldn't need to duplicate workarounds, so maybe we could fix GtkMenu so we don't need a subclass of GtkMenuItem specific for containing entries? Maybe Cody has already some thoughts about what needs to be fixed in GtkMenu(Item)? Sure, sounds good to me :-) Though, I don't have an opinion on what could be consolidated and made generically useful. --Ted 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: Dynamic help menus for 3.2
On Fri, 2011-10-07 at 18:22 -0400, Shaun McCance wrote: On Fri, 2011-10-07 at 15:01 -0500, Diego Escalante Urrelo wrote: Don't know if you have considered this but in OSX some applications have a search entry in its Help menu, this entry searches among all the menu items and also Help topics. It's really useful for applications with *huge* menus like FinalCut. It's has been a lifesaver the few times I've been unable to remember where a menu item was or what was the exact name of one. Might not be next best thing as-is, but perhaps it serves as inspiration for something else. That actually works as well in my prototypes, but it might not be in good enough shape for 3.4. The interaction with a text entry in a menu is really hard in GTK+. GtkMenu just wasn't designed to do that. Yeah, it wasn't. We have an implementation in our IDO library, you're welcome to use. If there's interest we can look at how this could move into GTK+. http://bazaar.launchpad.net/~canonical-dx-team/ido/trunk/view/head:/src/idoentrymenuitem.c Hope that helps. --Ted 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: GNOME Online Accounts extensibility
On Fri, 2011-10-07 at 10:21 -0400, Matthias Clasen wrote: And we don't want to add switches for services that are not covered by GNOME apps. Could you elaborate on the term GNOME apps in this context please? For instance, if Inkscape wanted to have account settings for the recently published Deviant Art APIs would that be allowed? Or is it encouraged that when Inkscape runs on GNOME OS it should provide it's own account setup dialog for those APIs? --Ted 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: GNOME Online Accounts extensibility
On Fri, 2011-10-07 at 10:49 -0400, David Zeuthen wrote: If you examine the GOA project and its git log, You can rest assured that I haven't read the git log, I did look at the last release though :-) combined with the idea of supporting generic IMAP/SMTP/XMPP/Caldav configurations, see https://bugzilla.gnome.org/show_bug.cgi?id=661117 that Patryk filed on my request... then... then GOA can be pretty nice from a corporate point of view. Because with that the you'd just drop a single config file in /etc/goa-1/config.d/mail.conf specifying the $u...@company.com for email, something else for XMPP and so on. So to be clear, you see GOA's configurability to be in setting up new account groups, but new protocols. So I could add Corp. Account but if my corp. uses a protocol that GNOME OS doesn't use otherwise, I couldn't add this. Trying to understand what configurability you expect in the future. --Ted 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: GNOME Online Accounts extensibility
On Thu, 2011-10-06 at 14:49 -0400, David Zeuthen wrote: On Thu, Oct 6, 2011 at 2:30 PM, Ken VanDine kvand...@gnome.org wrote: Sorry, not trying to sound harsh here but I couldn't find a better way to say this. Basically you are saying that GOA isn't really an open technology to help consolidate user's online accounts, it is only to help consolidate accounts for blessed GNOME apps? This doesn't really help users in the big picture, but I guess the design team makes those decisions. Does this mean third party developers shouldn't try to leverage GNOME as a platform anymore? Maybe that is a topic for another thread, as much as I love GNOME, it is becoming harder and harder to develop for. I miss the days when GNOME was a platform, I hope there is a way we can change that and turn it into a platform again! I think your mail is actually pretty offensive and also misrepresenting GNOME. I will not reply to it. Huh, I think you pretty much answered Ken's question indirectly. :-) IMHO, the problem with GOA is its lack of extensibility. So adding something like a corporate account type is difficult if not impossible. For instance, if was foo corp, and we had internal mail, jabber and status.net services -- I'd like to provide one way to provide this configuration and have one place for users to set up their accounts. I think handling this use case could provide some guidance for where GOA could go in making users who are corporate environments lives easier. --Ted 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: First release of geocode-glib available
On Sat, 2011-05-14 at 21:24 +0100, Bastien Nocera wrote: On Wed, 2011-05-11 at 10:20 +0200, Ted Gould wrote: On Mon, 2011-05-09 at 16:52 +0100, Bastien Nocera wrote: This library should be used in place of Geoclue's D-Bus API for geocoding and reverse geocoding. Is this now deprecated in the Geoclue API? Pretty much, though I can hardly tell KDE people to start using a glib-ish library for that. I would expect them to come up with their own library in due time. When we have a working new-fangled geoclue to replace the current one, the API (and the old geoclue code) will most likely disappear of their own. Why do you think they'd do that rather than just work on GeoClue? It seems like there's an advantage to using an API that can have multiple providers. The API is generic enough to support multiple providers, it's just that there's currently only one implementation. The fact that we have only one implementation means that we have one well maintained implementation. I don't think it's much of a problem. Do you have particular reasons why you think that supporting multiple backends is actually useful? I don't have a specific use case, but I would guess that name providers vary widely based on location. My guess would be that Yahoo is pretty good in the US/Europe but there's a better local provider for India/China for instance. I have no information on that, it just seems to be pretty consistent for data like this. Which is one of the things that struck me as odd with a new library being created that didn't use the plugable interface already created. Is there a reason you didn't just make a well maintained GeoClue backend? --Ted 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: no external panels for gnome-control-center [was Re: GNOME Feature Proposal: Backup]
On Wed, 2011-05-11 at 02:15 +0200, Luca Ferretti wrote: Il giorno mar, 10/05/2011 alle 20.51 +0100, Bastien Nocera ha scritto: http://live.gnome.org/DejaDup/Screenshots/Future for screenshots. Déjà Dup 19.1, which includes those changes, is already in Fedora Rawhide and will be in Ubuntu Oneiric once we land the GNOME 3 control center. That won't work for long. Once we've move the Bluetooth panel directly in the control-center, we'll be removing the external API from the control-center. It was only added for gnome-bluetooth, and will be removed then as well. Could someone please articulate the GNOME position for downstream distributors of GNOME technologies? It seems to me the previous position was to use the extension points instead of doing vendor patches. Yet, without extension points it seems that vendor patches are the only solution there. Thanks, Ted 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: First release of geocode-glib available
On Mon, 2011-05-09 at 16:52 +0100, Bastien Nocera wrote: This library should be used in place of Geoclue's D-Bus API for geocoding and reverse geocoding. Is this now deprecated in the Geoclue API? It seems like there's an advantage to using an API that can have multiple providers. --Ted 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: GSettings best practice
On Sun, 2010-11-07 at 17:15 +0100, Milan Bouchet-Valat wrote: Le dimanche 07 novembre 2010 à 10:57 -0500, Ryan Lortie a écrit : We were sitting around at the Boston summit today (me, vuntz, tedg, and pbor via IRC) noticing that we have a mix of people using /apps/gedit/ sort of paths and /org/gnome/evince/ sort of paths in GSettings. We all prefer /org/gnome/evince/ type of paths. This was very quickly discussed with on the list, and nobody answered then except Matthias: http://mail.gnome.org/archives/desktop-devel-list/2010-June/msg00097.html I was in favor of the org/gnome/something approach, but what would then happen to /desktop/ keys, which (as Matthias said in his reply) would be better kept separate? I think that org.gnome.desktop makes sense. And what about the migration now that both schemes are in use? Uhm, yes. :) I think they're just going to have to migrate. It should be a relatively straight forward transition. --Ted 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: JSON-Glib (was: New module proposal: Clutter core)
On Mon, 2010-10-04 at 12:50 +0100, Emmanuele Bassi wrote: • JSON-GLib (which should be added to the external dependencies) Just to be curious, why not propose JSON-Glib. It seems with all of the Javascript going into GNOME 3 it would make sense to have a blessed way to read JSON would be a really good idea... --Ted 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: (L)GPLv3
On Tue, 2010-07-06 at 09:34 -0400, William Jon McCann wrote: On Tue, Jul 6, 2010 at 9:00 AM, Ryan Lortie de...@desrt.ca wrote: Anybody who has an application that is GPLv2-only and has accepted enough contributions that it has become an unreasonable proposition to relicense has made a significant mistake. I don't want to punish them or anything, but they are the ones who picked a licence that prevents them from linking against just about anything. At least one company in our ecosystem has been, at least in some cases, writing GPLv3-only code. Which seems like an odd choice to me that probably needs some justification. Not sure if you're meaning Canonical there, but I thought I'd clarify if you were. Canonical's policy is that everything is GPLv3 (or AGPLv3 for service stuff) unless an exception is needed. For instance, I got exceptions for libappindicator and libdbusmenu and those are all LGPL2.1/3 to resolve the issue of needing to link with GPLv2 programs. Personally, I feel that libraries need to be LGPLv2/3. I'd love it if they could be LGPLv3, but that's probably not practical. IANAL but I'm curious if a standard exception couldn't be drafted for LGPLv3 to allow linking with GPLv2 programs. Perhaps with work, that could be GNOME policy going forward? I like v3, but I think we need to be able to link to v2 programs. --Ted 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: (L)GPLv3
On Tue, 2010-07-06 at 13:17 -0400, Ryan Lortie wrote: On Tue, 2010-07-06 at 12:12 -0500, Ted Gould wrote: IANAL but I'm curious if a standard exception couldn't be drafted for LGPLv3 to allow linking with GPLv2 programs. Perhaps with work, that could be GNOME policy going forward? I like v3, but I think we need to be able to link to v2 programs. As I mentioned it my earlier emails, it's not a term in the LGPLv3 that prevents you from linking GPLv2 programs to it. It's the GPLv2 in the program code that states you can't link this against anything other than GPLv2 code. Nothing we could add to the library licence (other than dual-licensing under GPLv2) could fix this. Yes, because of the additional restrictions. And it's my understanding is that there wasn't an exception added to the v3 license for v2 because of concern that people would circumvent the v3 restrictions by making all of their programs v2. Which makes sense. But, it seems like when we're making a choice between dual-licensing v2/3 and v3 with an exception for v2 only -- the exception is the better choice. --Ted 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: Modulesets Reorganization
On Wed, 2010-06-02 at 00:37 +0100, Lucas Rocha wrote: The release team would like to propose some important changes in the way we organize our modulesets. It's a shame that this came out almost simultaneously with GNOME 3 module decisions -- as it seems that they are intrinsically tied. For instance, if this was to rejected I'm unsure of what would happen to everything accepted to Applications. That being said, personally I think this going in the right direction. 1. The Desktop moduleset will only contain the components needed to get a desktop session running and provide core functionalities (e.g. gdm, gnome-session, gnome-settings-daemon, nautilus, etc). All applications providing extra relevant features to the desktop (e.g. gedit, Totem, Tomboy, etc) will be moved out from the Desktop moduleset. See the Extra Information section for more details. snip In summary, this means that the GNOME releases would be composed by the following modulesets: - Desktop - Platform - Extended Platform - Mobile I think that there should be a separation between a Desktop module and a Desktop Core module. The Desktop module that should include GNOME Shell, Nautilus, etc. Core would then contain things required to get a basic UI running but without a shell (no panel, just things apps depend on) My intent here is to reflect how the GNOME Desktop is currently being deployed in a couple of cases. I'm thinking of Unity and Meego. In both of these situations we've got basically everything we're talking about in Desktop here: gsd, gnome-session, mutter, etc. But, I don't think either case is planning on adopting GNOME Shell for the netbooks that they're targeted at. This would allow them to be Desktop Core compliant for the applications that need that functionality without having to pull in parts that they aren't going to use. --Ted 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: Re: External Dependency Proposal: libappindicator
Not to criticize your decision, but just to correct a couple of factual details in your e-mail: On Thu, 2010-05-06 at 12:20 -0400, Dan Winship wrote: As for the trayicons in the message tray, it is possible that tray-side-menu-rendering, as in libappindicator, would be useful for our design goals. However, I still think we don't want libappindicator. The StatusNotifier protocol that the appindicator work is built on is just... designed to solve some problem other than ours. It imposes complexity to support features we don't care about, while enforcing simplicity in places that would prevent us from implementing things we do care about (unless we extended it in non-standard ways, a la dbusmenu). The dbusmenu portion, along with the icon theme path that was also required, have been accepted by the KDE team as extensions to the protocol and are now supported in the KDE version of the Status Notifier Item spec. I think that we're fully cross-desktop now with our implementations. And at any rate, since gdbus will be landing soon, if we did want to support the StatusNotifier/dbusmenu protocol, we could just add that to GtkTrayIcon now. This round we plan on porting libappindicator to GDBus (in fact I'm very excited about it) as well. You're of course welcome to steal the code (it's open source :) for your implementation of GtkTrayIcon if you'd like. I'd be happy to help. --Ted 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: Label in tray = P in the A
On Tue, 2010-03-23 at 23:42 +, Sergey Udaltsov wrote: StatusIcons are not GTK widgets. And, as the result, the indicator has to emulate gtk widget. That's a real pain, folks. The indicator renders text to cairo, converts cairo to pixbuf, sets status icon from pixbuf. Worst of all, the widget has to follow gtk style, font rendering settings etc. What a pain.. Bug reports... Now, another one: https://bugzilla.gnome.org/show_bug.cgi?id=611875. The other big problem with this is that GSD doesn't know the style of where it's being embedded. So if it creates black text, and the panel is black, the text becomes unreadable. I'm not sure this is reasonably solvable within the Notification Area framework, but long term, we really need to have the text/icons rendered by the surface they're getting placed on. --Ted 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: External Dependency Proposal: libappindicator
On Fri, 2010-02-19 at 10:42 +0100, Olav Vitters wrote: On Thu, Feb 18, 2010 at 09:42:58PM -0600, Ted Gould wrote: Q: Does this fit the the design goals for GNOME Shell? A: I can't speak for the designers of GNOME Shell but they've talked about how the top panel should behave like a menu bar in many ways. This would definitely support that. If they have other design goals in mind, let's talk :) Fyi, if you want this to be included at this stage, above has to be clear before we (release team) vote on the external dep. Okay. Obviously that's a question that I can't answer. Though, one that I'd love an answer and a discussion about. --Ted 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: External Dependency Proposal: libappindicator
On Fri, 2010-02-19 at 11:00 +0100, Frederic Peters wrote: I would like to propose libappindicator as an external dependency. libappindicator is a simple library that provides a way for an application to put a menu inside an application specific area, most typically on a panel. It also provides a fallback to generic KDE Status Notifier Item and Notification Area protocols. Webpage: http://launchpad.net/indicator-application Design: https://wiki.ubuntu.com/DesktopExperienceTeam/ApplicationIndicators Tarballs: https://launchpad.net/indicator-application/+download License: LGPL v2/3 Bindings: Python and Mono Any plans for gobject-introspection support ? Yes, just haven't gotten to it :( The libindicate introspect support broke while I wasn't looking as well. I'll get to it (as I'm a big introspection fan) I just wanted to list the bindings that ARE working. There's also a patch for Vala support, but I haven't merged it in yet. --Ted 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: External Dependency Proposal: libappindicator
On Fri, 2010-02-19 at 14:16 +0100, Christian Persch wrote: I would like to propose libappindicator as an external dependency. libappindicator is a simple library that provides a way for an application to put a menu inside an application specific area, most typically on a panel. It also provides a fallback to generic KDE Status Notifier Item and Notification Area protocols. Webpage: http://launchpad.net/indicator-application Design: https://wiki.ubuntu.com/DesktopExperienceTeam/ApplicationIndicators Tarballs: https://launchpad.net/indicator-application/+download License: LGPL v2/3 Bindings: Python and Mono According to http://www.canonical.com/contributors this work is covered under canonical's horrible and inacceptable contributor agreement. IMNSHO Gnome should not depend on any work that treats external contributors in such a way. Like Clutter for example ;) Seriously though, GNOME already is dependent on projects that require contributor agreements. That hasn't been a requirement in the past, and I don't believe that it should be in the future. I'm very interested to see how the foundation board is proposing to deal with this. I imagine, that Canonical will work closely with the Board to ensure that our contributor agreement matches their guidelines. Also, why is this LGPL 23-only instead of the usual LGPL 2.1-or-later? Not to rehash what Cody said, but I'd hardly consider LGPL 2.1+ usual. Most of the lawyers I've talked to about it wouldn't do a + either. At least until the FSF makes me a member of it's board of directors and I get a vote on what + really means ;) --Ted 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: External Dependency Proposal: libappindicator
On Fri, 2010-02-19 at 23:20 -0500, Matthias Clasen wrote: If you are proposing an API that directly conflicts with something that is already provided in GTK+, you should really have a better one... I guess I don't feel like it's a conflict. I feel like it's an extension similar to how other libraries use parts of GTK, libappindicator uses GtkStatusIcon. An add-on if you will. Looking at the api docs to get beyond license questions, I see void app_indicator_set_menu (AppIndicator *self, GtkMenu *menu) If this does what I think it does (proxy part of a widget hierarchy over dbus), this is not a very supportable API. GtkMenuItems are generic containers, you certainly don't support all the things that people think of stuffing into menus. One of our goals was to make it very easy for application developers to add this new functionality into their applications. When looking at what the applications already had, this was menus, so we went with that. I don't think it's in any way perfect. It would be much cleaner to either expose the underlying dbus api or proxy something that is explicitly designed with this in mind: GtkActions. That's a great idea. What do you think would be a good API/name for a function that did that? Do you think it should take an array of actions or some sort of root action? Do you think that the function that takes a GtkMenu * should be deprecated? --Ted 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: application indicators
On Thu, 2010-02-18 at 13:32 -0500, Colin Walters wrote: * It'd be really nice to get some discussion of how this fits in with the design plans for GNOME Shell (note that in GNOME 2 if applications use this, you have potentially *3* representations of an application in the top panel, this is something we can obviously improve in GNOME Let's start this discussion now then! I'll defer to Jon or Jeremy on this, but it seems to me we could put this in the top application menu, assuming it's not used for notifications. I would hope that all applications wouldn't feel the need to have an app indicator. So hopefully there wouldn't be three for all applications... that being said, I think the application menu item would be an interesting place to put menus for an application that was using an app indicator. I'll ping usability and see if we can get this on the agenda for the usability hackfest next week. 3). * On a technical level, this really makes more sense in GTK+. Ted talked about this here: http://mail.gnome.org/archives/desktop-devel-list/2010-January/msg00042.html Now that module proposals are open we'll likely propose it as an external dependency next week (we're in a feature freeze crunch this week). Currently we're working on some patches for applications and should have more of them in an upstreamable state after this week after we get more testing and reviews on the work. But, do we agree that it makes sense for this to be in GTK+ (at least under #ifdef X11)? Ted seemed to say maybe.If we agree roughly on that, then do we want a cycle where we port a bunch of apps and components to use libappindicator, only to change it again when it moves in GTK+? Yes, I think GTK/glib is a good place. One of the big blockers is the requirement for DBus, which is going into those guys, but I'm not sure of the schedule for when that'll happen. I may be totally wrong here, but I'm just not sure how the schedules align. I think that, as long as the APIs are really similar, porting from libappindicator to the GAppIndicator (or whatever) shouldn't be too difficult. That being said, how can we make sure the APIs are really similar? --Ted 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: application indicators
On Thu, 2010-02-18 at 18:54 +, Bastien Nocera wrote: Have you done any research on what Windows or MacOS X provide in that area, for applications to use? How do the APIs differ? We weren't trying to match an API or duplicate one from OSX or Windows. What we were targeting is having a unified menubar. The API probably most closely matches KDE Status Notifier specification as we're basically wrapping the work that they did. Which, I guess we should mention, applications using libappindicator work in KDE. --Ted 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
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: GlobalMenu Application for inclusion as a GNOME module
On Thu, 2009-09-03 at 09:44 -0400, Colin Walters wrote: On Wed, Sep 2, 2009 at 7:17 PM, Sandy Armstrongsanfordarmstr...@gmail.com wrote: Assuming gnome-panel (and therefore panel applets) go away in GNOME 2.30, do you have a plan for integrating GlobalMenu in gnome-shell? The design for 3 is currently that application-global actions go in the application menu area, while document or window-specific ones remain in the window. So, I'm a bit confused by this separation. Does that mean File-Open would go in the application-global area (it doesn't work on a document or window) but then File-Close would go in the window? How are you planning on making this distinction on existing applications? --Ted 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: Planning for GNOME 3.0
On Fri, 2009-04-03 at 14:31 +0200, Vincent Untz wrote: Le jeudi 02 avril 2009, à 11:44 -0400, Willie Walker a écrit : For developers local to the Boston area, I'm happy to take a visit to your sight to go over accessibility considerations and to discuss your new UI's with you from an accessibility standpoint. I promise to focus solely on accessibility considerations and will avoid general armchair HCI quarterbacking. For those outside the Boston area, we can try to find someone to visit you for a face-to-face and/or we could do conference calls with screenshots or just shared desktops via VNC. Wow, this is an awesome proposal! Note that we can also arrange a special session during GUADEC or the Boston Summit for this if there's interest! +1 from me. I find with accessibility things I tend to guess more than I'd like. I'd really love to know that I'm doing it right. A session which talks about the various issues would be golden. --Ted 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: Planning for GNOME 3.0
On Thu, 2009-04-02 at 13:17 +0200, Vincent Untz wrote: There's one obvious question related to those potential changes: what will happen to the old way of doing things? For example, will we still make the GNOME Panel available if, for some reason, people are not immediately happy with GNOME Shell? There's no obvious answer to this, and this will have to be discussed. Some of us believe that it would be a good thing to keep providing the old elements for a limited time, to ease the migration. That being said, doing that would obviously take some development resources and slow down work on what should be the future. Not an easy choice, of course. However, it's worth noting that distributors and other community members using GNOME to build enterprise products will most certainly help maintain the GNOME 2.x shell for quite some time, and the project will support that to the greatest reasonable extent. I'm a little worried that this amounts to forking GNOME. Yeah, they'd all be in the same VCS, etc, etc, but at the end of the day there'd be two different user experiences. Currently, most distros that ship GNOME have it customized in various ways, but you can still spot a GNOME Desktop when you see one. You know it's GNOME. I'm worried that in the GNOME 3.0 world, for various technical and social reasons, that won't be the case. I'm worried that amounts to making GNOME a set of libraries and as recognizable on the Desktop of the Future(tm) as it is in a Nokia Tablet or a Garmin GPS today. --Ted 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: Metacity, Mutter, GNOME Shell, GNOME-2.28
On Wed, 2009-03-25 at 12:07 -0400, Owen Taylor wrote: So, basically, no I don't see a way that GNOME Shell coexists with Compiz other than as two separate shells for the GNOME desktop. And I think that coexistence is part of the problem with GNOME Shell becoming the default GNOME interface. Distributions need something that can gracefully decline between a composited and a non-composited environment. Not saying that Compiz can do that today, but we effectively get that with the combination of metacity and Compiz and lots of nasty hacks. But, overall it works. For a GNOME Shell like project to be successful it will need to have either two backends or some sort of architecture that would allow for GNOME Shell features to be integrated in other less featureful shell-like tools. While I love many of the concepts being explored and have suggested ideas for some of them, I just simply can't see the currently incarnation of GNOME Shell being the default for GNOME. --Ted 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: Metacity, Mutter, GNOME Shell, GNOME-2.28
On Mon, 2009-03-30 at 20:23 +0100, Alberto Ruiz wrote: 2009/3/30 Ted Gould t...@gould.cx: On Wed, 2009-03-25 at 12:07 -0400, Owen Taylor wrote: So, basically, no I don't see a way that GNOME Shell coexists with Compiz other than as two separate shells for the GNOME desktop. And I think that coexistence is part of the problem with GNOME Shell becoming the default GNOME interface. Distributions need something that can gracefully decline between a composited and a non-composited environment. Not saying that Compiz can do that today, but we effectively get that with the combination of metacity and Compiz and lots of nasty hacks. But, overall it works. For a GNOME Shell like project to be successful it will need to have either two backends or some sort of architecture that would allow for GNOME Shell features to be integrated in other less featureful shell-like tools. I don't get why that statement is true. For a GNOME Shell project to be successful, it hast to be freakin good. Mac OS X and Windows XP are way far more successful desktop environments than GNOME or KDE are, and they don't even have the notion of swappable windows managers, and if they do, none uses them. So what's your point here? Swappable Window Managers isn't important. Being able to have graceful degradation down to non-composited environments is. To be entirely honest, some of these are problems of our own situation. Neither Mac nor Windows have to worry about shipping binary nvidia drivers either. I'm not a fan of the situation, but we've solved this problem in the past with swapping window managers. I don't think that's the only way to do it, but it's definitely the easiest today. I'm not sure of all of the demo CDs out there, but I don't think that almost all of them come up in non-composited environments on the vast majority of hardware. Having the demo be entirely different than what you get when install seems like a really bad idea. --Ted 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: GSD should not housekeep the thumbnails
On Mon, 2008-09-22 at 18:19 -0500, Federico Mena Quintero wrote: JPEG loading with libjpeg is currently really slow (the benchmark being Photoshop, which is really goddamn fast for JPEGs). We could totally use some liboil/profiling ninjas to work on libjpeg to make it faster. Then, maybe thumbnailing on-the-fly wouldn't be painful. That sounds like a GREAT SoC/Senior Project/etc. assignment. Verifiable, measurable, contained and useful! --Ted 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: Session Management in 2.24
On Tue, 2008-03-25 at 12:04 +0100, Vincent Untz wrote: Le mardi 25 mars 2008, à 04:01 +, Emmanuele Bassi a écrit : On Tue, 2008-03-25 at 11:37 +0800, [EMAIL PROTECTED] wrote: Is it possible to add a extra task to improve logout dialog GUI? The current dialog in new-gnome-session is exactly the same as gnome-panel. Can we do as Ubuntu's own dialog, such as change button layout, show button bigger and more striking, add icon and tooltip text for each button? If it makes sense, I would like try. no, please: don't. I personally loathe that logout dialog, and love the default GNOME one, as it's less in your face and flashy. It will definitely not be the Ubuntu one. It might be changed, though. We are planning on moving to a new dialog in Ubuntu also after Hardy. It turns out the large number of buttons causes people to not read them, and then get a muscle memory to select items they don't want. I've done it several times myself. Also, I don't know of a mailing list for gnome-session, is this the place of any discussion or announcements you guys are planning on making? --Ted 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: Unifying the logout dialog, session management thoughts
On Thu, 2008-01-10 at 09:43 +0100, Vincent Untz wrote: Le mercredi 09 janvier 2008, à 21:46 -0800, Ted Gould a écrit : On Tue, 2008-01-08 at 14:03 +0100, Vincent Untz wrote: I don't think we need a new module. Dan and Lucas have worked on a new gnome-session with a dbus API. The dialog itself will be moved to gnome-session, since we'll be able to do what we want with the dbus API. So, in the short term would it make sense for Josselin to put the code into gnome-session so that the dialog could be displayed with a gnome-session-save --kill --show-dialog Then the dialog can end up in the newer code when it has a DBUS interface. Not sure which dialog you're talking about? We have two dialogs in gnome-panel for this :-) Yes, so I'm suggesting that they be moved to gnome-session, and be activated via the command line program. From Josselin's e-mail: since the logout/shutdown dialog boxes have been in gnome-panel, there is a double inconsistency across the desktop: * unsynchronized code duplication for GDM integration, and the same could arise for g-p-m communication code; * UI inconsistency between the default logout dialog (spawned by the panel) and the gnome-session dialog (e.g. triggered by g-p-m when you hit the power button). So getting them out of GNOME Panel and exclusively in GNOME session would solve the problem of the duplication. --Ted 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: Unifying the logout dialog, session management thoughts
On Tue, 2008-01-08 at 14:03 +0100, Vincent Untz wrote: I don't think we need a new module. Dan and Lucas have worked on a new gnome-session with a dbus API. The dialog itself will be moved to gnome-session, since we'll be able to do what we want with the dbus API. So, in the short term would it make sense for Josselin to put the code into gnome-session so that the dialog could be displayed with a gnome-session-save --kill --show-dialog Then the dialog can end up in the newer code when it has a DBUS interface. --Ted 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
