Vim for a RSI-suffering journalist?

January 10, 2009

Greetings lazyweb

This Christmas my sister, working as a journalist, talked to me about her painful experiences with RSI (Repetitive strain injury) problems, and I just now two weeks later remembered how vim was designed to be easy on the fingers exactly in regards to this kind of problems. What I’m not sure about is how much strain vim really could save a journalist. As a coder, the advantages are obvious because you’re jumping around in the code all the time, doing small changes. But as a journalist I fear the advantages are smaller, and I’m not so certain I want to recommend her start walking the steep hill that is getting efficient with vim when it might even cause her fingers more strain than before (considering that if she really mostly is just typing in insert mode, the whole switching modes paradigm isn’t helping).

So what’s the planet’s call, is vim fit for a journalist?


Idea of the week: Universal config file user interface

November 26, 2008

Here I am again, sitting around thinking about exciting software ideas when I actually should be working. This time it’s all about config files. How many times have you either:

1. Complained to yourself when you encounter a config file that uses its own file syntax
2. Wished that there was a gui available for some option you frequently change
3. Wanted to have all configuration options in one place?

No, I am not going to suggest that we make our own “KDE registry”. I am also not going to suggest a solution that needs each and everyone to adapt to it.

As the title hints, I want to create an universal config user interface. The way it would work, is that it would be split into two parts. One is a kind of a parser, that has a collection of config file syntaxes (think for example vim’s collection of syntax highlighting files) defining rules and other useful properties for a certain type of config file. The other part would be the gui itself, which would let the user play around with settings and see things change, while at the same time be certain that no fun is spoiled due to a misspelling, invalid value for a certain setting, or other similar unfortunate mistakes. As a plus, it could probably also be set to backup changes and save versions of the configuration in case things go terribly wrong.

Why would one want this? Well, editing config files for all your setup needs is a pain. But so is creating a gui for them. And while I of course acknowledge that advanced users prefer the possibilites that having settings in a text file bring, advanced users are humans too. Humans that make mistakes, and then spend hours debugging and searching for what’s wrong when they suddenly discover a single line in ~/.myfavoriteditorrc  “DoNotEraseMyWork = Treu”.

Also, it would be good to use as a fallback when you are going to instruct someone to change a more advanced setting, but at the same time don’t want to have to explain to them why it doesn’t work even though they typed “DoNotEraseMyWork = True” and saved it in ~/myfavoriteeditorrc.odt.

Does something like this already exist, maybe? Tell me in the comments.

CLI challence: handle weird filenames without the use of copy-paste

November 18, 2008

These days, being in a lab abroad, one situation I commonly face is handling complex filenames in the terminal. For many european languages, one could in these cases just spend a few moments finding the right accent key on the keyboard, and remember it for later how to type this key. But with the filenames I face here it’s often not appearant how I input a certain letter, or even worse, the filename is a victim of mojibake .

So I ask the planet, what can I do about this? I’d rather not have to reach for the copypasta, and in some cases even that does not help (messed up filename triggers tab-completion/shell bugs). Worst case is having to pull up konq/dolphin and actually gui-rename the file.

Here’s an archive with three weird filenames for your enjoyment.

Solutions in the comments.

Autohiding widgets: a prototype

October 18, 2008

After thinking about it for a bit I realized this was the second (or third?) time I have blogged about some idea I had, but never really tested out the theory. So this time I decided to try it out and see how it works. So here’s a prototype of the method I have been talking about the two last blogs. Picture on the left, and here’s a youtube video.

video in ogg version

The way it works is that widgets are inserted, along with a priority, into an object that does it’s magic when a resize event is triggered. It loks at the difference between the widgets size and its minimumSizeHint, and if it’s approaching zero it hides the least important widget. It uses the same value to accumulate how much slack there is (total difference between minimumsizehint and size), and determines if it’s ok to show the most higly prioritized widget.

Although this code here is just a big hack, it would be interesting to compile it into some kde applications and see how it works (if it works at all).

@mark, seb, re: discoverability with automatically hiding widgets

October 16, 2008

OK, I wanted to include a picture so I just made this into another blog post.
I would like to argue that this is more of a solution for making the app usable when it’s resized to less than normal sizes. If actually having to teach the user that it needs to make the window larger to get the controls he want on screen, then someone has messed up the defaults of the application. As long as it’s initially resized to a good size, it should feel natural to the user instantly if he sees windows grow smaller and then finally disappear when he gradually makes the window smaller.

And another point: have a look at this small krita.

…or even smaller!

