I have (too) many side projects. Many won’t ever be formally released. Today I am releasing one of them: KidMP, a kid-friendly media player.
This project started with an unusual need: for a long time, my daughter Clara has been watching movies on my laptop while we were traveling. Depending on who was driving, either my wife or I would start the movie on the laptop for her, then pass her the laptop once the movie has started.
This was not the most practical setup, but it worked reasonably well. A few years ago however, a schedule conflict prevented me from going on vacation with the rest of the family. As my wife would be driving alone, there was no way she could setup the laptop for my daughter. The day before they left, I started a quick hack: a media player which would be usable by someone who can’t read, and is not (yet!) computer-fluent. KidMP was born.
Over time, I worked on and off on this project, improving it after each family trip. Today I think KidMP is in a good-enough state to be released. It has been battle-field tested during several trips, used by the whole family, I believe it works reasonably well.
Quoting the README, here are the features which makes KidMP a kid-friendly player:
- Large, customizable thumbnails
- No need to be able to read
- Fully usable with only 3 keys: left arrow, right arrow and space (or return)
- Automatically resume playing at last position
- Start in fullscreen by default, difficult to quit by accident
It is designed to be used on a laptop in situations where using the touchpad is not easy: laptop is not on a table and kids are not precise enough with a touchpad. That is why it is primarily designed to be used with the keyboard.
Early versions used covers from IMDB, but I realized kids have difficulties recognizing them, so I added a way to grab screenshots from the actual movie and use them as thumbnails. I first thought I would have to do all screenshoting myself, but it turns out kids love this feature: every once in a while, Clara will go through the movie collection and change all the pictures!
Selecting movies is done through a cover-flow like strip:
When a movie is playing, pressing Space pauses playback and brings a toolbar at the bottom of the screen:
I hope your kids enjoy KidMP!
Now that KDE Applications 4.9 has been released, it is about time I blog about what changes you will find in Gwenview 2.9.
New Fullscreen Appearance
Appearance of fullscreen mode has been reworked. It no longer uses custom css-based widgets for the fullscreen toolbar. Gwenview now uses your current widget style, with a dark color scheme. I also added a subtle twist to the regular widgets in the form of some light shadows and highlights.
Another change in this bar is the use of square thumbnails. Gwenview 2.8 used to show classic scaled-down thumbnails, but this resulted in space loss as there were empty areas around each thumbnails. Starting with 2.9, thumbnails are also cropped to fit in a square, making better use of the limited available space.
The fullscreen color scheme is a copy of Obsidian Coast theme (to avoid dependency headaches), but you can use any color scheme you want. Because of lack of time, the option is hidden for now, so you have to use
kwriteconfig to set it.
For example, here is how to use the “Wonton Soup” theme:
kwriteconfig --file gwenviewrc --group FullScreen --key FullScreenColorScheme WontonSoup
The name of installed color schemes can be found in
$KDEDIR/share/apps/color-schemes/, where $KDEDIR is your KDE installation folder (usually
/usr). You can also pass a full path to a custom color scheme if you want.
To reset to Gwenview default color scheme, use:
kwriteconfig --file gwenviewrc --group FullScreen --key FullScreenColorScheme ""
This is probably one of the most important changes ever made in Gwenview. Before 2.9, Gwenview featured three different modes: browse, view, fullscreen. This is no longer the case in Gwenview 2.9: fullscreen is independent. This means you can now go fullscreen in browse mode.
Going fullscreen while browsing gives you a more immersive experience while you go through your pictures. It is quite nice on your regular computer, but makes even more sense when you connect your laptop to the big TV in the living room to show pictures to your guests.
Interestingly, this feature has been a long time coming. I had the idea in mind for at least two years. When I read iPhoto 11 announcement I felt like “Damn, now if I implement this, people will say I am just copying Apple!”. I gave a first try at implementing it for Gwenview 2.8, but got stuck, decided to go for the transitions instead. For 2.9 I was able to resurrect and finish the work I started six months ago.
This change implied a few keyboard shortcut changes. Here are the new shortcuts:
- F11: Toggle fullscreen on and off
- Enter: Toggle between browse and view mode
- Esc: Leave fullscreen (this one will change in 2.10, see bug 302898)
Auto-hiding Bird-Eye View
Gwenview 2.8 got rid of scrollbars on images, and introduced a bird-eye view to pan through the image. The bird-eye view is handy, but it is in the way of the image. In Gwenview 2.9, it now automatically hides itself after a short delay, showing back only while zooming or scrolling.
New Appearance for Dragged Images
When you drag images to a folder you now get a nicer preview: images are spread like a fan, giving a more natural feeling.
Optional Lock-Zoom Feature
This is a late addition, an hidden feature I am not satisfied about yet.
Before 2.8, Gwenview used to keep the zoom and position: if you were viewing image PICT0001.jpg, zoomed to 400% and scrolled to the bottom-right corner, then when you went to PICT0002.jpg, Gwenview would keep the zoom at 400% and try to keep the scroll position to the bottom-right corner.
This changed in 2.8, an unwanted side-effect of a code rewrite to make it possible to implement transitions. Bug 291759 was filed, asking to restore remembering of zoom state and position.
With the help of others I came up with a new implementation of this feature, but after using it for a few days, I realized I personally preferred when Gwenview reseted the zoomon image changes. Thinking more about it and discussing it with others, we realized locking zoom and position makes sense when you are triaging imported images, but does not make sense when you are showing images around. Problem: both use cases are valid use cases of Gwenview :/. Since release deadline was approaching I decided to come up with the following workaround:
The default behavior remains the same as Gwenview 2.8: zoom is not locked by default. A new hidden config option has been added to toggle this behavior. You can enable it with:
kwriteconfig --file gwenviewrc --group ImageView --key ShowLockZoomButton true
When this option is enabled, a padlock button appears to the right of the zoom slider. When the padlock button is checked, zoom and position are locked when browsing images.
As I said, I am not fully satisfied with that: the zoom widget is already quite cluttered, and I don’t like adding more clutter to it. We’ll see if I can come up with something better/smarter for 2.10.
That’s it for this version, hope you will enjoy Gwenview 2.9!
Latest addition to my kids DVD library is the Cars 2 DVD. They usually watch movies using a small PC running XBMC, so I started to rip it. I use either K9Copy or Ogmrip to rip DVDs, both get the job done without problem these days.
Not so lucky
Unfortunately Cars 2 DVD is different: Even if it can play it, VLC lists 99 titles on the DVD, which sounds a bit too much. K9Copy crashes on it. Ogmrip gets stuck when it tries to rip any track.
As I discovered later, Disney DVDs use a new protection system named ArccOS. Searching on the Internet I realized I was not the only one having this problem, but appart from similarly unlucky users, I only found Windows shareware applications claiming to be able to rip those Disney DVDs.
At this point I was desperate enough that I started a Windows XP VM and tried a few of these applications. Two of them failed, but the third one correctly ripped Cars 2… With a large watermark, it’s a shareware after all, there is got to be a catch. As I couldn’t find any other solution, I reluctantly paid 40€ for the full version :(.
Note that I am not extremist to the point of refusing to pay for software, but I have a problem with paying 4 times the price of a legally bought DVD to be able to exercise my right to make a copy of it.
Hope after all
Shortly after paying, I switched to another tab of my browser and noticed a search I made actually uncovered an interesting forum thread. This is where I learnt about ArccOS, but also where I discovered HandBrake, a free software, multi-platform, video transcoder application I have never heard about… I installed it from the Ubuntu PPA, tried it… You guessed it: It can rip Cars 2 DVD without any problem…
So as a conclusion, even if HandBrake documentation claims it is not a DVD ripper, if a DVD does not let itself get ripped, do not capitulate before giving HandBrake a try. You could very well save a few dozen euros in the process…
I was in the beautiful town of Tallinn last week, attending Akademy 2012. It was great to hang out again with other KDE developers around a laptop or a drink.
We had an awesome Karaoké night which started slowly but got a lot more fun when MC Aaron grabbed the microphone and convinced us to sing… Sébastien Renard and I even thought we could sing “Born in the USA”. our interpretation was later described to us as “courageous” :). There are pictures of us in action, hopefully no video of this performance is online…
On a more serious note, I noticed a recurring topic during this Akademy: Bugzilla. Jeroen van Meeuwen delivered a great presentation explaining the way Kolab Systems AG uses Bugzilla and how KDE could benefit by doing the same, we also had further discussions on how to take advantage of milestones, setting appropriate bug statuses, or integrating bugs.kde.org with our wikis. All those discussions got me motivated to improve my Bugzilla skills. In particular I’d like to try using milestones for the next releases of Gwenview… we’ll see how it goes.
My BoF session about going the Extra Mile went well. It felt great to see many contributors willing to give a hand there. I plan to write another blog post to get things started once I am done with a few preliminary tasks.
Another very interesting session for me was the color management one. I think I am finally starting to understand what this is all about. After the session I spent part of the afternoon with Boudewijn Rempt of Krita fame, working on adding color management support to Gwenview. It is not done yet, but I am confident it should be ready for KDE SC 4.10.
Finally, after a busy week, my wife joined me on Saturday and we went for some sightseeing over the week-end.
(More pictures available on Flickr)
Humps for 1 mile by Wendy on Flickr
If you have been reading my blog for a while, you know I tend to get obsessed with fixing little details in KDE applications which annoy me. I like doing this, but this is the kind of task which cannot be done by a lonesome coder if one wants to make a significant difference.
Other free software projects have launched initiatives in the past to get those little details ironed out. You may have heard about Ubuntu Papercuts, Fedora Fit and Finish or Gnome Every Detail Matters initiatives.
I want to start a similar initiative for KDE. To do so, I registered a BoF this year at Akademy, named “the Extra Mile”. The goal of this BoF is not to get started at fixing bugs right away, but rather discuss how we can organize ourself to make this initiative a success. I want to discuss topics such as:
- Which communication tool should we use (Bugzilla, Community Wiki, Forum, Mailing Lists?) and how should we use it
- How to approach those bugs. Should we work on many apps at a time, fixing common bugs? Should we identify and fix as many bugs as possible within one app? Or should we go for a mix of both?
- What is the best way to engage with application developers and raise awareness on these kind of issues
We are going to need people with different profiles to get this to work: developers interested in fixing bugs in their and/or other applications, UI specialists, but also users willing to report and triage those issues.
If you are interested, the BoF is scheduled on Thursday 10:30, room 227. I also created a wiki page for it.
PS: Please do not use the comments on this blog post to report issues you want to get fixed. It’s just not going to scale :) When the BoF is over we will announce how we are going to tackle those issues, at this time your input will be very much appreciated.
It’s been a long time since I last wrote about user interface mistakes in KDE applications. Here is a new addition to this series.
Starting with KDE 4.0, KDE applications ship with toolbars containing both icons and texts.
This setup makes it easier to understand the action associated with a toolbar button. Additionally, buttons with icon and text provide bigger mouse targets.
The price to pay for this is toolbars can become quite wide, to the point where they barely fit on 1024 x something screens (think netbooks or video projectors). To make matters worse, translations often increase text widths: French and German translations for example are known for being quite verbose.
If you maintain a KDE (or Qt) application, here are some simple steps you can follow to reduce the width of your toolbars without compromising too much.
Step #1: Do you really need that button?
This first step is quite obvious: go through your toolbars and check if some of the buttons present in the default configuration can be removed. If they are seldom used, maybe it is OK if their action is only reachable from the menubar?
You probably made such decisions while the application was created. Nevertheless it’s a good idea to revisit those decisions from time to time, based on your increased knowledge of the way your application is used.
Step #2: Icon-only buttons
Hide the text of some buttons. Since Qt 4.6, QAction has a “priority” property which defaults to QAction::NormalPriority. Set it to QAction::LowPriority to get an icon-only button in your toolbar. Peter Penz did it for Dolphin, I did the same for Gwenview. It obviously saves quite some horizontal space.
I couldn’t come with strong rules to decide whether a button should show text or not. You have to use your gut feeling here. Nevertheless here are some hints to give you an idea of situations where it may make sense to use icon-only buttons.
- The icon is common enough that it does not need text to be understood. Media icons (play, pause, next, previous), print, zoom or trash buttons come to mind. There are probably others.
- The button is part of a button group and works as a radio button, for example the view modes in Dolphin (icon, compact and detailed), the format or alignment buttons in a word processor.
- The action for this button is about manipulating the UI rather than an essential part of the task the user wants to accomplish. For example an action to toggle a sidebar.
- The action is part of a group of two opposed actions. In this case one of the two actions can often come without text, its meaning being defined by the other action. For example: Undo / Redo, Back / Forward.
Remember those are just hints: they may not make sense for your application. Additionally, make sure not to overdo it to the point of having only icon-only buttons!
Step #3: Shorten those texts!
For the remaining buttons which kept their texts, try to shorten the text to one or two words only, put a longer text in the tooltip. This serves two purposes:
- It reduces the button width
- It brings back value to the tooltip: don’t you hate it when you move the mouse hover a button and the tooltip which appears stupidly repeats the button text?
When defining the action text, make use of KUIT: mark the text using “@action:intoolbar”, This should give a hint to the translator that this string should be kept short.
When defining the action tooltip, remember the HIG says tooltips should be written using sentence capitalization, not title capitalization. QAction is not being very helpful there: when no tooltip is set, it falls back to using the “text” property as a tooltip, and the “text” property uses title capitalization :/. That is one more good reason to define tooltips yourself.
String freeze for KDE SC 4.9 starts on May 19th, so if your application is in KDE SC, you still have a few days left to check if your application toolbar could be improved!
During this Ubuntu cycle I have been working on-and-off on LightDM, mainly helping out David Edmundson on liblightdm-qt (the Qt wrapper for LightDM library), and the LightDM KDE greeter. The initial, quite ambitious, plan was to try to ship Kubuntu 12.04 with it by default. We quickly realized that would not happen, but we wanted to at least ensure LightDM KDE would be in a usable-enough state to be included in Ubuntu 12.04 archive.
So here it is, release 0.1.0 of this new greeter, featuring:
- 3 QML-based themes
- Guest support
- A System Settings module
- A few bugs (maybe) and design quirks (definitely!)
You can get the tarball from KDE download server or clone the GIT repository. (Note that you need LightDM itself for the KDE greeter to work. The LightDM daemon and Qt libraries can be downloaded from the LightDM project page). Kubuntu 12.04 users can get it with “apt-get install lightdm-kde-greeter”.
It still has some rough edges (it’s a 0.1.0 release after all!), but I have been using it for a few months now without trouble.
Enough talk already, here comes some screenshots:
“User Bar” theme:
“User List” theme:
System Settings module:
We hope you like it!
Update: 0.1.1 is out, fixing an issue with user pictures not appearing in “User Bar” and “User List” themes. You can get it from download.kde.org.