Lack of XrandR support for the Nvidia driver and Twinview

This first annoyance has very little chance to get fixed by the Ubuntu developers themselves. It’s Nvidia’s job to do his job right and I can only hope that Canonical has gained enough weight in order to be able to put some pressure in Nvidia’s driver development. Here’s the problem: With multiple monitors you get only one resolution in XrandR which is equal to the size of all your screens. If you want to change the resolution of one or both screens, you either have to do it manually from Nvidia’s control panel or you can write Modelines in you Xorg with every possible combination of screen resolution you’d want to use.
These Modelines are annoying to write and I’ve been copying and pasting the same modelines in my Xorg since Dapper Drake. ATI does it right, Nouveau does it right, now it’s Nvidia’s turn. The whole point is not to get XrandR support for the sake of it, the point is that applications should be able to set the resolution of screens individually and that it should be painless to  plug / unplug screens on the fly. If you don’t play video games, especially old ones, that run in a small resolutions you might not get why this bug is so annoying.

More stability to Nautilus

Let’s admit it: Nautilus crashes way to often, and when it does it crashes every single window you had opened. The crashes occur mostly while working in Samba shares or with CD-Roms. If the crashes can’t be fixed then Nautilus should behave like Google Chrome: if one window has to crash, it must be the only one to crash, don’t bring your friends down with you. The Samba browsing could get some love too, apart from the crashes. I see messages like “Unable to mount location” far too often. Ok, my file server may be a little slow to wake up, but it’s no reason to whine. Just be a little more tolerant, increase the timeout periods by a couple seconds and that should fix it.

Better disk naming

Disk naming is driving many people crazy and even me with 10 years of Linux experience, I sometimes get confused. We have the standard /dev/sda1 for disk devices, we have the grub convention (hd0), we have uuids, we have disk ids and all of this creates a big mess. I think the most confusing one is the grub naming convention. It’s confusing because you know that if you mess up things, your computer will not boot and I’m never sure which drive is (hd0,0).  Things like /media/45755213-1587ABDC215-EF14856 should not happen and it would not happen if Ubuntu’s drive were given a label when installing and if it was easy
to relabel a drive from Places > Computer. What happens if I try to do so ?  I get this error message :

The item could not be renamed.
Sorry, could not rename "74 GB Hard Disk: vbox" to "74 GB Hard Disk: vbox2":
Operation not supported by backend

This is crazy, which backend are you talking about? If it doesn’t work with *this* backend why don’t you use another one? Why do you let me ‘rename’ the “74GB Hard Disk” part?

Fixing the disk naming issue implies :
- giving the system drive a label during the install (ie. ‘ubuntu-disk’)
- having a GUI for fstab and grub.
- fixing the drive renaming in nautilus.

I admit that these issues won’t affect most users, well maybe the Nautilus stability will, everyone uses it and at some point it will crash. Most people don’t need to change resolutions on their dual screen setup and most people have one hard drive so the naming issue is not really one. But for each of these problems there is an underlying faulty design, something that needs to be fixed before things get worse and start affecting more people. The goal is not  to have a system that is good enough for the average user. There is no average user, each individual has special needs and each will uncover special cases that need to be treated with much attention.

Photo by phil h

Unfortunately, I don’t have much time to work on this book now, as I have tons of Web development to do. The Open Office document was staying here untouched and unfinished in my Documents directory and I thought this was too bad. This is all about mutual help and open contributions so I’m not going to let this idea rot on my computer.

The current document is already almost 100 pages long, but there is still some work to do :

• Convert the book in a Version Control System friendly format. It can be Latex (like the Ubuntu Manual), markdown, SGML, Docbook or any other format that can easily be exported to PDF. The current Open Office format is inappropriate to work on with multiple contributors.
• Add a Tools chapter which is a copy of the Tools section in Bugquad’s Knowledge base
• Give a better structure to the document, there should be as little forward references as possible and the reader should be able to stop reading the book at any point and still have valuable knowledge. (Check this out). David Tombs made a very good remark on the mailing list , but I do not want this Handbook to be a stripped down version of the Wiki, I should be useful for both beginners and experienced team members. A ‘lite version’ of the Bugsquad Handbook could easily be made by taking only the first 30 pages or so from the complete book.
• This project requires many eyeballs to stay fresh and up-to-date. If you want to be involved, you should subscribe to the mailing list and to some Wiki pages so you get notified when they change.
• Be awesome and bring your own ideas !

Download the current version of the Bugsquad Handbook : bugsquad-handbook.odt.tar.gz

