-
People like were thinking of a document-centric desktop before my GUADEC talk. W00t. It's nice to see people tuned in to the same channel.
(There is a lot of material in that blog post. Digest it slowly, bit by bit. I don't agree with the parts about needing to dump the fundamentals of our platform, but that's perhaps better seen from an implementator's perspective.)
-
Nemo is a file manager for GNOME which displays your files based on time, not on folder hierarchies. It also handles categories for files, like tags in F-spot. I had not seen it before GUADEC, and it's a pretty cool concept — much more developed than the simplistic timeline-of-days that I showed in GUADEC. Maybe we can embed the Mono VM into Nautilus and reuse Nemo's super-sexy widgets for time-based displays.
-
rpm2git — an easy way to publish distro patches
Various GNU/Linux distros have developed different, ad-hoc ways of publishing the patches they put on top of "pristine" released tarballs from upstream projects like GNOME. openSUSE lets you download full SRPMS from an FTP site, or in a slower but more elegant way through the openSUSE Build Service. Fedora has a CVS repository where they put specfiles and patches. Back in the Ximian days, we had a pretty cute web page, patches.ximian.com, where you could ask for the patches for a specific module, for one or more distros.
Since every distro publishes its patches in a different way, the following happens.
First, upstream developers have a hard time actually looking for those patches to review them and see if they are fit for inclusion in the mainline releases. Where does $distro publish its stuff? How do I know what its latest version is? How do I know what bugs they were trying to fix? Upstream developers should not have to learn the idiosyncrasies of each distro just to get code from them.
Second, distros themselves end up doing a lot of duplicated work. I just found out that both Fedora and openSUSE have patches in their gtk package to do the same things: one for GtkEntry to change the "*" into a "●" when the entry is being used for password entry; another one to let 64-bit builds install the 32-bit and 64-bit libraries in the correct places. If there had been an easy way to share those patches, maybe they wouldn't have duplicated the same work.
I am pleased to give you rpm2git. This is a little tool that you can use as follows:
First, you get a Git clone of an upstream repository, for example, something out of git-mirror.gnome.org.
Second, you get a SRPM and unpack it. You look at the version of that package (say, Nautilus 2.22.2).
Third, you find the Git tag for that version (svn/NAUTILUS_2_22_2).
Fourth, you call rpm2git with that tag name, your specfile, and a destination branch name.
Rpm2git will create a branch starting at the tag you specified, and it will apply the patches from the SRPM as individual commits. The commit messages come from the patch comments.
The idea is that you can later just publish this Git repository, and upstream developers or other distros will be able fetch your branches into their own base repositories. Then, they can cherry-pick patches at their convenience.
You can get rpm2git like this:
git clone git://gitorious.org/rpm2git/mainline.git rpm2git
Over the next few days I hope to start publishing Git repositories of the GNOME packages we ship in openSUSE, with branches for the patches we use.
Note that rpm2git is not the same as VCS-PKG, a really interesting project to go directly from source code under revision control to compiled distro packages.
-
Here is a fantastic presentation of how the Office 2007 user interface was redesigned (full blog post). Miguel already talked about this presentation when he went to the MIX08 conference.
Obligatory snarky comments: the presentation's slides look like ass. Garish backgrounds. Three different fonts on a slide. Bullets. Anyway, that's the visual material. The actual content of the presentation is very interesting.
Microsoft was in this situation: with Office they had a tremendously powerful piece of software with which people no longer felt comfortable. It's too complex. I don't know all the features anymore. I'm sure it has the feature I want, but I cannot find it. This fucking paper clip never gives me good advice and just gets in my way.
The thing is, designing or improving user interfaces is Real Work(tm). You have to watch people work and see where they get stuck. You have to make prototypes and see how people react to them. Microsoft did that for Office 2007.
On a much smaller scale, this is why I think that the plan for document-centric GNOME has a good chance of being successful. We can show Apple and Microsoft that free software has the balls to change the toplevel way in which people interact with their files. We can definitely turn our desktop into a more comfortable environment than what those proprietary environments gave us twenty years ago.
-
Speaking of comfortable environments, this is a street cafe one or two blocks away from the grand bazaar in Istanbul. I had the pleasure of having apple tea and coffee with HPJ and JPR on one of those tables, getting relaxed and ready before terrorizing the grand bazaar with our extreme haggling skills.
Let's see how many patterns of good urbanism there are in that place:
- Pedestrian street whose width does not exceed the height of the surrounding buildings, so you feel cozy.
- Public outdoor room which makes you feel sheltered and is nicely decorated.
- Filtered light from the trees, so you can enjoy a cool shade on a sunny day.
- Street cafe to talk and relax and see people go by.
- Four-story limit so that buildings don't overpower people.
- Positive outdoor space so that you have a sense of place.
-
I would love it if our Human Interface Guidelines were closer in spirit to A Pattern Language (book) than to Apple's HIG.
-
One of the most pleasurable things about GUADEC is the chance to find out that hackers share common interests outside of programming.
Andy Wingo was telling me about Richard Gabriel's book, Patterns of Software. Christopher Alexander wrote the preface — he's the main guy who defined those architectural and urbanism patterns from above.
JPR, HPJ, and myself were talking about peak oil. Will free software even be relevant if we can't keep the Internet running?
It turns out that our baby and Chris Blizzard's as well have the same kind of baby chair and swing.
It's fun to talk about camera-nerding with Hub.
-
Today I'm 0x20 years old. Yay.
-
I'm writing a little utility that generates Git repositories from some unpleasantly-formatted data. The test suite for this was really simple to write: you can simply ask git, "give me the SHA-1 hash that you have for the content" at the end of the test run (i.e. "git-cat-file -p HEAD" and parse out the "tree" hash from there). If the obtained hash matches your expected hash, then you know the test succeeded. This is much easier than comparing all of the expected/obtained content by hand.
-
Here is my presentation from GUADEC: Document-centric GNOME (ODP).
The code for document-centric Nautilus consists of the journal view and the Nautilus extension interface for journal providers. This code is not finished yet (nothing gets displayed to the screen; it's all engine code), but you can take a look here:
git clone git://gitorious.org/nautilus/mainline.git nautilus-document-centric
The master branch contains the document-centric code, which is built on top of nautilus-2.22.2. You can also visit the Gitorious repository for document-centric Nautilus and create your forks there.
-
John Anderson has posted a great little tutorial on Nautilus tips and tricks. Life-savers for me: the list of keyboard shortcuts and enabling the "advanced permissions" view.
-
Hot damn, someone is porting DTrace to Linux (source code). Maybe Mortadelo will be useful in the future again.
-
Ah, Istanbul.
-
The Blue Mosque introduced me to painted domes and arches. Now I know how to paint and decorate our vaults on the inside, which are just plain whitewashed right now.
-
Mario Ðanić has another interesting post about distributed version control systems. He proposes that each developer (or at least, every maintainer) could use the DVCS of their choice, but then we could have a common web/collaboration interface to all the DVCSs.
-
My current favorite way of developing against a stable release:
$ cat ~/bin/make-nautilus #!/bin/sh module_name=nautilus diff_name=~/suse/11.0/src/SOURCES/nautilus-document-centric.diff anchor_name=OPENSUSE_11_0_PATCHES branch_name=document-centric cd ~/src/$module_name git diff $anchor_name..$branch_name > $diff_name cd ~/suse/11.0/src/SPECS if rpmbuild -ba $module_name.spec then cd ../RPMS/i586 gnomesu -c "rpm -Uvh --force *$module_name*" notify-send -t 0 "$module_name is installed now" else notify-send -t 0 "$module_name doesn't build!" fi