August 12, 2012

Holger Berndt's Blog

Nautilus Extra Pane Removal: Myth Busting

Since I announced the birth and the growing-up of Nautilus' extra pane in this blog I guess it's only fair to also mention this feature's silent death here.

There's been a lot of vandalism 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, compact-mode, and the tree sidebar into nirvana.

All these removals came somewhat as a surprise to me, as they seem to directly oppose Nautilus' mission statement. So I guess this has been superseded. Too bad that this wasn't communicated - people would have been less surprised.

So, let's have a critical look at the reasoning for the removal of the extra pane.

Starting with the bug report:

Extra Pane mode was somewhat useful before GNOME 3 had side by side window mode.
Fun fact: That's the first time that I hear a GNOME designer call it "somewhat useful". Usually, the reaction was WE ALL HATE IT (capitals are theirs, I left the double-underline out). Anyways, historically, the extra pane was introduced because of 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.

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.

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 also removed but that I was allowed to bring back).

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.

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 trivial. With a shortcut assigned to it, these little things help me work. A lot.

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.¹

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:
Some of these side-aspects can be taken care of. By horrible hacks, though. Or by removing yet more features. If nothing is left, nothing is duplicated.

C'mon, if you want to argue against the extra pane, you can do better. I mean, if you're on a mission, I'm sure you can think of some more convincing arguments. Let's see...
The combination of panes and tabs is just too much.
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.
It is inconsistent with the file chooser
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 eloquent newspeak: When Nautilus receives yet more "love".

and doesn't work well with touch.
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.

Do you guys actually realize that your whole reasoning consists of either false or unelaborated claims?
We would like to add a more explicit copy/move feature shortly.
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 after you have a replacement. Not before.

That's basically it for the bug report and commit msg. But the blog post that I linked to before has more:
The first reason was that it was undiscoverable.
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.
this one also stood in the way of providing a better alternative
What alternative? How did it stand in the way? Don't be so fuzzy - where is the beef?
Even if you never used the Extra Pane you always had useless Move To and Copy To items in the menus.
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.
Should we keep the feature for which we have a new and better alternative in Nautilus
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.

I'll leave the side-by-side snapping out, becaues I've covered it already. Which brings me to
and a pile of bugs getting no attention in bugzilla
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 they won't tell you about).

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.

Which turns the statements from criticism into slander. Disgusting behavior.


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.

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.

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.




1 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.


Edit: 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 "can't we talk without filing bugs?", followed by "what a crappy comment". D'oh.

August 12, 2012 07:55 PM

July 22, 2011

Mollux.org

A new portfolio online

Hi folks!

what? Yet another post this year? That must mean mollux.org’s revival ;-) .. or not!

I’m just here to announce my new gallery online, a portfolio in fact. It should, and will reflect a turn that appeared in my photographic activities and be representative of my works (low incoming traffic, more concerned on quality than daily crap): abstract subjects, artists representations, photo-modelling, and maybe few travel diaries and contests.

Here’s the portfolio.

My old galleries won’t vanish but can de facto be considered as archives.

Oh er.. by the way, the site probably looks weird for IE users (unless they use IE9), and I don’t care much about it ;-) .

July 22, 2011 06:03 AM - (Comments)

May 19, 2011

Mollux.org

L’interdiction des avertisseurs de radars est injuste !

Ouais merdeuuu @#$%!

La liste des manifs FFMC, au passage.

May 19, 2011 07:15 AM - (Comments)

February 28, 2010

Holger Berndt's Blog

Nautilus in the stress field between design and function

So, there's been a lot of talk about Nautilus' present and future design. Especially Izo's article 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.

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 habituated 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 focus 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.

