I have been a bit quiet lately, but haven’t been slacking 
Among other things, I started working on implementing one of the oldest most-wanted feature of Gwenview: crossfade transitions between images. I have pushed the code to Gwenview git repository. It still lives in topic branches for now though.
I first worked with an evolution of the QWidget-based code. This is quite stable but it is too slow at HD (1920×1080) resolution. You can find this work in the “agateau/xfade” branch.
I thus decided to bite the bullet and start a massive refactor of the code, rebasing it on QGraphicsView with an OpenGL viewport. This is the much-faster-but-currently-full-of-regressions “agateau/xfade-qgv” branch.
This change makes Gwenview much smoother to use when going through images but it also helps quite a bit in comparison mode: images move around when selected and unselected, making it easier to track where they go.
I recorded a short video to demonstrate the current state of the xfade-qgv branch. It demonstrates both going through images and image comparison. In this video Gwenview runs on a HD monitor. Note that I had to record it with a digital camera, desktop recorders did not produce a smooth animation, so the video quality is not exactly optimal.
(Watch on blip.tv)
I hope I can bring the xfade-qgv branch back to feature-parity with master so that it can be merged in before Soft Feature Freeze (October 27th!).
Advertisement
Like this:
One blogger likes this post.
identi.ca
Muehehehe so this was your qgraphicsview branch ! Muehehe :p
Indeed
I did a bit of branch renaming before posting this article because the branch names were not so good.
Just beautiful
One thing I’d like to see in gwenview is a visual makeover. Preferably transparent full screen widgets and oxygen/air styled main window. Do you have any such plans?
No, because I think Gwenview should look like a KDE application, using standard widgets whenever possible. That does not mean it does not use custom widgets where standard widgets do not feel appropriate, but overall I don’t want Gwenview to stick out like WinAMP
Me too
You rocks, gwenview is best image viewer for Unix !!!
And thanks for appmenu-qt too :p
“No, because I think Gwenview should look like a KDE application”
>> yes !!
Not related but I’ve seen on Mac OS (I think, it was some times ago) that when you open an picture from the file manager, you get a view of the picture in a nice frame, without UI and all. Something like a desktop effect with a zoom and the desktop background goes darker.
)
Maybe this can be implemented as a KWin effect based on Gwenview (no idea if this is possible or related to your work, so just read and forget if I’m wrong
That’s simply called “preview” on Mac. There is an implementation of such feature for gnome called “sushi” (https://launchpad.net/gnome-sushi), which needs a customized file manager (nautilus). Sure such feature would be nice on KDE too, but I’m afraid it’s out of the scope of Gwenview.
That looks really great!
Cool, thanks! I have been waiting for a long time to crossfades in gwenview. (or digikam, any chance to do this in a kipi plugin?) Placing several pics next to each other is the other feature I always have been missing!
Uwe
Sorry, this can’t be done as a kipi plugin. As for placing pictures next to each other, you can already do this with Gwenview 2.7, just without animations.
Oh, how i wish Gwenview to have gps tagging feature with a beautyful map UI + some nice features from iphoto. That would make it the best simple app to manage your photos quick. Digikam is a bit chaotic as it comes to the UI
Nice! That looks a lot smoother and more fluid.
The animations sort of remind of me of Dolphin’s new icon view. Have you looked at all at using that for gwenview’s icon view as well?
Not for now… I am limiting myself to this work on the image view for KDE SC 4.8, but the icon view could indeed use some animations, maybe for KDE SC 4.9?
Sorry, I don’t think I was clear. I meant have you considered using the icon view from dolphin2 in gwenview?
Would love to, it is certainly beautiful! I haven’t had a look at the code yet, though, so it is not going to happen in KDE SC 4.8.
It would be wonderful if you implement that. I think it´s call ItemView-NG i´m not sure. Some other areas of KDE SC could benefit of that too.
And thanks for your work, not just this crossfade feature, is awesome.
That’s awesome!
I have a few questions about that:
1. Does this only affect the fullscreen like demonstrated in the video or also the normal view (I doubt they use different code?^^)
2. Does OpenGL now also take over picture magnification/zooming? So you could animate zooming into a picture as well and use for example Lanczos filter to anti-alias the pictures or so.
I hope you can make the zoom steps a bit smoother, it feels like first it is “Fit to screen”, then it is “Original size” and then you zoom it, but it feels to weird because the zoom steps are not regular.
3. You don’t use any code/techniques involving KWin?
Oh and would it be possible to zoom using the mouse wheel, without pressing Ctrl or something?
1. It affects both fullscreen and normal view for now.
2. OpenGL is not used for zooming yet, not sure this will be done in time for 4.8.
3. No KWin code is used here. Why would it be used?
4. Not planned for now, I personally dislike applications which zoom with the wheel, to me the wheel purpose is to scroll documents, not zoom into them.
1. Nice
2. Okay. Concerning that 4.8, wouldn’t it be enough to add your feature to the feature list and then you have time till hard feature freeze which is mid november?
3. Dunno, just thought, Compositing, KWin,
4. If I want to scroll the documents I can choose them from the preview pane, an option would be nice (You can choose between “Move image canvas” and “Scroll between documents”)
2. Yes can do that.
4. Note that I didn’t mean scroll documents as in go from one document to another but rather scrolling a document which is zoomed and does not fit the window.
This opens up all kinds of interesting possibilities… for example, I’d love it if, when you went to the next image, instead of just appearing, the old one slid off the left side of the screen, and the new one slid in from the right. (Heh, this could even be altered depending on whether you were running KDE with a RTL or LTR language). As a previous poster mentioned, usin open GL for zooming would be awesome, too. I remember how amazingly smooth the opengl Kipi view plugin (or whatever it was called) was.
Gret work! Loving how smooth it looks already!
Pingback: Demostración de las nuevas transiciones para Gwenview : KDE Blog
You’re “Aurélien Gâteau” on the blip.tv page (but not its title tag); it must be yet another web charset encoding snafu somewhere in the chain.
I saw that the other day, but assumed this was a problem with my browser. It seems it is not. I am going to remove the accents. Thanks for notifying me.
Hey Aurelien, maybe it’s not the right place here, I would like to note that panning (moving of pictures larger than your screen) of pictures can be very sluggish/laggy due to the (new?) smooth panning build in Gwenview.
I would like to have the option to turn smooth panning off.
Greetz!
Ivo (NL)
PS. I admit that my computer is not that new/fast (Ubuntu 11.10 on a P4-3.0GHz), but on a much older (windows) computer panning is no problem at all.
I plan to add an option to disable animations, but I doubt it will affect panning: there is no “smooth panning” feature, just smooth transitions between images.
Humm, now it looks like impossible to navigate within an image with the mouse scroll, that’s a big regression for me (and a lot of other users !)
Do you intend to fix it that for 4.8 ? I thought it was a beta-bug, now I have the same with RC1, please just not answer with “it’s not a bug, it’s a feature”
There are many ways to scroll the image: dragging it, dragging the rectangle in the bird eye view, using the mouse wheel or using the arrow keys.
Well, dragging, “bird eye” and arrow keys works just fine, but scrolling using a touchpad seems broken for me.
I’m using a multitouch-enabled touchpad, so I scroll using two fingers. It works well for any application except gwenview. But it worked just fine under 4.7.x. Did you made changes in this field ? (On how the scroll event are caught, etc etc)
Thanks
Yes, there have been many changes on the image view. Given the way the view is now implemented I am not surprised multitouch scroll broke. Unfortunately I do not have access to a multitouch device so it’s going to be difficult to fix.