Re: Firefox/NPAPI/Flash discussion for UDS

[Chris Coulson]

On 19/10/15 18:31, Bryan Quigley wrote:
> Hi Chris,
>
> The "do nothing" plan in this case would result in features being
> taken away during the primetime* life of the 16.04 LTS.  If we
> knowingly can't support them for even 2 years (likely more like 1
> year), should the LTS include them at all?
>
> 1- Minimal option:
> Just mention that the support will drop in the release notes, follow
> Firefox's lead for alerting users.
> Stop installing Flash in the Ubuntu installer
>
> 2 - Slightly more aggressive than Mozilla:
> Turn on click-to-play ahead of Mozilla
>
> 3- Aggressive option:
> Disable NPAPI for 16.04.
>
> Obviously, we can separate NPAPI vs Flash-NPAPI if we want in the above.
>
> I would rather users realize they also need Chromium/Chrome in their
> environments when they first install 16.04 rather than a random number
> of months later.  If we don't at least do 1 we're just asking for
> trouble,   I think doing number 3 for general NPAPI isn't that out of
> the question.
>
>> most sites that use Flash continue to work fine with the exception of things 
>> like Amazon Video
> I'm guessing most users have switched to Google Chrome for them.  Many
> sites that don't need DRM don't use Flash anymore anyway.
>
> I'll see if I can get a better answer for Adobe. Obviously EOY 2017 is
> very different than February 2017.
>
> Kind regards,
> Bryan
>
> *First two years, until the next LTS is released.
>
> On Mon, Oct 19, 2015 at 12:18 PM, Chris Coulson
>  wrote:
>> On 12/10/15 20:39, Bryan Quigley wrote:
>>> Hi all,
>>>
>>> Mozilla has announced their plan to drop NPAPI support for everything
>>> but Flash at the end of 2016[1].  That got me thinking that we might
>>> have to drop it sooner than that for 16.04 LTS [2] - which is what
>>> happened fro Chromium for 14.04 LTS.   Flash (NPAPI Linux) is also
>>> possibly going EOL for Firefox in February 2017 which might be good to
>>> talk about again as well.
>>>
>>> We previously talked about Flash and NPAPI last November [3][4].  We
>>> didn't believe at the time that Ubuntu alone had the pull to greatly
>>> change Flash use, and I don't think that's changed.
>>>
>>> If we do nothing for 16.04 LTS, then for Firefox:
>>> 8 months after released all plugins (aside from flash) stop working
>>> 10 months after release Flash is no longer maintained
>>>
>>> Flash 11.2 has also become less useful thanks to dependencies on hal
>>> [5] which is longer in Ubuntu, so many sites just don't work.  Also
>>> getting them to drop gtk2 should make it easier to maintain Firefox.
>>> These are really only relevant if we can get Adobe to commit to
>>> support Flash 11.2 for longer.
>>>
>>> I'm happy to ask upstream if we can have some people from Mozilla join
>>> us in a UDS session too, but it makes sense to hash this out a bit
>>> here first.
>>>
>>> Thanks!
>>> Bryan
>>>
>>> [1] 
>>> https://blog.mozilla.org/futurereleases/2015/10/08/npapi-plugins-in-firefox/
>>> [2] 
>>> https://groups.google.com/forum/#!topic/mozilla.dev.tech.plugins/sdLQgvG84uM
>>> [3] https://www.youtube.com/watch?v=6ZCVuy4ugDc
>>> [4] 
>>> http://pad.ubuntu.com/ep/pad/view/uos-1411-adobe-flash-on-firefoxlinux-eol/4MgjOcm3Oc
>>> [5] 
>>> http://www.omgubuntu.co.uk/2013/10/fixing-amazon-prime-streaming-drm-protected-flash-13-10?utm_source=feedly
>>>
>> Hi,
>>
>> I didn't feel that the session last time was all that useful - it
>> basically acknowledged that Flash on Linux is going EOL and that there
>> isn't much we can do about it. What has changed since then and what sort
>> of outcome are you looking for that would make an UOS session worthwhile
>> for this?
>>
>> AFAICT, the outcome at the end of any session will be the same: Mozilla
>> will still be planning to drop support for non-Flash NPAPI plugins
>> sometime next year, they still won't have any plans to support PPAPI
>> plugins, they'll still be investing in Shumway, Adobe will still be
>> planning to stop providing updates to Flash 11.2 based on some
>> non-public timetable (but we expect it to be sometime in 2017), and we
>> will keep distributing Flash 11.2 via the partner archive to all Ubuntu
>> releases for as long as it's supported.
>>
>> I wouldn't expect Adobe to spend time porting a piece of software that
>> they've depr

Re: Firefox/NPAPI/Flash discussion for UDS

[Chris Coulson]

On 12/10/15 20:39, Bryan Quigley wrote:
> Hi all,
>
> Mozilla has announced their plan to drop NPAPI support for everything
> but Flash at the end of 2016[1].  That got me thinking that we might
> have to drop it sooner than that for 16.04 LTS [2] - which is what
> happened fro Chromium for 14.04 LTS.   Flash (NPAPI Linux) is also
> possibly going EOL for Firefox in February 2017 which might be good to
> talk about again as well.
>
> We previously talked about Flash and NPAPI last November [3][4].  We
> didn't believe at the time that Ubuntu alone had the pull to greatly
> change Flash use, and I don't think that's changed.
>
> If we do nothing for 16.04 LTS, then for Firefox:
> 8 months after released all plugins (aside from flash) stop working
> 10 months after release Flash is no longer maintained
>
> Flash 11.2 has also become less useful thanks to dependencies on hal
> [5] which is longer in Ubuntu, so many sites just don't work.  Also
> getting them to drop gtk2 should make it easier to maintain Firefox.
> These are really only relevant if we can get Adobe to commit to
> support Flash 11.2 for longer.
>
> I'm happy to ask upstream if we can have some people from Mozilla join
> us in a UDS session too, but it makes sense to hash this out a bit
> here first.
>
> Thanks!
> Bryan
>
> [1] 
> https://blog.mozilla.org/futurereleases/2015/10/08/npapi-plugins-in-firefox/
> [2] 
> https://groups.google.com/forum/#!topic/mozilla.dev.tech.plugins/sdLQgvG84uM
> [3] https://www.youtube.com/watch?v=6ZCVuy4ugDc
> [4] 
> http://pad.ubuntu.com/ep/pad/view/uos-1411-adobe-flash-on-firefoxlinux-eol/4MgjOcm3Oc
> [5] 
> http://www.omgubuntu.co.uk/2013/10/fixing-amazon-prime-streaming-drm-protected-flash-13-10?utm_source=feedly
>

Hi,

I didn't feel that the session last time was all that useful - it
basically acknowledged that Flash on Linux is going EOL and that there
isn't much we can do about it. What has changed since then and what sort
of outcome are you looking for that would make an UOS session worthwhile
for this?

AFAICT, the outcome at the end of any session will be the same: Mozilla
will still be planning to drop support for non-Flash NPAPI plugins
sometime next year, they still won't have any plans to support PPAPI
plugins, they'll still be investing in Shumway, Adobe will still be
planning to stop providing updates to Flash 11.2 based on some
non-public timetable (but we expect it to be sometime in 2017), and we
will keep distributing Flash 11.2 via the partner archive to all Ubuntu
releases for as long as it's supported.

