Gwenview is a fast and easy to use image viewer for KDE. For more information, have a look at the overview.


Going past the last image (or not)
Aurélien - 2014.01.22

If you have used Gwenview before KDE SC 4.11 you might be familiar with the following situation: you are running Gwenview in fullscreen mode, pressing Space to go through a folder full of images. At one point, pressing Space does not do anything anymore... What's wrong? A quick move of the mouse to bring up the fullscreen bar reveals that you are on the last image.

A first solution

This would happen to me quite often, so during KDE SC 4.11 development period I decided to do something about it.

I initially wanted to show an on-screen notification to the user when trying to go past the last image, but it turned out to be complicated to do. If you are familiar with Qt development, you know behaviors such as going to the next image are centralized using QAction. You define the QAction once and then plug it in the menubar and toolbar. The QACtion also lets you define a keyboard shortcut. Why is it a problem? Because when you reach the last image, the action to go to the next image (let's call it goToNext) is disabled, which means its shortcut (rightfully) does not trigger anything, making it impossible to be notified of user attempts to go past the last image.

In 4.11 I settled for an alternative: the goToNext action would always be enabled, triggering it while on the last image would go to the first image and show an on-screen notification to let the user know he was now looking at the first image.

Not satisfied

After using this setup for a while, I was not satisfied with it: I realized I never want to go back to the first image, I just want to know I reached the end. Still it was nevertheless better than not getting any feedback at all, so I let it in. A post on Gwenview forum made me think about that again. The behavior change of the previous and next action broke user "bob p" workflow because the next and previous buttons were now always enabled.

So I set out to look at that annoyance again, and finally figured out a (hackish) way to get notified of shortcut presses when an action is disabled. This makes it possible to keep the goToNext action disabled while showing an on-screen notification to let the user know he reached the end of the image list.

Already on the last document

The nitty-gritty details

To implement this I created a class named DisabledActionShortcutMonitor. This class monitors an action changes through an event filter. When the action is disabled, its shortcut is assigned to a QShortcut. When the action is enabled, the QShortcut shortcut is reset. It's not pretty, but it does the work.

disabledactionshortcutmonitor.h looks like this:

class DisabledActionShortcutMonitor : public QObject
     * parent must be a widget because we need to create a QShortcut on it
    DisabledActionShortcutMonitor(QAction* action, QWidget* parent);

    void activated();

    bool eventFilter(QObject* object, QEvent* event);

    QShortcut* mShortcut;

And here is disabledactionshortcutmonitor.cpp:

DisabledActionShortcutMonitor::DisabledActionShortcutMonitor(QAction* action, QWidget* parent)
: QObject(parent)
    mShortcut = new QShortcut(parent);
    connect(mShortcut, SIGNAL(activated()), SIGNAL(activated()));

    delete mShortcut;

bool DisabledActionShortcutMonitor::eventFilter(QObject* object, QEvent* event)
    if (event->type() == QEvent::ActionChanged) {
        QAction* action = static_cast<QAction*>(object);
        if (action->isEnabled()) {
            // Unset the shortcut otherwise we get a dialog complaining about
            // ambiguous shortcuts when the user tries to trigger the action
        } else {
    return false;

You use it like this:

QAction* myAction = /*...*/;
// ...
DisabledActionShortcutMonitor* monitor = new DisabledActionShortcutMonitor(myAction, QApplication::activeWindow());
connect(monitor, SIGNAL(activated()), SLOT(doSomething()));

doSomething() will be called whenever the user uses myAction shortcut while myAction is disabled.

That's it, I hope it helps you if you are in this peculiar situation. Comments on how to improve the current implementation are welcome.

PS: Code for this feature is currently in a review request on Gwenview reviewboard. If you are a KDE developer with a few minutes to spare, why not have a look at it?

Flattr this

What's new in Gwenview 4.12?
Aurélien - 2013.12.12

With KDE Applications 4.12 about to be released, it's time to look at the changes which went in Gwenview during this cycle. Unfortunately, I am afraid the answer is : not much.

I just went through the revision log and despite the usual bug fixes, I could only find two relatively significant changes.

Nicer meta information sidebar

I have never been happy with the way the sidebar displayed meta information about the image. I finally took some time to work on it. Here is a before / after:

Meta information sidebar in 4.11 and 4.12

As you can see, I went for a stacked design with wrapping text. It makes better use of the space, providing more room for the content.

Nicer meta information window

Related to the meta information sidebar, I worked a bit on the window which opens when you click the "More..." link in the meta information sidebar. The properties listed in the window were not sorted, making it difficult to find what one is looking for. They are now sorted alphabetically by property keys, and some useless properties, either unnamed or filled with large binary content, are now hidden.

Meta information dialog in 4.11 and 4.12

Retrospectively, I should have added a search line in there as well. Unfortunately it is too late for 4.12.

What about 4.13?

Not much planned from my side for now, as you guessed I am not very active on Gwenview these days. There is a fancy new feature nevertheless, which I know some of you have been asking for a while: raw file preview support!

Thanks to great work from Martin Kyral, Gwenview can now display previews embedded within raw files. I am not the target audience for this feature, so I'll quote Martin instead:

[Raw support] theoretically enables gwenview to support everything dcraw supports (I haven't found a raw file that gwenview doesn't show with this patch). The patch does not perform full demosaicing nor any tweaks (set white balance or so) and I don't think it shall - digikam, darktable or rawtherapee are much more suited for developing the 'digital negatives'.

That's it for this cycle. Hope you are going to enjoy your (slightly) refreshed Gwenview 4.12!

Flattr this

Little bits of news about Gwenview
Aurélien - 2013.01.31

Some news from Gwenview world:

New mailing-list

One year ago, I decided to replace Gwenview mailing list with a forum. The idea behind that move being that forums were more adapted for user support.

Gwenview forum is doing quite well: there are more users helping each others there than what used to happen on the mailing-list. I assume this is because there are more users on KDE forums.

One thing happened during this cycle, though: a new contributor, Benjamin Löwe, joined and has been very active on Gwenview. Therefore I decided it would be a good idea to create a developer mailing-list: gwenview-devel.

Gwenview 2.10.0 is dead, long live Gwenview 4.10.0!

Until now Gwenview has always been using its own version number, which was the same as KDE SC version number, except the major was 2 instead of 4. For example, the version of Gwenview which came KDE SC 4.9.5 was 2.9.5.

This made sense to me because the version of Gwenview shipped with KDE SC 4.0.0 was the first major rewrite of Gwenview: so I bumped the version number to 2.0.0.

Even if it made sense to me, people were often confused by these two version numbers. Furthermore, Benjamin pointed out that since we used 2.y.z in the "FIXED-IN" Bugzilla field, our fixes did not show up in KDE SC release changelogs. Therefore I decided to bump the version to 4.10.0. No more confusion!

More reviews

Benjamin and I have been busy fixing as much bugs as possible for the 4.10.0 release. I am quite happy that almost all the latest commits have gone through review before landing in the KDE/4.10 branch.

I believe doing more reviews will help improve the quality of Gwenview code and avoid regressions. To this end I decided to start asking for review for my own code as well. Gwenview has been mostly a one-man project until now, so I committed directly to master. Now that the bus factor has been multiplied by 2, it is possible to get all code reviewed before it lands in master.

That's it for now, time to plan 4.11!

(PS: I am going to FOSDEM, see you in Brussels!)

Changes in Gwenview for KDE SC 4.10
Aurélien - 2012.12.04

I have been kept very busy during the last six months with Homerun, spending little time on Gwenview. Luckily Gwenview received several contributions from other developers during this cycle, so Gwenview 2.10 (from KDE SC 4.10) features some significant improvements.

Thumbnail view

Huge kudos to Benjamin Löwe for his work (among other bug fixes) on the thumbnail views!

He introduced custom thumbnail ratios. Until now thumbnails have been drawn in square cells. This often resulted in wasted space between rows. The thumbnails cells now default to a 3:2 ratio, which look much better especially with wide-screen pictures. If this is not clear, checkout the before/after screenshot:


This can be tweaked through an hidden configuration option: ThumbnailView/ThumbnailAspectRatio. If you want to go back to the previous format, set this key to 1.

Benjamin also improved thumbnail generation:

  • Thumbnails for images are now generated before thumbnails for folders,
  • Gwenview now starts generating thumbnails for fully visible thumbnails first, and takes care of partially visible thumbnails later
  • The way Gwenview writes thumbnails on disk is now more efficient

As if it was not enough, he worked on ensuring thumbnail views scroll to show the correct item in various situations, such as when starting Gwenview with an image as an argument and the thumbnail bar is visible.

Activity support

Another significant contribution came from Ivan Čukić, who added activity support to Gwenview: Gwenview now reports opened documents to the activity manager, making it possible to connect documents to activities using the Share-Like-Connect applet.

Color profile support

This feature has been wanted for a long time...

Work started at Akademy: after attending a color profile session in the morning, I got cornered in the afternoon at the cafeteria by Boudewijn Rempt and Kai-Uwe Behrmann... No way to escape any longer!

Boudewijn started the work during this afternoon, and I continued on it afterwards.

Currently Gwenview can:

  • Read embedded color profiles from PNG and JPEG files.
  • Use the image color profile together with the display color profile to output correct colors on the screen.

It currently misses (at least):

  • Support for color profile in thumbnails. This is tricky to get right because thumbnails are shared among applications, which means Gwenview has no way to know if a thumbnail has been generated with correct color profiles.
  • Support for reading color profiles from other image formats, such as TIFF.
  • Color profile support for printing.

Recursive importer

Until now, my main gripe with Gwenview importer was that it did not list everything: one had to navigate through the folder tree of the camera memory card to hunt for images. The experience is even worse when dealing with a smartphone folder tree.

The new importer is a bit different: it is recursive. When you plug a device it lists all images and videos. No need to know if they are stored in "DCIM/FBAR1000" or "DCIM/FBAR1001".

In most case this is what you expect, but not always: plugging a smartphone is a good example of a situation where you do not want to list all medias of the device: The pictures you took with your phone are usually in a sub-folder of a "DCIM" or a "Pictures" folder, but the phone contains many other folders filled with application data which you do not want to list (unless you really want to import that Angry Birds splash screen!)

Gwenview importer does not magically handle this for you, but tries to be reasonably smart: it is possible to select the root folder to list, and it will remember the last root folder for each device. This way, next time you plug your smartphone in, only the relevant pictures and videos should be listed.


The importer showing covers of music albums on my phone (yes, I have odd musical tastes)


After clicking on the "Google File-CD Gadget" button, I can restrict the importer to list the content of the photo folder and its subfolders


Now only my test pictures are listed, and it will show up this way next time I plug the phone

That's it for this version, hope you like it!

What's new in Gwenview 2.9?
Aurélien - 2012.08.08

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

Fullscreen Browse

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!

Flattr this

Akademy 2012
Aurélien - 2012.07.11

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.

2012-07-07_16-43-11 Russian dolls and jewelry 2012-07-08_13-33-19 Invulnerability! 2012-07-08_17-47-24 2012-07-09_12-13-08 2012-07-09_12-26-11

(More pictures available on Flickr)

Qt Image Decoders Stepping on Each Others
Aurélien - 2012.03.30

A weird bug

In December last year, Falk Krönert filled a strange bug: Gwenview failed to load some PNG images, which other applications were able to display flawlessly. I couldn't reproduce it back then with Gwenview 2.7.3, so couldn't dig any further.

Falk did not give up so easily though. After further investigations, he discovered the bug only happened with images whose width would be 2560 or 2808. Since I still couldn't reproduce it, he provided me with a QEmu image of his openSUSE installation so that I could investigate (now that is one dedicated bug reporter!)


Running the QEmu image, I was finally able to reproduce the bug. I started investigating, installing the necessary packages to build Gwenview and my beloved cgdb, learning how to use Zypper in the process.

Step one, an image format from the past...

I quickly discovered Qt was not able to discover the image format of the PNG. The code looked like this:

QBuffer buffer;
buffer.setBuffer(&mData); // mData contains the first 256 bytes of the image

QImageReader reader(&buffer);

mFormat = reader.format();
if (mFormat.isEmpty()) {
    return false;

In the case of this image, "mFormat" was supposed to contain "png", but it was empty instead.

In case you are not familiar with Qt image plugin code, it works like this: Qt provides a base class, QImageIOHandler, which image decoders must inherit from. so there is a QJpegHandler, a QPngHandler and so on. Some of these handlers are provided by Qt directly in QtGui.so, others are provided by Qt and kdelibs (and possibly others) as plugins installed in "plugins/imageformats".

Here is QImageReader::format() code:

QByteArray QImageReader::format() const
    if (d->format.isEmpty()) {
        if (!d->initHandler())
            return QByteArray();
        return d->handler->canRead() ? d->handler->format() : QByteArray();

    return d->format;

Debugger was telling me d->handler was correctly created by initHandler(), but QPngHandler::canRead() was never called!

Quite puzzled by this, I finally resorted to place a breakpoint in QImageIOHandler constructor. Once I hit the breakpoints, I printed the backtrace, and was astonished to find myself inside the PCX handler provided by kdelibs! This explained why QPngHandler::canRead() was not called, QImageReader was calling PCXHandler::canRead(), which unsurprisedly returned false.

This does not explain how Qt decided the image was a PCX in the first place. To decide which handler to use, initHandler() calls all implementations of QImageIOHandler::canRead(), the first one to answer true wins. PCXHandler::canRead() implementation is not very selective: it returns true if the first byte of the image is 10 (According to Wikipedia it should be possible to check at least the first two bytes, need to look into this).

Here is an hex-dump of the first bytes of the PNG image:

89 50 4e 47 0d 0a 1a 0a  00 00 00 0d 49 48 44 52  |.PNG........IHDR|
00 00 0a 00 00 00 00 02  08 02 00 00 00 1b 8e 12  |................|

There are a few 10 (0a in the dump) values but the first byte is definitely not 10.

Maybe the PCX loader is looking at the wrong position? I decided to place a breakpoint in PCXHandler::canRead() and print device->pos(). Sure enough, it sayd the position was 18, instead of the expected 0... If you look at position 18 (starting from 0) in the dump there is indeed a 0a value.

It is interesting to look at what this 0a stands for: The PNG specification tells us a PNG starts with an 8 byte signature, followed by a series of chunks. The first chunk must be an IHDR chunk. This chunk starts with "IHDR", followed by four bytes representing the image width, in most significant byte order. This means the first four bytes in the second line of the dump (00 00 0a 00) are the image width, and indeed, 0a00 is the hexadecimal for 2560... Do you remember the bug was only happening for some image sizes? If the width had been 2559, the IHDR chunk would have started with 00 00 09 ff, and thus the PCX handler would not have identified this image as a PCX.

Another format gets in...

While the PCX handler could be improved to use more than one byte as a signature, it is not the real problem: had device->pos() been correctly set to 0, it wouldn't have identified the image as PCX. QImageIOHandler::canRead() documentation explicitly says:

When reimplementing canRead(), make sure that the I/O device (device()) is left in its original state (e.g., by using peek() rather than read()).

Someone was not playing by the rules and was altering the device position before PCXHandler::canRead() was reached.

I was starting to suspect one of the other image handlers was doing something nasty. To try to isolate the culprit, I first removed all KDE image plugins but the PCX handler. No luck, still buggy. I then removed all Qt image plugins (PNG was still there as it is one of those built into QtGui.so) Bingo! The image was now being correctly identified. Using a quick dichotomy, I found out the TGA plugin was the nasty boy.

QTgaHandler::canRead() looks like this:

bool QTgaHandler::canRead(QIODevice *device)
    if (!device) {
        qWarning("QTgaHandler::canRead() called with no device");
        return false;
    QTgaFile tga(device);
    return tga.isValid();

Looking at the code you can probably guess it: QTgaFile constructor does not take care of not altering QIODevice state. Looking at the Git history for this handler shows it was copied from QtQuick3D to Qt before the 4.8.0 release, which explains why there was no problem when running Gwenview on top of Qt 4.7.

It is a bit sad however that this code was brought in instead of using KDE TGA handler, which has been around for a while, does not suffer from this bug and have (limited) write supports whereas the Qt handler is read-only.

Fixing time

I worked around this bug in Gwenview by taking advantage of the fact that QImageReader accept an optional "format" parameter, which can be used as a hint: QImageReader will first try to use an image handler which supports this format.

I was not using this feature until now because I thought passing a format would make QImageReader fail if the image was not of the specified format. It turns out I was wrong: the format parameter is just a hint, if the image cannot be loaded with a handler implementing this format, QImageReader will try the others. I should probably propose a patch for the documentation to reflect that.

The real fix however is to teach QTgaHandler proper manners. I just posted a fix on qt-project.org, hopefully it will get in.

Gwenview 2.8.2 (from upcoming KDE SC 4.8.2), has the work-around in but if you haven't upgraded yet, you can fix the bug by simply removing the TGA handler plugin. Look for a file named libqtga.so. It should be in:

  • openSUSE (64 bits): /usr/lib64/qt4/plugins/imageformats/
  • Ubuntu|Debian (64 bits): /usr/lib/x86_64-linux-gnu/qt4/plugins/imageformats/

(I don't know the location for 32 bits systems)

So to summarize, a rogue TGA handler was tricking a sloppy PCX handler into identifying a PNG file into a PCX file, what a mess!

Flattr this

What’s new in Gwenview from KDE 4.8
Aurélien - 2012.01.27

Now that KDE 4.8 has been released, it’s time to recap all changes you will find in Gwenview.

The main change is the addition of animations when viewing images: crossfading between images and nicer-to-use comparisons. You can learn more from this previous blog article.

This change was not nice for users of some graphic cards whose OpenGL drivers do not support what Gwenview tries to do. I decided to play it safe for now: animations in Gwenview now use software rendering by default. For better performance, you can enable OpenGL rendering in the configuration dialog.

This new version of Gwenview also comes with a lot of smaller changes, some of them caused by the limitations which were introduced by the new animation system.

Scrolling and Zooming

  • No more scrollbars: A bird-eye view lets you scroll the image.
  • Nicer zoom cursor. I realized Qt now supports truecolor cursors, so I drew a nicer magnifying glass cursor instead of the black+white+1bit-alpha-channel version. Holding down Ctrl to zoom won’t bring you back to the 90s anymore!
  • Pressing ‘F’ toggles zoom-to-fit on and off.
  • More consistent behavior: SVG images can now be scrolled using the same shortcuts as scrolling raster images.

Global User interface changes

  • The “sidebar collapser”, the little arrow on the left of the view which let you hide the sidebar is gone. It has been replaced by a button in the statusbar.
  • Labels for some of the toolbar buttons have been removed, reducing its width. It should now be more usable on small netbook-like screens.


  • The red-eye reduction and crop tools no longer show floating widgets over the image, a thin bar slides from the bottom of the window instead.


  • Compared images follow thumbnail view order: previously when one selected two or more images to compare them, they would not necessarily appear in the same order as in the thumbnail bar.
  • Arrow-key navigation in zoom-to-fit mode. This one has been requested by quite a few people. When an image is in zoom-to-fit mode, you can go to the previous and next image with the arrow keys. When you zoom in, arrow keys are used to scroll the image. This is very similar to the behavior provided by phones or digital cameras.

Video support

  • The on-screen-display is now transparent.
  • One can use the left and right arrow keys to seek
  • A late addition: an undocumented shortcut (P) to toggle playback
  • Note that video support is a bit fishy right now: it seems Phonon does not always play well with its video widget being embedded in a QGraphicsView, known symptoms are wrong colors or wrong aspect ratio. Hopefully this will improve in the next releases.

4.8.1 should bring you its usual series of bug fixes, among them is generating thumbnails for all images of the current folder, not only the currently visible ones. This fix is a bit bigger than usual *.1 fixes, so testers are welcome: the code lives in Gwenview git repository, in the “gen-all-thumbnails” branch.

I hope you enjoy this new Gwenview!

Flattr this


Oups, my burst shots are all shuffled!
Aurélien - 2012.01.05

At the end of December my wife and I were invited with other parents to my daughter last dance lesson of the year.

Of course, I brought my camera with me. I shot a little bit more than 160 pictures from the one hour lesson (if that sounds like a crazy number, then you probably don't have kids...).

Some of them were shot in burst mode, where the camera continuously takes a few pictures per second, increasing the chances the wannabe photographer gets at least one decent picture (and partially explaining the embarrassing large number of shots...)

Importing, aka, the mistake

Back home, I imported the pictures with Gwenview importer and started to comb through them to get rid of the cruft.

Burst mode is fun, but Gwenview importer does not play nice with it: by default it renames imported pictures using the shot date found in the image EXIF information. I like this feature because I find it more expressive to have a picture named "2011-12-17_12-47-47.jpg" than "pict0234.jpg". It has one big drawback though: the precision of time information stored in EXIF is one second. When one shoots in burst mode, more than one picture per second is produced... In such a situation, Gwenview importer inserts a "_n" suffix just before the extension dot, where "n" starts at "1" and is increased until the importer can create a file name which does not exist. It gets even a bit nastier when you realize Gwenview importer does not necessarily import pictures in file order, meaning the "n" values do not necessarily match the order in which the pictures were taken... not good.


I want to address this issue correctly in KDE SC 4.9, but meanwhile here are some workarounds.

If you haven't yet imported your burst-mode pictures, you can either disable image renaming altogether or change the "Rename Format" from "{date}{time}.{ext.lower}" to "{date}{time}_{name.lower}.{ext.lower}". This way imported images will still carry the original image name and will be properly ordered. File names will be a bit ugly, but at least you will be safe.

Configuring Gwenview importer to append the original file name at the end of imported pictures Configuring Gwenview importer to append the original file name at the end of imported pictures

If you have already imported the pictures it gets a bit more tricky. I looked at the EXIF information my camera recorded and noticed pictures have a "Exif.Panasonic.SequenceNumber" tag (yes, that sounds vendor-specific :/). This tag is set to 0 for normal pictures, but starts at 1 and goes up for burst-mode pictures. I thus put together "pict-exif-rename", a quick Python script using pyexiv2 to rename all images, appending a suffix based on the sequence number if it is greater than 0.

I pushed "pict-exif-rename" as a github gist, maybe you will find it useful.

It would be interesting to hear from different camera owners about the presence of the "Exif.Panasonic.SequenceNumber" tag (or an equivalent). You can quickly check its presence by running "exiv2 -Pkv a_picture.jpg | grep SequenceNumber". All pictures taken with my camera (Panasonic DMC-FS16) have this tag, it is set to 0 for non burst-mode pictures.

Flattr this


Announcing Gwenview Forum
Aurélien - 2011.12.14

Gwenview has had a mailing-list for a very long time now, but time changes. Nowadays I believe forums are more appropriate for end-users discussions than mailing-lists for a few reasons:

  • Forum do not require setting up individual passwords for every topic you are interested in.
  • It is easier to join an existing conversation on a forum you just discovered than on a mailing list you have not subscribed yet.
  • It is easier for non-technical users to read and join a forum.

Therefore I asked for a Gwenview forum to be created on forum.kde.org. You can find it forum.kde.org/viewforum.php?f=213 (too bad forums do not get nicer urls :/). Come and ask your questions here!

I plan to phase out the mailing-list. I haven’t yet decided of a day when it will be turned off but it’s probably going to happen in a month or two. After that the only remaining bit of SourceForge infrastructure used for Gwenview will be the (outdated) website, maybe I’ll get around to create a site for Gwenview under kde.org domain…

Flattr this

Older | Newer