Izo seems to have a typical case of forgotten addressed use-cases in his review when he writes about the stop button:
"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."
That you 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.

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 "Simplified Nautilus").

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 a lot of screen estate, and have a lot more unwanted UI elements in their face. Combine that with the talk about removing the menu bar alltogether (and thus loosing the habituated 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.

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.


Split View - Curse or Blessing?

Having the location bar embedded into the toolbar items also has another problem: It doesn't work well with the a split-view filebrowsing mode. This mode got some very harsh criticism 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).

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.

A reccurring question was "why split-view", and the proposal to implement panes in the window manager instead. This is a valid question, and has in fact been discussed on the Nautilus mailing list. (Hint: In general, project mailing lists are a good place for both, to research design decisions and to ask the "why" question.)

Fact is, split-view filebrowsing is not trying to solve window manager shortcommings on the wrong level. Even if Metacity had snap today, this wouldn't be an alternative.

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 source, and the target. What split-view does is to display a "default target" right next to the source. That's why it makes sense to have 2 panels, but not 3 or 4.

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.

The “default target” notation offers even more for advanced users, which can access both the source and the target pane in their Nautilus Scripts (and write for example a “diff these two directories” script with very little effort). This surely isn’t possible with a WM snap either.

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.

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.

Photo © Adventures in Librarianship on flickr, cc-by-nc-sa

February 28, 2010 08:01 PM

February 25, 2010

Holger Berndt's Blog

Linking notes and email messages

A 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: Claws Mail with the Python plugin and two of the shipped example scripts on the one side, Tomboy with the Claws Mail addin and the Reminder addin on the other side.

Starting with a message selection in Claws Mail,


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)


which in turn creates this Tomboy note


The Tomboy reminder plugin will take care to remind me about this next monday by raising the note.

To make the round-trip complete, there's a second example script that raises all Tomboy notes that link to a selected message.

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.

February 25, 2010 11:11 PM

January 18, 2010

Holger Berndt's Blog

The Tomboy and the Git

Tomboy's taming of the beast 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?

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 gitk, giggle, and gitg 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.

With that in place, it was easy to write a Tomboy addin 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.



I like these little helpers. They have a good work/gain ratio.

January 18, 2010 09:20 PM

January 17, 2010

Holger Berndt's Blog

Extending and Automating Claws Mail - the sneaky way

The 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).

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?).

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.

January 17, 2010 04:12 PM

December 13, 2009

Holger Berndt's Blog

Nautilus Split View and Upstream

Check out that screenshot about the current state of splitting a Nautilus window:



The exciting thing is that this is not a screenshot of my split-view branch, but of Gnome git master.

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 requested a review for it. Turned out that I had a good timing, because with the upcomming Gnome Shell, a debate 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.

I am very happy that Alex Larsson picked up the task to review and clean up the branch. Even more so as he recently commited a reviewed version to Gnome git master, which can be seen in above screenshot.

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..

December 13, 2009 11:12 PM

December 02, 2009

Holger Berndt's Blog

The Tomboy and the Beast

To 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!

I'm using Claws Mail as MUA and Tomboy 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.

When dragging emails from Claws Mail and dropping them into a Tomboy note, this is what you get:




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.

No more! I wrote a little addin for Tomboy that provides Claws Mail integration, so when loaded, email drag'n'drop results in this:



When clicking the link, the email is opened in Claws Mail again.

Code is on GitHub. 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.

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?

December 02, 2009 05:56 PM

September 18, 2009

Holger Berndt's Blog

Chronically Underrated: Undo

In 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 do the right thing. 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 offer an easy way to undo those actions again. The beautiful article "Never Use a Warning When you Mean Undo" by Aza Raskin should be a must-read for all UI developers.

Actually, this not only applies to graphical user interfaces, and clicking away dialog boxes, but also to command line interfaces. I've recently aliased rm with gvfs-trash on a few machines (including my own) for precisely that reason. Unfortunately, this alias does not work completely, but I am still hoping that I can habituate to its limitations.

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 (like digging up messages in the trash), 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).

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.

So, I thought I could break out the undo class 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 one for Qt and another one for GObject, 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.

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.

September 18, 2009 11:32 PM

August 06, 2009