I wouldn't expect Adobe to spend time porting a piece of software that
they've deprecated and are only providing security fixes for to newer
technologies (eg, gtk3, away from HAL). Speaking as the Firefox
maintainer, the current plugin really doesn't cause any problems for
Firefox maintenance at the distro level (there might be some burden
upstream, but Flash already works fine in gtk3 Firefox). And I think
you're over-exaggerating the impact of not having DRM support (because
of the HAL dependency) - most sites that use Flash continue to work fine
with the exception of things like Amazon Video, which haven't worked out
of the box on Ubuntu since we dropped HAL from the default install
(IIRC, sometime around 2010). If there really was a big demand for this,
we'd have fixed it 5 years ago. I even wrote a wrapper to make it work,
but there wasn't much interest in it
(https://code.launchpad.net/~chrisccoulson/+junk/flash-hal-helper).

Regards
- Chris

-- 
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop

Re: Firefox + Thunderbird crash reports are now going to errors.ubuntu.com

[Chris Coulson]

Hi,

On 05/10/15 16:19, Bryan Quigley wrote:
> Hi,
>
> I'm happy to keep an eye out.
>
> By the way, why do we use the Mozilla crash reporter instead of errors
> for Firefox?
Because it's more useful for crash reports to go straight to the
developers working on it. Firefox developers don't spend their time
looking for bugs in the error trackers of random distribution partners,
and there is a non-zero cost for Ubuntu developers to manually forward
issues upstream. Given that we can send crashes directly to upstream's
crash database, anything else is just busy-work.
>
> There seems to be significant differences in the number of
> plugin-container crashes sent to errors [1] vs mozilla's site [2].
>
> Kind regards,
> Bryan
>
> [1] https://errors.ubuntu.com/?package=firefox&period=day
> [2] 
> https://crash-stats.mozilla.com/topcrasher/products/Firefox/versions/44.0a1/date_range_type/report/crash_type/plugin/os_name/Linux/result_count/50?days=28
>
> On Mon, Oct 5, 2015 at 10:49 AM, Chris Coulson  
> wrote:
>> Hi,
>>
>> Given some ongoing issues with symbol uploads, I have just disabled the
>> upstream crash reporter in both Firefox and Thunderbird for all
>> releases. This means that crash reports will be going to
>> errors.ubuntu.com rather than Mozilla's crash database for the next few
>> weeks.
>>
>> As upstream developers aren't looking there, I would appreciate some
>> help with keeping an eye out for major issues and ensuring that those
>> are forwarded upstream.
>>
>> I should stress that this change is temporary.
>>
>> Regards
>> - Chris
>>
>> --
>> ubuntu-desktop mailing list
>> ubuntu-desktop@lists.ubuntu.com
>> https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
Regards
- Chris

-- 
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop

Firefox + Thunderbird crash reports are now going to errors.ubuntu.com

[Chris Coulson]

Hi,

Given some ongoing issues with symbol uploads, I have just disabled the
upstream crash reporter in both Firefox and Thunderbird for all
releases. This means that crash reports will be going to
errors.ubuntu.com rather than Mozilla's crash database for the next few
weeks.

As upstream developers aren't looking there, I would appreciate some
help with keeping an eye out for major issues and ensuring that those
are forwarded upstream.

I should stress that this change is temporary.

Regards
- Chris

-- 
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop

Re: Firefox Extensions still needed?

[Chris Coulson]

On 10/08/15 22:21, Xavier Guillot wrote:
> Hi,
>
> I can't answer to this specific question, but as an user with Firefox
> as default browser on Ubuntu 15.04 Desktop, if those addons are kept,
> perhaps they need to be signed.
>
> Today when I updated to the latest FF Nightly 42.0a1 on the daily ppa,
> Mozilla activated the obligation to use only officially signed extensions:
> https://support.mozilla.org/fr/kb/add-on-signing-in-firefox
>
> All 3 Ubuntu addons were automatically desactivated.
>
> On the nightly version, there is an option in About:config to restore
> the old behavior (xpinstall.signatures.required set to false), but on
> future normal and beta versions of Firefox, it will not be possible
> anymore normally.
>
> Even if the addons are provided directly in the packages and not on
> Mozilla site, it is still also possible to validate them.
>
> Best regards,
>
> Xavier
>

Ubufox was signed a few weeks ago and will be shipped with the Firefox
40 update tomorrow. However, it's only been through preliminary review,
and future Firefox versions disable side-loaded addons that haven't had
a full review.

I'm not sure about the status of the other addons (cc'ing dbarth).

Regards
- Chris
-- 
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop

Re: Default Browser Follow-up

[Chris Coulson]

On 14/08/13 12:37, Nik Th wrote:
>
>
> Sorry but I cannot understand why a default application is such a big
> matter.
>
Hi,

The choice of default applications is important because a lot of people
will decide whether they want to continue using a product based on their
first impressions. You can't simply dismiss the importance of the choice
based on the availability of alternative applications in the Software
Center. If we made a poor choice of default applications, then this
would reflect badly on Ubuntu overall.

Regards
- Chris

-- 
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop

Re: Upload rights for desktop-extra-set

[Chris Coulson]

On 03/04/12 13:13, Martin Pitt wrote:

Hello Rico,

Rico Tzschichholz [2012-03-30  9:29 +0200]:

I am Rico Tzschichholz and have done some work regarding the GNOME3
packaging. I am working on publishing a gnome-shell package-set since
its early states in my Testing PPA and since Natty in the Gnome3-Team
PPA and Debian.

It would be great to have upload rights for desktop-extra-set which will
give me the opportunity to update and fix things directly in Ubuntu.

+1 from me. Thank you for all your work!

Martin




+1 from me too!

Chris
-- 
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop

Re: Why don't we use Mozilla ESR in Precise?

[Chris Coulson]

On 06/02/12 17:55, Micah Gersten wrote:

On 02/06/2012 05:49 AM, Jo-Erlend Schinstad wrote:

On 06. feb. 2012 10:22, Jason Warner wrote:

Hi All -

Firefox ESR is indeed interesting, and it would seem to answer some 
of the question corporations might have about Firefox, but I think 
it is less interesting for Ubuntu.




You have to understand that my original post was not meant as a 
proposal, but as an open question. If Ubuntu now prefers the rapid 
release pace of Firefox and Thunderbird, then it doesn't bother me 
that much. But it does represent a shift in strategy. 10.04 has used 
3.6 until very recently when it became unsupported. The reason that 
was given for not upgrading it, was the SRU process. The reason that 
was given for starting to upgrade Firefox in a rapid pace afterwards, 
was that Mozilla had changed their support strategy and that it 
wouldn't be feasible to backport the necessary security patches to 
old versions. But now, Mozilla has changed their support strategy 
again, making it unnecessary to circumvent the norms.


Now this becomes a question of communication, which to me is the 
biggest weakness Ubuntu has that we can do something about. If this 
is an active decision, then I would be interested to know when it was 
made and why we haven't heard anything about it. This is a 
significant shift, and though I try to pay close attention to what's 
going on, it came as a complete surprise to me. I looked for 
blueprints, but I couldn't find any; 
https://blueprints.launchpad.net/ubuntu/precise?searchtext=firefox. 
It is bad communication, and we need to improve. I really don't like 
those surprises. I spend a fair amount of time writing articles and 
participating in discussions, in an effort to reduce some of the 
misunderstandings that will always be a part of FOSS. Because 
development is high pace and developers doesn't always have time, or 
even skills, to write comprehensible non-tech articles explaining why 
and how. When things like that suddenly changes without notice, then 
it can easily make what I write, wrong. In that case, my 
contributions, instead of being a small part of a small solution, 
becomes a bigger part of a big problem. I don't think I have to 
explain why that's demoralizing.


Consider documentation writers. You've spent a few hours writing some 
paragraphs or pages explaining why Ubuntu doesn't use the newest 
version of Firefox. You're satisfied that your explanation really 
does explain and is comprehensible by anyone. That's not easy. It's 
hard work. So you commit. Then translators begin working on it. And 
translating single strings is not always that difficult, but 
translating an article, is. You finish two months ahead of schedule.


But then someone makes a silent little decision, and instead of being 
two months ahead, you're suddenly two years outdated. Bad 
communication hurts both enthusiasm and the finished product. We need 
predictability.


As usual, this has become much longer than I had intended. Let me 
finish by making a proposal. Let's use the ESR versions by default in 
LTS versions of Ubuntu, and add a package called something like 
firefox-fastpace for those who want that. This way, we don't disrupt 
the stability and predictability that is so attractive to those who 
chooses LTS versions, but also make it easy for those who do want to 
be on the cutting edge of the browser developments. When upgrading 
from an LTS to a non-LTS, the user should be asked if the ESR version 
should still be used, or switch to the fast pace version.


Thanks for reading,

Jo-Erlend Schinstad



There was a UDS session on this [1] which I lead.  I was originally of 
the opinion that the ESR for LTS releases was the best course of 
action.  However, my wise colleagues have shown me that I was 
mistaken.  I thought it would be just like 3.6 (stable ABI, still 
getting High/Critical fixes).  The problems are:


  * High/Critical fixes will be backported only if it's not too
difficult (whatever that means)
  * There are usually new security features with each rapid release
  * No large testing base as Jason pointed out
  * Upgrades from ESR -> ESR will also be more shocking as UI across 7
