I have been quite quiet on Gwenview front lately, getting a job which does not involve two hours in a train everyday and becoming a father for the second time apparently does not help to find free time to hack (how surprising!)
Still I managed to get some work done on the start page and fixed a few bugs here and there. The main improvement though is the implementation of an importer for Gwenview, based on some previous experiment.
Its aim is to require as little manipulation as possible to get your pictures and video imported from your camera. It integrates with Solid so starting the import is just a matter of plugging in your camera/inserting your memory card, and selecting “Download Photos with Gwenview” from the popup which opens. You are then presented with a thumbnail view like the following, where you can select the documents to import as well as the import destination (destination is remembered across imports and defaults to ~/Pictures or whatever xdg defines):
Clicking “Import Selected” or “Import All” imports the documents to your destination folder. When it is done, the import asks you what to do with the documents on the device.
Once you clicked either “Delete” or “Keep”, you get this final page:
Whenever possible, the importer tries to be smart. For example it automatically goes inside folders as long as they are alone in the hierarchy, so if your pictures are all in /DCIM/FOOBAR/, it will go into this folder directly instead of showing you a single DCIM folder, then a FOOBAR folder. On the other hand, it won’t scan the whole device recursively, which could be quite painful if you just plugged a large external hard drive…
Another example is handling of already imported documents. Gwenview Importer will tell you if it skipped documents which have already been imported or if it renamed documents to avoid overwriting existing ones. For example if I select “Keep” in the “Delete or Keep” dialog and in a next import select the 3 imported documents as well as 2 new documents, I get this message (The wording can probably be improved, please send suggestions…):
Yet another point where the importer tries to be smart is on the name of the imported documents. Nothing is less useful than a series of pictures named PICT0001.JPG, PICT0002.JPG… so by default Gwenview Importer renames your pictures using the shooting date. This can be configured by clicking on the “Settings” button from the thumbnail page, which brings this configuration dialog:
I spent quite some time working on this formating thing. I tried to make it easy to customize the rename format by:
- providing a preview of the output,
- using words instead of single letter variables (ie {date} instead of %d),
- making the list of available variables with their description always visible,
- making the variable names clickable, so that you can easily insert them
It’s not as good as what Mac OS X can do, but I hope it is easy enough nevertheless. If I get the time to work a bit more on this (read: unlikely to happen :/), I think highlighting the variables in the line edit would be nice.
That’s all for now. Tell me what you think of this.
[...] Gwenview Importer « Aurélien’s room a few seconds ago from Choqok [...]
Gwenview is the most polished and well done kde4 app IMO.
I think we’re going to get in the way of our users with a “Download Photos with DigiKam” and a “Download Photos with Gwenview” entry in the device notifier.
At the least we should probably tell them what the difference between the two apps are so they don’t need to know the jargon. I also wonder if people will use both apps in parallel or if it would make sense to have a “this is my default photo app”?
I’m also unsure if showing such an option whenever any mass storage device is plugged in is useful. There are dozens of things one might want to do with plugging in a USB drive, listing them all seems odd. It’s also very odd when I’m prompted to download Photos from a disk that .. well .. has none.
Perhaps just making it react to cameras? (Solid supports this, thankfully via Solid::DeviceInterface::Camera ..)
Having a notion of a default photo app would definitely be useful.
About reacting only to cameras, I would like to have it show up for cameras and sd cards. Can Solid make the distinction between sd cards and an external hard drive or a generic usb stick? (Should ask Kevin)
Yes, it does know. In StorageDrive there is the DriveType enum which has these values: { HardDisk, CdromDrive, Floppy, Tape, CompactFlash, MemoryStick, SmartMedia, SdMmc, Xd }
Thanks for the info, added this to my TODO.
On the one hand, you don’t want to require the user to choose between applications every time they import photos, on the other hand users can easily end up in a low productivity rut if they don’t realise they have set one default but could change that. The ideal situation would be to make the default option strong enough that the user can pick it without thinking, while making the other option(s) visible enough that the user is aware there are other options.
In terms of making the difference clear I think the key term might be “photo album”, since DigiKam is a digital album manager:
“Import to DigiKam photo album” and “import to another folder”
Finally, from the users’ perspective, why would they choose one importer over another and why does KDE need two importers? DigiKam is a more sophisticated tool, perhaps it should always be the default if it is installed.
I would like to add that words like Photos and Videos should be used rather than Documents. After all, we are importing Photos, aren’t we?
Otherwise, it seems simple enough for a newbie.
I am not too satisfied about using “Documents” as well, but I thought it would be tedious to use “Photos or Videos” everywhere. Anyone has a better idea for a more appropriate word?
How about referring to both photos and video as “media”?
I think it’s a pretty well designed user interface. It’s very simple and easy to use but at the same time it’s quite powerful and has a lot of options. It’s a great work and I really hope to see it in KDE 4.4.
I’m really happy to see such a well thought interface design as part of Linux, and not only OS X.
Keep up the great work
Thanks this is great! I will definitely use it.
Please do *not* only show this for cameras, because I read the storage card of my camera using the card reader in my computer.
The number of times people plug in USB drives (solid state or just external drives) that have generic data on dwarfs the number of times camera storage cards are plugged in. Optimizing for the small use case doesn’t make sense, and it makes the interface look very stupid when it asks to import photos from your USB stick or in my case a 500MB drive that doesn’t have photos at all on it.
In the case of an SD card directly slotted in, one can start the important from gwenview or digikam directly.
Someone could also work on Solid’s actions being slightly more intelligent by being able to look at what’s on a device or remembering specific volume labels (so when you manually import into gwenview once, it would record the label of that volume and prompt to do the same thing automatically next time you plug it in; aka “trainging”).
That would be the “right” way of going about it. A mostly-of-the-time-wrong dumb interface isn’t.
I was thinking about associating apps with devices as well.
For example there could be a “Always open this device with this application” checkbox at the bottom of the device importer popup. User could then manage associations via the widget settings. What do you think of this, Aaron?
Not bad at all, even if it’s not as good as what OSX.
Isn’t it possible to use the same widget than Amarok and Kopete use for that kind of stuff ?
I was also thinking, why not making a dialog that would give the possibility to choose some Nepomuk tags for all the imported pictures ?
I had a look at the Amarok widget and I didn’t like it that much. Where does Kopete use such a widget?
About Nepomuk, it was part of the initial plan, but I removed it to keep things simple. I may add it back, need to think about it.
I’m pretty sure Kopete use the same kind of widget to choose the contact list layout.
Maybe it’s not the same but it looks very smiliar… I may be mistaking but anyway, even if it’s different, one of their choice could be the one needed by this import plugin.
In fact now that I’m thinking of it, they may be different… and the Kopete-way-of-doing-thing may be more appropriate (it’s just the same way of doing thing, but with a widget that makes it more eye-candy and clear for the user).
As I’m currently using KDE-Windows I can’t find that widget (Kopete crashes) but If I remember well they’re something like a “Contact List” tab in the configuration of Kopete where we see that widget.
[...] Gwenview Importer « Aurélien’s room a few seconds ago from Choqok [...]
Yes, definitely it should react only to cameras (this is what any other OS out there does right now), and having a default camera app (as Gnome does, for example) it’s another great idea.
Anyway I think Aurelien has done a great job!
Good job! I like the renaming dialog
. Does it always use U.S format for dates ? (note that it’s what I’d prefer even if I’m also French… )
About the “multiple apps to do the same thing” comment from Mr Seigo… well Digikam is an ‘extragear, and I think there should be something in base kde to handle such a common task.
By the way maybe this application could be named ‘Image importer’ or something similar, even if _technically_ it depends on Gwenview. Maybe it would be less confusing for the users ?
The date format cannot be changed right now. It is not the U.S format (which is month, day, year) it is the ISO format (year, month, day). The advantage of this format is that if you sort by filenames, you get image sorted by shooting date as well.
It depends on libgwenview (which is an internal library) but it could run without the gwenview binary. The only thing to change would be not hardcoding the fact that it starts Gwenview at the end. I can do this if there is enough demand for it.
Great work Aurelien! But maybe Aaron’s right – maybe this could be a separate program from Gwenview?
And I think “media” would be a better term than “documents”.
Anyway, I think your interface looks far better than the one on Windows – so great job!
It is a separate program, you can start it yourself with gwenview_importer /path/to/images. For now starting Gwenview is hardcoded, but this could be modified to start any other application.
About “media” vs “document”, that’s not bad, will give it a try.
This is a great news.
My users need to import photo from several camera, but they don’t need a Photo management application like Digikam : just a way to import the photo. This will be great.
+1 concerning Aaron Seigo remark concerning possible confusion for users
Sounds nice, but how will it decide my ~/Photos/folder/subfolder/ structure? Currently I manually copy all of my photos from the camera to my hard drive because I don’t trust other apps to do it ‘correctly’. Unlike cd-rippers which allow you to define the structure:
~/Music/Artist 1989 Album/01 Track.mp3
Photo apps don’t seem to have these options, and so I’ve been doing it myself…
A “default photo app” setting would be nice; since KDE4 i’ve only used GwenView even tho before I liked Digikam. GwenView is just so nice and simple and useful
For now it does not decide on the structure: it defaults to the xdg pictures folders (which is ~/Pictures if I am not mistaken). It remembers the destination folder so next time you import your pictures, chances are high it will already be using the correct folder, or you will just need to change the last part of it.
Gwenview is one of the bes apps in kde. Polished, easy to use. This is a great idea.
About the import dialog asking whether to keep the files. This approach is a bit dangerous. It would be better to have a checkbox, since it is easier to accidently click “yes” than to accidently check a checkbox.
I disagree. A checkbox which you have to check everytime is tedious, and a checkbox whose state is remembered is dangerous. I don’t think the user will click the button by mistake, especially since it’s labeled “Delete” and not “Yes”.
Well, to be honest there is a renaming tool in Digikam, which is quite similar to what is described here. So you could maybe have a look at what they do?
OT: Why couldn’t Gwenview and Digikam share *some* code in future? They seem to be duplicating each other, e.g. icon view with similar overlays, now Import and Rename tool….. I know that Digikam is more of a professional photo-management program, but manpower is limited, you see
DigiKam and Gwenview already share code through kipi plugins. I am not sure sharing the importer makes sense because DigiKam needs to do more work on the imported pictures (indexing them in its database for example)
I agree that importing could be shared more between both apps, even possibly just have one importer.
I think digikam will anyhow index/scan newly detected photos under the trees that are configured for photo collections. And having the default photo app (like e-mail, web-browser…) would be great, as importer could then auto-start the chosen application (gwenview, digikam…).
And BTW: great work on gwenview – I really like your balance between simplicity and powerfullness of the application. Most of the stuff you do, feels just enough for “typical user” (like my father…).
Great to see this work. I’ve been trying to teach my dad to transfer pictures off his camera but have to resign that it’s one area where KDE doesn’t shine yet with regards to simplicity. The import process in Digikam is way too complex for him to grasp and even I find some of its layout and options perplexing.
Your proposal looks ideal and I particularly like the option to change filenames to lower case, since I’m currently having to do that separately via KRename. However, my dad always transfers photos off a memory card plugged into the card reader slots on a USB multifunction device, so I sincerely hope there would be some kind of automatic detection and prompt for him when he plugs it in.
Congrats in general for your work on Gwenview – it was one of the real surprises with KDE4 and as others have mentioned, strikes the perfect balance between simplicity and functionality.
I’d prefer to scan the camera recursively – my girlfriend’s digicam for example created several subfolders. Manually importing each folder would be a PITA.
This could be solved by a checkbox “[X] scan whole device” which then shows only images and videos but not folders. Maybe this even can be preselected if a camera is detected (don’t know if this is possible).
Brilliant I love the idea. The users at my company would be greatly pleased by this functionality.
Only one thing I’ll mention – can you import photos to networked drives? For example, if I have a shortcut to a samba share in the file dialog, will I be able to import these photos from the camera directly into the network share?
There are a couple fixes I need to do in order for the importer to work with remote locations, but I hope it will be there in time for KDE 4.4.
@socceroos: I suppose Aurelien used the KIO infrastructure in KDE, so yes, it should work to any location KDE apps can save files to (ssh, ftp, samba, webdav).
At first with Kubuntu 9.04, I resisted Gwenview, but then learned I could do a lot of stuff with it. Crop was one neat thing.
My computer died, so I went to Kubuntu 9.10 on the new one, Gwenview, Version 2.3.2 Using KDE 4.3.2 (KDE 4.3.2). I have no idea what CROP is supposed to do, but it sure doesn’t crop. It apparently forces me to select one of a standard list of ratios for cropping. It does not give any crop box, and if I click on the position boxes, it mostly opens up full screen.
I had an urgent need a few days ago to crop, and finally did it by dinking with CONVERT from the command line. I am not skilled enough with my eyes to hit the crop without a lot of experimenting.
If Gwenview crop on 9.10 is working like it’s supposed to work, they have killed it.
I did a REMOVE and an INSTALL and no change.
Add on the fact that digikam on Kubuntu 9.10 crashes most of the time and bug report seems to be beyond me, 9.10 is not pleasing me very much. I tried to download and install the tarball for digikam beta6, and it had major compile problems. I may be forced to regress to 9.04.
It is a nasty problem, which does not seem to happen on all computers. I need to fix it, but until it is fixed, you can crop nevertheless: the crop handles are still there, but they are invisible. Move the mouse to the corner of the image, until you notice that the cursor change to a diagonal double arrow. You can now drag the corner.
That’s because Ubuntu added a beta version of digiKam, the crash has been fixed since 3 weeks, but Ubuntu isn’t updating the package. I close 20 reports daily about this crash, all coming from Ubuntu users.
I really hope they will update the package some day, I don’t want to do this bug-closing for the next 6 months.
They should never added digiKam-beta to a stable branch, it would have been better to provide it in an experimental branch…
But digiKam is not the only application added as beta in Ubuntu 9.10… more developers suffer from this stupid decision.
Have you asked the Kubuntu devs to do an SRU (Stable Release Update) for the fix? This should save you some time closing bugs.
No, I will do so now. But I think this package is a little bit ironic, at least for the Karmic release:
https://wiki.ubuntu.com/StableReleaseUpdates#Why
If they expect to have a very stable system and updates will need to be discussed so that the “stable experience” will not be destroyed for the user, why the hell are they adding so many beta-Software?
It is ridiculous I think… well anyway I will try to get the update through.
I meant “page”, not “package”….
I don’t know about the reason behind the choice of packaging this version of digiKam, rest assured the Kubuntu devs care about delivering stable software. No one is perfect though, hence the SRU process.
Do ping me on irc (agateau on freenode) if you need help with this.
Thanks for much for your attention. I am overwhelmed by the fact key people can actually be contacted. Reminds me of the time Kano personally answered a comment that I was unable to use that version of Kanotix which did not have the video driver for my old monitor, and he added it to the next release.
Okay, thanks for explanation. Someone commented something like that, but I did not understand exactly what was meant by it. I will try it next photo I want to crop. My eyeball is not good enough to crop with CONVERT, except in desperation.
I am in rural Mexico, the Third World part. Here, a perfect gift is a photo, they are not offended and do not consider it to be charity, which would be truly offensive.
I communicate by forum with people working in the States who have not been home as long as 18 years, and have had no pictures in that time. I transfer them both ways, and people are totally happy to get them. A grandma did not see her grandchildren, one who had become a parent.
Tomorrow I drive an hour to take wedding pictures, and here it is assumed I will do it free, which is scary for a non-professional with a cheap Canon A470. But, that is how rare photos are here. So, I do need some basic, easy editing, and the older Gwenview definitely had most of what I needed, the rest can be done with CONVERT.
Thanks.
I went to the wedding, and ended up with around 180 pictures. Many of them were table pictures of the feast later, for the bride’s memories, and they only need printed 4X6 for her.
The couple at the altar will need a lot of work, but my daughter back in the States said to pick out a few of the better ones, and she will attempt to make them better for me. So, maybe I won’t need to do the editing myself for once, which will sure up the quality, hee, hee.
When I switched to Linux Gwenview became my irfanview, doing the cropping, resizing and redeyes which covers about 90% of our usage.
The new version is even better and it kept its ease of use and I can make it as loaded with options as I want or as basic as needed for my folks who are now KDE4.3 users.
I have to things which I was wondering were possible.
1. saving in different quality/size
2. Save as.
2. If I have a picture that I like but from which I want to crop out a section (let’s say just a closeup ofthe faces of you and your kids), when it comes to save I am given Save or Save All but not Save As.
If I click Save, i keep the cropped work but write over the original (which I also want).
I can make a copy of the picture before hand and modify one ofthe two but it seems like a Save As option would let you save the new quickly without losing the original.
Another suggestion is about photo dimensions. People very often will crop a picture and go get it printed but they are not in perfect 4×6 size. Maybe a way to be able to see how much more you have to crop at sides or bottom/top so that you dont get a surprise once youre at the print machine.
I know suggestions are a dime a dozen and that helping hands are few and far between but i can do the first and am cluless about the second.
I love Digikam and getting used to GIMP but Gwenview is the program we use the most because it can be as simple as you want (for my retired folks who just want to view slideshows, oh yeah, more options….) or as complex as we need it to alter images.
It makes the Gnu-Linux desktop easy and fun to use.
Keep up the great work.
This is not really the place to request features but I’ll answer nevertheless
> Saving in different quality
This is in my TODO list
> Save as
“Save as” has always been there, in the “File” menu, but its behavior was a bit weird in KDE Crop ratio
It is there as well, you need to check the “Advanced settings” checkbox in the crop tool. This allows you to define a crop ratio (and finetune size and position)
I fired up my old e-machine, and Kubuntu offered to update to 9.10, and I let it. I had 57 borrowed old pictures to scan, I mean as old as 1897, long before the revolution, of my wife’s maternal great-grandfather when he was still a rich patron. (To make it clear, I am in Mexico.)
As you indicated, CROP worked on Gwenview, on this computer.
The problem is, I have started to learn GIMP, so it is much easier now with experience to crop in GIMP. Still, there will be times when Gwenview is going to be much faster if all I need is to crop.
Xsane works pretty good, I think. But, it seems, I am not 100% sure, like my old HP scanner in Win 98 automatically trimmed down the photo, Xsane supplies a file with the entire scanner bed and every photo has to be cropped manually.
Still, progress.
I recently upgraded KDE… and I lost my favorite photo app, Gwenview 1.x. Now I have 2.x… and I’m wondering where the best feature went? Where is my larger picture preview for the currently selected picture while in “Browse” mode?
To be clear – the lower left area: http://gwenview.sourceforge.net/data/screenshots//1.4/full/filter.jpg
Toggling between Browse and View is annoying. It used to be unnecessary. In fact, I pretty much never used view. Either browse, or Full Screen.
Now the closest I can get is “View” with the thumbnail bar. But the thumbnail bar sucks. It doesn’t let you do anything. You have to manually set the number of columns in a preference, rather than having it change automatically when you resize the bar. There is no zoom slider on it.
What I want is the browse file viewer, open at the same time as a view picture area. I like to be able to open folders containing huge numbers of pictures, have the thumbnails be very small, and just click on pictures to see them bigger – aka – when I’m looking for a particular picture.
Also, how about an option to get rid of the tabs for Folders / Information / Operations? I want to see all 3 of them at the same time – vertically spaced. Information and Operations both waste half of my screen with empty space.
You are completely offtopic here, this have anything to do with Gwenview Importer. Here are a few answers anyway:
- You can resize the thumbnails from the thumbnail bar by dragging the splitter between the bar and the image. This might help you to get a setup a bit more similar to what was in Gwenview 1.x.
- About space in the sidebar: I had a plan to allow some configuration here but couldn’t find the time to implement it. It is setup this way for now so that it works well on smaller resolution devices like netbooks.
Hi,
I posted here, cause it appeared that you were actively monitoring it
I thought about filing a bug… but when the tracker shows over 300 open bugs… it seemed likely to be ignored.
Is returning a size adjustable preview area to the browse mode on your TODO list? Or have the KDE API changes just made it too hard to implement now? How about just a preview that can be torn off from the program? I don’t have multiple monitors.. but I have a big enough monitor that that could work.
I just really don’t understand the point of the view mode. If the browse mode had two additional features, it could completely replace the view mode.
1) In the browse mode, put an (optional) large picture view window in-between the 3 tabs of information on the left, and the browse area on the right (Like the view mode looks today if you put the tabs on the left, pic in the middle, and the thumbnail bar on the right) – basically, just replace that feature limited thumbnail view with the proper “browse” file viewer.
2) Make the text that is shown below the pictures in the browse area configurable – like it is in the tab information bar (including, showing no information – which would implement exactly what the thumbnail bar does, only better, because it would dynamically set the number of rows depending on the window separator sliders, and the thumbnail sizes would be zoomable with the zoom slider.
Since I’m just spouting on your blog, and not offering C++ coding skills however… I’ll switch over to an easier question – Should it be possible to get gwenview 1.x to run on KDE 4.x? Or is that just physically impossible, since KDE burned the bridge to most of their previous apps with the change to 4.x?
I took a couple of stabs at building it… but it wasn’t looking promising, and I quit.
Thanks for all your work on the program. I don’t mean to sound unappreciative. It’s just frustrating when the main reason you use a program goes away with an “upgrade” and there appears to be no path back to the one that actually has the features I want.
Oops… now I see my feature request 2 is already implemented… its “hiding” in the view -> thumbnail details menu – would be nice if this was in a right click context menu within the thumbnail viewer, or down with the zoom slider.