Re: Hello, I'm Martin
On Tue, 2016-09-27 at 12:38 +0100, Martin Wimpress wrote: > Today is my second day at Canonical. I've joined the Desktop Team and > I'm absolutely delighted to be here! > > I'm working from home in Hampshire, England and connected to the > Internet via shortwave radio. My recent professional background has > been in large scale server infrastructure and the transmission and > analytics of "black box" flight data. In my spare time I'm a MATE > Desktop core team member and the lead for Ubuntu MATE. > > I am a massive fan of film and cinema, all genres except horror. I'm > a podcaster and co-present the Ubuntu Podcast. I like to unwind by > cooking good food :-) Welcome Martin! I was kinda hoping you'd say "cooking good food and enjoying it with some mate" ☺ Hope that desktop issues are easier to decode than black box data. 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: [Desktop 13.04-Topic] Having a smart ubuntu desktop
On Thu, 2012-10-18 at 11:10 +0200, Didier Roche wrote: In a world where we are using more and more connected web services doing some of our tasks (web mails, online documentation editing, online music players…) should we imagine having a more adapated image to our users? This will mean reducing our main image footprint by removing some of those tools we install by default: I'm thinking of thunderbird, libreoffice, rhythmbox and other main applications of our desktop for instance. What I see is that more people are having data online, but that doesn't necessarily mean using online clients. Or, in many cases the reason they're using the web client is because they don't know that there is a better, more integrated experience available. The counter-part would be to make our desktop smarter. I can imagine: - having the messaging menu (or an icon in the launcher, or an icon in the dash) showing, the first time you try to configure your email account, a window asking for your email - based on the answer, either proposing to directly use a web application (with unity integration) for an @gmail.com, @yahoo.com… and other email providers known to have good web integrations. Otherwise, proposing to install thunderbird, ideally opening the account creating setup prefiled with the information already be done. (we can of course imagine a checkbox to override the smart behavior). So I think that this is an interesting idea, but I'd propose it a little differently. If you, for instance said that you have a Google account we could offer to integrate the GMail website but also offer to set up IMAP to Synchronize e-mail locally. Perhaps another option would be to use the online accounts dialog to show which applications are currently using that account, but also which applications could use that account if they were installed. --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: [Desktop 13.04-Topic] Having a smart ubuntu desktop
On Thu, 2012-10-18 at 18:19 +0200, Didier Roche wrote: That's precisely why I've written: (we can of course imagine a checkbox to override the smart behavior). prefiling thunderbird fields based on those (so the user doesn't have to type twice his email) would be awesome if we can get to it ;) Hmm, I would have said that as we can make it smarter and set up local sync as well ;-) It isn't removing the behavior of being smart, it is extending it to provide more routes. If we continually encourage people to use websites instead of local apps we decrease the stickiness of Ubuntu in general. They might as well be using Chrome OS. --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
On Wed, 2012-10-17 at 13:18 +0100, Colin Watson wrote: On Wed, Oct 17, 2012 at 01:07:58PM +0100, James Hunt wrote: On 16/10/12 10:07, Colin Watson wrote: On Tue, Oct 16, 2012 at 09:59:11AM +0100, James Hunt wrote: The current thinking is in fact to have 1 process / user. I think Scott was suggesting that everything _can_ be handled by PID 1, but whilst that may be technically true, my view is that the benefits of 1 process / user outweigh having PID 1 handle everything. Won't this mean that you'll have to have extra complexity to have pid 1 tell the per-user upstart processes about dead processes, since only pid 1 is able to find out about these reliably? You'd need this, for example, to be able to have a respawning user job. Unclear at this stage: we are still gathering requirements, so no concrete design yet. However, iff the plan is to allow arbitrary amounts of data to be stored in a session, I'd prefer that to be external to PID 1 :-) I can understand that. I think we need a clear idea of how we're going to handle things like respawning before the desktop team makes any concrete plans, though; and preferably with a minimum of complex plumbing in upstart. It was my understanding that we could get this by upstart putting all of the processes in the user session in a cgroup for that user. This would require upstart to be the first process in the user session, but I think that's achievable. Is my understanding there incorrect? --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
On Wed, 2012-10-17 at 06:43 +0200, Martin Pitt wrote: snip I don't think the reason why starting Unity and starting the Dash takes so long is in any way related to startup order or that we wouldn't have a mechanism of starting things on demand (D-Bus activation works just fine for the most part). To be clear, I don't think that using upstart will materially effect the startup time of Unity or the desktop in general. There might be slight gains through clearer dependencies, but I don't think that's a reason to do it. I think you've pointed out some real issues there, but those are probably independent threads themselves. One opportunity where having session upstart (or systemd, FWIW) jobs would be handy is to finally replace update-notifier. It's become a collection of totally unrelated things (launching update-manager, launching Apport on crashes, launching Jockey on missing firmware, etc) just because we always need a session daemon to listen for events. This could be replaced by individual jobs that are triggered by uevents and inotify watches. This will help maintainability and improve memory usage a bit (2.5 MB RSS for upstart vs. 13 MB RSS update-notifier), and shouldn't noticeably increase CPU overhead. I think that this is the key benefit, and I think it happens in other places other than update-notifier. I think we need a way to remove the need for many of the long running services that we have in the desktop. --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
On Wed, 2012-10-17 at 08:43 -0700, Steve Langasek wrote: On Wed, Oct 17, 2012 at 08:43:31AM -0500, Ted Gould wrote: It was my understanding that we could get this by upstart putting all of the processes in the user session in a cgroup for that user. This would require upstart to be the first process in the user session, but I think that's achievable. Is my understanding there incorrect? No. cgroups provide multi-process resource control and push-button reaping of a set of related processes; they don't change the Unix semantics of PID 1 parent-of-last-resort handling, which is what we're talking about here. Now, Lennart has pushed a kernel change to allow parent-of-last-resort delegation, but a) TTBOMK that's unrelated to cgroups, b) that would tie us to a bleeding-edge kernel interface, c) it's not clear that it's needed for what we're trying to achieve. I guess I think the parent-of-last-resort is different than just simple noticing when a task dies and restarting it. For instance in[1] there is this: If the notify_on_release flag is enabled (1) in a cgroup, then whenever the last task in the cgroup leaves (exits or attaches to some other cgroup) and the last child cgroup of that cgroup is removed, then the kernel runs the command specified by the contents of the release_agent file in that hierarchy's root directory, supplying the pathname (relative to the mount point of the cgroup file system) of the abandoned cgroup. This enables automatic removal of abandoned cgroups. Which it seems to me that if we created a cgroup of for instance Compiz, if Compiz and all of its children were to die the cgroup would close and upstart would get notified. It could respond to that by respawing a new cgroup with a new Compiz in it. --Ted [1] http://www.kernel.org/doc/Documentation/cgroups/cgroups.txt 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
On Tue, 2012-10-16 at 09:59 +0100, James Hunt wrote: On 15/10/12 21:23, Ted Gould wrote: 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 current thinking is in fact to have 1 process / user. I think Scott was suggesting that everything _can_ be handled by PID 1, but whilst that may be technically true, my view is that the benefits of 1 process / user outweigh having PID 1 handle everything. It would make sense to add in user job logging with enhanced user session support. I already have a branch for this which went through a number of iterations to ensure that the facility was safe, secure and fast. The only way that all those requirements can be satisfied from my findings is to have a user process handle user job logging. So this fits in with the overall thinking on upstart user sessions too. Great! I think that makes a lot of sense. I think it also means that we can do additional AppArmor isolations that we couldn't do on PID 1. So then can we really early (right now) rearrange the desktop startup to start upstart when then start dbus and gnome-session? That would give us the ability to start migrating jobs over to being upstart user jobs over time without having to do all at once (like we have done with SysV Init jobs in system startup). I'm sure when we do this at first it'll cause some regressions with things like a11y, but if we start early we can fix them by release time. It would also be nice to get the user upstart as the DBus activation broker on the session bus. That way it knows all ;-) 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. Agreed. Again, I have a basic 'upstart-file-bridge' in development. However, there are a quite a few issues that need to be dealt for such a bridge to work reliably. One of the biggies is supporting recursive watches explicitly, or atleast internally to minimise the risk of possible fd-starvation. The first issue though is finding a suitable API to use: snip I guess what I care about is that we provide a way to specify it in the job definition, if upstart does it a hacky way to get it bootstrapped that's fine. We can move from doing the shell based to an *notify based solution internally over time. I just want to start defining jobs and killing long running processes. 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. Yes, and a D-Bus bridge might be useful too? In fact a modular bridge design might be even better. Again, you could just do: dconf watch | initctl emit dconf DPATH=/desktop/unity/foo Again, same as above, if we could hide that from the task definition that would be fine IMHO. We should also look to see if we can have dconf help here, since we are paying the maintainer to work on it... --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
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
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: [Desktop13.04-Topic] Drop gconf from the default installation
On Mon, 2012-10-08 at 16:58 +0200, Sebastien Bacher wrote: - lightdm-remote-session-uccsconfigure (need to look at it but I guess it shouldn't be hard) I'll fix that one. It used GConf when Unity used it, but has been migrated to GSettings now with Unity, just need to update the packaging. --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
Visual Design Assets
Hello, We were talking about project management today and how to get work items on the list for needing visual design. Previously we have assigned tasks and bugs to design, or individual designers, but in talking with Nick what he'd prefer is that we assign those tasks and bugs to him -- and he'll ensure that they stay up-to-date with their internal list of tasks. He claims his e-mail inbox can handle the task ;-) So, in the future, if you could please do that hopefully it'll result in better coordination of work items. --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: What I love about Unity
On Fri, 2011-12-30 at 23:03 +0100, Jo-Erlend Schinstad wrote: Den 30. des. 2011 20:30, skrev Ted Gould: Thanks for writing this up. I appreciate it. We're never perfect, but it's nice to see some positive reviews every once in a while :-) It was not meant as a positive review and I don't want it to be understood as such. Sure, it wasn't a review really. I guess it should have read noting some of the positive aspects. Though, in general, I was less careful with my words since I wasn't replying to the mailing list ;-) The point was to separate between what users see and what programs see and why that's important. The ultimate goal for me, is to teach everyone that there are no fundamental differences between 10.04 and 12.04. snip In general, you are correct, but I think your language there might hurt your argument. I think that, for most people, it seems drastically different because the data is presented in a different way, but it is fundamentally the same data. So instead of saying nothing changed it might be easier to say only the emphasis changed. As an example we could look at the use case of finding applications. You can still browse for the applications in groups like you could in the Applications menu of 10.04. But, it's not as handy. On the flip side searching them is much, much, easier. So we've switched the emphasis from browsing to searching. --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: Proposed desktop-extra set
On Mon, 2011-11-07 at 17:25 -0500, Jeremy Bicha wrote: The proposed description from today's meeting was Every package that is NOT in main, but needed for a vanilla GNOME. Vanilla GNOME is defined by upstream in gnome-suites-core, gnome-suites-core-deps, and gnome-apps http://git.gnome.org/browse/jhbuild/tree/modulesets; snip gnome-bluetooth I think that gnome-bluetooth is in main. --Ted signature.asc Description: This is a digitally signed message part -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
Re: [Oneiric-Topic] Simplifying system sleep functions
On Thu, 2011-04-21 at 12:06 -0400, Tony Espy wrote: On 04/21/2011 11:49 AM, Ted Gould wrote: On Thu, 2011-04-21 at 11:34 -0400, Tony Espy wrote: On 04/19/2011 08:09 PM, Jason Warner wrote: Hi Everyone - Sending this on behalf of John Lea, desktop design lead. == Currently Ubuntu contains two separate sleep functions, suspend and hibernate. This choice confuses users and is a un-necessary complication to 'sleeping' the computer. The proposed change is to combine both 'suspend' and 'hibernate' into a single 'sleep' function. When the user presses 'sleep', the computer should both suspend and hibernate simultaneously. The computer remains suspended for a set period of time (e.g. 30min) or until the battery charge falls below a set level. At the point the suspend state is discarded, and if the user wakes the computer after this point their state is restored from hibernate. However if the user wakes the computer before the suspend state is discarded, the computer is restored from 'suspend' and the 'hibernate' state is discarded. I'm not a fan of this idea. If suspend works for the vast majority of users, why complicate it by adding a timed auto-hibernate to the equation? As a few folks have pointed out, what if hibernate fails? What if the BIOS doesn't properly support a wake timer? I'm pretty sure the latter criteria for triggering hibernate ( critical low-battery event while suspended ) already works. It essentially wakes the system from suspend, the power manager notices the battery is critically low, and invokes a hibernate. The timed scenario would work in a similar manner, except that after a timer event wakes the system, the power manager would have to have added logic to trigger the hibernate. I'm much more in favor of hiding or even removing hibernate from the UI, as long as it remains an option for critical low-battery event for those systems that properly support hibernate. I think these are all valid cases, but I think that we should support this feature. I think how we should handle this is with a whitelist if machines that we know hibernate works on. We can provide instructions on adding your machine to that list if you want. Otherwise machines that get certified by a vendor that cares about Ubuntu could ship their machine in that whitelist. Two words come to mind...maintenance nightmare. ;) After having lived through OEM-hell the last three months dealing with ACPI stress testing and hibernate failures on Sandy Bridge machines, the idea of maintaining a whitelist of machines that are known to have a working hibernate function, doesn't seem very practical to me. I'm confused, wouldn't your work there be effectively building that whitelist? Sounds like work you've already done ;-) What I think this does, and I don't believe it's really a bad thing, is makes it so there are effectively two Ubuntu experiences. That which you get from installing off of the CD on random hardware, and that which you get when you use a hardware vendor that cares about Ubuntu. I think that we need to make the experience the best we can for hardware vendors that want to participate in Ubuntu -- and provide reasonable fallback for those who don't. Personally, if we really want to consider this idea, I think we need to put cycles into making hibernate work better first ( faster, more user feedback, ... ). Another alternative would be to explore something more radical, along the lines of what OS X does, which actually tries to combine hibernate and sleep as opposed to running them in a serial fashion as proposed. So I guess that'd be the list of things we should discuss in the session. What are the requirements and changes we'd need to make hibernate work well enough to make this a reality? We can't budget time if we don't know what we want :-) Also, I thought this *was* how OSX did things. Can you explain how that works as I don't know. --Ted signature.asc Description: This is a digitally signed message part -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
Re: [Oneiric-Topic] Appindicators for xfce4-panel, lxpanel and others?
On Fri, 2011-04-08 at 18:10 +0200, Julien Lavergne wrote: Le Thursday 07 April 2011 à 10:43 +0200, Jo-Erlend Schinstad a écrit : It would be good for both developers and users if they were working equally well on Unity, Gnome-panel, Xfce4-panel and Lxpanel. It's already available for lxpanel / LXDE / Lubuntu, just not enable by default due to the additional memory usage. There is also a xfce panel applet which implement appindicators. How bad is the additional memory usage? I mean, if the answer is we want zero more, there's not much we can do to help. But I'd like to think the appindicators are fairly conservative in that regard. --Ted signature.asc Description: This is a digitally signed message part -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
Re: [Oneiric-Topic] Reducing number of patches in our packages
On Fri, 2011-04-08 at 17:18 +0200, Rodrigo Moya wrote: On Fri, 2011-04-08 at 10:12 -0400, Jorge O. Castro wrote: On Fri, Apr 8, 2011 at 4:36 AM, Rodrigo Moya rodrigo.m...@canonical.com wrote: How would this affect application authors, would they need to go update again? what do you mean? Basically do we have to go from app to app adjusting them again or is this a change we can do in one place? well, the proposal I've made is to patch gtk_status_icon_* API in GTK, so that we don't have to patch any app at all, as they would be already be using the GTK API. So this means no more indicator patches. So yes, it would be a change in one place + the removal of all the appindicator patches in our packages That doesn't really work because we add explicit menu support which GtkStatusIcon doesn't have. Most applications just respond to the signals and then build the menu. So we'd have to add API to GtkStatusIcon and then have patches to the individual applications to support that API. --Ted signature.asc Description: This is a digitally signed message part -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
Re: [Oneiric-Topic] Simplifying system sleep functions
On Thu, 2011-04-21 at 11:34 -0400, Tony Espy wrote: On 04/19/2011 08:09 PM, Jason Warner wrote: Hi Everyone - Sending this on behalf of John Lea, desktop design lead. == Currently Ubuntu contains two separate sleep functions, suspend and hibernate. This choice confuses users and is a un-necessary complication to 'sleeping' the computer. The proposed change is to combine both 'suspend' and 'hibernate' into a single 'sleep' function. When the user presses 'sleep', the computer should both suspend and hibernate simultaneously. The computer remains suspended for a set period of time (e.g. 30min) or until the battery charge falls below a set level. At the point the suspend state is discarded, and if the user wakes the computer after this point their state is restored from hibernate. However if the user wakes the computer before the suspend state is discarded, the computer is restored from 'suspend' and the 'hibernate' state is discarded. I'm not a fan of this idea. If suspend works for the vast majority of users, why complicate it by adding a timed auto-hibernate to the equation? As a few folks have pointed out, what if hibernate fails? What if the BIOS doesn't properly support a wake timer? I'm pretty sure the latter criteria for triggering hibernate ( critical low-battery event while suspended ) already works. It essentially wakes the system from suspend, the power manager notices the battery is critically low, and invokes a hibernate. The timed scenario would work in a similar manner, except that after a timer event wakes the system, the power manager would have to have added logic to trigger the hibernate. I'm much more in favor of hiding or even removing hibernate from the UI, as long as it remains an option for critical low-battery event for those systems that properly support hibernate. I think these are all valid cases, but I think that we should support this feature. I think how we should handle this is with a whitelist if machines that we know hibernate works on. We can provide instructions on adding your machine to that list if you want. Otherwise machines that get certified by a vendor that cares about Ubuntu could ship their machine in that whitelist. What I think this does, and I don't believe it's really a bad thing, is makes it so there are effectively two Ubuntu experiences. That which you get from installing off of the CD on random hardware, and that which you get when you use a hardware vendor that cares about Ubuntu. I think that we need to make the experience the best we can for hardware vendors that want to participate in Ubuntu -- and provide reasonable fallback for those who don't. --Ted signature.asc Description: This is a digitally signed message part -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
Meeting item: FUSA, passwords vs. session saving
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 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
On Fri, 2009-02-27 at 19:40 +, Chris Coulson wrote: 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). 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 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-power-manager human icon set
On Thu, 2008-12-18 at 00:03 +0100, Sebastian Heinlein wrote: Am Montag, den 15.12.2008, 10:01 -0600 schrieb Ted Gould: On Sun, 2008-12-14 at 11:38 +, Matthew East wrote: I'd like to draw some attention to this bug, which has been open now for over 2 and a half years, and is still a problem in the latest release. https://bugs.launchpad.net/gnome-power/+bug/32921 +1 We could also patch GPM so that it would use more icons if that would help. I believe that only uses icons on the 20s for percentage currently. You should better create a patch and propose it upstream. I will, if the art team determines it to be useful. But they haven't done that. --Ted -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
Re: gnome-power-manager human icon set
On Sun, 2008-12-14 at 11:38 +, Matthew East wrote: I'd like to draw some attention to this bug, which has been open now for over 2 and a half years, and is still a problem in the latest release. https://bugs.launchpad.net/gnome-power/+bug/32921 +1 We could also patch GPM so that it would use more icons if that would help. I believe that only uses icons on the 20s for percentage currently. --Ted -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
Re: Desktop Team Meeting, 2008-10-02
On Fri, 2008-10-03 at 16:39 +1000, Sarah Hobbs wrote: Scott James Remnant wrote: == gnome-themes == kwwii began a discussion about the gnome-themes package, which has been suggested to be split into two pieces; one containing good themes and the other not so good themes. seb128 strongly suggests retaining the gnome-themes package, separating out the others into a seperate package; or having gnome-themes as a dummy package depending on both split packages (with only the good themes installed by default) Can I ask what the rationale behind this is? No rationale was given in the meeting, either. What's the rationale for anything? CD Size :) My understanding is that the gnome-themes package includes the hicontrast themes which are very important, but also includes themes that are more user preferences. At least for a default install, we don't need to include all the themes people could want. --Ted -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
Re: Change the default screensaver from black to ubuntu logo
On Aug 22, 2008, at 4:10 AM, Mads Rosendahl [EMAIL PROTECTED] wrote: I was just looking over the posts about the change of screensaver. I couldn't really find out what the discussion ended with. Can anyone sum up the outcome of the it all? Is anyone working on it at the moment or will it remain black for Intrepid? My understanding is that it will remain black in Intrepid. --Ted -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
Re: Change the default screensaver from black to ubuntu logo
On Thu, 2008-08-07 at 10:28 +0100, Odysseus Flappington wrote: I wouldn't mind sitting down and trying to submit the patches to the relevant projects myself, they're prolly at the right level for a beginner, but I really don't have the time at this point, maybe next year some time. While I understand having too much to do, if you have a little bit of time now one thing that would be useful is to start documenting and filing bugs on the apps that don't support inhibit but should. This way there can be some discussion on the individual cases, but also we can have a way to determine when the task is done. I think making an umbrella bug Suspend happens when I'm doing stuff that is dependent on all of them would help. --Ted -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
Re: Change the default screensaver from black to ubuntu logo
On Wed, 2008-08-06 at 11:35 +0100, Odysseus Flappington wrote: If the inhibit sleep on CPU load was ever implemented, it never worked. While in theory this sounds nice, it is nearly impossible to implement in practice. The reality is that it's difficult to determine which things are important to block suspend based on CPU load alone. How important is the animation on your desktop? Based on CPU load? What is implemented is there is a DBUS interface that applications can call which inhibits suspend. So if the application is doing something that it knows suspend will effect negatively (playing a full screen DVD) it can block that. This interface has issues too, but it does make more sense as applications are more likely to know which actions should be blocking. --Ted -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
Re: Change the default screensaver from black to ubuntu logo
On Fri, 2008-08-01 at 17:05 +0200, Martin Pitt wrote: Personally I wouldn't mind a more attractive screensaver by default. However, I'd insist on keeping the black one if you are on a laptop which is currently running on battery. No need to waste precious power there for bling. The reality is that the blank screensaver will save very little power over the floating Ubuntu logos. The blank screensaver leaves the backlight on, which is the majority of the power. DPMS is still configured with laptop setups through GPM, and that'll save the power. I don't think the 2D GPU usage would make much of a difference in power usage. --Ted -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
Re: Inclusion of Abiword 2.6 in Hardy Heron
On Fri, 2008-04-04 at 22:35 -0700, Ted Gould wrote: So, I'm for it but I think it is a very close call. I'll probably make an attempt at the packaging as I want to play with Abicollab, but it seems unlikely I'll get it right. I think if we want this to happen someone with significant deb-fu would have to do it. Seems that Fedora is shipping quite a few patches right now: http://cvs.fedoraproject.org/viewcvs/rpms/abiword/devel/ From the change log, someone with an @abisource e-mail address has been doing the packaging. Probably fairly up-to-date. --Ted -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
Re: Inclusion of Abiword 2.6 in Hardy Heron
I guess this is the way the way I see it: -1 Feature freeze (2.6 has tons of new features) +1 Longer support cycle which is a plus for an LTS +1 Significant improvements that are worth pushing for -1 Packaging seems non-obvious as the Abi folks have rearranged things a little bit. Increases risk of doing something wrong. +1 I like Abiword and would like to see it succeed, I think that 2.6 lays and important foundation for future word processing on Ubuntu --- +1 Total So, I'm for it but I think it is a very close call. I'll probably make an attempt at the packaging as I want to play with Abicollab, but it seems unlikely I'll get it right. I think if we want this to happen someone with significant deb-fu would have to do it. --Ted On Fri, 2008-04-04 at 21:20 -0700, Dylan McCall wrote: There is a bug report filed, requesting to update Abiword to the new version 2.6 for Ubuntu Hardy. It does not appear that the desktop team has been notified of it automatically though it was suggested that you folks should have something to do with the freeze exception, so I may as well let you know myself! The reasoning is, in my opinion, indisputable. 2.4.x is now dead; it is not going to receive any updates whatsoever. This means that many outstanding bugs in the package would remain unfixed in Hardy without updating the packaged version of Abiword. I should also take this moment to point out that abiword-gnome is in main... Further, 2.6.x breathes wonderful new life into Abiword, and it would simply be a shame not to see it in the context of having new stuff. I think Abiword deserves some support since the program is making wonderful progress to being a good, integrated and easy to use alternative to OpenOffice -- possibly worth considering as a default some day. That day when Ubuntu can have a powerful and integrated office suite by default will not come any time soon, however, if the packaged version in its LTS release is out of date by over a year. Such an idea cannot grow support if people are seeing an ugly, buggy and outdated version of the program. (While this is a tad off topic, in my opinion such an idea would be a good one; OpenOffice is wonderful, but totally out of place as a default thanks to its behaving completely different from anything else in this desktop environment; the more momentum towards a full-fledged GNOME Office, the better!). Relevant bug report: bugs.launchpad.net/ubuntu/+source/abiword/+bug/202174 Thanks, -Dylan McCall -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
Re: Standardized home directories (was: Use a general ~Downloads-folder for all applications.)
http://specs.freedesktop.org/basedir-spec/basedir-spec-0.6.html On Wed, 2008-02-06 at 11:49 +0100, Bogdan Butnaru wrote: The advantage of having a well-defined standard is that we could file bugs on launchpad against each application that doesn't conform, rather than each user meddling with the config of each application by themselves. I agree. I think that they should be tagged with a standard tag, perhaps basedir-spec. Then perhaps we can get a blueprint together for a release once we know them. --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: Getting a usability patch into gnome-panel package?
On Wed, 2008-02-06 at 16:06 -0400, William Lachance wrote: A while back I fixed up a patch originally written by Novell to GNOME panel, which makes it impossible to move without unlocking it first (the default setting is locked). This prevents the user from inadvertently moving the panel when (e.g.) they're just trying to open an application. While I like this better, doesn't it make sense to remove the Lock option on individual applets at the same time? I don't see why you'd need both. --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: About this computer
On Mon, 2007-12-17 at 23:17 +, (=?utf-8?q?=60=60-=5F-=C2=B4=C2=B4?=) -- Fernando wrote: [sudo] Traceback (most recent call last): File test.py, line 113, in module main() File test.py, line 10, in main '/org/freedesktop/Hal/Manager') File /var/lib/python-support/python2.5/dbus/bus.py, line 244, in get_object follow_name_owner_changes=follow_name_owner_changes) File /var/lib/python-support/python2.5/dbus/proxies.py, line 241, in __init__ self._named_service = conn.activate_name_owner(bus_name) File /var/lib/python-support/python2.5/dbus/bus.py, line 183, in activate_name_owner self.start_service_by_name(bus_name) File /var/lib/python-support/python2.5/dbus/bus.py, line 281, in start_service_by_name 'su', (bus_name, flags))) File /var/lib/python-support/python2.5/dbus/connection.py, line 607, in call_blocking message, timeout) dbus.exceptions.DBusException: org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.Hal was not provided by any .service files Is this normal? No. Do you have HAL installed? This would normally be a package requirement, but since there is no packaging on e-mailed files ;) --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: Desktop Team Development Meeting, 2007-12-13
On Fri, 2007-12-14 at 15:02 +0100, Vincent Untz wrote: Le jeudi 13 décembre 2007, à 14:48 +, Scott James Remnant a écrit : * UbuntuSpec:exit-strategy : Working on cleaning up XSMP to make people happy enough to put it in more apps. So then we can query their document change status. Should solve many other UI issues. Currently there is an issue finding the current version of the spec. Seems it's not in git. I didn't bring up bazaar ;) Do you plan to work with upstream on this? I've not followed the spec since UDS, so I must admit I don't know where things are going, but this really sounds like something that could be done upstream (or at least tried to be done upstream) Dr. Untz, Yes. I started talking to GNOME folks, and realized that nothing was going to happen without cleaning up XSMP enough that people weren't angry at it anymore :) So, I've been talking to the X folks about revising the spec and cleaning it up so that it's more clear. I still haven't found the current version though... work in progress. --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: About this computer
On Fri, 2007-12-14 at 09:28 +0100, Loïc Minier wrote:
In [11]: rootfses
Out[11]: dbus.Array([], signature=dbus.Signature('s'))
So according to hal, I don't have any volume mounted on /; my setup is
LVM over MD, /dev/mapper/raid1-root is my /; /dev/md1 is the PV.
Hmm, I'm not sure what we should display in that case. I kinda want to
go with the Facebook answer: It's complicated.
Maybe we should just list all the hard drives, and try to avoid dealing
with how they are set up.
--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: Switching off tabs in Pidgin by default
On Mon, 2007-12-03 at 19:10 +, [EMAIL PROTECTED] wrote: I think instead the issue should be taken with the upstream dev-team. Making a change to have the name of the sender flash, instead of the active tab. This seems like a more logical request. And will allow us to keep our taskbars from being flooded with windows. So you're thinking: When the chat window is minimized the last user to send a message should have their name appear in the window title. Should the tab be shifted in the window when it is redisplayed? --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
Debian Screensaver
Hello, Currently in gnome-screensaver we're replacing the Debian logo screensaver with an Ubuntu Logo one. I'm thinking we should change that so that we're just adding the Ubuntu one instead of replacing it. I don't think it'll confuse users and it does pay tribute to Debian's importance to Ubuntu. I think the Ubuntu logo should still be default. --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: Debian Screensaver
On Wed, 2007-11-28 at 22:38 -0800, Ted Gould wrote: I'll go ahead and put the Debian screensaver in the Ubuntu package. Okay, so some of the Debian folks are saying that this might create more issues that it would fix. I'm now in favor of the status quo :) --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: Panel resizing
On Fri, 2007-11-16 at 18:07 +1300, Matthew Paul Thomas wrote: On Nov 16, 2007, at 4:29 PM, Ted Gould wrote: As long as the icons on the dock use the themes correctly this shouldn't be a big deal. ... Unfortunately they don't, as you can see by playing with the Panel Properties window in Ubuntu 7.10. The most egregious example is the Ubuntu icon itself: despite the presence of /usr/share/icons/Human/scalable/places/distributor-logo.svg, the Ubuntu icon in the Main Menu applet doesn't scale beyond 48px, and the Ubuntu icon in the default Menu Bar applet doesn't scale at all. (The latter might be constrained by the non-resizing Applications text; I think that's an example of basic aesthetic incompatibility between text menus and a manually-resizable panel.) Yes, I think that them not using them correctly is the issue here. Even if the icons did use the themes correctly, that wouldn't work well for panel sizes such as 30px, 31px, and 41px to 47px inclusive, just as it doesn't work well now. With a panel size that was specified in points and scaling itself based on the screen resolution, you might easily end up in those pixel ranges and not know why the panel looked bad. Think of it as we suckered the art team into hinting all the icons already ;) That's why I suggest combining a scaling-resilient icon style with a smart resizing algorithm. Each icon would need to be drawn only *once*, and the panel would look much more consistent at different sizes. Artists could spend less time redrawing the same icons at different sizes, and more time increasing theme coverage. I don't think that we'll ever get to the point of making one icon. Just likely it's nearly impossible to make a great font without any hinting. But, we could get better. Because all of the icons sizes are SVG, we can scale them within specific ranges and it's like that they'll look pretty good, most users wouldn't notice. The next step would to be starting to do things like pixel fitting rendering of the SVGs. ClearType for graphics. I don't know of anyone doing this today -- it'd be tricky to say the least. I think it is worth solving the first part of this, handling using the icons we have first as that will gain significant improvement. The pixel fitting would definitely make it better. --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: Panel resizing
On Fri, 2007-11-16 at 16:12 +1300, Matthew Paul Thomas wrote: So to avoid the panel looking ugly at different resolutions, I think you'll need a couple of other things first. An icon style that is robust at all sizes from 16px*16px upward (so, for example, it doesn't feature 1-pixel strokes). And a smart image-resizing algorithm, that can shrink (large) icons so they don't look blurry at any size. This is a problem, and the way that we combat it is to make several versions of every icon. I believe there are three, but I'm not sure on that. Basically, super small, bigger and then scalable. As long as the icons on the dock use the themes correctly this shouldn't be a big deal. Think of it as we suckered the art team into hinting all the icons already ;) --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: Panel resizing
[Sorry about the late reply, sent with the wrong address which made the list unhappy] On Tue, 2007-11-13 at 23:21 +0100, Sebastian Heinlein wrote: AFAIK the panel will be rewritten for GNOME 2.22. Such discussions should go upstream. I guess I don't see this as entirely a panel issue, it seems to be more of an Applications that use the panel issue. Many of those are in the panel packages, but folks like NetworkManager are some of the most notable problems and not part of the panel package. Furthermore the font size should not change. If you choose to have a larger font the panel will be larger automatically. That seems to be what everyone's leaning towards. Should we be specifying the panel size in points instead of pixels? --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
Panel resizing
One of the UI reviews of Ubuntu Gutsy specifically mentioned that the panel resizing was not good. And specifically that in the world of SVG icons it should be perfect. Having never resized my panels I set out to grab some screenshots: https://wiki.ubuntu.com/DesktopTeam/PanelResize One of the things that I think stands out is that the text in any of the applications stays the same. Should it change? Let me argue this from a couple different perspectives: -- Use Case -- The biggest use case that I can see for adjusting the size of the panel would be for people who have high DPI screens or a hard time seeing the panel. In those cases, it would make sense that if they can't see the icons, they can't read the text also. So as they adjust the panel size, they probably want the text to get bigger. -- Font size is DPI independent -- The font being used by these applets is the application font. Which in the appearances dialog is set to a point size. If these people really have a DPI issue, the font should adjust likewise automatically. What they really want at the end of the day is _all_ their fonts to get bigger, not just one on their panel. -- Not a bug, feature -- Some people might really want to have huge panels with small text. Perhaps they're trying to avoid a couple of bad lines at the top of their LCD screen by filling them with whitespace. I can't think of a good reason, but the status quo seems to always have some weight associated with it. What do people think about the text issue? Is text something that should change with panel size? --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