releases can change quite a bit
  * No guarantee of ESR existence past year 2 (or even that long
depending on how you read it)
  * No guarantee that the ESR is inherently a stable platform (meaning
that previously, you had a release that was frozen and bug fixed
for a while before it was stable, Firefox 10 was stable enough for
6 weeks of life, but who says it's stable enough for a year)
  * The ever changing web, we recently migrated Lucid and Maverick to
Rapid Release since Flash and some websites were breaking with 3.6
  * The browser is one of the most exploited pieces of software on
Linux outside of the Kernel
  * (from Lucid Firefox 3.6 comparison) Why is Chromium so much faster?

With all these reasons, it seemed clear that we do

Re: It's time to jettison CCSM

[Chris Coulson]

On 26/01/12 18:24, Micah Gersten wrote:


On 01/26/2012 11:55 AM, Jorge O. Castro wrote:

On Thu, Jan 26, 2012 at 12:24 PM, Micah Gersten  wrote:

Because novices are using a power user tool does not mean we should
remove a power user tool.  I think attention just needs to be called to
the problems that can be caused and what better tools exist for novice
users. Places like askubuntu.com and the Ubuntu forums would be good
places to evangelize this as well as omgbuntu and maybe webupd8.

We have a power user tool, MyUnity. If it doesn't do exactly what
people want then people will file bugs and then people will either
write the config option or not.

Then we'll have a power user tool that will work. And we do try to
warn people about the dangers of CCSM, but this is one of those cases
where we need to say "Sorry, you can't switch to the cube" instead of
"well you can switch to the cube, but if you fail the saving throw
your desktop turns into a wallpaper with no panels, no launcher, and
no file manager and removing these dot directories, but hey, linux is
about choice!"


You're missing a key point here that Compiz and CCSM are not Unity.  If
you want to make it so CCSM doesn't work with Unity, that's fine, but
don't hijack the Compiz configuration for non-Unity users.

Micah



Hi,

Personally, I'm in favour of removing this. I was surprised at the 
number of people I met in Orlando who had hosed their Unity session 
after running CCSM. If developers attending UDS are doing this and 
finding it difficult to recover from, then I'd hate to think what sort 
of experience ordinary users are having with it, and what this is doing 
for our reputation.


As others have pointed out, there are some useful settings that would be 
good to have in other configuration panels. The zoom settings being a 
perfect example - in fact, I can't believe we are asking visually 
impaired users to use CCSM to enable functionality like this. Aside from 
the fact that this tool is dangerous, the UI is terrible.


Gconf-editor exists for people who really want to mess around with 
advanced settings in compiz. CCSM is pretty much just a dump of 
everything you can tweak in gconf already (but with some icons and 
sliders), which means that it isn't really any better from a UI 
perspective. However, it's more difficult to hose your compiz 
configuration in gconf-editor (enabling/disabling plugins requires you 
to edit a list rather than clicking a checkbox, and there is no obvious 
way to do silly things like changing the configuration backend).


AFAICT, we don't provide UI's that expose every hidden preference for 
any other piece of software (we expect that people will use 
gconf-editor/dconf-editor or whatever for tweaking advanced settings), 
so I don't see why compiz should be all that different really.


And I don't think power users will really miss something like CCSM. 
Power users will just use the same tools that they have always used to 
tweak advanced settings in other applications. CCSM isn't a power user 
tool, but a loaded gun packaged in to a graphical UI that gives novice 
users a false sense of security.


Regards
Chris

--
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop

Re: Updating to gedit-plugins 3.3.1

[Chris Coulson]

On 22/12/11 22:46, Andrew Starr-Bochicchio wrote:

Hi all,

I have a branch of the gedit-plugins package ready for upload. It
updates to the new upstream version 3.3.1 and remerges on Debian. As
it seems likely that gedit will remain on 3.2.X for precise, I wanted
to check in with this list before uploading. This version adds the new
dashboard plugin, and I don't think that I'm the only one who'd like
to see that in precise. Currently the package depends on gedit>=
3.2.1, but there is no assurance that it will not bump to  gedit>=
3.3.X at some point in the development cycle.

Are we definitely staying on gedit 3.2.X? If so, does it make sense to
track gedit-plugins 3.3.X?

See: lp:~andrewsomething/ubuntu/precise/gedit-plugins/3.3.1

Thanks!

-- Andrew Starr-Bochicchio

Ubuntu Developer
Debian Maintainer

PGP/GPG Key ID: D53FDCB1



Hi,

It seems like it would be more appropriate to upload this to 
https://launchpad.net/~gnome3-team/+archive/gnome3 instead, which will 
be tracking 3.3/3.4 series packages that don't make it in to precise.


Regards
Chris

--
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop

[Desktop 12.04-Topic] Mozilla upgrade experience

[Chris Coulson]

Hi,

Note, I've already registered a placeholder blueprint for this [1].

We currently have a couple of problems with the Firefox and Thunderbird
upgrade experience, which users of Mozilla's update service don't
experience (ie, everybody on Windows, Mac, or anyone using mozilla.org
binaries on Linux).

1) A long standing issue we have is that upgrades totally break all
currently running instances of Firefox or Thunderbird until they are
restarted. This is made worse because we move the install location
around between updates, but pulling the rug from underneath any running
instance is probably never going to work reliably, even if the install
location doesn't change.

Note, this isn't just an issue with Mozilla applications - we just
notice it more because we update them a lot more frequently than
anything else in the archive. As another example, there was a Glade ->
GtkBuilder transition a few cycles ago, where upgrades between
distro-versions broke things such as the currently running instance of
gnome-panel [2] due to the glade files being replaced with gtkbuilder ui
files. I just wanted to point this out before people start blaming
Firefox that this is really a problem with how our package manager works...

Upstream are currently planning work around silent updates, and they
have a wiki page documenting how their update process will probably work
[3]. We might be able to learn some things from this.

2) We have no way of warning people if any of their addons might stop
working when we offer them an upgrade. People using upstream builds are
notified before an upgrade if any of their addons aren't compatible with
the update, and if there are no addon updates available to fix this.

Do we want to provide such functionality, bearing in mind:
- We haven't had that many bug reports yet from users complaining of
addons being incompatible after an upgrade, although there have been 1 or 2.
- As of the time of writing, 92% of addons on AMO are compatible with
the current Firefox beta (due to be released on November 8th). However,
approximately 75% of addons in use are not hosted on AMO [4].
- From Firefox 10 (Jan 31st, 2012), addons are going to default to being
compatible, with some exceptions (addons with binary components) [4].

Anyway, some things to think about.

Regards
Chris

[1] -
https://blueprints.launchpad.net/ubuntu/+spec/desktop-p-mozilla-upgrade-experience
[2] - https://launchpad.net/bugs/422568
[3] - https://wiki.mozilla.org/Background_Updates
[4] -
https://wiki.mozilla.org/Features/Add-ons/Add-ons_Default_to_Compatible

-- 
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop

Re: PiTiVi in Ubuntu 11.10 and beyond

[Chris Coulson]

On 02/09/11 20:00, Jeff Fortin wrote:
>> The pitivi team just got a new version out with quite some nice
>> changesin it and said they would do the glade to gtkbuilder
>> conversion thiscycle, that seems enough material to revisit the
>> decision later if thenew version is proving to be solid and the
>> gtkbuilder switch get done sowhat people think of keeping pitivi on
>> by default until before beta anddiscuss what we do in a desktop team
>> meeting then?
>
> Hi, we're about to release a new version (hopefully this week-end) and
> I was wondering if you folks had any special requirements. The last
> time we talked with people from Ubuntu we learned that you are very
> careful about saving space on the install CD, so to make pitivi fit we
> migrated from libglade to gtkbuilder, got rid of the gconf dependency
> (maybe some other things too, I forget), and I implemented a
> soft-dependency manager so most remainings deps are optional.
>
> We haven't heard from the Ubuntu/Canonical folks at all since I asked
> on this mailing list in May. I've been subscribed to this mailing list
> and haven't seen further discussions on revisiting the decision to
> include pitivi or not... and I couldn't get a hold of you on IRC when
> I publicly asked the question a couple of times. We're completely in
> the dark here. Can we have a status update with any outstanding issues
> you may have?
>
>

Hi,

Sebastien is on vacation this week and I'm not sure if he is checking
e-mails. I'm not in a position to give you an authoritative answer on
this, but PiTiVi was mentioned briefly in our desktop team meeting last
week - see
http://irclogs.ubuntu.com/2011/08/23/%23ubuntu-desktop.html#t15:54. The
consensus seemed to be that we would revisit the decision at UDS.

Sorry I can't give you a more definitive answer.

Regards
Chris
-- 
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop

Re: [Oneiric-Topic] Firefox translations in Launchpad/Language packs

[Chris Coulson]

On Thu, 2011-04-07 at 10:50 -0500, Micah Gersten wrote:
> On 04/07/2011 09:57 AM, Martin Pitt wrote:
> > Chris Coulson [2011-04-07  9:25 +0100]:
> >> - This means that Firefox will output xpi's for every language in the
> >> future (not just for en-US). We either need to package these in to
> >> dedicated language packs for Firefox (e.g., firefox-locale-foo)
> > I. e. build separate binaries from the firefox source? This would
> > certainly work and make the process a lot easier, too. We can then
> > integrate it into the existing language-selector framework.
> >
> I this is a good idea so that Firefox security upgrades aren't blocked
> on new language packs.
> >> - Note that searchplugins are shipped independently of the xpi's. If
> >> we are going to be shipping Firefox translations with our language
> >> packs (as we do currently), this would mean Launchpad would need a
> >> mechanism for importing and exporting the searchplugins alongside the
> >> xpi's too.
> > As they are so small, wouldn't it be much easier to just ship them all
> > in the firefox.deb, as they come from upstream anyway?
> 
> This is another reason why generating firefox-locale-foo would be good. 
> Otherwise, we'd be adding ~3MB to the main firefox package.
> 
> Micah
> 
> 

Note that the next firefox-trunk daily build will provide a full set of
language packs, including all of the upstream translated search plugins.

Regards
Chris


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] Default Browser

[Chris Coulson]

Hi,

On Wed, 2011-04-27 at 17:52 -0500, Micah Gersten wrote:
> Apologies for the delay in response, responses inline.
> 
> This isn't about maintenance as much as a uniform browser experience. 
> The theory being that casual users don't care about the latest and
> greatest stuff as long as they know they're secure and have the tools
> they need.

