Trying to reduce our memory and battery footprint
Hey guys, In the past cycles, we saw our memory need for an user session increasing quite a lot. One of the consequence is that our battery life on laptop diminished. I think having a session discussing and trying to review if we can work on the more offending daemons, disabling some plugins and so on, can help to put her in a better position on that front. As with install disk cleaning, some regular checkups like this one can be interesting to process regularly, we can also discuss about how to put some automated tests in place to ensure we tackle any regression then on power consumption or used RAM. Cheers, Didier -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
[Desktop 13.04-Topic] Discussing PS-related product processes
Hey everyone, as you probably know already, PS is our upstream for a lot of desktop components nowadays (Unity, compiz, webapps, indicators, multi touch stack...). The past cycle has been a real ride in term of features, which spawn the release team, translation team and documentation team with FFe/UIFe. We need to discuss a way to ease the process in both ways with all involved parts. Seeing the importance of those components on our stack today, I think for instance that having a standing FF/UIF exception as we have for GNOME components in ubuntu will make sense. However, the counter-part will be that PS will work on getting things landing only when they are ready, to avoid further and further refinements (and additional documentation changes) as we had in the past just to match the date gate. So this one can clearly be a win-win situation. Also, I want to discuss about what can land in a SRU. Little (few pixel move) change, not really impacting the documentation may want to be considered. We currently have 2 examples we can discuss in the session: - https://bugs.launchpad.net/unity/+bug/1043808 (Dash: Preview activation doesn't have instant feedback). Design worked on a spinner to partially address this one. This is a behavior change in some way, for a transient state, however it can be completely acceptable in a SRU as it will make the quantal experience better and don't change doc/add new strings, and so on. - Another one is the ribbon on the application lens for software-center content. This one is giving (due to pixelized images with the magazines) a lot of headaches to design and they would want to remove it. This specific case is an UI change, but doesn't seem it would impact the understanding of the lens. We can base the UDS discussion on those examples to see how we can get the process smoother and more reliable for everyone in the next cycle and going on. :) Cheers, Didier -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
Re: [Desktop 13.04-Topic] Discussing PS-related product processes
In case anyone does not know what PS stands for (which I am sure many don't). Its Product Strategy previously called DX-team. On Mon, Oct 15, 2012 at 12:43 PM, Didier Roche didro...@ubuntu.com wrote: Hey everyone, as you probably know already, PS is our upstream for a lot of desktop components nowadays (Unity, compiz, webapps, indicators, multi touch stack…). The past cycle has been a real ride in term of features, which spawn the release team, translation team and documentation team with FFe/UIFe. We need to discuss a way to ease the process in both ways with all involved parts. Seeing the importance of those components on our stack today, I think for instance that having a standing FF/UIF exception as we have for GNOME components in ubuntu will make sense. However, the counter-part will be that PS will work on getting things landing only when they are ready, to avoid further and further refinements (and additional documentation changes) as we had in the past just to match the date gate. So this one can clearly be a win-win situation. Also, I want to discuss about what can land in a SRU. Little (few pixel move) change, not really impacting the documentation may want to be considered. We currently have 2 examples we can discuss in the session: - https://bugs.launchpad.net/unity/+bug/1043808 (Dash: Preview activation doesn't have instant feedback). Design worked on a spinner to partially address this one. This is a behavior change in some way, for a transient state, however it can be completely acceptable in a SRU as it will make the quantal experience better and don't change doc/add new strings, and so on. - Another one is the ribbon on the application lens for software-center content. This one is giving (due to pixelized images with the magazines) a lot of headaches to design and they would want to remove it. This specific case is an UI change, but doesn't seem it would impact the understanding of the lens. We can base the UDS discussion on those examples to see how we can get the process smoother and more reliable for everyone in the next cycle and going on. :) Cheers, Didier -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
Re: [Desktop 13.04-Topic] Discussing PS-related product processes
On 10/15/2012 02:43 AM, Didier Roche wrote: Hey everyone, as you probably know already, PS is our upstream for a lot of desktop components nowadays (Unity, compiz, webapps, indicators, multi touch stack...). The past cycle has been a real ride in term of features, which spawn the release team, translation team and documentation team with FFe/UIFe. We need to discuss a way to ease the process in both ways with all involved parts. Seeing the importance of those components on our stack today, I think for instance that having a standing FF/UIF exception as we have for GNOME components in ubuntu will make sense. However, the counter-part will be that PS will work on getting things landing only when they are ready, to avoid further and further refinements (and additional documentation changes) as we had in the past just to match the date gate. So this one can clearly be a win-win situation. AIUI, GNOME only has a MicroRelease exception, not a standing FF/UIF exception. If Feature Freeze were targeted for Features, then there are about 2 months left in the cycle to clean up any bugs. Also, the time between Feature Freezes is about 6 months, so if their schedule were adjusted to focus on Feature Freeze instead of the release date, you'd still get about 6 months of feature work into the release (it also means you get 2 months of polish as well). Obviously, if something slips, there's still the exception process, but that should be the exception, not the rule. Thanks, Micah -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
Re: [Desktop 13.04-Topic] Discussing PS-related product processes
Adding ubuntu-doc to the CC list as this seems more a FF/UIFE discussion than a -desktop discussion. On 15 October 2012 03:43, Didier Roche didro...@ubuntu.com wrote: Hey everyone, as you probably know already, PS is our upstream for a lot of desktop components nowadays (Unity, compiz, webapps, indicators, multi touch stack…). The past cycle has been a real ride in term of features, which spawn the release team, translation team and documentation team with FFe/UIFe. We need to discuss a way to ease the process in both ways with all involved parts. Seeing the importance of those components on our stack today, I think for instance that having a standing FF/UIF exception as we have for GNOME components in ubuntu will make sense. However, the counter-part will be that PS will work on getting things landing only when they are ready, to avoid further and further refinements (and additional documentation changes) as we had in the past just to match the date gate. So this one can clearly be a win-win situation. I believe standing feature freeze exceptions need a history of doing the right thing, which is not how I would describe what happened for quantal. Otherwise, it seems to me that giving the developers and designers more official permission to break the freezes they are already breaking would make the problems worse. Or to put it another way, PS really really needs to land these features closer to the beginning of a cycle in the regular archives (not a PPA) to get near-real-world testing so that there is time for polishing. I wonder if the emphasis on keeping Ubuntu+1 working has gone too far and if we are actually pushing Ubuntu developers to land new features late. Also, I want to discuss about what can land in a SRU. Little (few pixel move) change, not really impacting the documentation may want to be considered. We currently have 2 examples we can discuss in the session: - https://bugs.launchpad.net/unity/+bug/1043808 (Dash: Preview activation doesn't have instant feedback). Design worked on a spinner to partially address this one. This is a behavior change in some way, for a transient state, however it can be completely acceptable in a SRU as it will make the quantal experience better and don't change doc/add new strings, and so on. Adding a busy spinner seems harmless enough and wouldn't impact docs or translations. I don't think it would make much of a difference for video reviews. On the other hand, I wouldn't want to see animations change near Final Freeze or after. - Another one is the ribbon on the application lens for software-center content. This one is giving (due to pixelized images with the magazines) a lot of headaches to design and they would want to remove it. This specific case is an UI change, but doesn't seem it would impact the understanding of the lens. I need more information about that issue. We can base the UDS discussion on those examples to see how we can get the process smoother and more reliable for everyone in the next cycle and going on. :) Cheers, Didier Thanks, Jeremy -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
[Desktop13.04-Topic] GNOME plans review
Hey, That's a classic, we usually review our plans for GNOME for the next cycle. That's going to be a controversial topic but I want to suggest we stay on stable GNOME this cycle, the reasons are (in random order): - tracking unstable GNOME is taking lot of resources that we don't invest in our desktop (packaging a new stack every 3 weeks, dealing with transitions, regressions, etc) - our desktop is quite less stock GNOME than it used to be, which means we have extra integration work to do and it's less trivial to do those on the way during the cycle - GNOME unstable series and Ubuntu working every day are hard to conciliate goals - GNOME is not communicating early enough on what is coming for us to discuss next cycle at UDS (see nautilus 3.6 in quantal) - GNOME is shipping stables with transitions half done (see gstreamer 1.0 this cycle) which is not something we want in Ubuntu - our feedback loop with GNOME is not really working nowadays, they don't have time to look at most bugs and we hit regressions and sit on them until somebody on our side has time to look at them, which means neither GNOME or us benefits much from tracking unstable GNOME... On the con side though: - it gives us less opportunity to work with upstream on resolving issues - we don't get early feedback on what is happening - the new version of libraries might have APIs our app writers might want to use Comments? Seb -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
Re: [Desktop13.04-Topic] GNOME plans review
Le 15/10/2012 19:50, Sebastien Bacher a écrit : - the new version of libraries might have APIs our app writers might want to use On that I would note that we should keep a ppa for the unstable serie packages, open to contributions. Most app writer do want to target users of stable users out there anyway and will probably not want to jump on using the latest apis added. I've to say I'm not convinced we shouldn't update the libraries yet, they should be ok to track though they are also the elements the most likely to create issues for other people working on the distribution (think ftbfses introduced by gtk deprecations). One element to think about also is how that would impact the GNOME remix if the plan there is not ship the latest GNOME... Cheers, Sebastien Bacher -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
Re: [Desktop13.04-Topic] GNOME plans review
I'm a fan of this for quality reasons. Shipping very latest GNOME used to give Ubuntu a cutting edge feel, but nowadays, shiny new Ubuntu features tend to come from Unity and friends. The interesting new user-facing changes that GNOME brings are (mostly) in Shell. So I don't think the default Ubuntu image would lose much in terms of staying relevant by sticking to stable GNOME releases. That said, the GNOME Remix would have a much harder time feeling cutting edge. -mt On 15/10/12 13:50, Sebastien Bacher wrote: Hey, That's a classic, we usually review our plans for GNOME for the next cycle. That's going to be a controversial topic but I want to suggest we stay on stable GNOME this cycle, the reasons are (in random order): - tracking unstable GNOME is taking lot of resources that we don't invest in our desktop (packaging a new stack every 3 weeks, dealing with transitions, regressions, etc) - our desktop is quite less stock GNOME than it used to be, which means we have extra integration work to do and it's less trivial to do those on the way during the cycle - GNOME unstable series and Ubuntu working every day are hard to conciliate goals - GNOME is not communicating early enough on what is coming for us to discuss next cycle at UDS (see nautilus 3.6 in quantal) - GNOME is shipping stables with transitions half done (see gstreamer 1.0 this cycle) which is not something we want in Ubuntu - our feedback loop with GNOME is not really working nowadays, they don't have time to look at most bugs and we hit regressions and sit on them until somebody on our side has time to look at them, which means neither GNOME or us benefits much from tracking unstable GNOME... On the con side though: - it gives us less opportunity to work with upstream on resolving issues - we don't get early feedback on what is happening - the new version of libraries might have APIs our app writers might want to use Comments? Seb -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
Re: Trying to reduce our memory and battery footprint
On Mon, 2012-10-15 at 09:02 +0200, Didier Roche wrote: In the past cycles, we saw our memory need for an user session increasing quite a lot. One of the consequence is that our battery life on laptop diminished. I think having a session discussing and trying to review if we can work on the more offending daemons, disabling some plugins and so on, can help to put her in a better position on that front. At UDS Q we discussed getting upstart into the desktop, which I think is critical for a lot of these. Most of them are basically file watches and other events that upstart could do for us. I don't believe that happened in the Q cycle, do we think that we could get upstart underneath things with some new events in R? I'd love to see that. Curious how we should plan sessions based on that, it seems that the upstart sessions and these would be co-dependent. --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: Trying to reduce our memory and battery footprint
Le 15/10/2012 21:10, Ted Gould a écrit : I don't believe that happened in the Q cycle, do we think that we could get upstart Hey, James pinged me recently because foundation is planning work for next cycle and wanted to know what's the most important on the list for desktop. I said it would be user session jobs, do other still agree with that? If you have other request I think there is still time at UDS to discuss those Cheers, Sebastien Bacher -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
Re: [Desktop13.04-Topic] Default file manager
Le 13/10/2012 21:33, Dylan McCall a écrit : I agree with you to the extent that Nautilus 3.6 doesn't fit well with Unity, but this is not localized to Nautilus. This is _almost every GNOME app going forwards_. Right, at the same time I think you listed most of GNOME there, so going forwards it's not likely being an increasing list of those (or upstream would need to be an hard-buy-in GNOME but the current trend shows that most app writers are still conservative and care about other desktops) I'll admit to looking at this from some distance, but that sounds like a wasteful strategy, and I suspect it would eventually drain more resources than trying to solve this 'for good'. If you handle divergence by patching these applications to fit downstream, without providing any benefit for upstream, these projects will never stop diverging — and the divergence is way bigger than Nautilus as it is. Well, what you are basically saying that is nautilus is a file-manager designed for *GNOME* and GNOME only and they have no intend to support other desktop, so if we consider unity different from GNOME we better fork or pick another one? Before talking about file managers, people should talk about how Unity fits with the direction GNOME applications are going. Because that is the problem: Unity has a very different vision for how applications should work than the GNOME project, which it depends on for applications and development tools. Right, that's a valid concern that we need to address, it's a bit orthogonal to the file manager though (which is part of the base OS). We don't have really issues with apps so far, no app out of the GNOME desktop itself has stopped supporting non GNOME users... I think there needs to be a detailed plan for how Ubuntu is going to solve that problem with upstream. Barring that, there needs to be some consensus around why solving it upstream is unacceptable. Without that understanding, I think it would be impossible to make an informed decision on what to do about Nautilus. Well, I'm not sure there is much to solve there. GNOME has its desktop and vision, Ubuntu has a different one, there is no reason we need to align our designs... it does indeed makes life of app writers harder, but it seems it's the way it has to be... Cheers, Sebastien Bacher -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
Fixing 'unity --reset'
Hi everyone, Some changes to unity this cycle means that unity --reset doesn't work. Didrocks sort of explained what needed to happen to make it work and J Phani Mahesh stepped up to the plate taking a stab at it. - https://bitbucket.org/jpmahesh/unity-reset/src/00e73b345dae/reset-gio.py?at=master Some things here: - It needs to be tested more widely. - Someone needs to integrate it into Unity at some point once we know it works so people can do unity --reset. Thanks J Phani for this contribution! -- Jorge Castro Canonical Ltd. http://juju.ubuntu.com -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
Re: Trying to reduce our memory and battery footprint
On Mon, 2012-10-15 at 21:19 +0200, Sebastien Bacher wrote: Le 15/10/2012 21:10, Ted Gould a écrit : I don't believe that happened in the Q cycle, do we think that we could get upstart James pinged me recently because foundation is planning work for next cycle and wanted to know what's the most important on the list for desktop. I said it would be user session jobs, do other still agree with that? If you have other request I think there is still time at UDS to discuss those I still don't understand why we want a single upstart instance and not one system one and one per session. I think that having a single instance is what makes user jobs difficult as you have to handle all the states of things like encrypted file systems, where if we started the upstart process later, PAM/lightdm would do it for us. There are other benefits too, but at least if I can move that out of the way I can get other features :-) The feature that upstart doesn't have today that I think would help the most on the power/memory front is file watches. That way processes that watch a set of files for some change, could just be started when that change happens, deal with it, and then shut themselves down. Second for me would be DConf key watches. It is hard today to have something start when a key is set to True to enable a feature. Usually there has to be some sort of framework involved or a process has to sit around waiting to be enabled. --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: Better Maintenance of IBus, i.e., the Input Framework
Le 03/10/2012 01:58, Ma Xiaojun a écrit : IBus upstream is working on 1.5 branch which removed and changed some feature to accommodate GNOME Shell. So what about Unity? Hey, Thanks for your email. Could you give details on what in ibus 1.5 is gnome-shell specific? Could it be adapted to work on other desktop environments? The plan so far would be to rewrite a keyboard,input method indicator to work with ibus 1.5 and GNOME 3.6 it seems... Sebastien Bacher -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
Re: Better Maintenance of IBus, i.e., the Input Framework
On Mon, Oct 15, 2012 at 4:14 PM, Sebastien Bacher seb...@ubuntu.com wrote: Thanks for your email. Could you give details on what in ibus 1.5 is gnome-shell specific? Could it be adapted to work on other desktop environments? http://desktopi18n.files.wordpress.com/2012/05/ibus-setup-for-1-5.png ( Compare with 1.4 ibus-setup if you can. ) 1. Switching keyboard shortcuts are becoming more limited. They now use single shortcut and rely on OSD to handle the case where there is more than two input methods. OSD: http://desktopi18n.files.wordpress.com/2012/02/gnome-shell-ibus-switcher-20120216.png But the controversial new design is not landed on GNOME 3.6. In GNOME 3.6 live image, there is no switching shortcut at all by default, which is as annoying as OSX's default. http://code.google.com/p/ibus/issues/detail?id=747 (Most starred bug for IBus) https://bugzilla.gnome.org/show_bug.cgi?id=682315 (Wait until 3.8?) 2. No language panel any more; always use Embedded in menu. Embedded in menu, as a default, is totally broken (no menu at all) on current Unity environment. Ubuntu is currently using Python based GTK2 UI. IBus 1.5 is supposed to be used with new Vala based GTK3 U. https://github.com/ibus/ibus/tree/master/ui/gtk3 3. Input methods has to be global. This seems to be another Nautilus story of GNOME. https://bugzilla.gnome.org/show_bug.cgi?id=684210 And IBus is following GNOME's policy. Fedora folks already suffered from this new change since Fedora ships pre-release IBus 1.4.99 since Fedora 17. http://code.google.com/p/ibus/issues/detail?id=1477 The plan so far would be to rewrite a keyboard,input method indicator to work with ibus 1.5 and GNOME 3.6 it seems... Cool. I'm an IBus member actually. I'd like to work with you guys. -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
[Desktop13.04-Topic] accessibility
I have three accessibility items. First, I'd like to drop the HighContrastInverse LowContrast themes. GNOME dropped support for these two themes late this cycle and they can no longer be set in an unpatched gnome-control-center. The idea is that this one theme will be significantly better than trying to support three mediocre themes. I hacked in support for these themes for 3.6.0 in Ubuntu 12.10 but gnome-themes-standard 3.6.1 isn't building for me yet with the hack. The two dropped themes aren't really terribly usable anyway, and unless someone steps up to maintain them, it's not worth the headache to try to keep them building. My second item is a requested feature. It would be really great if Unity would support the zoom and color effects built in to GNOME 3.6. By setting inverse or adjusting the brightness/contrast this way, all apps (even web pages in your web browser) will respect your color setting. http://bicha.net/img/gnome-zoom1.png http://bicha.net/img/gnome-zoom2.png http://bicha.net/img/gnome-zoom3.png And finally, Unity includes a mostly hidden accessibility status menu. It's probably a good thing it's hidden as it's almost useless at the moment. I filed bug http://pad.lv/1067166 requesting that a replacement be designed and included in 13.04. Jeremy -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
Re: [Desktop13.04-Topic] Default file manager
On 13 October 2012 04:57, Omer Akram om2...@ubuntu.com wrote: - GtkMenuButton needs to export its menus to dbus for use by the HUD there.. that is the thing that i don't like at all... we need to patch nautilus to show a complete menu bar. nautilus (and other gnome apps) with just one menu + settings cog isn't really that suits very well to Unity.. As file manager is more important than any other [gnome] app we would really want our file manager to look like a real app :-) The traditional File/Edit/View menu has been dropped from Nautilus and it's far from trivial to just add it back. And with about 75 items in the menus, Nautilus 3.4 isn't a particularly good UI or well-suited to Unity. As Dylan pointed out, a dozen apps have already switched to the new App Menu. So far only Epiphany Nautilus use the gear menu but that's likely to be fairly popular too. Presumably, these new menus work better with touch screens. So due to that reason it may make sense to switch to some other file manager... even if its currently less maintained and spend a few resources into improving that to a level that is competent enough for the next LTS. I think we have done that in the past for a greater good Could you give an example of a better file manager then? Jeremy -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
Re: [Desktop13.04-Topic] GNOME plans review
On Mon, Oct 15, 2012 at 11:08 PM, Jeremy Bicha jbi...@ubuntu.com wrote: The other big example this cycle is ibus. GNOME 3.6 doesn't work properly without a not-released-as-stable version of ibus. http://pad.lv/1045914 Have you contacted with IBus upstream? Developers of IBus are mostly using Fedora, which ships 1.4.99 since Fedora 17. We all know that IBus 1.4 on Unity is broken. But in fact IBus 1.4 on GNOME 3.4 (Precise) is not much better, the tray icon constantly flashes. I've been using a PPA for patched ibus-gjs for one of my 12.04 box. Official ibus-gjs doesn't work on precise, probably due to IBus version reason. The point is, you've been far behind on IBus stuff for long. -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
Re: [Desktop13.04-Topic] GNOME plans review
On 16/10/12 15:08, Jeremy Bicha wrote: One element to think about also is how that would impact the GNOME remix if the plan there is not ship the latest GNOME... Seb, I blame the remix idea on you. ;) Anyway, if the GNOME remix becomes an official flavor, I was hoping to then ask for permission to include the GNOME3 PPA due to our unique overlap with the flagship Ubuntu release. It's still a bit of a handicap as I don't think we could gain that trust if we included things that regressed Unity. If we don't fork ubuntu-control-center and ubuntu-settings-daemon off from gnome-control-center, then I don't believe it will be possible to ship GNOME Shell 3.7/3.8 next cycle. The last two cycles we've shipped the latest GNOME Shell but with bugs due to incomplete g-c-c/g-s-d support in Ubuntu (for 12.04 it was http://pad.lv/965921 with keyboard shortcuts not able to be configured from System Settings and for 12.10 it was 1045914 with a missing keyboard layout status menu). It's a reasonable guess that for 3.8, the GNOME developers will move aggressively to kill fallback mode and make optimizations and GNOME Shell will depend on those newer optimizations. A big reason for the GNOME remix is to show that you can contribute to GNOME from Ubuntu. I worry about what happens when most users are using a different distro than most developers. Shipping an outdated GNOME means that we have a much less compelling story to tell these developers. Jeremy Whatever happens I think its important to maintain compatibility between Unity and Gnome-shell. It would be terrible to end up back where we were at 18months ago where installing gnome-shell (from the ppa) broke everything else. Tim -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
Re: Fixing 'unity --reset'
Le 15/10/2012 22:14, Jorge O. Castro a écrit : Hi everyone, Some changes to unity this cycle means that unity --reset doesn't work. Didrocks sort of explained what needed to happen to make it work and J Phani Mahesh stepped up to the plate taking a stab at it. - https://bitbucket.org/jpmahesh/unity-reset/src/00e73b345dae/reset-gio.py?at=master Some things here: - It needs to be tested more widely. - Someone needs to integrate it into Unity at some point once we know it works so people can do unity --reset. Thanks J Phani for this contribution! Hey, Thanks J Phani for this contribution! As explained to Jorge on IRC yesterday, still some work is needed to integrate it into ubuntu: It would be better to use the python gobject gsettings binding rather than calling subprocess for gsettings reset directly. Also, not having the list hard-coded by detecting which schemas are installed on the system: otherwise, gsettings might fail if you reset a schema which isn't installed, and you can miss some if you don't reset extra plugins not part of the default install. (And the default list can also change over releases). Cheers, Didier -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
