Welcome to ~ubuntu-desktop, Rodrigo Moya
Hello all, Rodrigo has worked in the desktop team for several months now, and will continue to do so. He has picked up all the necessary packaging skills, is familiar with our processes, freezes, revision control handling, and our goals. As per the desktop developer policy [1] he got four supporters in the existing team [2], so I just added him to ~ubuntu-desktop now. Welcome Rodrigo, and thanks for your great work! Martin p.p. Ubuntu Desktop Team [1] https://wiki.ubuntu.com/DesktopTeam/Developers [2] https://lists.ubuntu.com/archives/ubuntu-desktop/2011-April/003001.html -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
Re: Proposing to add Rodrigo Moya to ~ubuntu-desktop
On Thu, 2011-04-21 at 10:06 +0200, Sebastien Bacher wrote: Le mercredi 20 avril 2011 à 10:44 +0200, Martin Pitt a écrit : I propose to add him to the ~ubuntu-desktop team, so that he can Hi, Rodrigo has been doing lot of desktop work this cycle especially on the GNOME3 updates and usually his updates don't have issues and can be uploaded as it so yes, let's add him to the team, welcome Rodrigo ;-) ok, thanks all! Now I can break everything I want then? :) thanks! -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
Re: Proposing to add Rodrigo Moya to ~ubuntu-desktop
Le jeudi 21 avril 2011 à 10:42 +0200, Rodrigo Moya a écrit : On Thu, 2011-04-21 at 10:06 +0200, Sebastien Bacher wrote: Le mercredi 20 avril 2011 à 10:44 +0200, Martin Pitt a écrit : I propose to add him to the ~ubuntu-desktop team, so that he can Hi, Rodrigo has been doing lot of desktop work this cycle especially on the GNOME3 updates and usually his updates don't have issues and can be uploaded as it so yes, let's add him to the team, welcome Rodrigo ;-) ok, thanks all! Now I can break everything I want then? :) We know where you live! congrats ;) Didier -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
Re: [Oneiric-Topic] Appindicators for xfce4-panel, lxpanel and others?
On Fri, 2011-04-08 at 18:10 +0200, Julien Lavergne wrote: Le Thursday 07 April 2011 à 10:43 +0200, Jo-Erlend Schinstad a écrit : It would be good for both developers and users if they were working equally well on Unity, Gnome-panel, Xfce4-panel and Lxpanel. It's already available for lxpanel / LXDE / Lubuntu, just not enable by default due to the additional memory usage. There is also a xfce panel applet which implement appindicators. How bad is the additional memory usage? I mean, if the answer is we want zero more, there's not much we can do to help. But I'd like to think the appindicators are fairly conservative in that regard. --Ted signature.asc Description: This is a digitally signed message part -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
Re: [Oneiric-Topic] Reducing number of patches in our packages
On Fri, 2011-04-08 at 17:18 +0200, Rodrigo Moya wrote: On Fri, 2011-04-08 at 10:12 -0400, Jorge O. Castro wrote: On Fri, Apr 8, 2011 at 4:36 AM, Rodrigo Moya rodrigo.m...@canonical.com wrote: How would this affect application authors, would they need to go update again? what do you mean? Basically do we have to go from app to app adjusting them again or is this a change we can do in one place? well, the proposal I've made is to patch gtk_status_icon_* API in GTK, so that we don't have to patch any app at all, as they would be already be using the GTK API. So this means no more indicator patches. So yes, it would be a change in one place + the removal of all the appindicator patches in our packages That doesn't really work because we add explicit menu support which GtkStatusIcon doesn't have. Most applications just respond to the signals and then build the menu. So we'd have to add API to GtkStatusIcon and then have patches to the individual applications to support that API. --Ted signature.asc Description: This is a digitally signed message part -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
Re: [Oneiric-Topic] Simplifying system sleep functions
On Thu, 2011-04-21 at 11:34 -0400, Tony Espy wrote: On 04/19/2011 08:09 PM, Jason Warner wrote: Hi Everyone - Sending this on behalf of John Lea, desktop design lead. == Currently Ubuntu contains two separate sleep functions, suspend and hibernate. This choice confuses users and is a un-necessary complication to 'sleeping' the computer. The proposed change is to combine both 'suspend' and 'hibernate' into a single 'sleep' function. When the user presses 'sleep', the computer should both suspend and hibernate simultaneously. The computer remains suspended for a set period of time (e.g. 30min) or until the battery charge falls below a set level. At the point the suspend state is discarded, and if the user wakes the computer after this point their state is restored from hibernate. However if the user wakes the computer before the suspend state is discarded, the computer is restored from 'suspend' and the 'hibernate' state is discarded. I'm not a fan of this idea. If suspend works for the vast majority of users, why complicate it by adding a timed auto-hibernate to the equation? As a few folks have pointed out, what if hibernate fails? What if the BIOS doesn't properly support a wake timer? I'm pretty sure the latter criteria for triggering hibernate ( critical low-battery event while suspended ) already works. It essentially wakes the system from suspend, the power manager notices the battery is critically low, and invokes a hibernate. The timed scenario would work in a similar manner, except that after a timer event wakes the system, the power manager would have to have added logic to trigger the hibernate. I'm much more in favor of hiding or even removing hibernate from the UI, as long as it remains an option for critical low-battery event for those systems that properly support hibernate. I think these are all valid cases, but I think that we should support this feature. I think how we should handle this is with a whitelist if machines that we know hibernate works on. We can provide instructions on adding your machine to that list if you want. Otherwise machines that get certified by a vendor that cares about Ubuntu could ship their machine in that whitelist. What I think this does, and I don't believe it's really a bad thing, is makes it so there are effectively two Ubuntu experiences. That which you get from installing off of the CD on random hardware, and that which you get when you use a hardware vendor that cares about Ubuntu. I think that we need to make the experience the best we can for hardware vendors that want to participate in Ubuntu -- and provide reasonable fallback for those who don't. --Ted signature.asc Description: This is a digitally signed message part -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
Re: [Oneiric-Topic] Simplifying system sleep functions
On 04/21/2011 11:49 AM, Ted Gould wrote: On Thu, 2011-04-21 at 11:34 -0400, Tony Espy wrote: On 04/19/2011 08:09 PM, Jason Warner wrote: Hi Everyone - Sending this on behalf of John Lea, desktop design lead. == Currently Ubuntu contains two separate sleep functions, suspend and hibernate. This choice confuses users and is a un-necessary complication to 'sleeping' the computer. The proposed change is to combine both 'suspend' and 'hibernate' into a single 'sleep' function. When the user presses 'sleep', the computer should both suspend and hibernate simultaneously. The computer remains suspended for a set period of time (e.g. 30min) or until the battery charge falls below a set level. At the point the suspend state is discarded, and if the user wakes the computer after this point their state is restored from hibernate. However if the user wakes the computer before the suspend state is discarded, the computer is restored from 'suspend' and the 'hibernate' state is discarded. I'm not a fan of this idea. If suspend works for the vast majority of users, why complicate it by adding a timed auto-hibernate to the equation? As a few folks have pointed out, what if hibernate fails? What if the BIOS doesn't properly support a wake timer? I'm pretty sure the latter criteria for triggering hibernate ( critical low-battery event while suspended ) already works. It essentially wakes the system from suspend, the power manager notices the battery is critically low, and invokes a hibernate. The timed scenario would work in a similar manner, except that after a timer event wakes the system, the power manager would have to have added logic to trigger the hibernate. I'm much more in favor of hiding or even removing hibernate from the UI, as long as it remains an option for critical low-battery event for those systems that properly support hibernate. I think these are all valid cases, but I think that we should support this feature. I think how we should handle this is with a whitelist if machines that we know hibernate works on. We can provide instructions on adding your machine to that list if you want. Otherwise machines that get certified by a vendor that cares about Ubuntu could ship their machine in that whitelist. Two words come to mind...maintenance nightmare. ;) After having lived through OEM-hell the last three months dealing with ACPI stress testing and hibernate failures on Sandy Bridge machines, the idea of maintaining a whitelist of machines that are known to have a working hibernate function, doesn't seem very practical to me. What I think this does, and I don't believe it's really a bad thing, is makes it so there are effectively two Ubuntu experiences. That which you get from installing off of the CD on random hardware, and that which you get when you use a hardware vendor that cares about Ubuntu. I think that we need to make the experience the best we can for hardware vendors that want to participate in Ubuntu -- and provide reasonable fallback for those who don't. Personally, if we really want to consider this idea, I think we need to put cycles into making hibernate work better first ( faster, more user feedback, ... ). Another alternative would be to explore something more radical, along the lines of what OS X does, which actually tries to combine hibernate and sleep as opposed to running them in a serial fashion as proposed. /t -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
Re: Default Desktop Experience for 11.04
On 2011-04-08 08:52, Martin Pitt wrote: Rick Spencer [2011-04-07 18:38 -0700]: 1. There are key feature regressions, for example, there is no systray support for many important applications. ... If this is a major issue, then frankly I'd rather just remove the whitelist and allow all old-style systray applications than dropping Unity by default completely. Totally unaware of the preceding considerations, I'm a little puzzled by this discussion. Based on what I have read in this thread, I'd vote for dropping the whitelist whether the issue is major or not. Personally I have noticed that mail-notification is broken in Unity, which is enough of a reason for me to keep using Classic for now when not needing Unity for developing tests. If the feature can be provided, without a price in the form of e.g. extra maintenance time, is there a good reason for disabling it? Closing the door prematurely on the users and developers concerned seems not right to me. -- Gunnar Hjalmarsson -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
Re: [Oneiric-Topic] Appindicators for xfce4-panel, lxpanel and others?
Le Thursday 21 April 2011 à 10:33 -0500, Ted Gould a écrit : How bad is the additional memory usage? I mean, if the answer is we want zero more, there's not much we can do to help. But I'd like to think the appindicators are fairly conservative in that regard. For a modern PC, it's not really an issue. But for Lubuntu, which target limited hardware, each Mb is important :) We consider that the gain is not enough vs the memory usage. But this could change in the futur :) However, It was not a complain about indicators. To be complete, the implementation of indicators in lxpanel is also not (IMO) good enough to be enable by default. Regards, Julien Lavergne -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
