tag:blogger.com,1999:blog-17129780088924765802024-03-13T01:42:43.524+01:00Holger Berndt's Bloghbhttp://www.blogger.com/profile/01696157718617410014noreply@blogger.comBlogger20125tag:blogger.com,1999:blog-1712978008892476580.post-44231926362078974542012-08-12T21:55:00.003+02:002017-09-19T23:01:03.440+02:00Nautilus Extra Pane Removal: Myth BustingSince I announced the <a href="http://berndth.blogspot.de/2009/02/splitting-shell.html">birth</a> and the <a href="http://berndth.blogspot.de/2009/12/nautilus-split-view-and-upstream.html">growing-up</a> of Nautilus' extra pane in this blog I guess it's only fair to also mention this feature's silent <a href="http://git.gnome.org/browse/nautilus/commit/?id=b8d5b4a7bcf47ed34a6343c95bcc3b079255c0a0">death</a> here.<br />
<br />
There's been a lot of <a href="https://mail.gnome.org/archives/desktop-devel-list/2012-July/msg00022.html">vandalism</a> happening in the repository lately, and unfortunately, the extra pane was one of the victims. But it's in good company, joining type-ahead selection, <a href="http://git.gnome.org/browse/nautilus/commit/?id=241e462024070d9f79f4816256fc00ff5119e25f">compact-mode</a>, and the <a href="http://git.gnome.org/browse/nautilus/commit/?id=253d4bf50b04a2ad3a063d467818b02ca2002584">tree sidebar</a> into nirvana.<br />
<br />
All these removals came somewhat as a surprise to me, as they seem to directly oppose <a href="https://mail.gnome.org/archives/gnome-announce-list/2009-December/msg00038.html">Nautilus' mission statement</a>. So I guess this has been superseded. Too bad that this wasn't communicated - people would have been less surprised.<br />
<br />
So, let's have a critical look at the reasoning for the removal of the extra pane.<br />
<br />
Starting with the <a href="https://bugzilla.gnome.org/show_bug.cgi?id=676858">bug report</a>: <br />
<br />
<blockquote class="tr_bq">
<i>Extra Pane mode was somewhat useful before GNOME 3 had side by side window mode.</i></blockquote>
Fun fact: That's the first time that I hear a GNOME designer call it "somewhat useful". Usually, the reaction was <a href="http://www.flickr.com/photos/mairin/4382707014/in/set-72157623492365266/">WE ALL HATE IT</a> (capitals are theirs, I left the double-underline out). Anyways, historically, the extra pane was introduced <b>because of</b> GNOME 3 (see linked mission statement above), not despite of it. Nautilus wanted to make the move from a document launcher to a file manager, because of the GNOME Shell taking over the launcher part. Now, I am not sure where it's moving. File management isn't the focus anymore for sure, looking at all removals combined. It seems the focus is to look pretty. For all those users who start Nautilus to lay back and enjoy its look, as opposed to getting work done. I wonder how many of those exist, outside of the designer world.<br />
<br />
That brings us to the most stated reason for the removal of the extra pane: The claim that it has become obsolete due to window snapping. That is just factually wrong.<br />
<br />
The main point of the extra pane is to have a default target for file operations. Many operations work on files in two distinct locations: Copy or move files from folder A to folder B. Or from a remote location to the local computer. Or from a USB stick into the document folder. The extra pane introduces this concept of "that other location". So it's possible to get the job done with a single menu item. Or even with a single shortcut key (functionality that was <a href="http://git.gnome.org/browse/nautilus/commit/?id=b3fc292bceb64c1a4799df320bd235b314466aef">also removed</a> but that I was allowed to <a href="http://git.gnome.org/browse/nautilus/commit/?id=c857f6b1f96cb03e4c0e645cc676bcc03e8c5ab8">bring back</a>).<br />
<br />
This inherent connection is the feature that the extra pane offers. It's really a lot different to displaying two random windows side-by-side. That snapping looks somewhat similar doesn't make it a replacement for the feature.<br />
<br />
Let me give another example. The inherent connection between the two panes is also available from inside Nautilus Scripts. A have a script that just "diff's the right thing", be it two files in a directory, two files in different directories, or two directories. The script is <a href="https://gist.github.com/3332269">trivial</a>. With a shortcut assigned to it, these little things help me work. A lot.<br />
<br />
Only after somebody showed me this "one key press diff the right thing" feature with window snapping, similarly easy to do and to set up, can he argue that window snapping obsoletes the extra pane.<sup>¹</sup><br />
<br />
The visual side-by-side display of extra pane is just a nice added bonus to the feature. But even visually it's way better than window snapping:<br />
<ul>
<li>It doesn't need to be full screen. Last time I checked, GNOME was also supposed to be used on desktops - many of which have big screens nowadays.</li>
<li>It's easy to get that view, and to get rid of it again. One menu item or button press, instead of mouse placement origies.</li>
<li>It has less visual clutter. No double sidebar, no double menu, and so on</li>
<li>It's easier to see which pane is selected (actions are applied to the pane that isn't greyed out, <a href="http://www.flickr.com/photos/mairin/4382707014/in/set-72157623492365266/">genius</a>)</li>
</ul>
Some of these side-aspects can be taken care of. By <a href="https://bugzilla.gnome.org/show_bug.cgi?id=681004">horrible hacks</a>, though. Or by removing yet more features. If nothing is left, nothing is duplicated.<br />
<br />
C'mon, if you want to argue against the extra pane, you can do better. I mean, if you're on a <a href="http://www.qdh.org.uk/wordpress/?p=358">mission</a>, I'm sure you can think of some more convincing arguments. Let's see... <br />
<blockquote class="tr_bq">
<i>The combination of panes and tabs is just too much.</i></blockquote>
And then you decide to move the feature that cannot be handled by window managers into the window manager, and leave the feature that could inside Nautilus? Interesting. In a weird way.<br />
<blockquote class="tr_bq">
It is inconsistent with the file chooser</blockquote>
In what way? That the file chooser cannot open two panes? Sure, that's because it's a file chooser, not a file manager. By the way, Nautilus has a few features left that the file chooser cannot do either. Like copying and moving files. Or renaming. I see a bright future for Nautilus after you've made it consistent with the file chooser. Or, as has been written in <a href="http://blogs.gnome.org/mccann/2012/08/01/cross-cut/">eloquent newspeak</a>: When Nautilus receives yet more "love".<br />
<br />
<blockquote class="tr_bq">
and doesn't work well with touch.</blockquote>
What's wrong with it? And why will window snapping be better? I think it's actually easier to action a menu item than to start and drag-and-drop two windows to snap.<br />
<br />
Do you guys actually realize that your whole reasoning consists of either false or unelaborated claims? <br />
<blockquote class="tr_bq">
We would like to add a more explicit copy/move feature shortly.</blockquote>
I doubt you can introduce the "default target" functionality otherwise in a clearer way. And - even if you could - here's a wild idea: Strip the features out <b>after</b> you have a replacement. Not before. <br />
<br />
That's basically it for the bug report and commit msg. But the blog post that I linked to before has more:<br />
<blockquote class="tr_bq">
The first reason was that it was undiscoverable.</blockquote>
What a reason. Make it more discoverable, then? I thought you were a designer?! Of course, that would mean that you're not on a mission.<br />
<blockquote class="tr_bq">
this one also stood in the way of providing a better alternative</blockquote>
What alternative? How did it stand in the way? Don't be so fuzzy - where is the beef?<br />
<blockquote class="tr_bq">
Even if you never used the Extra Pane you always had useless Move To and Copy To items in the menus.</blockquote>
In fact, having these menu items always displayed was a review comment, because that's supposed to be the GNOME way. The original patch only showed them when an extra pane was open. Now, this is brought up as a reason to remove the feature? Funky. <br />
<blockquote class="tr_bq">
Should we keep the feature for which we have a new and better alternative in Nautilus</blockquote>
We don't have that! I explained it numerous times, but my comments have always been ignored. Provided that you read comments on your own bug reports, you actually know better. Which leaves an ugly after-taste.<br />
<br />
I'll leave the side-by-side snapping out, becaues I've covered it already. Which brings me to<br />
<blockquote class="tr_bq">
and a pile of bugs getting no attention in bugzilla</blockquote>
Now, this is the point that really makes me furious, and that probably makes my mails and posts more explicit than they otherwise would be. The design team has always been badmouthing my work on that feature. It started with "extra pain", claimed that it was "messy code", that "files vanish".² Now, they claim that we had oh-so-many bugs (but of course secret ones, which <a href="https://mail.gnome.org/archives/nautilus-list/2012-August/msg00009.html">they won't tell you about</a>).<br />
<br />
Of course, I asked dozens of times what's so messy about it. I love being reviewed. Receiving and doing reviews is one of the best ways to learn and advance. However, I never, ever, got an answer.<br />
<br />
Which turns the statements from criticism into slander. Disgusting behavior.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://1.bp.blogspot.com/-OK7q3ZtIMCU/UCf039dseLI/AAAAAAAAAZU/KtREsRGxPB8/s1600/24533757.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="320" src="https://1.bp.blogspot.com/-OK7q3ZtIMCU/UCf039dseLI/AAAAAAAAAZU/KtREsRGxPB8/s320/24533757.jpg" width="320" /></a></div>
<div class="separator" style="clear: both; text-align: center;">
</div>
<br />
Of course, these claims spread over the web, where you can now read all day long that the feature was removed because it was oh-so-buggy and an oh-so-bad hack on top of Nautilus instead of making it properly, and so on.<br />
<br />
That's just not true. The extra pane patch (which consisted of about 2000 lines, by the way - for a quick hack I would probably have needed 10 or so) introduced some architectural changes that make sense even if you don't want to have the extra pane. In fact, it would have been smart to keep those, even if the feature was to be removed.<br />
<br />
I think I've covered all of the argumentation brought up so far that led to the removal of the extra pane in Nautilus. Not a single item with substance.<br />
<br />
<hr width="80%" />
<span class="Apple-style-span" style="font-size: xx-small;"><br /><br /><b>1 </b>Fun fact: I like window snapping, too. Actually, I even had a locally
patched Metacity on my machine that did snapping somewhere in the middle
of GNOME 2 already. It's cool to have Evince and a LaTeX editor open
side-by-side, for example. If snapping could have replaced the extra
pane, I would have cleaned up that patch and submitted it, instead of
putting lots of effort in the extra pane. But I didn't, because snapping
cannot replace it.</span><br />
<br />
<span class="Apple-style-span" style="font-size: xx-small;"><span class="Apple-style-span" style="font-size: xx-small;"><b>2 </b></span></span><span class="Apple-style-span" style="font-size: xx-small;"><span class="Apple-style-span" style="font-size: xx-small;">E</span>dit: When hearing about the "files vanish" part, naturally, I got a bit nervous, and immediately tried to
find out what that statement was about. Turned out that there was no
data loss, in fact no bug. And the reaction on my inquiry was a huffy note along
the lines of </span><span class="Apple-style-span" style="font-size: xx-small;"><span class="Apple-style-span" style="font-size: xx-small;">"can't we talk without filing
bugs?", followed by </span>"what a crappy comment". D'oh.</span>hbhttp://www.blogger.com/profile/01696157718617410014noreply@blogger.com45tag:blogger.com,1999:blog-1712978008892476580.post-21106822964963884262010-02-28T21:01:00.000+01:002017-09-19T23:00:48.437+02:00Nautilus in the stress field between design and function<div class="separator" style="clear: both; text-align: center;">
<a href="http://farm4.static.flickr.com/3252/3380954554_e2fb5e399e.jpg" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" src="http://farm4.static.flickr.com/3252/3380954554_e2fb5e399e.jpg" height="320" width="240" /></a></div>
So, there's been a <a href="http://mairin.wordpress.com/2010/02/23/gnome-ux-hackfest-photos/">lot</a> <a href="http://mairin.wordpress.com/2010/02/24/misc-notes-from-gnome-ux-hackfest-tuesday/">of</a> <a href="http://seilo.geekyogre.com/2010/02/nautilus-zeitgeist/">talk</a> about Nautilus' present and future design. Especially <a href="http://www.design-by-izo.com/2010/02/27/deconstructing-nautilus-and-rebuilding-it-better/">Izo's article</a> collects some interesting proposals for design enhancement that are in my opinion very well worth consideration. It does, however, also contain some points that make me feel a little uneasy.<br />
<br />
Naturally, UI redesign comes not only with re-organisation and re-design of existing functionality, but also with omitting of unimportant components. Also naturally, the latter part is tricky to get right, because people don't like it when the functionality that they are <a href="http://www.alistapart.com/articles/neveruseawarning">habituated</a> to use is suddenly gone, without any accessible replacement. I don't mean to say that UI reduction is impossible, but it's something that has to be considered carefully, according to the <a href="http://mail.gnome.org/archives/nautilus-list/2009-December/msg00001.html">focus</a> and target audience of the project. This is a hard process, because individuals or small groups don't necessarily cover all the use-cases that an application wants to address.<br />
<br />
Izo seems to have a typical case of forgotten addressed use-cases in his review when he writes about the stop button:<br />
<blockquote>
"The stop button. More useful in web browsers, if you want to stop the web browser from loading a page, completely useless in a file manager, where file accessing times are considerably quicker than web browsing times. You simply never have an opportunity to stop the file manager from loading a page. It’s an old relic. I’ve never used the stop button."</blockquote>
That <b>you</b> have never used a stop button in a (network transparent!) file manager does not mean that it's "completely useless". Got the hint in the parentheses? Nautilus does indeed want to support network filesystems, be it NFS and friends or GIO/GVFS mounted stuff. Loading these is actually not too different to what you do with your browser. These can clearly be very slow, and that you didn't think of that just shows that you forgot an important use-case that Nautilus wants to support, because you have no personal use for it.<br />
<br />
Now, I am not saying that the stop button is the best design for that. It most probably isn't. One could for example test if it could be combined with your proposal of the "refresh" button: Display the "refresh" symbol when the displayed location is fully loaded, and put a little stop symbol there while it's loading (this combination of stop/refresh has been proposed before in "<a href="http://davidsiegel.org/nautilus-simplified/">Simplified Nautilus</a>"). <br />
<br />
People are different, and have different ways to use applications. Many other proposals, for example, just assume that the sidebar is visible. You mean to save a little bit of screen space by omitting the small "Home" toolbar button, arguing that it's also accessible in the sidebar? Well, when I look around, a fair number of computer-novices that I see don't have the sidebar visible at all. When forcing it upon them, they actually loose <i>a lot</i> of screen estate, and have <i>a lot</i> more unwanted UI elements in their face. Combine that with the talk about removing the menu bar alltogether (and thus loosing the <i>habituated</i> easily accessible way to toggle the sidebar visibility), and you have a good potential to regress usability for a non-negligible part of your target audience. In the end, people don't open Nautilus to lay back and enjoy its look, but to get work done.<br />
<br />
I am also not entirely convinced that it's so bad to have two toolbars. I mean, how much screen estate do you loose, in reality? For one thing, the toolbar covers less space than the sidepane. In browser mode, you typically don't have dozens of Nautilus windows on a single workspace (and as I said, the toolbar covers less space than the sidepane). On the other hand, even if you have reduced the number of toolbar buttons to six plus a wide-enough search window, as your mockups show, what's better: To use a few vertical pixels, or not to be able to see your current folder "Pictures from Patrick's wedding where aunt Maggie got really drunk"? Hard to say.<br />
<br />
<br />
<span style="font-size: large;">Split View - Curse or Blessing</span>?<br />
<br />
Having the location bar embedded into the toolbar items also has another problem: It doesn't work well with the a <a href="http://berndth.blogspot.com/2009/12/nautilus-split-view-and-upstream.html">split-view filebrowsing mode</a>. This mode got some <a href="http://www.flickr.com/photos/mairin/4382707014/in/set-72157623492365266/">very harsh criticism</a> at the recent designers hackfest that I stumbled upon by coincidence (strangely, this discussion didn't find its way to Nautilus communication channels yet). I wrote some comments on the corresponding blog posts, but I also want to write a small comment about that here on my own webspace, without the risk of being moderated (as seemed to have happened on other people's digital homes, which obviously found my remarks unpleasant).<br />
<br />
First of all, I am disappointed by the way the criticism was expressed. The designers may very well have some valid points, but I wouldn't know, because they seem to actively refuse to answer my request to elaborate on their non-descriptive slating. Also, there are some remarks that make it look like they didn't even give it a fair try before condemning it.<br />
<br />
A reccurring question was "<i>why</i> <i>split-view</i>", and the proposal to implement panes in the window manager instead. This is a valid question, and has in fact been discussed on the <a href="http://mail.gnome.org/mailman/listinfo/nautilus-list">Nautilus mailing list</a>. (Hint: In general, project mailing lists are a good place for both, to research design decisions and to ask the "why" question.)<br />
<br />
Fact is, split-view filebrowsing is <b>not</b> trying to solve window manager shortcommings on the wrong level. Even if <a href="http://blogs.gnome.org/metacity/2010/01/21/snap/">Metacity had snap today</a>, this wouldn't be an alternative.<br />
<br />
The key difference is the inherent connection between those two panes, which gives clear benefits. When you want to do file management (which is now becomming the key-focus of Nautilus), you often have to deal with two locations at the same time: The <i>source</i>, and the <i>target</i>. What split-view does is to display a "<i>default target</i>" right next to the source. That's why it makes sense to have 2 panels, but not 3 or 4.<br />
<br />
This default target is accessible in the menu, via the "{Copy| Move} to other pane" items. Users that need to do heavy-duty file handling can assign keyboard shortcuts to those menu items, and move around files with a single button press.<br />
<br />
The “default target” notation offers even more for advanced users, which can access both the source and the target pane in their <a href="http://library.gnome.org/users/user-guide/stable/gosnautilus-444.html.en">Nautilus Scripts</a> (and write for example a “diff these two directories” script with very little effort). This surely isn’t possible with a WM snap either.<br />
<br />
Users with simpler needs aren’t really affected much by of all this. The only effect for them is that “extra pane” option in the view menu that they don’t wanna click.<br />
<br />
I actually think that it is a very natural model to show source and target location when they are that fundamental to the typical action that the user wants to do with a given application. I find it much more intuitive than the clipboard copy/paste stuff that is generally accepted because people got used to this strange idea.<br />
<br />
<i>Photo ©</i><span style="font-size: small;"><i> Adventures in Librarianship on flickr, cc-by-nc-sa</i></span>hbhttp://www.blogger.com/profile/01696157718617410014noreply@blogger.com11tag:blogger.com,1999:blog-1712978008892476580.post-35831853317023243462010-02-26T00:11:00.003+01:002010-02-26T00:19:13.631+01:00Linking notes and email messagesA few days ago, I've cobbled together a note-taking solution for my email messages. It's very unixy, consisting of a fair number of different parts working together: <a href="http://www.claws-mail.org/">Claws Mail</a> with the <a href="http://www.claws-mail.org/plugin.php?plugin=python">Python plugin</a> and two of the shipped example scripts on the one side, <a href="http://projects.gnome.org/tomboy/">Tomboy</a> with the <a href="http://berndth.blogspot.com/2009/12/tomboy-and-beast.html">Claws Mail addin</a> and the <a href="http://flukkost.nu/blog/tomboy-reminder/">Reminder addin</a> on the other side.<br />
<br />
Starting with a message selection in Claws Mail,<br />
<br />
<div class="separator" style="clear: both; text-align: center;"><a href="http://2.bp.blogspot.com/_tWQEjnxEHnw/S4b87Cg1xrI/AAAAAAAAAFU/LbI2G_3zgbo/s1600-h/cm.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="http://2.bp.blogspot.com/_tWQEjnxEHnw/S4b87Cg1xrI/AAAAAAAAAFU/LbI2G_3zgbo/s320/cm.png" /></a></div><br />
a click on the "Create Tomboy Note" menu item of the Python example script results in this dialog popping up (I know that this dialog is ultra-ugly, but hey, it's a quick&dirty easy-code example script, nothing more)<br />
<br />
<div class="separator" style="clear: both; text-align: center;"><a href="http://4.bp.blogspot.com/_tWQEjnxEHnw/S4b-AHWTPBI/AAAAAAAAAFc/si5ZFcFOIWg/s1600-h/popup.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="http://4.bp.blogspot.com/_tWQEjnxEHnw/S4b-AHWTPBI/AAAAAAAAAFc/si5ZFcFOIWg/s320/popup.png" /></a></div><br />
which in turn creates this Tomboy note<br />
<br />
<div class="separator" style="clear: both; text-align: center;"><a href="http://2.bp.blogspot.com/_tWQEjnxEHnw/S4b-PAvxG2I/AAAAAAAAAFk/eUNwF2UoJTY/s1600-h/note.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="http://2.bp.blogspot.com/_tWQEjnxEHnw/S4b-PAvxG2I/AAAAAAAAAFk/eUNwF2UoJTY/s320/note.png" /></a></div><span id="goog_1267137745307"></span><span id="goog_1267137745308"></span><br />
The Tomboy reminder plugin will take care to remind me about this next monday by raising the note.<br />
<br />
To make the round-trip complete, there's a second example script that raises all Tomboy notes that link to a selected message.<br />
<br />
Okay, admittedly not the end-user friendliest setup, but it suits my needs pretty well. And it shows the benefits of scripting language interfaces for glueing components together -- it didn't take long to write the scripts to make this work, even though the plugins and addins have not especially been designed for it.hbhttp://www.blogger.com/profile/01696157718617410014noreply@blogger.com1tag:blogger.com,1999:blog-1712978008892476580.post-48240590962906920062010-01-18T22:20:00.001+01:002010-01-18T22:20:01.024+01:00The Tomboy and the Git<a href="http://berndth.blogspot.com/2009/12/tomboy-and-beast.html">Tomboy's taming of the beast</a> turned out to be a very useful feature for my daily note keeping. But emails are not the only pieces of information that I often find associated with tasks. Another recurring source that I want to reference are commits in source code management systems. So, if Tomboy can play nicely with my MUA, why shouldn't it play nicely with my source code repository browser as well?<br />
<br />
Unfortunately, there's no drag-and-drop target for git repository viewers defined. Most viewers just don't let you drag from the commit list into another application. So, I tried to contact the guys from <a href="http://www.kernel.org/pub/software/scm/git/docs/gitk.html">gitk</a>, <a href="http://live.gnome.org/giggle">giggle</a>, and <a href="http://trac.novowork.com/gitg/">gitg</a> in the hope to define such a dnd target. The guys from gitg seemed to be the only ones interested in that functionality (good thing that gitg is currently my favorite browser anyways), and it didn't take long until they added the required features.<br />
<br />
With that in place, it was easy to write a <a href="http://github.com/hb/tomboy-git-addin">Tomboy addin</a> that handles dropping of git references into a note analogous to dropping email messages: By creating a link with a nice icon and a meaningful text which when clicked opens the git repository viewer and selects the respective commit.<br />
<br />
<div class="separator" style="clear: both; text-align: center;"><a href="http://1.bp.blogspot.com/_tWQEjnxEHnw/S1TPDLgCFoI/AAAAAAAAAFM/8jPrMHvqFIg/s1600-h/gitg-tomboy.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="http://1.bp.blogspot.com/_tWQEjnxEHnw/S1TPDLgCFoI/AAAAAAAAAFM/8jPrMHvqFIg/s320/gitg-tomboy.png" /></a><br />
</div><br />
I like these little helpers. They have a good work/gain ratio.hbhttp://www.blogger.com/profile/01696157718617410014noreply@blogger.com0tag:blogger.com,1999:blog-1712978008892476580.post-61278851935609230782010-01-17T17:12:00.000+01:002010-01-17T17:12:29.787+01:00Extending and Automating Claws Mail - the sneaky wayThe recent release of Claws Mail 3.7.4 has also seen a much more powerful version of the Python plugin. It is now possible to write scripts that are executed automatically on startup, shutdown, or opening of a compose window. It's also now possible to write scripts that work on an already opened compose window. The user interface got better as well (e.g. it's now possible to trigger scripts via toolbar buttons).<br />
<br />
However, what the latest release still lacks, is documentation and examples. After all, features that are not documented don't exist. This is supposed to get better in the next release. I've started adding a few example scripts to the source distribution that show possible solutions to questions that have been raised on the user's mailing list lately. Most of these should already work with the released version of the plugin, with the exception of the startup script that show's how to add new menu items for custom actions into the main window (the examples being a menu item to mark a thread as read, and to add a menu item to create and show the Python plugin's API documentation on-the-fly - isn't introspection cool?).<br />
<br />
Anyways, if anybody scripted something cool with the plugin, please consider sending the (well commented) script to me. I'd be happy to consider it for inclusion in the distributed examples.hbhttp://www.blogger.com/profile/01696157718617410014noreply@blogger.com1tag:blogger.com,1999:blog-1712978008892476580.post-36989807331316139542009-12-14T00:12:00.002+01:002009-12-14T10:27:33.566+01:00Nautilus Split View and UpstreamCheck out that screenshot about the current state of splitting a Nautilus window:<br />
<br />
<div class="separator" style="clear: both; text-align: center;"><a href="http://1.bp.blogspot.com/_tWQEjnxEHnw/SyVvGyQSv9I/AAAAAAAAAFE/kOQ7XiK1Zgs/s1600-h/nautilus-master.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="http://1.bp.blogspot.com/_tWQEjnxEHnw/SyVvGyQSv9I/AAAAAAAAAFE/kOQ7XiK1Zgs/s400/nautilus-master.png" /></a><br />
</div><br />
The exciting thing is that this is not a screenshot of my split-view branch, but of <a href="http://git.gnome.org/cgit/nautilus/log/">Gnome git master</a>.<br />
<br />
So after successfully using the split view branch for Nautilus for several months, and (mostly thanks to the PPA) getting some feedback from others, I finally <a href="http://mail.gnome.org/archives/nautilus-list/2009-November/msg00030.html">requested a review</a> for it. Turned out that I had a good timing, because with the upcomming Gnome Shell, a <a href="http://mail.gnome.org/archives/gnome-shell-list/2009-December/msg00000.html">debate</a> is currently going on anyways about the future role of Nautilus. With a possible switch away from being a desktop shell and towards more typical file management tasks, split-view fits better into the picture as it used to.<br />
<br />
I am very happy that <a href="http://blogs.gnome.org/alexl/">Alex Larsson</a> picked up the task to review and clean up the branch. Even more so as he recently <a href="http://mail.gnome.org/archives/nautilus-list/2009-December/msg00037.html">commited</a> a reviewed version to Gnome git master, which can be seen in above screenshot. <br />
<br />
The UI is not yet final, and there are a few issues still to be worked out, but I really like the route that it's going. So, if all goes well, there won't be any Nautilus packages for Lucid in my PPA..hbhttp://www.blogger.com/profile/01696157718617410014noreply@blogger.com16tag:blogger.com,1999:blog-1712978008892476580.post-8913717280052507212009-12-02T18:56:00.000+01:002009-12-02T18:56:40.522+01:00The Tomboy and the BeastTo a large degree, Open Source is about scratching personal itches. The results are oftentimes small scripts, tools or plugins, rather than ending up as big projects of their own. Even if only little time is invested, the result can sometimes make a difference in terms of working efficiency. And picking low-hanging fruits surely is fun!<br />
<br />
I'm using Claws Mail as MUA and <a href="http://projects.gnome.org/tomboy/">Tomboy</a> to organise my ideas and workflow. Both are truly excellent in their areas. However, an email is oftentimes connected to an idea, or a task, so I want to connect emails and notes somehow. Unfortunately, Claws Mail and Tomboy don't play well together.<br />
<br />
When dragging emails from Claws Mail and dropping them into a Tomboy note, this is what you get:<br />
<br />
<div class="separator" style="clear: both; text-align: center;"><br />
</div><div class="separator" style="clear: both; text-align: center;"><a href="http://2.bp.blogspot.com/_tWQEjnxEHnw/SxaoItQzIlI/AAAAAAAAAE8/YAXDx1D3ykk/s1600-h/tomboy-no-addin.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="http://2.bp.blogspot.com/_tWQEjnxEHnw/SxaoItQzIlI/AAAAAAAAAE8/YAXDx1D3ykk/s320/tomboy-no-addin.png" /></a><br />
</div><br />
Of course, the temporary files are cleaned up again after Claws Mail is closed, so the links are not only clumsy and non-descriptive, but also non-persistent and therefore totally useless in a note.<br />
<br />
No more! I wrote a little addin for Tomboy that provides Claws Mail integration, so when loaded, email drag'n'drop results in this:<br />
<br />
<div class="separator" style="clear: both; text-align: center;"><a href="http://2.bp.blogspot.com/_tWQEjnxEHnw/SxanY-3WCrI/AAAAAAAAAE0/elkKxSk2Bus/s1600-h/tomboy-claws-mail-addin.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="http://2.bp.blogspot.com/_tWQEjnxEHnw/SxanY-3WCrI/AAAAAAAAAE0/elkKxSk2Bus/s320/tomboy-claws-mail-addin.png" /></a><br />
</div><br />
When clicking the link, the email is opened in Claws Mail again.<br />
<br />
Code is on <a href="http://github.com/hb/tomboy-claws-mail-addin/">GitHub</a>. I still couldn't find enough motivation to write the autofoo for it, so for now, a small hand-cooked Makefile has to do. Be sure to read the README file. I am not a fan of binary releases, but if anybody is interested in the dll, drop me a line. Also note that it currently only works with Claws Mail from CVS.<br />
<br />
First impression of the Tomboy addin interface was very positive. It makes writing small addins easy, even for those unfamiliar with the general codebase. Well, even more in this case, as Tomboy ships with an Evolution addin which does the same thing for Evolution, and was an obvious source of inspiration.. Isn't Open Source great?hbhttp://www.blogger.com/profile/01696157718617410014noreply@blogger.com6tag:blogger.com,1999:blog-1712978008892476580.post-91939847772015276802009-09-19T01:32:00.003+02:002009-09-19T01:41:02.693+02:00Chronically Underrated: UndoIn the past years, software designers have done a lot of research not only of what a good user interface is supposed to look like, but also how it is supposed to behave. A key component (that to this day a lot of software still gets wrong) is to not bother users with dialogs, especially not those nasty modal ones, but to just <span style="font-weight: bold;">do the right thing</span>. Of course, the program can't always know what the right thing is supposed to be, so to accomodate for mistakes, the application should still shoot ahead, but <span style="font-weight: bold;">offer an easy way to undo<span style="font-weight: bold;"> </span></span>those actions again. The beautiful article <a href="http://www.alistapart.com/articles/neveruseawarning">"Never Use a Warning When you Mean Undo"</a> by Aza Raskin should be a must-read for all UI developers.<br /><br />Actually, this not only applies to graphical user interfaces, and clicking away dialog boxes, but also to command line interfaces. I've recently aliased <span style="font-style: italic;">rm</span> with <span style="font-style: italic;">gvfs-trash </span>on a few machines (including my own) for precisely that reason. Unfortunately, this alias does not work <a href="https://bugzilla.gnome.org/show_bug.cgi?id=591493">completely</a>, but I am still hoping that I can <span style="font-style: italic;">habituate</span> to its limitations.<br /><br />Unfortunately, Claws Mail is a sinner in that respect, too. On the plus side, it makes it hard to actually loose work (so it's not guilty of Aza's worst software sin). However, in many cases it prevents data loss by distracting the user (by popping up dialog boxes), and makes it hard to revert an accidental operation (<a href="http://www.thewildbeast.co.uk/claws-mail/bugzilla/show_bug.cgi?id=1972">like digging up messages in the trash</a>), so it is guilty of Aza's second and third worst software sins. Also, Claws Mail sadly doesn't come with Undo/Redo capabilities at all (well, apart from text entry in the compose window editor).<br /><br />Some years ago, probably around 2004, I was looking around for a general purpose undo/redo stack that offered GObject integration for a pet project of mine. I was very disappointed to not find anything back then, so I rolled my own. It's a small class that offers undo/redo stacks (optionally with a limited stack size). Stack entries can be grouped, groups can be nested. Everything can have a description. As an optional viewer, I had a simple gtk+ widget to display undo/redo stack entry descriptions in a list (or tree, in case of groups), acting as the view in a MVC pattern. Anyways, in the end, I got distracted from the pet project, and never published it.<br /><br />So, I thought I could <a href="http://github.com/hb/undo_stack">break out the undo class</a> from that old project, clean it up, streamline it a bit, and replace deprecated GObject/gtk+ stuff with shiny new technoligy. While doing that, I was looking around again at available undo frameworks, and was a little surprised to find <a href="http://doc.trolltech.com/4.5/qundo.html">one for Qt</a> and another <a href="http://github.com/herzi/gundo">one for GObject</a>, both of which I would assume to be older than my class (GUndo's ChangeLog dates back to late 2005, but some copyright headers speak of 1999). I wonder why I haven't found them earlier.. The funny thing is that both are kind of similar to what I did. Especially GUndo is (API-wise) crazily close to what I came up with (but of course, I still like mine better!). I guess there is only a limited amount of reasonable solutions to the undo/redo problem.<br /><br />We'll see if it's feasible to hook up Claws Mail with an undo stack. It's usually hard to put undo capabilities into a program that hasn't been designed for that from the start. But maybe it'll be possible to put at least a few error-prone actions (like getting back a message that was falsely moved into the trash) in.hbhttp://www.blogger.com/profile/01696157718617410014noreply@blogger.com2tag:blogger.com,1999:blog-1712978008892476580.post-38719243785478059922009-08-06T21:09:00.002+02:002009-08-10T11:22:41.127+02:00Claws Mail got bitten by a Snake!I've been successfully using the <a href="http://www.claws-mail.org/plugins.php">Perl plugin</a> for Claws Mail for a long time now. It hasn't seen many updates lately, but that's because I am mostly happy with it for my personal needs.<br /><br />However, filters for Claws Mail is one of the few remaining areas where I'm still a Perl user. I have the feeling that my mental capabilities are insufficient for memorizing the dozens (hundreds?) of <a href="http://glyphic.s3.amazonaws.com/ozone/mark/periodic/Periodic%20Table%20of%20the%20Operators%20A4%20300dpi.jpg">operators</a>, magic variables etc., especially after a while of absense from the language. "<span style="font-style: italic;">There is more than one way to do it"</span> is fine, but with age, I tend to prefer "<span style="font-style: italic;">There is a single (obvious) way to do it</span>" as a motto. So, for all of my scripting purposes, I found a new home at the <a href="http://www.python.org/">Python</a> people. Please, no discussion which one is "better", for whatever definition of "better". Both are nice languages, and I guess people just have to figure out which one suits their individual work flow better.<br /><br />So, lately, I had to embed a Python interpreter in some C code, and, as often when learning about new technologies, I though this might be a fun add-on to Claws Mail. Don't worry, I am not trying to bloat Claws Mail with every single interpreter out there -- although that might actually be a fun experience.<br /><br />So I cooked up a small Python plugin for Claws Mail, which adds an interactive Python console to Claws Mail (stolen and adapted from <a href="http://chipx86.github.com/gtkparasite/">gtkparasite</a> - which is a great project). It's also possible to execute scripts from the menu, for further automation. The interface to Claws Mail is still limited, and only includes calling menu items for now.<br /><br /><object width="425" height="344"><param name="movie" value="http://www.youtube.com/v/GnW4pMpiY40&hl=de&fs=1&"><param name="allowFullScreen" value="true"><param name="allowscriptaccess" value="always"><embed src="http://www.youtube.com/v/GnW4pMpiY40&hl=de&fs=1&" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="425" height="344"></embed></object><br /><br />(Planet readers: A short demo screencast is <a href="http://www.youtube.com/watch?v=GnW4pMpiY40">here</a>).<br /><br />Code is on <a href="http://github.com/hb/claws_mail_python_plugin/tree/master">GitHub</a>.<br /><br />PS: Yes, I know that the name Python actually refers to a commedy group, not to the animal. But I don't care.<br /><br /><span style="font-weight: bold;">Update:</span> The plugin source moved to <a href="http://scm.dotsrc.org/viewvc.cgi/claws-mail/plugins/python/?pathrev=gtk2">Claws Mail CVS</a>. It also gained on a new trick on the way -- automated composing of mail messages. See the README file for an example.hbhttp://www.blogger.com/profile/01696157718617410014noreply@blogger.com5tag:blogger.com,1999:blog-1712978008892476580.post-29096641937517182292009-07-22T10:08:00.013+02:002009-07-22T22:10:16.412+02:00TrashJournal: Your friendly Desktop RaccoonThe <a href="http://www.gnome.org/">Gnome</a> desktop doesn't really have a good view on the trash can. The display in Nautilus is very limited for a number of reasons. Most importantly, it does neither display the original path, nor the deletion date. Thus, it does not allow sorting by deletion date, and you never know where your restored files will end up. Also, if you deleted two files with the same name, there's no way to distinguish between them.<br /><br />That leaves two choices for the humble user: Keep the trash can in order, or treat it as a black hole.<br /><br />As a third option, one can use a little Python script that I wrote up recently, which gives a journaled view of the trash can:<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://1.bp.blogspot.com/_tWQEjnxEHnw/SmbQXYsDELI/AAAAAAAAADc/CchJWEst3WU/s1600-h/TrashJournal.png"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer; width: 400px; height: 151px;" src="http://1.bp.blogspot.com/_tWQEjnxEHnw/SmbQXYsDELI/AAAAAAAAADc/CchJWEst3WU/s400/TrashJournal.png" alt="" id="BLOGGER_PHOTO_ID_5361201506613924018" border="0" /></a><br />Code is (as usual) on <a href="http://github.com/hb/trashjournal/tree/master">GitHub</a>. As it's a Python script, you should be able to just run it (provided that you have Gnome- and GTK+ Python bindings installed).<span style="display: block;" id="formatbar_Buttons"><span class="on down" style="display: block;" id="formatbar_CreateLink" title="Link" onmouseover="ButtonHoverOn(this);" onmouseout="ButtonHoverOff(this);" onmouseup="" onmousedown="CheckFormatting(event);FormatbarButton('richeditorframe', this, 8);ButtonMouseDown(this);"><br />In fact, if the gconf dependancy was made optional, the script should work on any desktop which conforms to the freedesktop.org trash can spec.<br /><br />Okay, admittedly, this pet project is basically the result of my wanting to try out GIO, which is actually pretty nice.<br /></span></span>hbhttp://www.blogger.com/profile/01696157718617410014noreply@blogger.com3tag:blogger.com,1999:blog-1712978008892476580.post-49933450552775911502009-07-18T17:43:00.004+02:002009-07-18T19:57:47.263+02:00Excursion to Packaging-LandI just pushed a new <a href="http://github.com/hb/nautilus/tree/jaunty-split-view">branch</a> that cherry-picks most of the commits from the split-view branch of Nautilus, but only requires dependancies that are available on a standard Ubuntu Jaunty installation.<br /><br />More excitingly, I just uploaded packages for this branch for Ubuntu Jaunty to my <a href="https://launchpad.net/%7Eberndth/+archive/ppa">PPA</a>. The primary reason was to make it easier for me to use the branch at work. But of course, this also makes the code more accessible for Ubuntu users, so I hope for more testing reports.hbhttp://www.blogger.com/profile/01696157718617410014noreply@blogger.com2tag:blogger.com,1999:blog-1712978008892476580.post-19086073800026649202009-06-13T21:20:00.001+02:002009-06-13T21:22:08.568+02:00Nautilus Split View UpdateI've been working on cleaning up the history of the my Nautilus split view branch, and basing it on the official git repository. That's done now, so consider this post a <span style="font-weight: bold;">call for testing</span>! <a href="http://github.com/hb/nautilus/tree/split-view">Grab the source</a> and <a href="http://live.gnome.org/Nautilus/Development/Nautilus">get it running</a>. Please send <a href="mailto:berndth@gmx.de?subject=Nautilus%20Split%20View">emails</a> with bug reports, patches, remarks, and also success stories. I'd also be interested in reports from spatial-mode users, just to make sure the patchset doesn't introduce any regressions for them. I'd really like some more testing before requesting a review upstream.<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://1.bp.blogspot.com/_tWQEjnxEHnw/SjPzlBm_55I/AAAAAAAAAC0/gXm531gJuEw/s1600-h/nautilus_split_view.png"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer; width: 320px; height: 175px;" src="http://1.bp.blogspot.com/_tWQEjnxEHnw/SjPzlBm_55I/AAAAAAAAAC0/gXm531gJuEw/s320/nautilus_split_view.png" alt="" id="BLOGGER_PHOTO_ID_5346885000031627154" border="0" /></a><br />Some visual polishing took place compared to the <a href="http://www.youtube.com/watch?v=yqBDEi17l2A">old screencast</a>, for example the thin border in the theme's selected-color around the active pane, and shadow around the inactive pane.<br /><br />The buttons with the greyed-out look in the location bar on the right side of the screenshot are in fact sensitive. Clicking e.g. directory buttons changes to the respective directory and also make that pane active. The grey zoom control widgets and the insensitive-looking background work in an analogous way. That's not exactly HIG-compliant, but it seems very natural and intuitive.<br /><span style="display: block;" id="formatbar_Buttons"><span class="on down" style="display: block;" id="formatbar_CreateLink" title="Link" onmouseover="ButtonHoverOn(this);" onmouseout="ButtonHoverOff(this);" onmouseup="" onmousedown="CheckFormatting(event);FormatbarButton('richeditorframe', this, 8);ButtonMouseDown(this);"></span></span>hbhttp://www.blogger.com/profile/01696157718617410014noreply@blogger.com37tag:blogger.com,1999:blog-1712978008892476580.post-4904261118288831872009-05-17T10:25:00.012+02:002009-05-17T11:24:57.791+02:00Geo-TaggingLately, I had to deal with digital maps at work - a very interesting topic. As I wanted to check out <a href="http://projects.gnome.org/libchamplain/">libchamplain</a> anyways, I did a little plugin to display an estimate of the sender's location on a map in Claws Mail. This is a screenshot of one of my mails from a conference which I attended last year:<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://3.bp.blogspot.com/_tWQEjnxEHnw/Sg_Ui_jmGmI/AAAAAAAAACk/FqbjHpHsrT0/s1600-h/geolocation.png"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer; width: 320px; height: 192px;" src="http://3.bp.blogspot.com/_tWQEjnxEHnw/Sg_Ui_jmGmI/AAAAAAAAACk/FqbjHpHsrT0/s320/geolocation.png" alt="" id="BLOGGER_PHOTO_ID_5336717781098699362" border="0" /></a><br />Of course, there's no way to infer the geographic location of a sender from the mail with any kind of certainty. For example, as mailing list management software tends to rewrite the mail headers, mails to the Claws Mail Users mailing list show up as originated <a href="http://dotsrc.org/sponsors/">here</a>:<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://2.bp.blogspot.com/_tWQEjnxEHnw/Sg_U71WBsoI/AAAAAAAAACs/XR-XPIFKJIc/s1600-h/aalborg.png"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer; width: 320px; height: 218px;" src="http://2.bp.blogspot.com/_tWQEjnxEHnw/Sg_U71WBsoI/AAAAAAAAACs/XR-XPIFKJIc/s320/aalborg.png" alt="" id="BLOGGER_PHOTO_ID_5336718207854162562" border="0" /></a><br /><br />Other mailing lists (like GTK+, or Cairo) work fine, though.<br /><br />The surprising (and somehow scary) result is that it works on a surprisingly large number of mails (in my quick test, almost half of the time), and if it does, it's oftentimes quite accurate, with deviations sometimes as small as 2 or 3 kilometers. I honestly wouldn't have expected that. The <a href="http://github.com/hb/claws_mail_geolocation_plugin/tree/master">plugin is currently hosted on github</a>, and requires Claws Mail from CVS and libchamplain 0.3.<br /><br />On a side note: Also on github is an <a href="http://github.com/hb/claws_mail_gnome_plugin/tree/master">early version of a Gnome plugin</a>, which includes the Gnome address book in Claws Mail's completion list. That plugin crashes on unload, though, which also happens during Claws Mail shutdown. I haven't investigated that in detail yet, but I wouldn't be surprised if that was due to a dependancy library not being plugin safe. Wouldn't be the <a href="http://trac.galago-project.org/ticket/86">first time</a>.<br /><span style="display: block;" id="formatbar_Buttons"><span class="on down" style="display: block;" id="formatbar_CreateLink" title="Link" onmouseover="ButtonHoverOn(this);" onmouseout="ButtonHoverOff(this);" onmouseup="" onmousedown="CheckFormatting(event);FormatbarButton('richeditorframe', this, 8);ButtonMouseDown(this);"></span></span><span style="text-decoration: underline;"></span><span style="display: block;" id="formatbar_Buttons"><span class="on" style="display: block;" id="formatbar_CreateLink" title="Link" onmouseover="ButtonHoverOn(this);" onmouseout="ButtonHoverOff(this);" onmouseup="" onmousedown="CheckFormatting(event);FormatbarButton('richeditorframe', this, 8);ButtonMouseDown(this);"></span></span>hbhttp://www.blogger.com/profile/01696157718617410014noreply@blogger.com2tag:blogger.com,1999:blog-1712978008892476580.post-48967094726343494422009-04-20T22:17:00.003+02:002009-04-20T22:17:00.152+02:00Easter weekend coding funHad some slack time over the easter weekend, so I was able to do some fun coding.<br /><br />The Nautilus crew accepted <a href="http://git.gnome.org/cgit/nautilus/commit/?id=5515869bbecb46e04a5219af1553cd1a7cf5710e">two</a> <a href="http://git.gnome.org/cgit/nautilus/commit/?id=0934864e259a8aec827ce157a8a2b258a8d6d1f8">small</a> patches of mine to deal with keyboard shortcuts. Now it's possible to assign shortcuts to Nautilus scripts, and the shortcuts are remembered accross sessions. That's fixing two long-term annoyances of mine. It landed just in time for Gnome 2.26.1, meaning the Ubuntu Jaunty is shipping the fixes already. Good timing.<br /><br />The Nautilus split view branch that I have been <a href="http://berndth.blogspot.com/2009/02/splitting-shell.html">blogging about</a> (Planet readers: There is a screencast embedded in the previous post) is an ongoing pet project. I consider the branch pretty feature complete, except maybe background color modification of the inactive pane. However, the branch is currently based on an older revision, so the next big thing to do would be rebasing to the current state. In general, I am not hesitating to rebase the public branch on <a href="http://github.com/hb/nautilus/tree/split-view">github</a> when appropriate, even though I know that it's <a href="http://www.spinics.net/lists/linux-arch/msg03946.html">bad</a>. Drop me a message if you want to contribute, and that poses problems for you. Anyways, with Gnome moving to git, all that is becomming easier, especially for externals. Did I already mention that git is awesome?<br /><br />Of course, Claws Mail got some love, too. The notification plugin got support for window manager urgency hints and the fd.o sound specification. It also got a reworked bubble logic, to fix issues with Ubuntu's <a href="http://glyph.twistedmatrix.com/2009/04/notification-disappointment-in-ubuntu.html">broken</a> notification daemon. That will be going into cvs once I was able to test with Ubuntu Jaunty. I also wrote a little patch to include Gnome's addressbook in Claws Mail's address completion. The latter is not likely to go into cvs, but I may wrap the patch up and create a plugin for that.hbhttp://www.blogger.com/profile/01696157718617410014noreply@blogger.com3tag:blogger.com,1999:blog-1712978008892476580.post-48758444268613821872009-02-18T22:58:00.001+01:002009-02-18T23:01:53.448+01:00Splitting the Shell ...<div style="text-align: justify;"><img style="margin: 0pt 0pt 10px 10px; float: right; cursor: pointer; width: 200px; height: 150px;" src="http://2.bp.blogspot.com/_tWQEjnxEHnw/SZrZrURsnKI/AAAAAAAAAB0/QDdlThS1fwc/s200/300187377_24127ab6b5_m.jpg" alt="" id="BLOGGER_PHOTO_ID_5303790849382718626" border="0" /> ... but hopefully without cracking it completely.<br /><br />Some time ago, I read up on split view filebrowsing in Nautilus, Gnome's desktop shell. The <a href="http://bugzilla.gnome.org/show_bug.cgi?id=309646">requests</a>, <a href="http://blogs.gnome.org/cneumair/2008/07/08/its-done/#comment-302">comments</a>, discussions, <a href="http://ubuntuforums.org/showthread.php?t=675322">polls</a>, and flames fill endless bugreports, forums, <a href="http://brainstorm.ubuntu.com/idea/5499/">ideas</a>, articles, and mailing list <a href="http://www.nabble.com/Split%5CDual-pane-view-in-nautilus-td17205477.html">threads</a>. Well, I am one of those people that like Nautilus, but miss the split view capability during heavy duty filebrowsing jobs. I liked Norton Commander back in the old days, and its numerous successors. And I am not alone.<br /><br />So, in the true spirit of Open Source, I finally got my hands dirty and got a shot at it. It's not completely finished, but in a state that allows for a screencast preview:<br /><br /><object width="425" height="344"><param name="movie" value="http://www.youtube.com/v/yqBDEi17l2A&hl=de&fs=1&rel=0"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/v/yqBDEi17l2A&hl=de&fs=1&rel=0" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="425" height="344"></embed></object><br /><br />The code is hosted on github:<br /><code>$ git clone <a href="git://github.com/hb/nautilus.git" class="git_url_facebox" rel="#git-clone">git://github.com/hb/nautilus.git</a><br />$ git checkout -b split-view origin/split-view</code><br /><br /><br /><span style="font-weight: bold;"><span style="font-size:100%;">B</span><span style="font-size:100%;">ut will it blend? That is the question.</span></span><br /><br />I am curious if that branch will make it upstream. If you'd like that, you can help with testing and reporting (both, failures and successful uses)! While the patch is UI-wise minimal-invasive, quite a lot of code had to be shoveled around, so I am happy about every tester.<br /></div><br />(the beautiful shell picture is by <a href="http://www.flickr.com/photos/giopuo/300187377/">giopuo</a>, published on flickr under Creative Commons by & share alike)hbhttp://www.blogger.com/profile/01696157718617410014noreply@blogger.com4tag:blogger.com,1999:blog-1712978008892476580.post-8552287779793488652008-08-19T20:12:00.001+02:002008-08-19T20:12:01.092+02:00Linux driver nightmare<a href="http://linuxhaters.blogspot.com/">Linux Hater</a> is right in many of his claims, especially when talking about (non-existing) ABI or even API compatibility of the Linux kernel across versions. Everything is fine as long as your hardware is working out-of-the-box, but as soon as something is not supported out-of-the-box, you're up for a major nightmare.<br /><br />The past few days, I've been trying to migrate one of our systems from Windows XP to Linux. That box has a few pieces of non-standard hardware installed, mostly sensor systems. Many of those drivers have not found their way into the kernel yet. So let's see..<br /><ul><li>Installed Xubuntu 8.04 LTS</li><li>Install kernel headers, build system, etc.<br /></li><li>Contact vendor of USB Relais and ask for Linux kernel module</li><li>Surprisingly, got a module that (after minor modifications) compiles and even works!</li><li>Test USB camera. No luck with the Orange iBOT2. Apart from the iBOT2, our framework also supports UVC cameras. Bought a Logitech UVC camera (look out for the "Vista-ready" sticker), which works out of the box in Ubuntu 8.04! Yay!</li><li>Get and compile CAN driver. Seems to work nicely.</li><li>Contact measurement camera vendor, and ask for Linux drivers. Got drivers for a 2.4 kernel. After some investigation, also got experimental drivers for a 2.6 kernel that's been developed on 2.6.13 (and is GPL'ed OSS, btw).<br /></li><li>Got the camera driver to compile and load on Hardy's kernel with major modifications. Getting camera info (like chip temperature) works fine, but grabbing images results in kernel panic. Unfortunately, grabbing pictures from the camera is a rather important feature...<br /></li><li>Heard rumours that the camera driver works at least up to kernel version 2.6.17</li><li>Try to get kernel packages for something around 2.6.17. No luck on Hardy.</li><li>Clone vanilla kernel git repository, compile kernel 2.6.17. After several attempts, the self-compiled kernel even boots up!</li><li>Compile camera driver again. Grab a first picture! Yay!</li><li>Unfortunately, now the whole rest of the system is pretty broken. Hardy doesn't seem to like a manual kernel-downgrade.</li><li>Got the idea that it might be easier to upgrade a kernel, than to downgrade it. Killed the whole system and installed Xubuntu Dapper 6.06 LTS, which comes with kernel version 2.6.15. Maybe that version will work too, and I won't even need to upgrade..<br /></li><li>Compile all external drivers again</li><li>Test if the UVC camera still works. Of course -- it doesn't.</li><li>Download UVC kernel module from svn (there are no snapshots available). Try to compile it -- no luck. Try to find the latest svn revision number that actually compiles with Dapper's kernel by bisection. Compiled and loaded that kernel module.</li><li>Now, let's test with our framework<br /></li><li>Oh no -- our framework depends on newer versions of installed libraries (Boost, Qt, etc. pp.) than what is available for Dapper. Grab Boost, Qt, and all other libs from upstream, and compile them.</li><li>Oh no, the cmake build system backported to Dapper doesn't contain all necessary modules either (FindPkgConfig.cmake, others). Get those modules as well. No need to say that the backported cmake build system behaves slightly different to what is installed on Hardy as well.<br /></li><li>Compile and start the program. Oh no, crash deep inside Qt. Right -- no OpenGL support without proprietary graphics drivers. Install those as well.</li><li>Test UVC camera. It works!<br /></li></ul>Being a supporter and developer of OSS software myself, I can understand the reasons of the kernel developers for not maintaining a stable ABI (or even API) for kernel modules. But for the user, this is just a major pain, that ultimately renders Linux unusable on many environments.hbhttp://www.blogger.com/profile/01696157718617410014noreply@blogger.com2tag:blogger.com,1999:blog-1712978008892476580.post-61825643649953184072008-05-18T23:20:00.005+02:002008-05-19T11:02:32.315+02:00Reactions to the Debian - OpenSSL - disasterI really wanted to abstain from commenting the <a href="http://wiki.debian.org/SSLkeys">Debian OpenSSL disaster</a>. I have however read far to many <a href="http://www.gergely.risko.hu/debian-dsa1571.en.html">false claims</a> and <a href="http://www.links.org/?p=327">bloodcurtling comments</a> to leave them uncommented.<br /><br />Clearly, the Debian's OpenSSL maintainer has messed up <span style="font-weight: bold;">seriously</span>. Very seriously. He is the one to blame for thousands of machines being easily attackable during a time period of about 2 years.<br /><br />It's not as if the OpenSSL team was unblamable of this misery though.<br /><ul><li>The <a href="http://marc.info/?l=openssl-dev&m=114651085826293&w=2">original query</a> of the Debian Developer resulted in an <a href="http://marc.info/?l=openssl-dev&m=114652287210110&w=2">unfortunate answer</a> of an OpenSSL team member, and other than that ignorance. <a href="http://marc.info/?l=openssl-dev&m=117288023124631&w=2">Another mail</a> about a year later clearly says that a patch commenting out those lines made it into Debian, again with no feedback, so even the "If OpenSSL had known that this should go into Debian..." argument is invalid. I wonder why, since an OpenSSL guy claims that this mistake is so obvious and that upon seeing the patch, "we (the OpenSSL Team) would have fallen about laughing, and once we had got our breath back, told them what a terrible idea this was."<br /><br />I am not going to comment on the the claim that openssl-dev was the wrong mailing list, as <a href="http://advogato.org/person/branden/diary/5.html">Branden's blog post</a> leaves nothing to add on that topic.<br /><br /></li><li>The claim that making OpenSSL Valgrind-clean is just a minor, unimportant cosmetic fix is wrong. The OpenSSL library is typically used by programs with network access. The developers of these programs often use Valgrind to catch memory access failures, which could easily compromise the security of the machine if not detected. Being able to Valgrind your code without drowning in OpenSSL warnings and errors is an important thing.<br /><br />Using very questionable (see point below) constructs in the code without even a source code comment is not something to be proud of either.<br /></li></ul><ul><li>The claim that the original OpenSSL code is not buggy is wrong. The claim that the "harmless" part of the disastrous patch is just harmless is wrong. It fixes a serious bug in OpenSSL. Using uninitialised objects with allocated or automatic storage results in <span style="font-weight: bold;">undefined behavior</span> in C.<br /><br />It may add Entropy to the pool. It may crash. It may send out a tarball of your .ssh and .gnupg directories to <a class="linkification-ext" href="mailto:ronald@mcdonald.com" title="Linkification: mailto:ronald@mcdonald.com">ronald@mcdonald.com</a> without letting you know.<br /><br />All three options (and <span style="font-weight: bold;">any</span> other option) is completely valid at program run time, or even at compile time.<br /><br />For example, this is a program that I use to predict the lottery numbers of the next five years:<br /><br />#include <stdio.h><br /><span style="font-family:courier new;"></span><br /><span style="font-family:courier new;">int main()</span><br /><br /><span style="font-family:courier new;">{</span><br /><br /><span style="font-family:courier new;"> int a;</span><br /><br /><span style="font-family:courier new;"> a++;</span><br /><br /><span style="font-family:courier new;"> printf("%d\n",a);</span><br /><br /><span style="font-family:courier new;"> return 0;</span><br /><br /><span style="font-family:courier new;">}</span><br /><br /><br />What? This doesn't work for you? Welcome to the wonderful world of undefined behavior.<br /><br />In the light of this, above linked comments sound almost ironic.<br /></li></ul><br />I feel Debian has learnt a lesson out of this. Can the OpenSSL team say the same?<br /><br /><span style="font-weight: bold;">Disclaimer:</span> These are solely my oppinions. I speak for no project or company or whatever. I am in no way affiliated to either OpenSSL or Debian. Both are outstanding, impressive free software projects.hbhttp://www.blogger.com/profile/01696157718617410014noreply@blogger.com2tag:blogger.com,1999:blog-1712978008892476580.post-85083841265753459942008-03-04T15:38:00.007+01:002008-03-09T23:05:26.192+01:00Claws Mail goes OpenSync - progress reportIt's been a while since my initial <a href="http://www.nabble.com/Only-the-brave:-Claws-Mail-goes-OpenSync%21-td14787318.html">announcement</a> of the Claws Mail - <a href="http://www.opensync.org/">OpenSync</a><span style="text-decoration: underline;"> </span>connection. Addressbook and calendar synchronisation are a pretty important topic for me. I hate trying to keep all those addressbooks or calendar events on PDAs or cell phones in sync manually. It is a lot of hassle - and ultimately just doesn't work.<br /><br />The OpenSync guys came up with a pretty well thought-out synchronisation framework that sounded interesting enough to invest some rainy Saturday afternoons and hook up Claws Mail with it.<br /><br />Now that contact synchronisation is going better and better, I decided to make my hands dirty on calendar events as well. <a href="http://www.colino.net/wordpress-1.5/">Colin</a>, being the author of Claws Mail's <a href="http://www.claws-mail.org/plugin.php?plugin=vcalendar">vCalendar plugin</a>, helped me out and implemented part of my calendar interface wishlist in the vCalendar plugin. As a result, one-way syncs of calendar events from Claws Mail to OpenSync counterparts are possible.<br /><br />As a proof of concept, let's use a Claws Mail / EDS sync group to show upcomming calendar events in the GNOME clock:<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://1.bp.blogspot.com/_tWQEjnxEHnw/R82yFzoiZJI/AAAAAAAAABE/yRLTX-2udnY/s1600-h/Bildschirmfoto.png"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer;" src="http://1.bp.blogspot.com/_tWQEjnxEHnw/R82yFzoiZJI/AAAAAAAAABE/yRLTX-2udnY/s320/Bildschirmfoto.png" alt="" id="BLOGGER_PHOTO_ID_5173987359747892370" border="0" /></a><br />It's far from being complete (and even farther from being usable), but it's an encouraging progress.<br /><br />Hosting moved to <a href="http://github.com/">github</a>. There's <a href="http://github.com/hb/claws_mail_opensync_plugin/tree/master">one repository</a> for the OpenSync plugin for Claws Mail, and <a href="http://github.com/hb/claws-mail-sync/tree/master">another repository</a> for the Claws Mail plugin for OpenSync. You'll need both if you want to try this out. Also, the plugin for OpenSync requires a pretty recent (probably svn) version of OpenSync up and running.hbhttp://www.blogger.com/profile/01696157718617410014noreply@blogger.com6tag:blogger.com,1999:blog-1712978008892476580.post-83946542519182490752008-02-12T09:42:00.000+01:002008-02-12T11:18:37.342+01:00Licence funIf a piece of software wants to link against GPL'd code, it has to be <a href="http://www.gnu.org/licenses/gpl-faq.html#WhatDoesCompatMean">GPL-compatible</a>. To be more accurate, it has to be compatible with that specific GPL version. So far so good.<br /><br />Now, GPLv2 and GPLv3 are <a href="http://www.gnu.org/licenses/gpl-faq.html#v2v3Compatibility">incompatible.</a> As a consequence, code under GPLv2 and GPLv3 cannot be combined. This has nasty consequences.<br /><br />This time it's not <a href="http://www.claws-mail.org">Claws Mail</a> that bites, but it got <a href="http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=462963">bitten back</a> by <a href="http://www.clamav.net/">ClamAV</a>. Claws Mail is licenced under GPLv3 or later. It has an optional plugin for email antivirus-scanning that uses libclamav, which is licenced under GPLv2 (only). Do you see it comming? That plugin, even if itself licenced under GPLv2 or later and thus in theory compatible with both sides that it is supposed to connect, is itself <a href="http://www.gnu.org/licenses/gpl-faq.html#GPLAndPlugins">illegal</a>.<br /><br />In fact, you can take the FSF <a href="http://www.gnu.org/licenses/gpl-faq.html">GPL FAQ</a>, section "<span style="font-style: italic;">Combining work with code released under the GNU licenses</span>", <span style="font-weight: bold;">read "non-free" or "proprietary" as a synonym for "licenced under GPLv2"</span>, and the statements remain valid.<br /><span style="text-decoration: underline;"></span><br /><span style="font-weight: bold;">Isn't that ironic, at best?<span style="font-weight: bold;"><br /><br /></span></span>Now, what is the way out? <a href="http://www.colino.net/wordpress-1.5/">Colin</a> asked the FSF about the problem, and the options are basically to<br /><ul><li>convince ClamAV to put their library under a licence compatible to GPLv3</li><li>have libclamav grant Claws Mail specific permission to link libclamav<br /></li><li>change Claws Mail's licence to GPLv2 or later</li></ul>It is also possible to<br /><ul><li>roll out ClamAV's functionality into separate processes (fork(), exec() is legal)</li><li>just drop the ClamAV plugin<br /></li></ul><span style="font-weight: bold;"><span style="font-weight: bold;"></span></span>Fun, isn't it?hbhttp://www.blogger.com/profile/01696157718617410014noreply@blogger.com2tag:blogger.com,1999:blog-1712978008892476580.post-17943726561564559662008-01-23T22:56:00.000+01:002008-01-23T23:14:08.732+01:00Hello World! test postThis is the mandatory test post. I got this blog a long, long time ago, but never used it. Future will show whether or not I will have some random thoughts to share.hbhttp://www.blogger.com/profile/01696157718617410014noreply@blogger.com0