Archive for the ‘UI’ Category

KDE on multiuser/multicomputer systems?

November 13, 2009

On my schools computer lab we have lots of desktop computers all with gnome, kde and various other wm’s installed, with the home folder shared across all computers. Lately I’ve become more and more conscious of the various bugs setups like this bring in KDE. Even though most of the computers in question run the same (k)ubuntu, there’s many times more glitches than a similar single-user system. Things like “do you want to forget these audio devices” popping up on every login, plasmoids randomly failing to load when changing computers, wallpapers also randomly going blank, having to resize the panels when changing to/from a widescreen computer, plasmoid positions jumping around, etc etc, they all make me wonder how much the changing environment case has been taken into account designing the KDE desktop.

Are there tricks to get working setups for my case? Would the best bet perhaps to be to only use a least common denominator type of setup, only introducing new stuff when I know they work everywhere? Or am I crazy to even expect the desktop to work similarly on a (seen from KDE configuration POV) constantly changing environment?


Drag’n’drop menus/Ark “extract here” popup menu

April 2, 2009

KDE Brainstorm is great, when I was a little bored of fixing bugs and started feeling tired of the same code all the time, seeing peoples ideas once again brought me back to the coding mood. What they suggested this time was a menu where you can drag an archive file, and have “Extract here” pop up in the menu at the destination where the file is dropped. Looking at dolphin/libkonq code I saw that there was a TODO for actually bringing this kind of functionality back (remember dropping an image file on the desktop and getting “set as wallpaper”?) So I dived in and started hacking on a new plugin architecture for adding this kind of popups.

At this point the code has not been polished and is not ready for commiting yet, but it will be in a few days I think. Screenshot:


For anyone that want to extend their application with an item like this, now is the time to act to get it ready in time for 4.3. The “set as wallpaper” plugin will also be trivial to implement and is up for grabbing for anyone looking for a junior/junior high job.

These kind of conveniences are, in my eyes, the small but important things that made KDE what it is.

A rule for everybody who’s thinking about styling a button

January 21, 2009

I wish there was a rule from the start when designing KDE4. Whenever you really really need to not use one of the already very nice default Oxygen style buttons, and can find no way around actually creating your very own custom look button, please, PLEASE do it all the way and make sure it has unique, clear looks for the normal, hover and pressed down state.

Looking at the 4.2 desktop now I see so many widget elements breaking this rule. The most obvious (and possibly also the most important) is the start button – which has only one hover picture. When you press it you get no feedback at all, and the mental image I get every time I click that button is hitting my fist against a brick wall (why? it’s hard to explain, it just feels so hard and unmovable without the proper visual feedback).

Actually, when I think about it, this is actually the same for _all_ the buttons I have on my bottom panel. Including the systray expander button, which actually doesn’t even have a hover state. The task list is an exception, that one is actually doing it right. (Not that that one gives me a lot of feedback either with the all too subtle color change it has, but that’s really a problem with the current style, and not kde by itself).

A quick end note, to be honest, this was actually the kind of things I set out to fix when I slowly started KDE development some time back with ui improvements to Ark. I eventually got stuck maintaining ark instead, and these small annoyances that I have been thinking about for way too long, had to wait in the back of the queue while Ark was getting fixed from the bruised and bad condition that I found it in.

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.

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.

Ark: service menu, password protection files and more

July 12, 2008

Time for another update on my Ark changes!
Let’s just do it simple, I’ll put some screenshots here and I’ll explain along:

The batch extract/extraction progress

This is probably the feature I’ve been working most on. After modifying the libarchive plugin and doing some calculating of how much is to be extracted, the extraction shows very nicely and accurately how far it has come in the total extraction. It will also extract many files in a row when given from the command line. Now, some users might wonder (some might even complain) on why I’m even making a command line tool with gui feedback at all. Some of the other users again, will understand immediately just why this comes in handy, which brings us to the next point:

The dolphin/konqueror service menu

With the batch extraction in place and ark taking lots of nice parameters, implementing the service menu for dolphin/konqueror is a breeze. I haven’t completed it fully so far, but above is a quick preview of what’s working so far. Next up here will be a small submenu, showing additional entries such as “Extract to…”, “Extract all to subfolders”, etc. (I haven’t really decided which use cases deserve a menu entry here, feel free to discuss this in the comments section).

The (once more) redesigned extract dialog

So after playing with several solutions of how to actually informing the user of the auto-subfolder mechanism, I eventually decided that the best way to make it natural while not doing too much uncontrollable magic in the background is to first check if the archive is a single folder archive, next use this information to enable/disable the checkbox and informing the user why this choice has been made.

Password protected archives

Finally, there is the password protected rar files that was mentioned in the comments by a user in a previous blog entry. At first I was surprised to see that there was simply no support for passwords at all in the new archive framework, but after coding a little bit I was once more again impressed about how solid the ark codebase is, and how easy it was to add this extra property to the display. So far rar and zip files are checked for password protection, and the display reflects this. Next up is querying the user for the actual password, and finally getting that password all the way to the extraction code.

Another thing that surprised me was that libzip, which is what ark uses for zip files, doesn’t support reading/writing password protected archives yet. A way around this now would be to either 1. switch completely to using the command line zip utility, like the way rar is handled now, 2. switch to the cli zip util only for password protected files, or 3. pull out the relevant extraction functionality from the cli zip util, and include this as another zip plugin for ark. What do you think?

Ark’s interface changes: another progress update

June 28, 2008

OK, time for another update. The code that I mentioned in my last post has been properly cleaned up now. I would like to thanks for all the comments I received, it was more than I expected. There was also a lot of feature requests, and I have been working on implementing/testing the most requested ones:

Using the KHistoryCombo instead of a custom listwidget for recent history entries
Ok, I ripped out the listview and am letting the kdirselect dialog do its magic for now. The only problem is though, that for the quick extract all submenu to do it’s thing it needs to read the recently used folders from the dirselectdialog. There is as far as I can see not a properly defined way  to do this, but for now it works fine by just reading the global KConfig entry that contains these directories. A consequence of this though, is that recently used directories are shared between all kde programs and all kinds of directories will appear in the quick extract menu. Is this a downside or upside? I’m not sure, really.

Preserving paths should be better handled
There are many different use cases to when you might to want to preserve paths or not, but I think the most common two ones are 1, you just want to extract it all with paths, and 2, you want to extract two or three files and don’t want them spread all over an almost empty directory structure. Ark does its best to set the dialogs to sensible defaults, but for the special cases a checkbox for preserve paths on/off has been added.

No double subfolders – Ark should be intelligent enough to not create double subfolders when extracting
Now implemented; Ark checks to see if there is just a single folder in the archive, and if so shows the user the detected subfolder name and takes care not to create double subfolders. Ark will also by default extract archives without subfolders into a single subfolder named after the archive.

Ark should be prepared for usage through dolphin/konq service menus
Now being worked on: So far ark accepts an –extract argument that will immediately show the extract all files dialog after opening the file. In most cases however, you don’t want to have to press enter and just want things to go smoothly, and for this reason I have started writing a batch extract interface. This will live next to the usual mainwindow interface, and can be activated by passing the –batch argument. The batch interface will simply extract all archives passed to their respectively subfolders and show the progress while doing it.

Lastly, the only screenshotable change is the slightly redesigned extract dialog. Enjoy!

My git repos for these changes is being pushed regularly to my public github repos here:

Oh, and Aaron, we miss you!