The fairly rapid uptake of Firefox 4 (over 100 million downloads so far,
and it's still not advertised as a major upgrade for 3.6 users yet)
would suggest that users do care about the latest and greatest. And as
mentioned briefly on IRC yesterday, Epiphany (and Midori) users aren't
all that secure right now, with Webkit not getting a security update in
over 6 months (despite the fact that a lot of Chromium CVE's are for
Webkit code). Chromium and Firefox seem to be the safer bet from a
security POV for Lucid and Maverick users at the moment.

> While having the Firefox test suite enabled is good, that only find
> regressions in Firefox itself.  As the default browser, I'm concerned
> about system integration breaking which the Firefox regression suite
> cannot catch.

What aspects of system integration are you concerned about that the test
suite wouldn't catch?

> Indeed, which is why making it simple for those who recognize the brand
> and want it as their browser is important.

> While sync is important for power users, how important is it for the
> casual user of Ubuntu?

Nearly every single person I know now owns multiple devices and already
shares data across those devices (whether that be just data from GMail
or Facebook). Regardless of whether users are using it right now or not,
this is the sort of thing that users do want to use. I don't think we
can dismiss the ability to share bookmarks and history across devices as
a power-user feature. The ability to share data is exactly the sort of
thing that users do expect to be able to do in a connected world.

> To use the old cliche, will grandma be happy if she gets a browser that
> looks different every 6 weeks?  If functionality moves, will people be
> able to adjust?  Your question hits the nail on the head, which browser
> will provide the best experience for our users?  Is it one that's
> constantly changing or one that's static for the release?  As power
> users, we generally want the latest and greatest.  

Grandma isn't going to get a browser that looks different every 6 weeks.
Whilst the featureset will change gradually over the life of an Ubuntu
release, there won't be radical differences between each version (have a
look at Fx 5 and Fx 6 now - they're merely incremental changes over Fx 4
rather than the major change that Fx 4 is over Fx 3.6, and this is what
the rapid release cycle will continue to bring).

Remember that Mozilla have over 400 million Firefox users to think
about, so they aren't really going to be pushing major changes to users
every 6 weeks if those changes all require significant adjustments to
the way that people use their browser.

> Mozilla's rapid
> release cycle gives us a great excuse to do this.  However, since we're
> trying to bridge the chasm here,  what are users on the other side
> looking for?
> Just for the record, the maintenance burden will be about the same
> whether Firefox is the default browser or not, the main issues are IMHO:
> Can we satisfy the core requirements of browser usage w/out using
> Firefox/Chromium?
> Will people be happy with a rapidly changing browser?

Well, the web will continue to evolve regardless of the default browser
we ship. The question is, will LTS users be happy with a browser that
doesn't support the latest web technologies in 2 years time?

> What's the tradeoff of a security update vs system integration breaking?
> 
> These questions also apply to Thunderbird as a default E-Mail client as
> well (s#browser|Firefox/Chromium#mail client|Thunderbird#).
> 
> Micah
> 

One other point I realised I overlooked when I noticed some spam e-mail
yesterday - what are the anti-phishing tools in other browser like?
Firefox and Chromium both have pretty solid phishing protection. Googles
test URL ( http://malware.testing.google.test/testing/malware/ )
triggers a warning in both browsers. However, when I click this link in
both Epiphany and Midori, I don't see any such warning. Lack of phishing
protection would be a big fail for the default browser from my POV.

Regards
Chris


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: Proposing to add Rodrigo Moya to ~ubuntu-desktop

[Chris Coulson]

On Wed, 2011-04-20 at 10:44 +0200, Martin Pitt wrote:
> Hello all,
> 
> Rodrigo has worked in the desktop team for several months now, and
> will continue to do so. In my experience he has picked up all the
> necessary packaging skills, is familiar with our processes, freezes,
> revision control handling, and our goals. In the last couple of months
> I did not have anything major to complain about his commits/uploads.
> 
> I propose to add him to the ~ubuntu-desktop team, so that he can
> commit to our branches and upload GNOMEish packages directly.
> 
> He has already been a PPU for a while:
> https://wiki.ubuntu.com/RodrigoMoya/PerPackageUploadApplication
> 
> As per https://wiki.ubuntu.com/DesktopTeam/Developers we need two more
> supporters for this.
> 
> Opinions?
> 
> Thanks,
> 
> Martin

+1

I haven't sponsored anything of Rodrigo's directly, but I did have a
quick look at his uploads and everything looks fine. He's very familiar
with the GNOME packages too. I'm surprised he wasn't already a member.

I'm sure that the additional help will be most welcome :)

Regards
Chris


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] Default Browser

[Chris Coulson]

On Thu, 2011-04-07 at 10:36 -0500, Micah Gersten wrote:
> Since now both Firefox and Chromium have committed to rapid release
> schedules, I think it's time to reevaluate the default browser in
> Ubuntu.  I am concerned that some of these upgrades might break system
> integration at some point.  While the security team does its best to
> prevent regressions, we can't test every case (especially ones we don't
> know about :)). Perhaps, if we can find one with sufficient features,
> switch to a Webkit based browser with a more normal release schedule (6
> months).  We could have an installer like Kubuntu does to install
> Firefox or Chromium on demand.  This will also keep the system
> documentation current within the release as the screenshots/menus won't
> be out of date shortly after release.
> 
> Thanks,
> Micah
> 
> 

Hi,

So, here are my initial thoughts about this. I'm not going to respond to
every mail in this thread, as that would just take too much of my time.
The response here is directed at the whole thread really.

What problem are we actually trying to solve here? If it is an issue of
maintenance, then I don't think it really solves anything for us - in
fact, I it makes it slightly worse IMO and I will attempt to explain
why.

Changing the default browser isn't going to make Firefox or Chromium go
away (unless you're suggesting we abandon them entirely, but you suggest
adding a shortcut to Firefox or Chromium in the default install). If we
change the default browser, we're still going to provide the same level
of support we have always provided for Firefox (and Chromium too, many
thanks to Fabien), and I definitely wouldn't want to see this change.
However, there would also be an extra browser for us to look after as
well, so if the problem is actually related to maintenance, then this
doesn't really solve it at all.

Also, quoting what you say in your mail:

> While the security team does its best to prevent regressions, we can't
> test every case (especially ones we don't know about :))

This is why we run the test-suite in Firefox now, and this should avoid
the need for a lot of manual testing (although, I'm not entirely sure
about the scope of your current testing). The Firefox test suite is
pretty extensive - see
https://bugzilla.mozilla.org/show_bug.cgi?id=644621 as an example of the
sort of level at which things can be regression tested in Firefox. I'm
not aware of many other projects that use testing frameworks that enable
you to test things at this level.

Also, remember that Firefox is quite an important and familiar brand
name for people migrating from other operating systems (and we do need
to entice these people to come and try Ubuntu). IMO, only Chromium can
match Firefox here, but you are suggesting we look at something else
anyway.

I see a lot of people are recommending Epiphany. I've used this before,
but it's never been my default browser. I used it again today, for the
first time in a year or so. Here's a brief summary of some of the things
I noticed:

- Text rendering is pretty bad. For some reason, text appears to be tiny
in Epiphany compared with any other browser (or any other application on
my desktop for that matter). This is easily visible by comparing
something like http://www.bbc.co.uk/news side-by-side in Firefox and
Epiphany.

- It has a very wasteful statusbar by default. Ok, I know you can turn
this off - but when I did this and then hovered over some links on the
page, I got a tiny overlay in the bottom-left hand corner displaying the
destination URL in the same barely-readable font that the rest of the
page is in (I had to squint so I could read it). These font sizes don't
seem to match anything else on my system.

- Invalid certificate warnings in Epiphany are unacceptable. Firefox
presents you with an obvious warning before displaying the content and
requires the user to acknowledge what they are doing in order to see the
content. Epiphany warns you of this by presenting the content normally
and displaying a broken padlock at the end of the URL bar (rather than
the unbroken padlock it usually displays). I hardly even noticed this.
This is basically https://bugzilla.gnome.org/show_bug.cgi?id=542454 ,
which is 2.5 years old. Jamie also reported the same issue in Launchpad
(https://launchpad.net/bugs/589877).

- My extra mouse buttons don't work in Epiphany (to go back and
forwards). This was reported 5 years ago
(https://bugzilla.gnome.org/show_bug.cgi?id=337852).

- There is no button to quickly bookmark the current page. Instead, I
have to go to Bookmarks -> Add Bookmarks... where a modal dialog
appears. There also appears to be no visual cue that the current page is
already bookmarked, although this is pretty minor.

- No session saving, and it doesn't even seem to ask for confirmation
when I close a window that has multiple tabs open.

- If I accidentally close a tab, I don't seem to be able to get it back
again.

In addition to this, Firefox has a signifi

Re: [Oneiric-Topic] Default Browser

[Chris Coulson]

Hi,

I will reply to this thread properly in a few days, but I wanted to
reply to this particular post now.

On Sat, 2011-04-09 at 14:23 +0100, Shane Fagan wrote:

> Firefox I don't think ever fit in because of XUL.

I'd like to know why you think Firefox won't ever fit in because of XUL?
After all, it's just another toolkit (like QT is just another toolkit,
or perhaps you think that QT wouldn't fit in too?), and Firefox does
actually render platform native widgets in most cases. In any case, I
think Firefox fits in pretty well in Natty, and I'd be interested to
know what you think currently stands out.

> It takes a lot of work every release to get the plugin going to make Firefox 
> act in some
> way like a regular addition to the desktop. 

As the Firefox maintainer in Ubuntu, this is news to me - perhaps I'm
missing something?

> Also on integration issue
> it also isn't integrated with unity with quicklists and all that kind
> of thing.

Well, it's already integrated with the global menu. In addition to this,
I'm going to be doing work on integrating it with the launcher in Unity
next cycle. However, a spec or some suggestions of useful things I could
do with quicklists would be welcome.

What else is missing?


> Maintaining the plugin for
> Firefox and adding more bits to it every time and working around
> compatibility stuff and having to keep the 2 packages going is a lot
> more effort than just patching something once and shipping it.

Same response as the one to your similar comment above ;)

Regards
Chris


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

[Oneiric-Topic] Default e-mail client

[Chris Coulson]

Priority: e?

At UDS for Natty we had a session to discuss the default e-mail client
in Ubuntu. Whilst we agreed that we would continue to ship Evolution for
11.04 (with developer effort mostly focused on Unity), we did discuss
alternatives. In particular, we looked at Thunderbird as a possible
replacement for Evolution in the future, and we discussed some pro's and
con's between the 2 clients as they are today. Also, David Ascher, Bryan
Clark and Andreas Nilsson attended UDS and gave an interesting
demonstration of the work that is happening on Thunderbird (I think this
session got recorded, so there might still be a video of this somewhere
if people are interested).

I will summarize briefly the outcome of that session.

Evolution pro's:
- Good integration with the desktop already (eg, messaging menu and
appmenu)
- Integrated with existing translation infrastructure
- Calendaring functionality by default, and integrated with the desktop
- Support for syncing contacts with U1
- Contacts sync with GMail
- GNOME release process is better aligned with our 6 month cycle
- Exchange support (no idea how well this works, but it exists)

Evolution con's:
- Outdated and confusing UI
- Historically has been fairly slow and unstable (although it is better
now)
- UI is pretty bad on netbooks and other small form-factor devices
- I'm not convinced that Evolutions additional features are that
important to our target users

Thunderbird pro's:
- Responsive and more active upstream
- Familiar brand for users moving from other operating systems, which
has the same benefits as shipping Firefox
- Lots and lots of extensions, and a very rich extension framework
- Initial account setup is so much more intuitive
- I like the tabbed interface ;)