Holger Berndt's Blog

Claws Mail got bitten by a Snake!

I've been successfully using the Perl plugin 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.

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 operators, magic variables etc., especially after a while of absense from the language. "There is more than one way to do it" is fine, but with age, I tend to prefer "There is a single (obvious) way to do it" as a motto. So, for all of my scripting purposes, I found a new home at the Python 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.

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.

So I cooked up a small Python plugin for Claws Mail, which adds an interactive Python console to Claws Mail (stolen and adapted from gtkparasite - 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.



(Planet readers: A short demo screencast is here).

Code is on GitHub.

PS: Yes, I know that the name Python actually refers to a commedy group, not to the animal. But I don't care.

Update: The plugin source moved to Claws Mail CVS. It also gained on a new trick on the way -- automated composing of mail messages. See the README file for an example.

August 06, 2009 07:09 PM

July 22, 2009

Holger Berndt's Blog

TrashJournal: Your friendly Desktop Raccoon

The Gnome 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.

That leaves two choices for the humble user: Keep the trash can in order, or treat it as a black hole.

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:


Code is (as usual) on GitHub. As it's a Python script, you should be able to just run it (provided that you have Gnome- and GTK+ Python bindings installed).
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.

Okay, admittedly, this pet project is basically the result of my wanting to try out GIO, which is actually pretty nice.

July 22, 2009 08:08 AM

June 20, 2008

Mollux.org

Laughin’ my ass off: meretrix ISO-certified works

Did you know that Meretrix Technologies “Care About Your Needs”? That could not tell you anything special, unless you remember that meretrix is latin for prostitute. Good to know that they’re ISO9001 certified :-D .

See: http://www.meretrix.com/.

Are they really serious, trying to be funny or simply ignorant?

Moreover, quoting the main page:

[..]
We’re about performance, because you’re about performance, and we’re about unleashing the dynamic energy of today’s technology for you! We understand the importance of standards-compliant open systems technology, and we can provide the complete solutions that you need.
[..]
Here at Meretrix Technologies, we understand the value of Continuous Quality Improvement. We believe that if we can provide constant improvement in our services, that their quality will continue to increase as a result, particularly over time, and that will, of course, mean greater performance over the long run.
[..]

They sell blue pills maybe?

And also:

[..]
And as part of the Meretrix Vision, as seen by our founder, respected technologist, humanitarian, and bon-vivant Harry Mantakos, we believe that anyone who takes this web page seriously is a complete idiot. Hell, I wasn’t even wearing pants when I wrote it.
[..]

Definitely not serious. Woud you present your founder with such a picture?

June 20, 2008 09:53 AM - (Comments)

February 14, 2008

Mollux.org

gToDo for IT/OS2008

This time it’s just an early port of gToDo to Maemo. With the agreement gToDo’s author, QBall Cow, I’ve taken over the maintenance of gToDo 0.x (he’s focusing at gToDo 2.x, but there’s still some users using the 0.x version). A preliminary package for maemo is available from my Maemo repository, it includes few patches from mine (this is why it’s versioned 0.16.0rc3), but there’s still some GUI rework needed. Expect an update soon!

Homepage of gTodo
gToDo at maemo.org

February 14, 2008 01:38 PM - (Comments)

Audio Tag Tool and Gringotts for IT/OS2008!

Editing tags in audio files (OGG/MP3), and carrying your secret keys in a strongbox while travelling with your N810 tablet in your pocket? It’s now possible!

I’ve completed the preliminary port of two of my favourite applications to Maemo (IT/OS2008 aka Chinook): Audio Tag Tool and Gringotts. Did some changes to the sources, debian’ized and created packages (with the necessary dependencies to Gringotts: libmcrypt4, libmhash2 and libgringotts). Asked for authors’ agreement, and here are some early packages of Audio Tag Tool 0.12.3 and Gringotts 1.2.10pre1! They (and their deps) at available on their respective official download locations as well as by the way of my personal Maemo repository.

Homepage of Audio Tag Tool
Audio Tag Tool at maemo.org

Homepage of Gringotts
Gringotts at maemo.org

February 14, 2008 09:11 AM - (Comments)

February 06, 2008

Mollux.org

Pecomato and RsBackup for IT/OS2008

Pecomato and RsBackup are now available on Maemo IT/OS2008 (Chinook). It was more about doing adaptations than doing real porting process, had to learn a bit of .deb ARM package creation and debian repository setup. Pecomato 0.0.15 and RsBackup 0.0.9 (a Qt4 pre-version) run fine on my N810 tablet, now I can use my picture file process scripts when travelling ;-) .