Would you agree me with me if I say that in this case, the problem that the interface has just become practically unusable, should take priority over the fact that the user might be a little bit confused about how to get his windows back (although I still thinks it should feel natural if done right)? And instead, it automagically turned into this:

Hope I didn’t create any strawmen here by misunderstanding your arguments, yell back if I did 🙂

Space-prioritizing widgets

October 16, 2008

A thought struck me just now. My impression is that a lot of applications, when resized, will just resize the widgets, UI, toolwindows, everything with it in a proportional manner. Wouldn’t it be better if when you resize, the less important widgets and window elements are just hidden, and pop up again once you enlarge the window and give it a bit more screenspace?

How about a way to prioritize the elements on screen, such that you can define some things as always-needed (kind of like always on top in window manager space), and rank other less important tools below that. My vision is then, that for example an app like Krita, once you make the app really small it would only show the bare necessity, in this case somethinglike just the picture and a color chooser.

A picture I made with my awesome gimp skills for those of you that cannot see my vision through my words:

Automated HCI testing: a research project aimed for use with KDE

October 6, 2008

Stupid wordpress. second time I’m writing this. OK, I would like to present my idea for the research project I will work on for a year from now.

Problem: Users don’t test usability in FOSS software enough. It’s too laborous and unrewarding.

Solution: Take advantage of the fact that many users enjoy trying out new features, but don’t go so far as to actually download, compile and test unreleased software. Build a solution that let’s them test unreleased software easily. Use technologies such as klik or glick to include all needed libraries in a single runnable binary. Allow for instrumenting the software with automated tests (for example, with a qt app, one could use a class that would attach to all qt buttons and menus and generate statistics on which buttons were used most, and how a certain task was performed, maybe even record all events and do some sort of a playback that the developer can observe). Distribute this instrumented software to a large group of users and generate a summary of the results that the developer can use for reference when (re)designing the software.

Implementation details: Since this is a one year research project, I aim at making a prototype of this solution, only implementing the needed parts as I go along. I do intend to write it so that the project can be continued afterwards as well. What I need from the community is help with testing this solution on a certain piece of software. What kind of software this would be is of course dependent on how I implement the prototype, but since I know KDE well I think choosing a KDE application would be a good choice. (Maybe even choose Ark, as some might remember that I also code on)

I have not yet finalized on this plan, it might change or even be replaced altogether. But either way I would like to know what the community thinks about the idea? Are there any obvious logical problems? Technical problems? Let me know in the comments.

A dashboard for your extra mouse button

September 23, 2008

Just thought I’d share with you people what I did the other day. I’m one of those people who just haven’t managed to let go of icons on the desktop, so one thing I found myself doing a lot is showing the dashboard (ctrl+f12) and then clicking the shortcut. So if figured, what if I made it so that I can activate desktop icons with just one click, using that extra button on the right side of the mouse that I never use?

Here’s what you do. First install xbindkeys and xautomation (needed for the xte utility), then edit your ~/.xbindkeysrc file and add:
"xte 'mouseclick 1'"
b:6 + release

"dbus-send --type=method_call --dest=org.kde.plasma /App local.PlasmaApp.toggleDashboard"

This is also assuming that you have setup xorg correctly and you want to bind button 6. Pressing the button down sends away a dbus request to show the dashboard. Then, when you release the mouse button the xte utility simulates a button click wherever you have the mouse.

Finally, to have this all the time, add xbindkeys to your startup application list with the wonderful KDE4 gui that I just discovered moments ago. No need to go on hacking inside the .kde/Autostart directory.

Re: deskzilla, they gave us a site license

August 18, 2008

Here’s a followup to the previous post about deskzilla, they were actually really quick to response to my request and sent me a wide site license free for distribution. So, for anyone who wants it I uploaded it here:


Deskzilla – what do you think?

August 18, 2008

So at last the new version of rolled in, and for the occasion I started looking around for frontends to this thing. I stumbled upon Deskzilla, which is proprietary, but they give away free open source licenses (I applied for one today) and have been mostly linux friendly so far in my opinion.

Here’s a screenshot of the layout I eventually ended up after playing with it for a few hours today:

It’s really comfy to be able to cache the bug reports and efficiently do jobs as confirming, marking duplicate bugs and commenting on things without having to deal with browser tabs and pages waiting for reload.

So, how’s the community’s view upon this piece of software? Do people look the other way because this is proprietary, or am I just slow to discover deskzilla? Are there already FOSS apps that do this? (and don’t try to say kbugbuster, it’s completely broken)