Is gwenview_importer removed in KDE in 42.2?

[hcvv]

Using KDE.

When connecting camera (mass storage device) to the system in 13.1 the pop-up menu offered, amongst other options, "Down load Images with gwenview.

In 42.2 this option is not offered.

In 13.1 the functionality was provided by the program /usr/bin/gwenview_importer, which was installed with the package gwenview. In 42.2 this executable is no longer part of the package.

Does anybody know why this is missing and if there is any chance to get it back?

Or do I better ask this on the KDE forums?

[Ebkr]

@hcvv

Using KDE. When connecting camera (mass storage device) to the system in 13.1 the pop-up menu offered, amongst other options, "Down load Images with gwenview. In 42.2 this option is not offered. In 13.1 the functionality was provided by the program /usr/bin/gwenview_importer, which was installed with the package gwenview. In 42.2 this executable is no longer part of the package. Does anybody know why this is missing and if there is any chance to get it back? Or do I better ask this on the KDE forums?

Hello, Henk, I encountered the same problem yesterday. Import from my camera was not possible under Leap 42.2. My last successful imoport of pictures was in Nov. 2016 under Leap 42.1. I didn’t fiind a bugreport for this matter in KDE bug reports --KDE Bugtracking System- Components for Gwenwview. Time allowing I will write one. Ebkr

[wolfi323]

@Ebkr

Time allowing I will write one.

No point in doing that.

Yes, the importer was missing in the KF5 port, but it has been added back already meanwhile:
http://agateau.com/2016/gwenview-importer-is-back/

It is there in gwenview 17.04.0, which will be included in Leap 42.3.
(and we added the fix for the mentioned brokenness already too, no need to wait for 17.04.2 with the openSUSE packages… )

You can get it for 42.2 too by adding the KDE:Applications repo.
But note that this requires the latest KF5/Plasma5 and Qt5 packages from KDE:Qt5 and KDE:Frameworks5 too.

OTOH, AFAIK the importer basically just copies the files from some source to some destination. You should be able to do the same with dolphin…

[Ebkr]

@wolfi323

No point in doing that. Yes, the importer was missing in the KF5 port, but it has been added back already meanwhile: http://agateau.com/2016/gwenview-importer-is-back/ It is there in gwenview 17.04.0, which will be included in Leap 42.3. (and we added the fix for the mentioned brokenness already too, no need to wait for 17.04.2 with the openSUSE packages… ) You can get it for 42.2 too by adding the KDE:Applications repo. But note that this requires the latest KF5/Plasma5 and Qt5 packages from KDE:Qt5 and KDE:Frameworks5 too. OTOH, AFAIK the importer basically just copies the files from some source to some destination. You should be able to do the same with dolphin…

Hello, Thanks for the advice to do it with dolphin, i I didn’t know that way. Quite simple. Ebkr

[hcvv]

@wolfi323

OTOH, AFAIK the importer basically just copies the files from some source to some destination. You should be able to do the same with dolphin…

Not really. Gwenview has the feature to create file names of the copied files according to patterns like

Vacation-%Y-%d-%m-%h:%m:%s.jpeg

Thus getting rid if the nothing saying file names generated by cameras.
Digicam (the other one offered in the popup) can’t. Dolhpin can’t either.

There are solutions to that (using the CLI tool jhead), but it is always frustrating when users are loosing features they “always used”. And it is when just one of the first simple steps in starting work on your vacation photos simply vanished >:).

One of those things that let end-users despair about computers in general (and Linux in this case). It should simply be there and “work”.

[hcvv]

So, have to wait for Leap 42.3 before it is officially back :(.

I will report that in the Dutch part of the forums where a user started this.

[Fraser_Bell]

@hcvv

Not really. Gwenview has the feature to create file names of the copied files according to patterns like

Vacation-%Y-%d-%m-%h:%m:%s.jpeg

Thus getting rid if the nothing saying file names generated by cameras.
Digicam (the other one offered in the popup) can’t. Dolhpin can’t either.

There are solutions to that (using the CLI tool jhead), but it is always frustrating when users are loosing features they “always used”. And it is when just one of the first simple steps in starting work on your vacation photos simply vanished >:).

One of those things that let end-users despair about computers in general (and Linux in this case). It should simply be there and “work”.

(Perhaps should say KDE in this case? … again?)

If using KDE Plasma, in dolphin you can also use right click – actions – Rename with KRename after transferring.

That is how I do it, using DigiKam to download the files, then from Dolphin using KRename.

Of course, make sure KRename is installed.

[Fraser_Bell]

Oh, yes …

Note that using DigiKam to download the files takes longer than using Dolphin to copy the files across, but it is safer. DigiKam takes the extra step of running checksums, as does Unison.

[hcvv]

There are more things that Gwenview did (and I hope will do). It finds all the images even if the camera has a directory structure to store them (I have one camera that creates a new directory for each day). With Dolphin you have to visit all those, in Gwenview all is shown as thumbnails.

But the main problem is of course that people, once having found out which tool works best fulfilling their needs, are confronted with this and then have to find several bits and pieces to do what they did so many years.

Maybe confronting people with unexpected hurdles is something that fits in e.g. an army training course, but I am not sure it is something that creates trust in the continuity of the features offered by the computer platform you depend on.

[Fraser_Bell]

@hcvv

There are more things that Gwenview did (and I hope will do). It finds all the images even if the camera has a directory structure to store them (I have one camera that creates a new directory for each day). With Dolphin you have to visit all those, in Gwenview all is shown as thumbnails.

But the main problem is of course that people, once having found out which tool works best fulfilling their needs, are confronted with this and then have to find several bits and pieces to do what they did so many years.

Maybe confronting people with unexpected hurdles is something that fits in e.g. an army training course, but I am not sure it is something that creates trust in the continuity of the features offered by the computer platform you depend on.

Yes, and there has been way too many examples of this lately! May I add to that, moving the buttons around and changing the shortcut keys within apps, for no other apparent reason than to “change” things for the newest version (of KDE, as that seems to be where most of these headaches are lately, but of course not limited to that environment).

I have wasted a lot of time since moving to 42.2 just undoing mistakes caused by hitting the wrong button or using the wrong shortcut, simply because they have been changed from what they have been for the past seems like a decade! All major traps to high velocity production touch-typists, and a super irritant.>:)