[kwin] [Bug 482142] drag in drop files in Google Chrome renders Chrome unusable

[Michal Sylwester]

https://bugs.kde.org/show_bug.cgi?id=482142

Michal Sylwester  changed:

   What|Removed |Added

 CC||msylwes...@gmail.com

-- 
You are receiving this mail because:
You are watching all bug changes.

[plasma-nm] [Bug 350521] [RFE] [OpenVPN] kdeplasma-applets-plasma-nm does not support OTP Tokens for OpenVPN connections

[Michal Sylwester]

https://bugs.kde.org/show_bug.cgi?id=350521

Michal Sylwester  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|REPORTED|CONFIRMED

--- Comment #12 from Michal Sylwester  ---
*** This bug has been confirmed by popular vote. ***

-- 
You are receiving this mail because:
You are watching all bug changes.

[digikam] [Bug 334799] Import button on toolbar not activated after plugging in USB stick/memory card with photos

[Michal Sylwester]

https://bugs.kde.org/show_bug.cgi?id=334799

Michal Sylwester <msylwes...@gmail.com> changed:

   What|Removed |Added

 Status|RESOLVED|VERIFIED

--- Comment #7 from Michal Sylwester <msylwes...@gmail.com> ---
Works perfect now - thanks!

-- 
You are receiving this mail because:
You are watching all bug changes.

[digikam] [Bug 334799] Import button on toolbar not activated after plugging in USB stick/memory card with photos

[Michal Sylwester]

https://bugs.kde.org/show_bug.cgi?id=334799

--- Comment #5 from Michal Sylwester <msylwes...@gmail.com> ---
Yes, just tried with current sources.

-- 
You are receiving this mail because:
You are watching all bug changes.

[digikam] [Bug 361882] New: "Download new" tries to only download selected images