Now these folders too will get some love, it was very easy to create new icons with inkscape.

Extra folder icons

If you can grab the svgs here : humanity-folders-extra.tar.gz

UPDATE: I removed the bin folder icon which was already in the official theme, added icons for Games and Books. I also made alternative icons for UbuntuOne, the original orange on orange one isn’t that great.

This application shows a Debian logo in the panel and gives you access to essential documents for packagers and developers : The Debian FAQ, the Developer Reference, the Maintainer’s guide and the Debian Policy. You can fetch it on the project’s page or on my PPA.

Ok, let’s start digging in. First thing to do when you want to use libindicator in your Python applications is to install the python-appindicator package (I assume that you are running Lucid Lynx). Once this is done import the module in your program :

import appindicator

In the body of your program create a Indicator object

ind = appindicator.Indicator ("debian-doc-menu","debian-swirl", appindicator.CATEGORY_APPLICATION_STATUS)

You instantiate an indicator object with 3 parameters, first an unique identifier for your app, then an icon (you can pick any stock icon from your icon theme) and finally a category that will tell libindicate where to place the icon in the panel.
You have 5 categories to choose from :

• CATEGORY_APPLICATION_STATUS
• CATEGORY_COMMUNICATIONS
• CATEGORY_SYSTEM_SERVICES
• CATEGORY_HARDWARE
• CATEGORY_OTHER

As you can see, the names are self explanatory.
Then you set the status of your indicator :

ind.set_status (appindicator.STATUS_ACTIVE)

Again you have 3 statuses to choose from :

• STATUS_PASSIVE : The icon is hidden
• STATUS_ACTIVE : The icon is visible
• STATUS_ATTENTION : The icon changes to the attention icon, requesting some kind of interaction with the user

You can set the attention icon with :

ind.set_attention_icon ("indicator-messages-new")

Then you’re likely to want to attach a menu to this icon, it’s a standard Gtk Menu :

menu = gtk.Menu()
faq_item = gtk.MenuItem("Debian FAQ")
faq_item.connect("activate", faq_clicked)
faq_item.show()
menu.append(faq_item)

You attach the menu with :

ind.set_menu(menu)

Of course you have to write some actions for the menu :

def faq_clicked(widget,data=None):
    os.system("evince /usr/share/doc/debian/FAQ/debian-faq.pdf.gz &")

And you’re done ! Run the gtk.main() and you got your AppIncidator running.

Next thing to do is to find an application using a legacy “systray” icon and propose a patch to the developers, maybe Parcellite would be a good start, it would be a good way to show how it’s done in a C project.

Here I am on my new blog. The old one, Tweekers’s Blog was in french and I shall still update  it from time to time. Last night, as I couln’t get to sleep, I told myself “That’s it, I’m fed up with the French blogosphere, I have to start a new blog in English”.Don’t get me wrong, there are some great French guys, but quite frankly, I feel that they lack the Hacker culture I want to be a part of. A lot of French blogs talk about Free Software, which is great, but the underlying message is that they try to defend themselves from a great evil power (proprietary software). I don’t have this feeling. I already have my (software) freedom and no one is going to take it away from me. My only goal is to build awesome Open Source software, that’s the only way to make people use them.

Yes, this is all about the Open Source VS Free Software debate. Free Software advocates tend to say that Open Source guys only care about the technology and not about the ethics. That’s not true, I care about the ethics and I’m aware of them. But to bring Free Software to the people they have to be quite darn good or else nobody would want them. There is only a tiny minority of non-technical people willing to use shitty Free Software instead of good proprietary ones just for freedom’s sake. All the rest, they don’t give a rat’s ass about the ability to hack the source code, they just want something that works.

We, as the hacker community, must bring excellent software to the people or else they won’t give a shit and they’ll go buy an iPhone because it’s a nifty piece of technology that justs works.

This blog doesn’t target an imaginary reader that would be totally new to Open Source. This blog is meant to be read by hackers, by geeks, by people who actually use their freedom to study and modify the source code of the software they use. I will post some Python code here. You’d better be prepared to read it. This is not for people who say “Open Source is great, everybody can modify the software, well not me but someone else with the skills can”. You don’t have to be a guru to read this blog, but at least you must have the will to understand things. Understanding how things work is part of the hacker culture and Open Source is our language. I’m sick and tired to have the feeling that everyone around me can’t answer my questions on hacking. I clearly had the wrong audience. I’m finished being at the top of the newbies, now I want to be at the bottom, I want everyone around me to be better than me or at least my equal.

We want to learn, we want to hack and we want to make the best software there is on earth.