Pecomato at garage.maemo.org
Pecomato in maemo.org’s OS2008 catalogue

RsBackup at garage.maemo.org
RsBackup in maemo.org’s OS2008 catalogue

The maemo repository, at mollux.org, serving Pecomato and RsBackup .deb’s.

February 06, 2008 11:03 PM - (Comments)

October 05, 2007

Mollux.org

Gallery updates: California

Hey all,

back from our short vacation time in California, few days spent with lovely friends of us, who live near San Francisco. Of course, we’ve added - at last - a bunch of photos to the gallery. They are mostly from San Francisco and few nice places around, and from the High Sierras (Sierra Nevada, Yosemite National Park).

We’ve created a smaller folder with some highlights:
200709xx_highlights

All other folders, including few artistic compositions (last two folders):
20070915_muir_woods
20070915_san_francisco
20070915_stinson
20070916_monterey_carmel
20070917_san_francisco
20070918_sf_academy_of_sciences
20070919_san_francisco
20070919_sf_botanical_garden
20070919_sf_conservatory_of_flowers
20070919_sf_japanese_tea_garden
20070920_lake_tahoe
20070922_bodie
20070922_mono_lake
20070923_curry_village
20070923_mist_trail
200709xx_bw_series
200709xx_on_california_roads

And a private one, that requires you to log in:
200709xx_sf_pv

The traditional appetizers:

SF: Golden Gate Bridge SF: Market Street SF: Conservatory of Flowers
Lake Tahoe Emerald Bay Nevada Falls

And, by the way, I’ve added some forgotten photos from August 2007, taken in le Clos Lucé, the last residence of Leonardo da Vinci (in Amboise near Tours, France). This was obviously not the right moment to visit it, it was over-crowded with hundreds of Italian (and other usual French, Japanese) tourists, making the visit uncomfortable and a bit stressing. That also explains the lack of interesting pictures, as I dislike shooting in such conditions.

20070815_clos_luce

October 05, 2007 11:20 PM - (Comments)

October 01, 2007

Mollux.org

Announcing Pecomato 0.0.15

A critical buffer overrun was found and fixed - there’s no risk of data loss, just a crash after files are processed. Thus leading to an urgent release, 0.0.15.

The PECoMaTo page is here. Downloads section is here.

October 01, 2007 07:42 AM - (Comments)

August 26, 2007

Mollux.org

Announcing Pecomato 0.0.14

Pecomato 0.0.14 is out!

I’ve added the possibility to append IPTC records (filter edits) to an existing IPTC chunk. Include/exclude filters are not limited to 100 items anymore. The loading of exclude filters from a file has been fixed (it was broken in 0.0.13). Pecomato is now licensed under GPL v3 or greater. Few RPM packaging rules also changed and I’ve added .7z archives.

Starting from 0.0.14, I’ll only provide GNU/Linux and Windows packages. Other ports will be done on-demand or according to my spare time and will.

Jump to the downloads section. The PECoMaTo page is here.

August 26, 2007 10:42 AM - (Comments)

August 02, 2007

Mollux.org

Visit Mollux City!

C’mon, make it grow :-) . Click to visit Mollux City!





Visit Mollux City


Now we can increase the industry, but I wonder if we really should do that!

August 02, 2007 01:36 PM - (Comments)