Thunderbird con's:
- Translations not integrated with Launchpad (we have the same issue
with Firefox though)
- Integration with the desktop lacking (no messaging menu or appmenu)
- No exchange support
- Calendaring support is only available via an addon (Lightning), and is
not integrated with the panel clock
- No GMail or U1 contact sync (although GMail contact support is
available via an addon)

That is a brief summary of where we were at the last UDS. Since then,
the following work has happened:

- I have written an extension to add appmenu support to Thunderbird (and
Firefox), which will be merged upstream at some point.
- Mike Conley has been working on integrating Thunderbird with the
messaging menu and the launcher in Unity. There's pretty good progress
on this already, with extensions already available to test.
- Mike has also started working on U1 contact sync.

However, there have also been changes to the release schedule for
Firefox. It's currently unclear how these affect Thunderbird.

So, as of today, these are the things that I think we would miss if we
switched the default client to Thunderbird:

- GMail contact support - I think this one is fairly important, and I'll
offer to help get this fixed if I can.
- Calendaring support - Whilst I agree that the existing calendar
integration in Evolution is nice, I'm not convinced that it's a
deal-breaker for our target audience. I use the calendaring in Evolution
for work, but I don't miss it at all on my home desktop (where I use
Thunderbird).
- Exchange support - again, whilst Exchange support may be important in
a corporate environment, I don't think this is particularly important to
most users we are targetting. This seemed to be the consensus amongst
the people who attended the session at the last UDS too.
- Translation support in Launchpad - I'm already planning to work on
this anyway (see [1]).

So, we should discuss the default mail client again at UDS in Budapest.
Also, note that this is the last cycle before the next LTS, which means
that if we are going to change our default e-mail client, we need to do
it this cycle (else we probably won't have another opportunity until
12.10).

Hopefully I didn't miss anything off there.

Regards
Chris

[1] -
https://lists.ubuntu.com/archives/ubuntu-desktop/2011-April/002856.html


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: Default Desktop Experience for 11.04

[Chris Coulson]

On Fri, 2011-04-08 at 11:13 +0300, Timo Jyrinki wrote:

> For 11.10, probably something should be done about the logging in
> time, with is terrible at least with a traditional spinning, encrypted
> disk, compared to normal Gnome. Weirdly sometimes I saw a pretty fast
> logging in even after reboot, but normally it's 30s+ from gdm to
> desktop. Something is seriously churning the hard disk with seeks,
> possibly something that only occurs with specific conditions.
> 
> -Timo
> 

Yeah, we desperately need to reign this in next cycle. Startup time
(particularly the time taken for the desktop to load from GDM) has more
than doubled on my laptop since Maverick. It's now pretty much back to
the days where I can switch on my laptop and go and make myself a coffee
during the time it takes to boot.

Regards
Chris


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] Firefox translations in Launchpad/Language packs

[Chris Coulson]

On Thu, 2011-04-07 at 10:07 +0200, Martin Pitt wrote:
> Priority: low
> 
> Discuss integration of Firefox translations into Launchpad and
> language-packs. This decayed quite a bit since Firefox 4.0 in Natty,
> and right now we are back to just using the upstream tarballs.
> 
> Martin

Hi,

Thanks for bringing this one up.

There doesn't seem to be any reason for me not to forward to this list
the e-mail I've already sent to people internally about this, so I'll
quote it all here:

> Hi,
> 
> So, for the last few days I have been thinking about the current state
> of Firefox translations in Ubuntu, and thinking how we can improve it
> in future releases (remembering that we are probably going to get 3-4
> major Firefox versions per year too).
> 
> From my observations in Natty, here is a summary of where I think the
> current issues are:
> 
> 1) xpi updates are very much a manual process, and are decoupled from
> Firefox version bumps (meaning that it is extra effort to update
> xpi's). We need to be able to do this really really quickly in the
> future.
> 
> 2) po2xpi seems to be completely broken with the change to the chrome
> format in Firefox 4.
> 
> 3) po2xpi has produced broken xpi's in the past (e.g. bug 629640 is
> because of a broken chrome.manifest).
> 
> 4) For search plugins - Upstream Mozilla builds are shipping fully
> translated search plugins for a lot of search engines. They are also
> shipping per-locale search plugins which have a better relevance for
> each group of users. The only localization we are doing for search
> plugins is changing the search URL for Yahoo in some locales. The only
> locale-specific plugin we are shipping is Baidu for zh-CN users.
> 
> 5) Search plugin distribution seems completely broken to me. We're
> having to maintain a copy of all of the en-US search plugins in
> langpack-o-matic, for any locale where we make a locale-specific
> change in just one plugin. The search plugins really don't belong in
> langpack-o-matic.
> 
> 6) The PO format that Launchpad exports to be parsed by po2xpi isn't
> in a format which we can use to collaborate with upstream translators,
> and it's not easily convertible in to the right format either (i.e.
> properties and dtd files using the layout of the l10n-central
> Mercurial repo's).
> 
> I would like to resolve all of these issues, so I've been doing a bit
> of pre-UDS thinking.
> 
> - Firstly, I think we should kill po2xpi entirely. It's basically
> doing what the Firefox build system is already very good at doing
> (building xpi's from source). We should be using the Firefox build
> system to build the language pack xpi's that we ship. This resolves
> point 2 and 3.
> 
> - This means that we will build the xpi's when we build Firefox, and
> implies that we need to ship all locales with the Firefox source
> package. I've had a look at the layout of the l10n-central repository,
> and I think I've figured out how to merge all of the translations in
> to a single Firefox source tree (although I haven't tried it yet).
> This should fix point 1 (although it will make our source tarball
> bigger)
> 
> - This means that Firefox will output xpi's for every language in the
> future (not just for en-US). We either need to package these in to
> dedicated language packs for Firefox (e.g., firefox-locale-foo), or
> Launchpad will need to import all xpi's and then make them available
> to langpack-o-matic to build the language packs. In any case, the
> xpi's built by Firefox will be in the final form that we intend to
> distribute to users, and won't be modified by Launchpad or
> langpack-o-matic.
> 
> - I would still like to be able to use Launchpad to do Firefox
> translations. However, with Firefox building its own xpi's we would
> need to adopt a process similar to Chromium. I will write tools to
> convert from source <-> po, which could be integrated in to Launchpad
> eventually. This will enable us to import translations directly from
> the Firefox source. It will also enable us to export translations from
> Launchpad and easily convert them in to a format that could be merged
> in to the upstream Mercurial repo. I will ask upstream if they think
> this would benefit them (I don't see a reason why they wouldn't want
> additional help doing translations). This fixes point 6.
> 
> - If I merge the l10n-central branches in to our Firefox source, this
> means that we will automatically get the upstream translated search
> plugins (fixing point 4). I just need to be careful how we handle
> plugins that we modify to change affiliate codes. This would mean that
> we could drop the search plugins from langpack-o-matic (fixing point
> 5).
> 
> - Note that searchplugins are shipped independently of the xpi's. If
> we are going to be shipping Firefox translations with our language
> packs (as we do currently), this would mean Launchpad would need a
> mechanism for importing and exporting the searchplugins alongside the
> xpi's too.
> 
> Anyway,

Re: Feature Proposal: Enable two finger touchpad scrolling by default

[Chris Coulson]

On Thu, 2011-03-17 at 14:26 +0100, Milan Bouchet-Valat wrote:
> On jeu., 2011-03-17 at 14:14 +0100, Martin Pitt wrote:
> > Chase Douglas [2011-03-17  8:57 -0400]:
> > > We've received a request to enable two finger scrolling by default in
> > > Ubuntu. After querying some of our uTouch and X developers, everyone
> > > seems to be in agreement that this is a good idea.
> > 
> > This is in fact a request that I also already heard more than once
> > from friends of mine. It has been possible to enable this using some
> > xinput commands, but enabling it by default might be nice indeed.
> > 
> > It would be even better to add an option to gnome-mouse-properties
> > for this, of course :)
> This is already present in Maverick if I'm not mistaken. (At least it's
> present, maybe it doesn't work...)
> 
> The problem I can see with this is that two-finger scrolling can only be
> the default when the touchpad supports it. We need to fallback to
> scrolling from the side of the touchpad, else it would be a regression
> for many users.
> 
> 
> Regards
> 
> 
> 

Yes, the option already exists in gnome-mouse-properties.

I've just confirmed on my laptop that edge-scrolling *is* disabled when
turning on two-finger scrolling. My touchpad doesn't support two-finger
scrolling, so that would be a pretty bad out-of-the-box experience for
me (and other people in this situation) if we went ahead and did this.

Regards
Chris


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: Call for Natty Feedback!

[Chris Coulson]

On Wed, 2011-03-02 at 12:16 +0100, frederik.nn...@gmail.com wrote:

> 
> 26 Epiphany-webkit should be default browser, since it integrates with
> Unity and neither Chromium nor Firefox do that

Hi,

Well, that is going to improve right after Alpha 3 (see [1]).

Regards
Chris

[1] -
http://bazaar.launchpad.net/~mozillateam/firefox/firefox-4.0.head/revision/805



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: Call for Natty Feedback!

[Chris Coulson]

On Wed, 2011-03-02 at 06:28 +1030, Jason Warner wrote:
> Hello!
> 
> 
> Natty Feature Freeze is here and A3 is upon us! Anyone following along
> closely should see and feel a fairly stable and usable system,
> complete with Unity and classic Gnome. 
> 
> 
> I'd like to hear people's thoughts on Unity...and I'd like it to be
> pretty unfiltered and raw. In particular, I'm interested in seeing how
> people feel about:
> 
> 
> * The look and feel
> 
> 
> * Usability
> 
> 
> * Stability (knowing that we are entering a heavy bug fixing time!)
> 
> 
> * Highlights and favorite features
> 
> 
> * Perceived shortcomings and/or "wishlist" items
> 
> 
> You can reply to this email if your feedback is general/conversational
> or file a bug if you are experiencing a specific issue. Filing a bug
> with 'ubuntu-bug unity' command would do the trick and would get seen
> by the appropriate people for specific issues. 
> 
> 
> It will be fun to hear what everyone thinks! I look forward to seeing
> the feedback. 
> 
> 
> Cheers,
> Jason  
> 
> 
> PS. For those that like to navigate via keyboard (and who doesn't!),
> this should be
> helpful 
> http://askubuntu.com/questions/28086/keyboard-shortcuts-in-unity/28087#28087 

Hi,

Perhaps we should have something like
http://input.mozilla.com/en-US/beta/feedback for Unity?

Regards
Chris


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: Default bookmarks for Firefox and Chromium

[Chris Coulson]

On Wed, 2010-08-04 at 10:58 -0500, Steven wrote:
> http://ubuntuforums.org/index.php
> 
> 
> What's the rational behind:
> https://answers.launchpad.net/ubuntu/+addquestion
> http://www.debian.org/
> ? Do people really read the Answers part of Launchpad, and if so,
> would the devs really want people going there for support instead of
> the Ubuntu Forums (they are kind of busy, after all)? Also, why is
> Debian in there at all? Is this a courtesy to them since they're our
> upstream? I don't really understand why a casual Ubuntu user would
> need to go to debian.org, especially enough to warrant a default
> bookmark.
> 
> 
> -Steven

The Answers part of Launchpad is specifically designed for users to ask
questions and request support for their problems, and we want to
encourage the use of that. If we didn't want users to ask questions,
then there would be no point in providing the service.

Having said that, the Answers bookmark seems to be a little bit
redundant - most applications (Firefox included) already have a "Get
Help Online..." entry in the Help menu.

Regards
Chris



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

Default bookmarks for Firefox and Chromium

[Chris Coulson]

Hi,

A few weeks ago, philinux from ubuntuforums approached me with a
suggestion that we should think about updating the default bookmarks in
Firefox, and I suggested opening a bug report with some ideas for new
defaults on. With hindsight in mind, a bug report probably isn't the
best venue for discussing these things, and there has only been a
handful of suggestions so far.

Currently, we ship 4 extra bookmarks to the vanilla Firefox profile (I'm
not sure whether we add any bookmarks to the default Chromium profile
too, but we probably should do if we don't already). These are:

http://www.ubuntulinux.org/
http://wiki.ubuntu.com/ (although the link for this one is currently
broken, but fixed in bzr)
https://answers.launchpad.net/ubuntu/+addquestion
http://www.debian.org/

Do people think these are a good set of defaults, and if not - do they
have any ideas for other bookmarks they think should be there by default
(or think that any shouldn't be there)? I'm open to suggestions,
although I'm reasonably happy with what we have currently.

Regards
Chris





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: gnome-system-tools and a bug fix

[Chris Coulson]

On Sat, 2010-03-06 at 22:05 -0800, Erik Andersen wrote:

> Hi.
> Bug #433654 (https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/433654)
> is about audio not working properly on karmic and lucid when multiple
> users are used (one user gets to the audio device first and no one
> else can use it). Eventually it was figured out that if users aren't
> part of the audio group and consolekit is installed everything works
> properly. However, the defaults for a desktop user and an
> administrator users is to have them in the audio group which causes
> this problem. However, if consolekit isn't installed, you have to be
> part of the audio group to play sound. However, ubuntu-desktop depends
> on consolekit so it is rather reasonable to assume that it will be
> installed.
> So, to fix the bug, should the default administrator and desktop users
> be removed from the audio group?
> (This was basically asked at
> https://answers.launchpad.net/ubuntu/+source/gnome-system-tools/+question/103004
> , but it hasn't been answered yet, and I doubt the people who would
> know the answer have seen it.)
> Thanks,
> Erik B. Andersen
> 

Hi,

Thank you for bringing this to our attention. This issue has been
annoying me for a while now as well, so I'm glad that the issue is
understood. As the first user is no longer part of the audio group, it
makes sense that we don't add subsequent users to the audio group too,
so I will do the gnome-system-tools change to fix this this today.

Thanks!

Chris


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: Trimming down gnome-applets (and removing HAL dependency)

[Chris Coulson]

On Sun, 2009-08-02 at 09:59 +0200, Martin Pitt wrote:
> I'm not personally attached to this. To me it sounds that
> functionality which people need should rather be added to nm-applet.
> Is there a chance to split it out as a separate binary, so that it can
> get a dependency to g-network-admin and be dropped from the default
> install? If that's too much hassle, I don't mind dropping it. Karmic
> changed so much, I guess we need to leave some cruft along the way..
> 
> Thanks,
> 
> Martin
> 
> -- 
> Martin Pitt| http://www.piware.de
> Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
> 
Hi Martin,

I'm not sure whether the functionality already exists in Network
Manager, but I agree that would be the best place for it. I had a
thought about splitting it in to it's own binary, but that may be quite
difficult to do. When we remove an applet currently, we actually make it
a Null applet which will clean itself from the users config the next
time they load their panel. If we split modemlights in to it's own
package, then the extra package would need to be installed on upgrade,
else existing users with the modemlights applet on their panel will find
their panel config is broken after the upgrade. This would also affect
users doing a fresh install with an existing /home folder.

It might be possible to split it in to it's own package by hacking the
gnome-applets build system to build a real modemlights and a Null
modemlights applet, and then interchange them with update-alternatives
when the user installs the extra binary. That could be quite messy
though, and quite a bit of work.

I'm currently working on the 2.27.4 update of gnome-applets, so I'll
disable battstatus now (I think everyone will agree that we don't need
this one anymore). I'll leave modemlights for the time being, and see
what other peoples feelings are too.

Thanks
Chris


-- 
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop

Re: Trimming down gnome-applets (and removing HAL dependency)

[Chris Coulson]

On Sun, 2009-08-02 at 12:18 +0530, Bryan Quigley wrote:
> I agree on those two and have two more to add.  (If these are already
> gone/changed in karmic, sorry)
> Neither for full removal but they just shouldn't be ran per user at
> startup:
> Jockey - purpose is notification of hardware changes.  
> Update manager - purpose is notification of updates available
> 
> Thoughts?
> 
> On Sun, Aug 2, 2009 at 4:56 AM, Chris Coulson
>  wrote:
> Hi,
> 
> As you're all aware, the mixer-applet was recently disabled in
> Karmic.
> This got me thinking about whether we need all the other
> applets we
> currently have on the default install, and I wondered whether
> there were
> any others that could be disabled too.
> 
> I just wanted to know what everyone else thought. The ones
> that are
> currently installed which I think could probably be disabled
> are:
> 
> *** battstatus ***
> 
> This currently is able to use either a HAL backend or the
> legacy /proc/acpi interface for obtaining battery information.
> This has
> previously been (and might still be) a source of bugs when the
> legacy
> interface presents inconsistent information compared to what
> gnome-power-manager says (eg, battstatus saying laptop is on
> AC where
> g-p-m says it is on battery). AFAIK, the legacy /proc/acpi
> interface has
> been deprecated for some time, and we don't really want the
> HAL backend
> either. I'm not sure what benefit this adds in addition to the
> gnome-power-manager status icon, but I think it is a good
> candidate for
> removal. It is also the only applet in gnome-applets which
> depends on
> HAL. Fedora don't ship this applet currently.
> 
> *** modemlights ***
> 
> This has a dependency on network-admin from gnome-system-tools
> which we
> don't even install by default anymore, so is crippled on the
> default
> install anyway. To be functional, users will need to manually
> download
> gnome-network-admin, so I'm not sure if we'd lose anything by
> removing
> this applet.
> 
> Do people have any objections to removing these applets, or
> know if any
> users are still using them? Perhaps you can think of some
> other applets
> that could also be disabled? Is there any use-case I have
> missed which
> would prohibit the removal of these 2 applets?
> 
> Regards
> Chris
> 
> 
> 
> --
> ubuntu-desktop mailing list
> ubuntu-desktop@lists.ubuntu.com
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
> 
Thank you for your input, but I started this really to talk specifically
about gnome-applets. If you want to talk about removing other session
agents, then you might be better off starting a new topic with a more
appropriate title. And I don't really agree that you could remove the 2
examples you gave from user sessions anyway.

Regards
Chris


-- 
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop

Trimming down gnome-applets (and removing HAL dependency)

[Chris Coulson]

Hi,

As you're all aware, the mixer-applet was recently disabled in Karmic.
This got me thinking about whether we need all the other applets we
currently have on the default install, and I wondered whether there were
any others that could be disabled too.

I just wanted to know what everyone else thought. The ones that are
currently installed which I think could probably be disabled are:

*** battstatus ***

This currently is able to use either a HAL backend or the
legacy /proc/acpi interface for obtaining battery information. This has
previously been (and might still be) a source of bugs when the legacy
interface presents inconsistent information compared to what
gnome-power-manager says (eg, battstatus saying laptop is on AC where
g-p-m says it is on battery). AFAIK, the legacy /proc/acpi interface has
been deprecated for some time, and we don't really want the HAL backend
either. I'm not sure what benefit this adds in addition to the
gnome-power-manager status icon, but I think it is a good candidate for
removal. It is also the only applet in gnome-applets which depends on
HAL. Fedora don't ship this applet currently.

*** modemlights ***

This has a dependency on network-admin from gnome-system-tools which we
don't even install by default anymore, so is crippled on the default
install anyway. To be functional, users will need to manually download
gnome-network-admin, so I'm not sure if we'd lose anything by removing
this applet.

Do people have any objections to removing these applets, or know if any
users are still using them? Perhaps you can think of some other applets
that could also be disabled? Is there any use-case I have missed which
would prohibit the removal of these 2 applets?

Regards
Chris



-- 
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop

[Merge] lp:~chrisccoulson/gnome-session/ubuntu into lp:~ubuntu-desktop/gnome-session/ubuntu

[Chris Coulson]

Chris Coulson has proposed merging lp:~chrisccoulson/gnome-session/ubuntu into 
lp:~ubuntu-desktop/gnome-session/ubuntu.

Requested reviews:
Sebastien Bacher (seb128)

Here is the gnome-session patch to add 2 new DBus methods (RequestShutdown and 
RequestReboot). The FUSA can use these terminate the session properly.
-- 
https://code.launchpad.net/~chrisccoulson/gnome-session/ubuntu/+merge/5365
Your team Ubuntu Desktop is subscribed to branch 
lp:~ubuntu-desktop/gnome-session/ubuntu.
=== modified file 'debian/changelog'
--- debian/changelog	2009-04-08 11:03:50 +
+++ debian/changelog	2009-04-08 17:36:53 +
@@ -1,3 +1,12 @@
+gnome-session (2.26.0svn20090408-0ubuntu2) jaunty; urgency=low
+
+  * debian/patches/95_dbus_request_shutdown.patch:
+- Add "RequestShutdown" and "RequestReboot" DBus methods to
+  allow other applications to shutdown or reboot the machine
+  via the session manager.
+
+ -- Chris Coulson   Wed, 08 Apr 2009 18:04:43 +0100
+
 gnome-session (2.26.0svn20090408-0ubuntu1) jaunty; urgency=low
 
   * Updated to the current svn version (lp: #257067, #272854)

=== added file 'debian/patches/95_dbus_request_shutdown.patch'
--- debian/patches/95_dbus_request_shutdown.patch	1970-01-01 00:00:00 +
+++ debian/patches/95_dbus_request_shutdown.patch	2009-04-08 17:36:53 +
@@ -0,0 +1,97 @@
+Index: gnome-session-2.26.0svn20090408/gnome-session/gsm-manager.c
+===
+--- gnome-session-2.26.0svn20090408.orig/gnome-session/gsm-manager.c	2009-04-08 18:02:20.0 +0100
 gnome-session-2.26.0svn20090408/gnome-session/gsm-manager.c	2009-04-08 18:04:09.0 +0100
+@@ -2815,6 +2815,48 @@
+ }
+ 
+ gboolean
++gsm_manager_request_shutdown (GsmManager *manager,
++  GError**error)
++{
++g_debug ("GsmManager: RequestShutdown called");
++
++g_return_val_if_fail (GSM_IS_MANAGER (manager), FALSE);
++
++if (manager->priv->phase != GSM_MANAGER_PHASE_RUNNING) {
++g_set_error (error,
++ GSM_MANAGER_ERROR,
++ GSM_MANAGER_ERROR_NOT_IN_RUNNING,
++ "RequestShutdown interface is only available during the Running phase");
++return FALSE;
++}
++
++request_shutdown (manager);
++
++return TRUE;
++}
++
++gboolean
++gsm_manager_request_reboot (GsmManager *manager,
++GError**error)
++{
++g_debug ("GsmManager: RequestReboot called");
++
++g_return_val_if_fail (GSM_IS_MANAGER (manager), FALSE);
++
++if (manager->priv->phase != GSM_MANAGER_PHASE_RUNNING) {
++g_set_error (error,
++ GSM_MANAGER_ERROR,
++ GSM_MANAGER_ERROR_NOT_IN_RUNNING,
++ "RequestReboot interface is only available during the Running phase");
++return FALSE;
++}
++
++request_reboot (manager);
++
++return TRUE;
++}
++
++gboolean
+ gsm_manager_shutdown (GsmManager *manager,
+   GError**error)
+ {
+Index: gnome-session-2.26.0svn20090408/gnome-session/gsm-manager.h
+===
+--- gnome-session-2.26.0svn20090408.orig/gnome-session/gsm-manager.h	2009-04-08 18:00:57.0 +0100
 gnome-session-2.26.0svn20090408/gnome-session/gsm-manager.h	2009-04-08 18:02:07.0 +0100
+@@ -148,7 +148,10 @@
+ guint  flags,
+ gboolean  *is_inhibited,
+ GError*error);
+-
++gbooleangsm_manager_request_shutdown   (GsmManager *manager,
++GError**error);
++gbooleangsm_manager_request_reboot (GsmManager *manager,
++GError**error);  
+ gbooleangsm_manager_shutdown   (GsmManager *manager,
+ GError**error);
+ 
+Index: gnome-session-2.26.0svn20090408/gnome-session/org.gnome.SessionManager.xml
+===
+--- gnome-session-2.26.0svn20090408.orig/gnome-session/org.gnome.SessionManager.xml	2009-04-08 17:59:06.0 +0100
 gnome-session-2.26.0svn20090408/gnome-session/org.gnome.SessionManager.xml	2009-04-08 18:00:34.0 +0100
+@@ -301,6 +301,23 @@
+   
+ 
+ 
++	
++  
++
++  Request a shutdown with no dialog
++

[Merge] lp:~chrisccoulson/gnome-media/bug337235 into lp:~ubuntu-desktop/gnome-media/ubuntu

[Chris Coulson]

Chris Coulson has proposed merging lp:~chrisccoulson/gnome-media/bug337235 into 
lp:~ubuntu-desktop/gnome-media/ubuntu.

Requested reviews:
Sebastien Bacher (seb128)
-- 
https://code.launchpad.net/~chrisccoulson/gnome-media/bug337235/+merge/4422
Your team Ubuntu Desktop is subscribed to branch 
lp:~ubuntu-desktop/gnome-media/ubuntu.
=== modified file 'debian/changelog'
--- debian/changelog	2009-03-03 22:22:58 +
+++ debian/changelog	2009-03-12 21:49:02 +
@@ -1,3 +1,11 @@
+gnome-media (2.25.92-0ubuntu2) jaunty; urgency=low
+
+  * debian/patches/04_gst-mixer_help.patch:
+- Correctly display the help by calling gtk_show_uri 
+  as opposed to running xdg-open (LP: #337235). 
+
+ -- Chris Coulson   Thu, 12 Mar 2009 21:18:37 +
+ 
 gnome-media (2.25.92-0ubuntu1) jaunty; urgency=low
 
   * New upstream version (LP: #337462):

=== added file 'debian/patches/04_gst-mixer_help.patch'
--- debian/patches/04_gst-mixer_help.patch	1970-01-01 00:00:00 +
+++ debian/patches/04_gst-mixer_help.patch	2009-03-12 21:49:02 +
@@ -0,0 +1,47 @@
+diff -Nur -x '*.orig' -x '*~' gnome-media-2.25.92/gst-mixer/src/window.c gnome-media-2.25.92.new/gst-mixer/src/window.c
+--- gnome-media-2.25.92/gst-mixer/src/window.c	2009-03-03 17:20:53.0 +
 gnome-media-2.25.92.new/gst-mixer/src/window.c	2009-03-12 21:32:07.0 +
+@@ -99,34 +99,23 @@
+ }
+ 
+ static void
+-open_uri (GtkWindow *parent,
+-  const char *uri)
++cb_help (GtkAction *action,
++	 GnomeVolumeControlWindow *win)
+ {
+-  GtkWidget *dialog;
+   GdkScreen *screen;
++  GtkWidget *dialog;
+   GError *error = NULL;
+-  gchar *cmdline;
+-
+-  screen = gtk_window_get_screen (parent);
+-
+-  cmdline = g_strconcat ("xdg-open ", uri, NULL);
+-
+-  if (gdk_spawn_command_line_on_screen (screen, cmdline, &error) == FALSE) {
+-dialog = gtk_message_dialog_new (parent, GTK_DIALOG_DESTROY_WITH_PARENT,
++  
++  screen = gtk_window_get_screen (GTK_WINDOW (win));
++  
++  if (gtk_show_uri (screen, "ghelp:gnome-volume-control", GDK_CURRENT_TIME,
++  &error) == FALSE) {
++  	dialog = gtk_message_dialog_new (GTK_WINDOW (win), GTK_DIALOG_DESTROY_WITH_PARENT,
+  GTK_MESSAGE_ERROR, GTK_BUTTONS_CLOSE, "%s", error->message);
+ gtk_dialog_run(GTK_DIALOG(dialog));
+ gtk_widget_destroy(dialog);
+ g_error_free(error);
+   }
+-  g_free(cmdline);
+-}
+-
+-
+-static void
+-cb_help (GtkAction *action,
+-	 GnomeVolumeControlWindow *win)
+-{
+-  open_uri (GTK_WINDOW (win), "ghelp:gnome-volume-control");
+ }
+ 
+ static void

-- 
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop

[Bug 336647] Re: Please merge pidgin 2.5.5 from Debian

[Chris Coulson]

Thanks Didier :)

-- 
Please merge pidgin 2.5.5 from Debian
https://bugs.launchpad.net/bugs/336647
You received this bug notification because you are a member of Ubuntu
Desktop, which is a direct subscriber.

-- 
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop

[Bug 336647] Re: Please merge pidgin 2.5.5 from Debian

[Chris Coulson]

As we are passed feature freeze, I believe this will also need a FFe.
(https://wiki.ubuntu.com/FreezeExceptionProcess)

-- 
Please merge pidgin 2.5.5 from Debian
https://bugs.launchpad.net/bugs/336647
You received this bug notification because you are a member of Ubuntu
Desktop, which is a direct subscriber.

-- 
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop

[Bug 336647] Re: Please merge pidgin 2.5.5 from Debian

[Chris Coulson]

Surfaz - are you doing the merge then? You've subscribed sponsors, but
there isn't anything for them to sponsor yet

** Tags added: upgrade

** Tags removed: needs-update

-- 
Please merge pidgin 2.5.5 from Debian
https://bugs.launchpad.net/bugs/336647
You received this bug notification because you are a member of Ubuntu
Desktop, which is a direct subscriber.

-- 
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop

[Bug 325973] Re: "Starting File Manager" windows open uncontrollably

[Chris Coulson]

** Changed in: nautilus (Ubuntu)
 Assignee: Chris Coulson (chrisccoulson) => Ubuntu Desktop (ubuntu-desktop)
   Status: In Progress => Triaged

** Changed in: nautilus (Ubuntu)
 Assignee: Ubuntu Desktop (ubuntu-desktop) => Ubuntu Desktop Bugs 
(desktop-bugs)

-- 
"Starting File Manager" windows open uncontrollably
https://bugs.launchpad.net/bugs/325973
You received this bug notification because you are a member of Ubuntu
Desktop, which is a bug assignee.

-- 
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop

Re: Meeting item: FUSA, passwords vs. session saving

[Chris Coulson]

On Fri, 2009-02-27 at 20:13 +, Ted Gould wrote:
> That's basically what it does, but it also sends out a signal that it's
> going to shutdown to all the applications to allow them to inhibit the
> shutdown for various reasons.
> 
> http://www.gnome.org/~mccann/gnome-session/docs/gnome-session.html#id2735819
> 
> This could be that a document isn't saved or just because you feel like
> it.  I'm not sure if any apps have implemented all of the new API.
> There's been some talk about putting it into GTK+, but I don't believe
> that there is anything today.
> 
> But, maybe that is the fix.  Maybe we should extend gnome-session to
> have enough options that we just call it directly?  That way it doesn't
> give us the big ugly dialogs, but it can handle the PK/CK stuff.
> 
> There is currently only commands to bring up dialogs:
> 
> http://www.gnome.org/~mccann/gnome-session/docs/gnome-session.html#org.gnome.SessionManager.Shutdown
> 
>   --Ted
> 
Hi,

When I started writing the patch for the FUSA, I expected that
gnome-session exported an interface for restarting and shutting down
directly (without calling the dialog), as it is already possible to do
this for log out (calling org.gnome.SessionManager.Logout). I was
surprised when I realised that it didn't actually support this, which is
why I settled for sending a message to ConsoleKit directly and
implementing PolicyKit support in the FUSA. I think that patching
gnome-session to extend the Shutdown() method (or adding a new method)
is probably a good way to go. This means that other applications (such
as update-notifier's reboot dialog) could hook in to it as well, without
having to worry about PolicyKit support. The patch probably wouldn't be
too intrusive either.

If I have a bit of spare time over the weekend, I'll work on a patch
just to see how feasible it could be to implement.

Regards
Chris




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: Meeting item: FUSA, passwords vs. session saving

[Chris Coulson]

On Fri, 2009-02-27 at 18:15 +, Ted Gould wrote:
> Hello,
> 
> Chris provided a patch for using PolicyKit and ConsoleKit in the FUSA
> applet that makes it so that if multiple people are logged in, you can
> get a password dialog, and shutdown the system.  The way that this works
> is that it asks ConsoleKit for the shutdown and restart actions and if
> they need a password asks PolicyKit to handle it.
> 
> One of the things that this changes is that we're shutting down using
> ConsoleKit instead of asking GDM to do the shutdown for us.  This means
> that we're not logging out of the session, and doing the equivalent to
> "sudo shutdown -h now" on the command line.  So, if the session manager
> supports saving sessions it won't, as we're not even asking it to.
> 
> This obviously isn't great.  But, this is fixed in the new GDM as it
> will use DBus and so we can get the PK messages from the request to GDM,
> and we can again start asking GDM to do the shutdown/restart for us.
> But, that's a solution for Karmic.
> 
> I feel like today we're given the choice between two bugs:
> 
>   * Don't allow restart/shutdown to work with multiple users
>   * Don't save sessions on restart/shutdown
> 
> I guess I'm writing this to see if anyone has any ideas.  Anyone?
> Perhaps we should discuss these two during the desktop meeting on
> Tuesday?  I'm kinda thinking about going with the password dialog, but I
> think this shouldn't be an individual decision.
> 
>   --Ted
> 

Ted,

I had a brief look at the gnome-session code when writing the patch, and
it appears that the only thing that it does differently to the FUSA is
block on any applications that are trying to inhibit closing the
session. In this case, it pops up the inhibit dialog. Once the user has
confirmed this, all it seems to do is send Stop() to ConsoleKit in the
same way that the FUSA does now.

It seems that the only thing the new FUSA misses is being able to cancel
the action if some application wants to inhibit it (but that didn't
happen with the old GDM interface anyway).

Perhaps I'm missing something, but other than the inhibit dialog, it
doesn't seem like the FUSA does anything different to gnome-session now.

Regards
Chris


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

[Merge] lp:~chrisccoulson/totem/bug327304 into lp:~ubuntu-desktop/totem/ubuntu

[Chris Coulson]

Chris Coulson has proposed merging lp:~chrisccoulson/totem/bug327304 into 
lp:~ubuntu-desktop/totem/ubuntu.


-- 
https://code.edge.launchpad.net/~chrisccoulson/totem/bug327304/+merge/3501
Your team Ubuntu Desktop is subscribed to branch 
lp:~ubuntu-desktop/totem/ubuntu.

-- 
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop