[Desktop12.10-Topic] User configuration change after package upgrade
Hey everyone, I know that will sound like a deja-vu for some of you (we did discuss about it at UDS Brussels IIRC), however I think the situation nowdays will make it more needed than what it was in the past. Sometimes, we need to change/update some user configuration on upgrade. However, as everyone knows, the upgrade/installation phase is proceeded by root, so we dont have a sane and secured access to all user data on this machine at this particular time. Of course, there is still the gold rule don't change user configuration on upgrade that we try to keep as much as possible, and in this case, changing the gsettings default is just enough most of the time. However, some cases are still valid and changing the gsettings default doesn't work, on top of my head: - Unity launcher icons. Some softwares renames their .desktop file name (ubuntu one for instance) in newer release. The key for those icons are put together in a list [firefox.desktop, ubuntuone.desktop], and so if ubuntuone.desktop is renamed after a system upgrade, the launcher will just drop ubuntuone.desktop but not showing the new one. An upgrade to detect that case and replace ubuntuone.desktop with the new name will be handy. - We got the glorious example on compiz in the past. Fortunatly, this one will soonly be fixed with the case of gsettings, but we surely do have other similar cases when a default is reset to the default and not considered as such. - Even if compiz is fixed, we needed to change the default plugin list more than once, depending on which profile is running, that's another use case. So, I want to open the discussion on how to do this in a light and harmless way (no python for instance ;)). Stamp that a migration happened. Should this be some triggered by client packages themselves? When should this be run in the session? and so on :) Cheers, Didier -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
[Desktop12.10-Topic] Keybindings health check
Hey guys, We had tried to get some shortcut changes during the Precise cycle. Some successfully, some were not (like changing the change worspace keybindings). I propose a healthy check session/discussion with the design team to see what changes will be done for 12.10, what we need to expose on gnome-control-center, reviewing what we already expose there. Also, what changes are needed on the window manager side to propose more than one (configurable) keybinding to not break past conventions with new proposed ones. Thanks, Didier -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
[Desktop 12.10 Topic] The future of third-party driver installation
Hello Desktop fans, We have had Jockey for quite a while now to perform the installation of proprietary (e. g. NVidia), alternative (e. g. fglrx vs. fglrx-updates), third-party (e. g. from openprinting.org) drivers. However, I feel that this needs some refreshing: * The code base of Jockey is quite complex, it was meant for a lot more stuff than we are actually using it for. We also came up with simpler ways of mapping hardware to packages, mostly with additional tags in the apt package lists. We also have a more upstream friendly API in PackageKit/aptdaemon now to do this kind of thing. We can simplify the jockey code base and backend logic a lot (up to the extend of completely dropping it) by making full use of above new technologies and dropping the extra features we don't use. The exception is the openprinting.org detection, but that could go into system-config-printer or python-cups directly. * We install some drivers (like Broadcom wifi) straight from Ubiquity now, which certainly makes sense for devices where there is no free alternative. For the others (e. g. NVidia) we pop up a notification and offer to install them. I'd like to walk through the current UI and discuss how this could be made more steamlined and less confusing (e. g. for NVidia it can potentially offer 6 different drivers for you!) * We might consider merging the jockey UI functionality, which is mostly a shallow GUI around install that package now) into software-center, control-center, or something similar to the codec installer. I'd again appreciate if someone from the design team could participate in that (hello Matthew!). Thanks, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
[Desktop 12.10 Topic] Old libraries cleaning
Hey, Not so much a discussion topic that a just do it, but I think we might get close of dropping pygtk, gtk2 and gconf from the CD so maybe let's see how much progress we can do this cycle with that? Cheers, Sebastien Bacher -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
[Desktop 12.10 Topic] Login speed improvements
Hey, Yet another leftover from precise, not much to discuss as well, rather a just do it. We did a bit of work this cycle but didn't go far, there is still room for improvement especially with nautilus, compiz. Cheers, Sebastien Bacher -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
[Desktop 12.10 Topic] Quality,testability for the desktop components
Hey, The Canonical upstream teams did some good progresses on testing and quality this cycle, that's a good step for the Ubuntu Desktop quality, we still rely on quite some components from other upstreams though that didn't engage into a such process yet though (those who looked at gnome-settings-daemon, nautilus, gvfs, etc bugs on launchpad probably know what I mean there). I would like to see if we can work on our side and with upstream to get those automated tested in some ways. It would be also nice to see regular run and report of the testsuits for other components which already have one (i.e glib, gtk) and some testing of their rdepends before upload. Cheers, Sebastien Bacher -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
{Desktop 12.10 Topic] Holistic approach to Ubuntu documentation
I think it's necessary for Ubuntu to take documentation to another level. When I first started with Ubuntu, I really wanted to learn how it all fit together. I have used computers most of my life so I'm accustomed to reading documentation and I was perfectly willing to dive right in. But it just wasn't that easy, not necessarily because of the information itself, but because of how it was organized and presented. There were no clear starting point and no trails to follow. There were broken links on wikis, and outdated information lying around. Much of the documentation would only use version numbers, and have no easy way to see when it was last updated, or if it had been superseeded. Confusion reduces peoples ability to learn. To me, this is The Issue with Ubuntu. If we're really going to succeed in taking Ubuntu «across the chasm», then we must make it easy for the curious to become users and for the enthusiasts to become power-users. For this to happen, we need to do something drastic about the way documentation is presented. I think Ubuntu Documentation must: * Have an obvious starting point * Lead to the next step * Be instantly recognizable as valid or invalid * Be grouped when applicable * Primarily focused on LTS * Reviewed for each release (hence the point above) * Easy to contribute to by reporting issues * Be not only API docs, but contain readable text. developer.u-c and help.u-c has improved a lot in this regard, but not enough. Look at this page first: http://developer.ubuntu.com/resources/platform/api/12-04/. As a reader, I can come across issues that I'm not able to read, but will help improve the documentation. I should have a very easy way to report it. There's no way at all on that site, though at the very bottom, I can submit a tutorial. Another example, look at this page: http://developer.ubuntu.com/api/ubuntu-12.04/python/Unity-5.0.html. Right, but that's Ubuntu 5.0. I was looking for 5.10. Is this still valid? There's no way to know. We shouldn't rely on people to trust that if not stated otherwise, it is valid. This is the web. There are millions of old and unmaintained documents out there. It must be obvious that it is valid. This also helps anyone recognize invalid documentation, enabling them to report it or fix it. And what if my primary focus is developing an application for LXDE and I want to use only an indicator? In this specific case, I'd use a separate version for the API docs and call it Unity Specification 1.0 for 12.04. Then if there are any changes between now and 14.04, I'd call that 2.0. For versions in between I'd add 1, 2 or 3. So, if there are API changes i 13.04, I'd expect to find a Unity Specification 1.2 and that it would clearly show the differences between 1.2 and 1.0, considering the newest LTS the In the case of Unity-5.0 for Python above, I'm not sure I'd call that Documentation. That is the convention, but I'm not sure that's what people expects. I'd call that document a Specification. For Documentation, I would expect more readable text, explaining what it's for and how it is used. Enum: Unity.FilterRenderer CHECK_OPTIONS_COMPACT 4 Right. How do I use it? .) Jo-Erlend Schinstad -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
Re: {Desktop 12.10 Topic] Holistic approach to Ubuntu documentation
On 18 April 2012 20:39, Jo-Erlend Schinstad joerlend.schins...@ubuntu.com wrote: I think it's necessary for Ubuntu to take documentation to another level. When I first started with Ubuntu, I really wanted to learn how it all fit together. I have used computers most of my life so I'm accustomed to reading documentation and I was perfectly willing to dive right in. But it just wasn't that easy, not necessarily because of the information itself, but because of how it was organized and presented. There were no clear starting point and no trails to follow. There were broken links on wikis, and outdated information lying around. Much of the documentation would only use version numbers, and have no easy way to see when it was last updated, or if it had been superseeded. Confusion reduces peoples ability to learn. To me, this is The Issue with Ubuntu. If we're really going to succeed in taking Ubuntu «across the chasm», then we must make it easy for the curious to become users and for the enthusiasts to become power-users. For this to happen, we need to do something drastic about the way documentation is presented. I think Ubuntu Documentation must: * Have an obvious starting point * Lead to the next step * Be instantly recognizable as valid or invalid * Be grouped when applicable * Primarily focused on LTS * Reviewed for each release (hence the point above) * Easy to contribute to by reporting issues * Be not only API docs, but contain readable text. developer.u-c and help.u-c has improved a lot in this regard, but not enough. Look at this page first: http://developer.ubuntu.com/resources/platform/api/12-04/. As a reader, I can come across issues that I'm not able to read, but will help improve the documentation. I should have a very easy way to report it. There's no way at all on that site, though at the very bottom, I can submit a tutorial. Another example, look at this page: http://developer.ubuntu.com/api/ubuntu-12.04/python/Unity-5.0.html. Right, but that's Ubuntu 5.0. I was looking for 5.10. Is this still valid? There's no way to know. We shouldn't rely on people to trust that if not stated otherwise, it is valid. This is the web. There are millions of old and unmaintained documents out there. It must be obvious that it is valid. This also helps anyone recognize invalid documentation, enabling them to report it or fix it. And what if my primary focus is developing an application for LXDE and I want to use only an indicator? In this specific case, I'd use a separate version for the API docs and call it Unity Specification 1.0 for 12.04. Then if there are any changes between now and 14.04, I'd call that 2.0. For versions in between I'd add 1, 2 or 3. So, if there are API changes i 13.04, I'd expect to find a Unity Specification 1.2 and that it would clearly show the differences between 1.2 and 1.0, considering the newest LTS the In the case of Unity-5.0 for Python above, I'm not sure I'd call that Documentation. That is the convention, but I'm not sure that's what people expects. I'd call that document a Specification. For Documentation, I would expect more readable text, explaining what it's for and how it is used. Enum: Unity.FilterRenderer CHECK_OPTIONS_COMPACT 4 Right. How do I use it? .) Jo-Erlend Schinstad Your topic mixes developer docs, entry-level user docs, and power user docs. Each of those needs a different approach and I think it's simpler to tackle them as three mostly separate things. Also, if you're going to discuss documentation, you should probably include the docs team (CC'd now) as that's where people interested in that read. Thanks, Jeremy Bicha -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
Re: {Desktop 12.10 Topic] Holistic approach to Ubuntu documentation
Den 19. april 2012 03:11, skrev Jeremy Bicha: Your topic mixes developer docs, entry-level user docs, and power user docs. Each of those needs a different approach and I think it's simpler to tackle them as three mostly separate things. Also, if you're going to discuss documentation, you should probably include the docs team (CC'd now) as that's where people interested in that read. The point is the exact opposite. We shouldn't split documentation up into completely unrelated pieces. That is the problem. We should consider it a whole. One single tree of knowledge. Before a release, we should be able to walk the entire tree and make sure all documents are Obviously Valid. You don't have to specialize in a single topic in order to do that. It just requires effort, and for that, it must be obvious what to do. With different docs being at different places, organized in different ways, maintained by unrelated teams and mixing versions, it's very difficult to do any kind of quality assurance or to do anything in a systematic way – as a whole. But for documentation to be seen as a whole, related software must sometimes also be seen as connected. That's why I replied here, since Unity is my main example. It's not simply about documentation. For instance, if I want to learn how to write a Python application for Unity, I have to read this: Unity-5.0 AppIndicator3-0.1 Indicate-0.7 ... They are obviously connected, but it's not at all obvious in versioning or documentation. I'd like to see something more like Unity Specification 1.0 Documentation, which would include those technologies. I'd like to see a Vala/GTK implementation of the Dash, for instance. And it'll have completely different versions than those listed above. This means that we can't just adapt documentation to software, but also adapt software to be more documentable in a way. I don't think this has to be very difficult, but it requires discussions and decisions. Seeing the bigger picture. The desktop is the most visible, most important aspect in this regard. Jo-Erlend Schinstad -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
Re: {Desktop 12.10 Topic] Holistic approach to Ubuntu documentation
On Thu, Apr 19, 2012 at 03:51:02AM +0200, Jo-Erlend Schinstad wrote: Den 19. april 2012 03:11, skrev Jeremy Bicha: Your topic mixes developer docs, entry-level user docs, and power user docs. Each of those needs a different approach and I think it's simpler to tackle them as three mostly separate things. Also, if you're going to discuss documentation, you should probably include the docs team (CC'd now) as that's where people interested in that read. The point is the exact opposite. We shouldn't split documentation up into completely unrelated pieces. That is the problem. We should consider it a whole. One single tree of knowledge. Before a release, we should be able to walk the entire tree and make sure all documents are Obviously Valid. You don't have to specialize in a single topic in order to do that. It just requires effort, and for that, it must be obvious what to do. With different docs being at different places, organized in different ways, maintained by unrelated teams and mixing versions, it's very difficult to do any kind of quality assurance or to do anything in a systematic way – as a whole. Well, both of you make valid points. Can the documentation be *maintained* in a single tree, yet split out by user type (one set for my mom, one for me)? Bryce -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