[Michal Sylwester via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=361882

Bug ID: 361882
   Summary: "Download new" tries to only download selected images
   Product: digikam
   Version: 5.0.0
  Platform: Compiled Sources
OS: Linux
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: Import
  Assignee: digikam-de...@kde.org
  Reporter: msylwes...@gmail.com

Trying to use "Download New" to download new images from SD card makes Digikam
try to import selected images instead

Reproducible: Always

Steps to Reproduce:
In both cases ensure there are images marked as not downloaded yet on SD card
Scenario A:
1. Unselect all images

Scenario B:
1. Select previously downloaded image

Common:  
2. Select Download New
3. Complete other download steps

Actual Results:  
Scenario A:
Nothing happens

Scenario B:
I get dialog from Digikam telling me that I'm trying to overwrite existing
image (one of the selected ones)

Expected Results:  
In both scenarios: selection is ignored, new images are downloaded

I believe it worked fine around beta 3 (except for marking the downloaded
images, but that was addressed in 359386)

-- 
You are receiving this mail because:
You are watching all bug changes.

[digikam] [Bug 360462] Can't drag image from list to map in Google Maps mode

[Michal Sylwester via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=360462

--- Comment #4 from Michal Sylwester <msylwes...@gmail.com> ---
Interesting, I forgot to mention this, but it works fine on 4.14 from Ubuntu. I
will try to check whether they patched it somehow...

-- 
You are receiving this mail because:
You are watching all bug changes.

[digikam] [Bug 360462] Can't drag image from list to map in Google Maps mode

[Michal Sylwester via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=360462

--- Comment #2 from Michal Sylwester <msylwes...@gmail.com> ---
Created attachment 97862
  --> https://bugs.kde.org/attachment.cgi?id=97862=edit
Screenshot of the geolocation editor with action marked

Red arrow indicates drag start end drop points. After drop nothing happens.
Unfortunately I didn't manage to include the mouse pointer...
Note Google Maps in map area. With OpenStreetMap the action is successful.

-- 
You are receiving this mail because:
You are watching all bug changes.

[digikam] [Bug 360462] New: Can't drag image from list to map in Google Maps mode

[Michal Sylwester via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=360462

Bug ID: 360462
   Summary: Can't drag image from list to map in Google Maps mode
   Product: digikam
   Version: 5.0.0
  Platform: Compiled Sources
OS: Linux
Status: UNCONFIRMED
  Severity: minor
  Priority: NOR
 Component: Geolocation-Editor
  Assignee: digikam-de...@kde.org
  Reporter: msylwes...@gmail.com

When trying to drag an image from list to the map while in Google Maps mode the
mouse cursor indicates it is not possible (and it actually isn't). In
OpenStreetMap mode it works as expected.

Also (I can open a separate wishlist/bug items for these, just le me know):
- would be nice to be able to drag images directly on the map (I thought it
used to be possible?)
- add a minimum height to the images list (somehow I managed to open the window
with the list invisible, took me a while to find it)
- geolocation editor does not remember it's size for me (related to 357738?)

Reproducible: Always

Steps to Reproduce:
1. Open geolocation editor
2. Ensure google maps mode is being used
3. Try to drag image from the list to the map

Actual Results:  
"Can't do this" mouse cursor, when mouse button is released nothing happens 

Expected Results:  
Image is geotagged at the "drop" coordinates

Workaround: Use OpenStreetMap map instead

-- 
You are receiving this mail because:
You are watching all bug changes.

[digikam] [Bug 360434] Geolocation Editor messed up size and contents

[Michal Sylwester via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=360434

--- Comment #8 from Michal Sylwester <msylwes...@gmail.com> ---
Took me longer to compile it than it took you to fix it! Looks like everything
I mentioned is fine now, thanks!

-- 
You are receiving this mail because:
You are watching all bug changes.

[kde] [Bug 360436] New: Crash after running gps correlation

[Michal Sylwester via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=360436

Bug ID: 360436
   Summary: Crash after running gps correlation
   Product: kde
   Version: unspecified
  Platform: unspecified
OS: Linux
Status: UNCONFIRMED
  Keywords: drkonqi
  Severity: crash
  Priority: NOR
 Component: general
  Assignee: unassigned-b...@kde.org
  Reporter: msylwes...@gmail.com

Application: digikam5 (5.0.0-beta3)

Qt Version: 5.4.2
Operating System: Linux 4.2.0-29-generic x86_64
Distribution: Ubuntu 15.10

-- Information about the crash:
- What I was doing when the application crashed:
In the Geolocation Editor run the correlation with gpx file. Crashed after all
images were tagged.
Some images were actually groups of 2, in these cases only the first image was
tagged.

-- Backtrace:
Application: digiKam (digikam5), signal: Segmentation fault
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[Current thread is 1 (Thread 0x7fda5eaf9b80 (LWP 1408))]

Thread 20 (Thread 0x7fda5e6f6700 (LWP 1410)):
#0  0x7fda8a87f88d in poll () at ../sysdeps/unix/syscall-template.S:81
#1  0x7fda68ca012c in ?? () from /lib/x86_64-linux-gnu/libusb-1.0.so.0
#2  0x7fda86b8d6aa in start_thread (arg=0x7fda5e6f6700) at
pthread_create.c:333
#3  0x7fda8a88ae9d in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:109

Thread 19 (Thread 0x7fda5b6ca700 (LWP 1412)):
#0  pthread_cond_wait@@GLIBC_2.3.2 () at
../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
#1  0x7fda8b18a55b in QWaitCondition::wait(QMutex*, unsigned long) () from
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#2  0x7fda8d771d82 in Digikam::ScanController::run (this=0x7fda8e0354e0
<_ZZN7Digikam12_GLOBAL__N_113Q_QGS_creator13innerFunctionEvE6holder>) at
/build/digikam5-YeukDu/digikam5-5.0.0~beta3/core/libs/database/utils/scancontroller.cpp:696
#3  0x7fda8b1892be in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#4  0x7fda86b8d6aa in start_thread (arg=0x7fda5b6ca700) at
pthread_create.c:333
#5  0x7fda8a88ae9d in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:109

Thread 18 (Thread 0x7fda5aec9700 (LWP 1415)):
#0  pthread_cond_wait@@GLIBC_2.3.2 () at
../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
#1  0x7fda4b9564da in ?? () from /usr/lib/x86_64-linux-gnu/dri/r600_dri.so
#2  0x7fda4b955c17 in ?? () from /usr/lib/x86_64-linux-gnu/dri/r600_dri.so
#3  0x7fda86b8d6aa in start_thread (arg=0x7fda5aec9700) at
pthread_create.c:333
#4  0x7fda8a88ae9d in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:109

Thread 17 (Thread 0x7fda47e22700 (LWP 1456)):
#0  pthread_cond_wait@@GLIBC_2.3.2 () at
../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
#1  0x7fda8b18a55b in QWaitCondition::wait(QMutex*, unsigned long) () from
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#2  0x7fda8cc067b3 in Digikam::ParkingThread::run (this=0x1b97e00) at
/build/digikam5-YeukDu/digikam5-5.0.0~beta3/core/libs/threads/threadmanager.cpp:115
#3  0x7fda8b1892be in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#4  0x7fda86b8d6aa in start_thread (arg=0x7fda47e22700) at
pthread_create.c:333
#5  0x7fda8a88ae9d in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:109

Thread 16 (Thread 0x7fda47621700 (LWP 1457)):
#0  pthread_cond_wait@@GLIBC_2.3.2 () at
../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
#1  0x7fda80b5648b in ?? () from
/usr/lib/x86_64-linux-gnu/libQt5WebKit.so.5
#2  0x7fda80b564c9 in ?? () from
/usr/lib/x86_64-linux-gnu/libQt5WebKit.so.5
#3  0x7fda86b8d6aa in start_thread (arg=0x7fda47621700) at
pthread_create.c:333
#4  0x7fda8a88ae9d in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:109

Thread 15 (Thread 0x7fd9ceffd700 (LWP 1493)):
#0  0x7fda82726869 in g_mutex_lock () from
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#1  0x7fda826e1c2c in g_main_context_check () from
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x7fda826e2190 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x7fda826e22fc in g_main_context_iteration () from
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#4  0x7fda8b3c029b in
QEventDispatcherGlib::processEvents(QFlags) ()
from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#5  0x7fda8b36675a in
QEventLoop::exec(QFlags) () from
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#6  0x7fda8b1843d4 in QThread::exec() () from
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#7  0x7fda8b1892be in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#8  0x7fda86b8d6aa in start_thread (arg=0x7fd9ceffd700) at
pthread_create.c:333
#9  0x7fda8a88ae9d in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:109

Thread 14 (Thread 0x7fd9ce7fc700 (LWP 1494)):
#0  pthread_cond_wait@@GLIBC_2.3.2 () at
../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
#1  0x7fda808645b4 in ?? () from
/usr/lib/x86_64-linux-gnu/libQt5WebKit.so.5

[digikam] [Bug 360434] Geolocation Editor messed up size and contents

[Michal Sylwester via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=360434

--- Comment #3 from Michal Sylwester <msylwes...@gmail.com> ---
Created attachment 97854
  --> https://bugs.kde.org/attachment.cgi?id=97854=edit
Confusing icon

-- 
You are receiving this mail because:
You are watching all bug changes.

[digikam] [Bug 360434] Geolocation Editor messed up size and contents

[Michal Sylwester via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=360434

--- Comment #2 from Michal Sylwester <msylwes...@gmail.com> ---
Created attachment 97853
  --> https://bugs.kde.org/attachment.cgi?id=97853=edit
Super high progress bar with doubled percentage value

-- 
You are receiving this mail because:
You are watching all bug changes.

[digikam] [Bug 360434] Geolocation Editor messed up size and contents

[Michal Sylwester via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=360434

--- Comment #1 from Michal Sylwester <msylwes...@gmail.com> ---
Created attachment 97852
  --> https://bugs.kde.org/attachment.cgi?id=97852=edit
Too small initial size

-- 
You are receiving this mail because:
You are watching all bug changes.

[digikam] [Bug 360434] New: Geolocation Editor messed up size and contents

[Michal Sylwester via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=360434

Bug ID: 360434
   Summary: Geolocation Editor messed up size and contents
   Product: digikam
   Version: 5.0.0
  Platform: Ubuntu Packages
OS: Linux
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: Geolocation-Editor
  Assignee: digikam-de...@kde.org
  Reporter: msylwes...@gmail.com

After opening the Geolocation Editor it opens way too small and does not seem
to remember it's size (this seems related to 357738). Additionally, the list of
images being edited is gone. 

Reproducible: Always

Steps to Reproduce:
1. Select few images
2. Open Geolocation Editor:
 - window way too small, no list of images
 - correlation progress bar at the bottom extra high, percentage doubled 
 - there is a trash icon with a description "Display bookmarked positions on
the map." which is confusing...

Actual Results:  
Opens very small, no list of images

Expected Results:  
Reasonable initial size, list of images, progress bar reasonable size

See screenshots

-- 
You are receiving this mail because:
You are watching all bug changes.

[digikam] [Bug 359516] New: Trash not sortable by deletion time

[Michal Sylwester via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=359516

Bug ID: 359516
   Summary: Trash not sortable by deletion time
   Product: digikam
   Version: 5.0.0
  Platform: Ubuntu Packages
OS: Linux
Status: UNCONFIRMED
  Severity: minor
  Priority: NOR
 Component: Albums View
  Assignee: digikam-de...@kde.org
  Reporter: msylwes...@gmail.com

Items in trash seem to be always sorted by name. Would be nice to have it
sortable by date as well. It would be easier to find recently removed items.

Reproducible: Always

Steps to Reproduce:
1. Go to trash, check how images are sorted

Actual Results:  
Sorted always by name

Expected Results:  
Possible to change between sort by name/sort by deletion time

It would be nice to have the sorting changeable by clicking the table headers.

Also, perhaps it would make sense to disable the View->Sort order while in
trash? It does not really work here, and changing order in the real albums
while they are not visible may be confusing.

-- 
You are receiving this mail because:
You are watching all bug changes.

[digikam] [Bug 359431] When importing images if they are available in pairs with same name/different format consider pairing them as 2 versions of same image

[Michal Sylwester via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=359431

--- Comment #2 from Michal Sylwester <msylwes...@gmail.com> ---
Nice. I've never used grouping before, I'll see how it works for me.

Michal

-- 
You are receiving this mail because:
You are watching all bug changes.

[digikam] [Bug 359431] New: When importing images if they are available in pairs with same name/different format consider pairing them as 2 versions of same image

[Michal Sylwester via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=359431

Bug ID: 359431
   Summary: When importing images if they are available in pairs
with same name/different format consider pairing them
as 2 versions of same image
   Product: digikam
   Version: 5.0.0
  Platform: Other
OS: Linux
Status: UNCONFIRMED
  Severity: wishlist
  Priority: NOR
 Component: Versioning
  Assignee: digikam-de...@kde.org
  Reporter: msylwes...@gmail.com

Most of the time I'm happy with my camera's JPEGs, however occasionally I like
to fall back to RAW for some fine tuning. To facilitate this I tend to shoot
photos in camera's RAW + JPEG mode, resulting in 2 files per show. The downside
is I have to manually work my way through to duplicates.

Reproducible: Always

Steps to Reproduce:
1. Set camera to RAW + JPEG mode to record 2 copies of each shot (one in RAW,
one in JPEG)
2. Import into Digikam


Actual Results:  
All images are duplicated

Expected Results:  
Best case for me would be to have Digikam show just one image in album, with 2
versions: the RAW image as original one, and the JPEG as current version after
camera's processing.

This may be very specific to my workflow, I'm not sure how useful it would be
for other users.

-- 
You are receiving this mail because:
You are watching all bug changes.

[digikam] [Bug 359429] Image history: original image's entry contains markup

[Michal Sylwester via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=359429

--- Comment #1 from Michal Sylwester <msylwes...@gmail.com> ---
Created attachment 97227
  --> https://bugs.kde.org/attachment.cgi?id=97227=edit
Screenshot of the relevant part of the sidebar

-- 
You are receiving this mail because:
You are watching all bug changes.

[digikam] [Bug 359429] New: Image history: original image's entry contains markup

[Michal Sylwester via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=359429

Bug ID: 359429
   Summary: Image history: original image's entry contains markup
   Product: digikam
   Version: 5.0.0
  Platform: Other
OS: Linux
Status: UNCONFIRMED
  Severity: minor
  Priority: NOR
 Component: Versioning
  Assignee: digikam-de...@kde.org
  Reporter: msylwes...@gmail.com

In image history sidebar the entry for original image contains some markup: is
wrapped in ... with an additional  in the middle

Reproducible: Always

Steps to Reproduce:
1. Open versions sidebar for image with some history


Actual Results:  
Extra markup visible

Expected Results:  
No markup

-- 
You are receiving this mail because:
You are watching all bug changes.

[digikam] [Bug 359087] Preview image scroll position should be smarter when changing between images with different resolutions

[Michal Sylwester via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=359087

--- Comment #1 from Michal Sylwester <msylwes...@gmail.com> ---
Recalled one more scenario where current implementation is inconvenient. I
usually shoot photos in JPEG + RAW mode (so each shot results in 2 files).
Beside the nuisance of having each photo fine it works fine, except when the
zoom level is changed from 100%. As the RAWs are presented via the embedded
JPEG, which has smaller resolution than the full one (in separate file), this
also results in the annoying jumping of the zoomed in region.

-- 
You are receiving this mail because:
You are watching all bug changes.

[digikam] [Bug 359386] New: Import from SD forgets downloaded images, but remembers marked as downloaded

[Michal Sylwester via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=359386

Bug ID: 359386
   Summary: Import from SD forgets downloaded images, but
remembers marked as downloaded
   Product: digikam
   Version: 5.0.0
  Platform: Ubuntu Packages
OS: Linux
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: Import
  Assignee: digikam-de...@kde.org
  Reporter: msylwes...@gmail.com

When importing images from SD card the imported images are marked as
downloaded, but after re-inserting same card later they are again marked as
new.
Interestingly, images marked as downloaded manually are marked so permanently,
even after re-inserting the card.

Reproducible: Always

Steps to Reproduce:
1. Insert an SD card with new images
2. Open the import tool
3. Download new images - images are marked as downloaded
4. Close and re-open the import tool
5. Images still marked as downloaded - as expected
6. Close the import tool
7. Pull out the SD card
8. Insert the SD card back
9. Open the import tool

Actual Results:  
Up to step 8 everything is as expected. 
At step 9 the previously downloaded images are marked as new again

Expected Results:  
In step 9 previously downloaded images are marked as downloaded

If instead of downloading I just mark the images as downloaded (using Item ->
Mark as downloaded) they are marked as downloaded permanently.

Just in case this is relevant, my workflow looks right now like this:
1. Open the import dialog
2. Import new images (by manually selecting the really new ones)
3. Mark the images imported during previous import as downloaded (older ones
are already marked as downloaded)

My non-default import setting:
- Date-based sub-albums with custom format
- Auto-rotate

-- 
You are receiving this mail because:
You are watching all bug changes.

[digikam] [Bug 359098] New: Edited images are sorted before originals

[Michal Sylwester via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=359098

Bug ID: 359098
   Summary: Edited images are sorted before originals
   Product: digikam
   Version: 5.0.0
  Platform: Ubuntu Packages
OS: Linux
Status: UNCONFIRMED
  Severity: minor
  Priority: NOR
 Component: Albums View
  Assignee: digikam-de...@kde.org
  Reporter: msylwes...@gmail.com

After editing an image and saving it as new version the new one is sorted
before the original.
Happens at least when sorted by name or by date. 

Reproducible: Always

Steps to Reproduce:
1. Select image, let's say "image.jpg"
2. Using editor make same changes
3. Save as new version, file "image_v1.jpg" is created.

Actual Results:  
image_v1.jpg is sorted before image.jpg

Expected Results:  
image_v1.jpg is sorted after image.jpg

4.14 behaves the way I would expect it.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kde] [Bug 359097] New: Crash after processing a batch queue

[Michal Sylwester via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=359097

Bug ID: 359097
   Summary: Crash after processing a batch queue
   Product: kde
   Version: unspecified
  Platform: unspecified
OS: Linux
Status: UNCONFIRMED
  Keywords: drkonqi
  Severity: crash
  Priority: NOR
 Component: general
  Assignee: unassigned-b...@kde.org
  Reporter: msylwes...@gmail.com

Application: digikam5 (5.0.0-beta3)

Qt Version: 5.4.2
Operating System: Linux 4.2.0-28-generic x86_64
Distribution: Ubuntu 15.10

-- Information about the crash:
Run a batch queue, extracting embedded jpeg images from CR2 files. Images are
processed, but then digikam crashes. Happens sometimes - I haven't noticed any
specific rule when it happens and when not.

Note: I'm using a build that includes workaround for 358913

The crash can be reproduced sometimes.

-- Backtrace:
Application: digiKam (digikam5), signal: Segmentation fault
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[Current thread is 1 (Thread 0x7f108909eb80 (LWP 20326))]

Thread 18 (Thread 0x7f1088c9b700 (LWP 20327)):
#0  0x7f10b4e268dd in poll () at ../sysdeps/unix/syscall-template.S:81
#1  0x7f109324712c in ?? () from /lib/x86_64-linux-gnu/libusb-1.0.so.0
#2  0x7f10b11346aa in start_thread (arg=0x7f1088c9b700) at
pthread_create.c:333
#3  0x7f10b4e31eed in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:109

Thread 17 (Thread 0x7f1085c6f700 (LWP 20329)):
#0  0x7f10b4e2249d in read () at ../sysdeps/unix/syscall-template.S:81
#1  0x7f10b4da62d0 in _IO_new_file_underflow (fp=0x7f10782b9910) at
fileops.c:580
#2  0x7f10b4da5088 in __GI__IO_file_xsgetn (fp=0x7f10782b9910,
data=, n=2) at fileops.c:1402
#3  0x7f10b4d9a5f0 in __GI__IO_fread (buf=, size=1, count=2,
fp=0x7f10782b9910) at iofread.c:42
#4  0x7f10b065f91c in Exiv2::isJpegType(Exiv2::BasicIo&, bool) () from
/usr/lib/x86_64-linux-gnu/libexiv2.so.14
#5  0x7f10b0655239 in
Exiv2::ImageFactory::open(std::auto_ptr) () from
/usr/lib/x86_64-linux-gnu/libexiv2.so.14
#6  0x7f10b0655489 in
Exiv2::ImageFactory::open(std::__cxx11::basic_string const&, bool) () from
/usr/lib/x86_64-linux-gnu/libexiv2.so.14
#7  0x7f10b70ff53f in Digikam::MetaEngine::load
(this=this@entry=0x7f10780d5070, filePath=...) at
/home/michal/digikam5-5.0.0~beta3/core/libs/dmetadata/metaengine.cpp:281
#8  0x7f10b714c356 in Digikam::DMetadata::load
(this=this@entry=0x7f10780d5070, filePath=...) at
/home/michal/digikam5-5.0.0~beta3/core/libs/dmetadata/dmetadata.cpp:100
#9  0x7f10b67e33a7 in Digikam::ImageScanner::loadFromDisk
(this=this@entry=0x7f1085c6e5e0) at
/home/michal/digikam5-5.0.0~beta3/core/libs/database/item/imagescanner.cpp:1550
#10 0x7f10b67e3530 in Digikam::ImageScanner::newFile
(this=this@entry=0x7f1085c6e5e0, albumId=0) at
/home/michal/digikam5-5.0.0~beta3/core/libs/database/item/imagescanner.cpp:289
#11 0x7f10b6725ca4 in Digikam::CollectionScanner::scanNewFile
(this=this@entry=0x7f1085c6e9f0, info=..., albumId=0) at
/home/michal/digikam5-5.0.0~beta3/core/libs/database/collection/collectionscanner.cpp:1252
#12 0x7f10b6727187 in Digikam::CollectionScanner::scanAlbum
(this=this@entry=0x7f1085c6e9f0, location=..., album=...) at
/home/michal/digikam5-5.0.0~beta3/core/libs/database/collection/collectionscanner.cpp:1087
#13 0x7f10b6729bc5 in Digikam::CollectionScanner::partialScan
(this=this@entry=0x7f1085c6e9f0, albumRoot=..., album=...) at
/home/michal/digikam5-5.0.0~beta3/core/libs/database/collection/collectionscanner.cpp:687
#14 0x7f10b6729d0c in Digikam::CollectionScanner::partialScan
(this=this@entry=0x7f1085c6e9f0, filePath=...) at
/home/michal/digikam5-5.0.0~beta3/core/libs/database/collection/collectionscanner.cpp:613
#15 0x7f10b7d12140 in Digikam::ScanController::run (this=0x7f10b85cd4e0
<_ZZN7Digikam12_GLOBAL__N_113Q_QGS_creator13innerFunctionEvE6holder>) at
/home/michal/digikam5-5.0.0~beta3/core/libs/database/utils/scancontroller.cpp:769
#16 0x7f10b57302be in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#17 0x7f10b11346aa in start_thread (arg=0x7f1085c6f700) at
pthread_create.c:333
#18 0x7f10b4e31eed in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:109

Thread 16 (Thread 0x7f108546e700 (LWP 20331)):
#0  pthread_cond_wait@@GLIBC_2.3.2 () at
../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
#1  0x7f1075f614da in ?? () from /usr/lib/x86_64-linux-gnu/dri/r600_dri.so
#2  0x7f1075f60c17 in ?? () from /usr/lib/x86_64-linux-gnu/dri/r600_dri.so
#3  0x7f10b11346aa in start_thread (arg=0x7f108546e700) at
pthread_create.c:333
#4  0x7f10b4e31eed in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:109

Thread 15 (Thread 0x7f1072422700 (LWP 20350)):
#0  pthread_cond_wait@@GLIBC_2.3.2 () at
../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
#1  

[digikam] [Bug 359088] New: With "Show a count of items in Tree Views" Trash always shows count of 0

[Michal Sylwester via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=359088

Bug ID: 359088
   Summary: With "Show a count of items in Tree Views" Trash
always shows count of 0
   Product: digikam
   Version: 5.0.0
  Platform: Ubuntu Packages
OS: Linux
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: Albums View
  Assignee: digikam-de...@kde.org
  Reporter: msylwes...@gmail.com

With "Show a count of items in Tree Views" Trash shows count of 0 instead of
numer of items in trash. 

Reproducible: Always

Steps to Reproduce:
1. "Show a count of items in Tree Views"
2. Compare the numer of items shown in tree view with actual trash contents


Actual Results:  
Tree view always shows 0

Expected Results:  
Numer of items in trash

-- 
You are receiving this mail because:
You are watching all bug changes.

[digikam] [Bug 359087] New: Preview image scroll position should be smarter when changing between images with different resolutions

[Michal Sylwester via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=359087

Bug ID: 359087
   Summary: Preview image scroll position should be smarter when
changing between images with different resolutions
   Product: digikam
   Version: 5.0.0
  Platform: Ubuntu Packages
OS: Linux
Status: UNCONFIRMED
  Severity: wishlist
  Priority: NOR
 Component: Preview
  Assignee: digikam-de...@kde.org
  Reporter: msylwes...@gmail.com

When watching images zoomed in it is currently possible to switch to different
image and the are shown is preserved (this is convenient as a quick alternative
to the light table). The problem occurs when the images have different
resolutions. 
- With a same image in different resolutions different area will be shown
- While switching back and forth between images where one is lower resolution
the position will be capped to the maximum of the smallest image. Happens when
I cropped one image, and accidentally select it while working on another one.

Reproducible: Always

Steps to Reproduce:
Scenario 1:
1. Make sure there are 2 versions of image, high and low resolution 
2. Preview one of them
3. Switch to the other

Scenario 2:
1. Make sure one of the images in thummbar has significantly lower resolution 
2. Preview high-resolution image (preferabelly in lower right corner)
3. Switch to low-resolution image
4. Switch back to high resolution image


Actual Results:  
Scenario 1: Area further up and left from originally selected is visible
Scenario 2: Different area of the image is visible

Expected Results:  
Scenario 1: Same area as originally selected is visible
Scenario 2: Same area of both images is visible (here is the additional issue
of whether and how zoom should be adjusted)

I think this may be a little tricky to make it work the way I would like,
especially as it would most likely also require considerations about zoom level
- should it change? Most of the time I don't care that much about actual zoom
relative to "100%", more to the relative visible area of an image, so it would
mean it should also change...

-- 
You are receiving this mail because:
You are watching all bug changes.

[digikam] [Bug 358913] Using Versionning, after returning from edit mode wrong image is selected, image itself is not updated [patch]

[Michal Sylwester via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=358913

--- Comment #13 from Michal Sylwester <msylwes...@gmail.com> ---
I had only time for a quick test so far, but seems to work just as I'd expect
it to work. Thanks!

-- 
You are receiving this mail because:
You are watching all bug changes.

[digikam] [Bug 358913] Using Versionning, after returning from edit mode wrong image is selected, image itself is not updated [patch]

[Michal Sylwester via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=358913

--- Comment #12 from Michal Sylwester <msylwes...@gmail.com> ---
Sure, I'll give it a try, but not before weekend.

-- 
You are receiving this mail because:
You are watching all bug changes.

[digikam] [Bug 358913] After returning from edit mode wrong image is selected, image itself is not updated

[Michal Sylwester via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=358913

--- Comment #7 from Michal Sylwester <msylwes...@gmail.com> ---
You're right. After disabling versioning everything works as I would expect it:
thumbbar selection does not change, preview is updated.

-- 
You are receiving this mail because:
You are watching all bug changes.

[digikam] [Bug 358913] New: After returning from edit mode wrong image is selected, image itself is not updated

[Michal Sylwester via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=358913

Bug ID: 358913
   Summary: After returning from edit mode wrong image is
selected, image itself is not updated
   Product: digikam
   Version: 5.0.0
  Platform: Other
OS: Linux
Status: UNCONFIRMED
  Severity: minor
  Priority: NOR
 Component: general
  Assignee: digikam-de...@kde.org
  Reporter: msylwes...@gmail.com

After editing image, saving it and closing editor...
1. The image shown in the main window is still the one before edits
2. The image selected on the thumbbar is the image following the edited one
The thumbnail image is actually correctly updated.

I can reproduce it consistently. Additionally, turning the thumbbar off and on
removes current selection.

This may be related to bug 326796, but my pictures are on NTFS partition.

This is on 5.0.0~beta3-wily~ppa1 from philip5's ppa, but I think I've seen it
also on 4.x

-- 
You are receiving this mail because:
You are watching all bug changes.

[digikam] [Bug 358913] After returning from edit mode wrong image is selected, image itself is not updated

[Michal Sylwester via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=358913

--- Comment #2 from Michal Sylwester <msylwes...@gmail.com> ---
Created attachment 96976
  --> https://bugs.kde.org/attachment.cgi?id=96976=edit
Bug screencast

Note at about 0:10 selection change in thumbbar and image not being updated.

-- 
You are receiving this mail because:
You are watching all bug changes.

[digikam] [Bug 358913] After returning from edit mode wrong image is selected, image itself is not updated

[Michal Sylwester via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=358913

--- Comment #4 from Michal Sylwester <msylwes...@gmail.com> ---
The preview is one thing. The thumbnail is updated, but the selection moves to
the next image. 
Note at the end I have to click the updated thumbnail to see the updated image.
To actually see the following image (the one selected after 0:10) I have to
first pick a different picture.

It's getting a little wicked, but take a look how the thumbnail selection
changes when I clicked save and it should be pretty obvious. 

BTW: I noticed that sometimes the preview does follows the thumbnail, so I see
the correct preview of the next image. It's still the next one, not the edited
one.

-- 
You are receiving this mail because:
You are watching all bug changes.

[digikam] [Bug 358913] After returning from edit mode wrong image is selected, image itself is not updated

[Michal Sylwester via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=358913

--- Comment #5 from Michal Sylwester <msylwes...@gmail.com> ---
Created attachment 96978
  --> https://bugs.kde.org/attachment.cgi?id=96978=edit
Console output

Only part while saving the image, let me know if you need larger context.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kmail2] [Bug 323168] GPG signature validation fails due to KMail modifying headers within received mails

[Michal Sylwester via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=323168

--- Comment #13 from Michal Sylwester <msylwes...@gmail.com> ---
Seems to work! When I save the email to file and try to verify it using openssl
it validates. I still have some issue with kmail complaining about "Not enough
information to check signature validity." but this seems to be unrelated to
this particular bug, and possibly an issue with my system.

Just in case I'll also attach a newer signed email.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kmail2] [Bug 323168] GPG signature validation fails due to KMail modifying headers within received mails

[Michal Sylwester via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=323168

--- Comment #17 from Michal Sylwester <msylwes...@gmail.com> ---
Good tip, indeed kmail misses the root cert. I'll try to fix it once I find
some more spare time.

Anyway, I agree, this is different story, and this bug can be closed.

-- 
You are receiving this mail because:
You are watching all bug changes.