[digikam] [Bug 375656] Tags view (left side) includes grouped images when it shouldn't
https://bugs.kde.org/show_bug.cgi?id=375656 --- Comment #1 from Jens --- This bug is still in the 5.6.0 pre-release but it is stranger. - Tag some images that are grouped - Go to the tags view on the left side - Open the tagged group - Untag the images *inside* the group -> they disappear from the tags view, which is correct - Close the group - Open the group again -> Images inside the group reappear, even if not tagged - this is incorrect I would expect only tagged images in the tags view, regardless of grouping status - see previous comment. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 381378] New: Face rectangle from XMP sidecar drawn incorrectly for EXIF rotated images
https://bugs.kde.org/show_bug.cgi?id=381378 Bug ID: 381378 Summary: Face rectangle from XMP sidecar drawn incorrectly for EXIF rotated images Product: digikam Version: 5.6.0 Platform: Other OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: Faces-Engine Assignee: digikam-de...@kde.org Reporter: jens-bugs.kde@spamfreemail.de Target Milestone: --- Created attachment 106158 --> https://bugs.kde.org/attachment.cgi?id=106158&action=edit example image pair with screenshot and metadata I have two identical JPEG photos. Both have identical XMP sidecar files specifying two faces at identical positions using mwg-rs:Regions tag (mwg-rs:Regions / rdf:Bag / rdf:li / rdf:Description / mwg-rs:Area). The single difference between these photos is that the original image was rotated 90° left (portrait) and this was compensated by adding an EXIF orientation tag specifying 90° rotation. The other image is not rotated and has no EXIF orientation flag. With the first image, Digikam (5.6.0-pre appimage on Mac OS X 10.12.5) will show the face rectangle specified in the XMP file at an incorrect position. The second image (normalized, and EXIF orientation flag removed or reset) is OK. I have attached the EXIF metadata and XMP sidecars of one such image pair to test this, as well as (censored) screenshots of Digikam displaying both images with this metadata. The root cause must be in the EXIF metadata, because when I copy this XMP sidecar to other image pairs, face rectangles are displayed correctly. Can you think of a reason why the face rectangles are not shown at the right position? How / where is the rectangle position calculated? I have many such images (>10'000) and I do not want to redraw or redetect all faces ... Thank you! -- You are receiving this mail because: You are watching all bug changes.
[Breeze] [Bug 381288] Breeze could use higher-contrast text by default (tweaked color scheme attached)
https://bugs.kde.org/show_bug.cgi?id=381288 --- Comment #5 from Jens Reuterberg --- I have to agree with Sebas here: the choice is a "damned if you do, damned if you don't level" - the harsh contrasts would make many users feel as if the experience is worse... I am not trying to wave you away of course - you are more than right there are many users who find the theme too vague but as there is a contrast colour scheme of Breeze Dark it feels as if its kinda covered. On Friday, 16 June 2017 17.46.16 CEST Nate Graham wrote: > https://bugs.kde.org/show_bug.cgi?id=381288 > > Nate Graham changed: > >What|Removed |Added > > CC||pointedst...@zoho.com > > --- Comment #3 from Nate Graham --- > It's worth mentioning that reviewers have noted Breeze's lack of sufficient > text contrast. For example: > http://www.ocsmag.com/2017/02/17/the-state-of-plasma/ -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 380434] 5.6.0-pre pkg does not detect filesystem changes
https://bugs.kde.org/show_bug.cgi?id=380434 --- Comment #2 from Jens --- I am still using 10.11, not Sierra. Haven't had a compelling reason to upgrade yet. Do you think that makes a difference? -- You are receiving this mail because: You are watching all bug changes.
[kde] [Bug 380494] New: Akonadi baloo crash
https://bugs.kde.org/show_bug.cgi?id=380494
Bug ID: 380494
Summary: Akonadi baloo crash
Product: kde
Version: unspecified
Platform: unspecified
OS: Linux
Status: UNCONFIRMED
Keywords: drkonqi
Severity: crash
Priority: NOR
Component: general
Assignee: unassigned-b...@kde.org
Reporter: jem...@mailmaxe.de
Target Milestone: ---
Application: akonadi_baloo_indexer (4.14)
KDE Platform Version: 4.14.30
Qt Version: 4.8.7
Operating System: Linux 4.10.0-22-lowlatency x86_64
Distribution: Ubuntu 17.04
-- Information about the crash:
several prblems starting akonadi:
org.kde.pim.akonadi_search_xapian: Could not obtain lock for Xapian Database.
This is bad
org.kde.pim.akonadicontrol: Agent instance "akonadi_baloo_indexer" has no
interface!
org.kde.pim.akonadicontrol: Agent instance "akonadi_baloo_indexer" has no
interface!
akonadi_baloo_indexer(9079): Could not obtain lock for Xapian Database. This is
bad
akonadi_baloo_indexer(9079): "DatabaseLockError" "DatabaseLockError: Unable to
get write lock on /home/werner/.local/share/baloo/notes/: already locked"
akonadi_baloo_indexer(9079): "DatabaseLockError" "DatabaseLockError: Unable to
get write lock on /home/werner/.local/share/baloo/calendars/: already locked"
akonadi_baloo_indexer(9079)/libakonadi: Unable to register service
"org.freedesktop.Akonadi.Agent.akonadi_baloo_indexer" at dbus: ""
KCrash: Application 'akonadi_baloo_indexer' crashing...
KCrash: Attempting to start /usr/lib/kde4/libexec/drkonqi from kdeinit
KCrash: Connect sock_file=/home/werner/.kde/socket-mobiLX/kdeinit4__0
org.kde.pim.akonadicontrol: ProcessControl: Application
"/usr/bin/akonadi_baloo_indexer" stopped unexpectedly ( "Der Prozess ist
abgestürzt" )
org.kde.pim.akonadicontrol: Application '/usr/bin/akonadi_baloo_indexer'
crashed! 1 restarts left.
QProcess: Destroyed while process ("/usr/bin/akonadi_baloo_indexer") is still
running.
org.kde.pim.akonadicontrol: ProcessControl: Application
"/usr/bin/akonadi_baloo_indexer" stopped unexpectedly ( "Der Prozess ist
abgestürzt" )
org.kde.pim.akonadicontrol: Application '/usr/bin/akonadi_baloo_indexer'
crashed! 0 restarts left.
akonadi_baloo_indexer(9197): "DatabaseLockError" "DatabaseLockError: Unable to
get write lock on /home/werner/.local/share/baloo/email/: already locked"
akonadi_baloo_indexer(9197): "DatabaseLockError" "DatabaseLockError: Unable to
get write lock on /home/werner/.local/share/baloo/emailContacts/: already
locked"
akonadi_baloo_indexer(9197): Could not obtain lock for Xapian Database. This is
bad
akonadi_baloo_indexer(9197): "DatabaseLockError" "DatabaseLockError: Unable to
get write lock on /home/werner/.local/share/baloo/notes/: already locked"
akonadi_baloo_indexer(9197): "DatabaseLockError" "DatabaseLockError: Unable to
get write lock on /home/werner/.local/share/baloo/calendars/: already locked"
akonadi_baloo_indexer(9197)/libakonadi: Unable to register service
"org.freedesktop.Akonadi.Agent.akonadi_baloo_indexer" at dbus: ""
KCrash: Application 'akonadi_baloo_indexer' crashing...
KCrash: Attempting to start /usr/lib/kde4/libexec/drkonqi from kdeinit
KCrash: Connect sock_file=/home/werner/.kde/socket-mobiLX/kdeinit4__0
The crash can be reproduced every time.
-- Backtrace:
Application: (akonadi_baloo_indexer), signal: Aborted
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[KCrash Handler]
#6 0x7f4311fc377f in __GI_raise (sig=sig@entry=6) at
../sysdeps/unix/sysv/linux/raise.c:58
#7 0x7f4311fc537a in __GI_abort () at abort.c:89
#8 0x7f4315ba6f15 in qt_message_output(QtMsgType, char const*) () at
/usr/lib/x86_64-linux-gnu/libQtCore.so.4
#9 0x7f43146d9cc7 in () at /usr/lib/libakonadi-kde.so.4
#10 0x7f43146d918a in () at /usr/lib/libakonadi-kde.so.4
#11 0x7f4315cdbd11 in QObject::event(QEvent*) () at
/usr/lib/x86_64-linux-gnu/libQtCore.so.4
#12 0x7f431321a03c in QApplicationPrivate::notify_helper(QObject*, QEvent*)
() at /usr/lib/x86_64-linux-gnu/libQtGui.so.4
#13 0x7f4313220f76 in QApplication::notify(QObject*, QEvent*) () at
/usr/lib/x86_64-linux-gnu/libQtGui.so.4
#14 0x7f4313f7ef5a in KApplication::notify(QObject*, QEvent*) () at
/usr/lib/libkdeui.so.5
#15 0x7f4315cc18ad in QCoreApplication::notifyInternal(QObject*, QEvent*)
() at /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#16 0x7f4315cc5366 in QCoreApplicationPrivate::sendPostedEvents(QObject*,
int, QThreadData*) () at /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#17 0x7f4315cf209e in () at /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#18 0x7f4311686377 in g_main_context_dispatch () at
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#19 0x7f43116865e0 in () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#20 0x7f431168668c in g_main_context_iteration () at
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#21 0x7f4315cf220e in
QEventDispatcherGlib::processEven
[digikam] [Bug 380434] 5.6.0-pre pkg does not detect filesystem changes
https://bugs.kde.org/show_bug.cgi?id=380434 Jens changed: What|Removed |Added Platform|Other |Mac OS X Disk Images OS|Linux |OS X -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 380434] New: 5.6.0-pre pkg does not detect filesystem changes
https://bugs.kde.org/show_bug.cgi?id=380434 Bug ID: 380434 Summary: 5.6.0-pre pkg does not detect filesystem changes Product: digikam Version: 5.3.0 Platform: Other OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: Bundle-MacOS Assignee: digikam-de...@kde.org Reporter: jens-bugs.kde@spamfreemail.de Target Milestone: --- The most current appimage / pkg bundle for macOS does not detect file system changes on my Macbook Pro 15 (2013). I have to restart Digikam whenever I (externally) add or remove or rename an image within a Digikam collection. Neither (Fn-)F5 nor DB maintenance > Scan for new images detect any changes. -- You are receiving this mail because: You are watching all bug changes.
[Breeze] [Bug 379861] The Kontact icon is a wifi icon
https://bugs.kde.org/show_bug.cgi?id=379861 --- Comment #2 from Jens Reuterberg --- Its based on the RSS and old Akregator icon which, when in monochrome becomes very "wifi icon" like (mostly because Wifi icons tend to be "anything with a signal symbol in it"). One idea would be to change the Akregator icon from scratch and remove the focus on the RSS symbol (the thing that looks like a wifi thing) On Tuesday, 16 May 2017 19.15.08 CEST Daniel Vrátil wrote: > https://bugs.kde.org/show_bug.cgi?id=379861 > > Daniel Vrátil changed: > >What|Removed |Added > > Component|general |Icons > Product|kontact |Breeze > Version|5.5.1 |unspecified >Assignee|kdepim-b...@kde.org |visual-des...@kde.org > CC||dvra...@kde.org, > >||kain...@gmail.com > > --- Comment #1 from Daniel Vrátil --- > I think you are referring to Akregator (RSS feed) icon, which looks like > wifi icon tilted by 45 degrees. This is an icon provided by Breeze, not by > Akregator, so reassigning to Breeze. -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 379745] New: double shortcut
https://bugs.kde.org/show_bug.cgi?id=379745 Bug ID: 379745 Summary: double shortcut Product: kdenlive Version: 16.12.3 Platform: Kubuntu Packages OS: Linux Status: UNCONFIRMED Severity: minor Priority: NOR Component: Installation Assignee: vpi...@kde.org Reporter: jem...@mailmaxe.de Target Milestone: --- There are two actions (Auswahlwerkzeug, Abstandwerkzeug) that want to use the same shortcut (). This is most probably a bug. Please report it in bugs.kde.org -- You are receiving this mail because: You are watching all bug changes.
[Breeze] [Bug 379638] Icon request: equal, unequal and swap
https://bugs.kde.org/show_bug.cgi?id=379638 --- Comment #1 from Jens Reuterberg --- For clarity of the icons - I am not a big Krusader user myself so just want to ask some (perhaps obvious) questions concerning the usage so we don't make icons that are more confusing than anything else. Show Equal Files - would an equal sign be clear enough or would for example an "equal sign within a document" make more sense (or less)? Show Unequal Files - should share some kind of similarity with the Equal Files icon so that both are "connected" in my logic (which is why say a document or file symbol with an equal/unequal sign in it would make more sense in my mind). But maybe that would be muddling the understanding of it. Swap - since that might look like a "reload" icon would say a line in the middle or something that represent the two panels make sense? Am I way of base in this thinking? On Mon, May 8, 2017 at 9:33 , Alex Bikadorov wrote: > https://bugs.kde.org/show_bug.cgi?id=379638 > > Bug ID: 379638 >Summary: Icon request: equal, unequal and swap >Product: Breeze >Version: unspecified > Platform: Other > OS: Linux > Status: UNCONFIRMED > Severity: normal > Priority: NOR > Component: Icons > Assignee: visual-des...@kde.org > Reporter: alex.bikado...@kdemail.net > CC: kain...@gmail.com > Target Milestone: --- > > The Krusader project needs three icons: > * equal: a simple "=" sign as icon, monochrome colours > * unequal: the mathematical unequal sign (equal combined with a > slash), > monochrome and additionally in red if this is not too much work > * swap (sides): a double arrow "<->", monochrome > > Background/Usage: Krusader file synchronizing feature > * equal: show identical files > * unequal: show differing files > * swap: swap the panel sides > > All of them might be useful for other applications. > > Thank you! > > -- > You are receiving this mail because: > You are the assignee for the bug. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 363522] import: use UUID from XMP sidecar / metadata instead of creating another one
https://bugs.kde.org/show_bug.cgi?id=363522 --- Comment #1 from Jens --- Hi, can anything be done about this? This makes the import process of iphoto2xmp (see github -> jensb/iphoto2xmp) much harder and I don't really see why Digikam would need to regenerate a unique ID here. Thank you! -- You are receiving this mail because: You are watching all bug changes.
[kmail2] [Bug 368350] folder full text search doesn't work : folder status always 'still not indexed'
https://bugs.kde.org/show_bug.cgi?id=368350 --- Comment #7 from Jens --- (In reply to Laurent Montel from comment #6) > We fixed a lot of bug about it in 5.5.0. > Could you test it please ? > Regards KDE 5.5.0 or KMAIL 5.5.0? i use KDE-Plasma 5.9.4 and KDE-Framework 5.31.0 -- You are receiving this mail because: You are watching all bug changes.
[kmail2] [Bug 368350] folder full text search doesn't work : folder status always 'still not indexed'
https://bugs.kde.org/show_bug.cgi?id=368350 --- Comment #5 from Jens --- there is soon a solution? -- You are receiving this mail because: You are watching all bug changes.
[muon] [Bug 378805] Muon Updater does not finish
https://bugs.kde.org/show_bug.cgi?id=378805 Jens changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #1 from Jens --- This muon updater issue has been solved today. It looks as if the cause was a hanging update of "libreoffice-l10n-de" which now has been solved today and this as a consequence seems to have solved the muon updater issue. So sorry for maybe causing unnecessary library entries and thank you anyway. -- You are receiving this mail because: You are watching all bug changes.
[muon] [Bug 378805] New: Muon Updater does not finish
https://bugs.kde.org/show_bug.cgi?id=378805
Bug ID: 378805
Summary: Muon Updater does not finish
Product: muon
Version: 2.2.0
Platform: Kubuntu Packages
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: NOR
Component: muon
Assignee: echidna...@kubuntu.org
Reporter: i.m.j...@gmx.de
CC: silh...@gmail.com
Target Milestone: ---
For some days now muon doesn't finish with the usual grey finish window and the
"all up to date" message. It just shows an empty package list control.
I'm sorry, but I'm still not very experienced in trouble shooting on
Linux/Kubuntu. But I tried to get some error messages by running it from
Terminal. Maybe this might help:
**
$ muon-updater
QDBusConnection: session D-Bus connection created before QCoreApplication.
Application may misbehave.
QDBusConnection: session D-Bus connection created before QCoreApplication.
Application may misbehave.
Object::connect: No such signal
org::freedesktop::UPower::DeviceAdded(QDBusObjectPath)
Object::connect: No such signal
org::freedesktop::UPower::DeviceRemoved(QDBusObjectPath)
$ JSonScanner::yylex - error reading from io device
Bus::open: Can not get ibus-daemon's address.
IBusInputContext::createInputContext: no connection to ibus-daemon
JSonScanner::yylex - error reading from io device
found error while replying QDBusError("org.freedesktop.DBus.Error.InvalidArgs",
"")
**
I'm still running Kubuntu 14 LTS and yes I know I should upgrade, but I need to
run some programs that seem to cause problems on newer Ubuntus, so at the
moment this is not an option for me.
Maybe someone could help me nevertheless.
Thank you :)
Jens
--
You are receiving this mail because:
You are watching all bug changes.
[Breeze] [Bug 378606] Please replace those childish avatar images
https://bugs.kde.org/show_bug.cgi?id=378606 --- Comment #5 from Jens Reuterberg --- I'm not entirely certain which are the "technical" ones you refer - is it the B/W then thank you I made them. I rather disagree with you except on one point - the default avatar - I think that was just chosen more or less at random at the time and was the stock/base out of which the "famous people" avatars where made (Gandhi, Da Vinci etc) That leaves us with the issue of which one to chose. B/W penguin? -- You are receiving this mail because: You are watching all bug changes.
[Breeze] [Bug 378606] Please replace those childish avatar images
https://bugs.kde.org/show_bug.cgi?id=378606 Jens Reuterberg changed: What|Removed |Added CC||jens...@kolabnow.com --- Comment #3 from Jens Reuterberg --- We have a rather eclectic mix of avatars to chose from http://i.imgur.com/eOZn8D8.png , anyone can suggest more images if they want to. We are serious. Any distro can, if they choose, define WHAT kind of user they prefer. If you want to stick to "as serious as possible" you can just keep the B/W avatars. You can even remove every single avatar except one or two that you prefer. We are a DE, we don't tell distros what they're user group should be and we have added up a few avatars that we felt like doing - our job is to ensure that. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-baloo] [Bug 378597] New files are not indexed
https://bugs.kde.org/show_bug.cgi?id=378597 Jens changed: What|Removed |Added CC||jens.wolf@rauschenberg-mfr. ||eu -- You are receiving this mail because: You are watching all bug changes.
[kmail2] [Bug 368350] folder full text search doesn't work : folder status always 'still not indexed'
https://bugs.kde.org/show_bug.cgi?id=368350 Jens changed: What|Removed |Added CC||jens.wolf@rauschenberg-mfr. ||eu --- Comment #3 from Jens --- Same Issue with Kmail 5.2.3 -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 378478] New: Small Improvement of subalbum display in thumbnails view
https://bugs.kde.org/show_bug.cgi?id=378478 Bug ID: 378478 Summary: Small Improvement of subalbum display in thumbnails view Product: digikam Version: 5.6.0 Platform: Other OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: AlbumsView Assignee: digikam-de...@kde.org Reporter: jens-bugs.kde@spamfreemail.de Target Milestone: --- Created attachment 104896 --> https://bugs.kde.org/attachment.cgi?id=104896&action=edit screenshot mockup of current album header and collapsed / expanded possible enhancement I have two small suggestions for the album view: display of number of images and removal of (IMHO unnecessary) text, and allowing to collapse the thumbnails of one album (like in iPhoto). See attached screenshot. With the left side arrow pointing down, the view is expanded and the album's thumbnails are visible below. With the arrow pointing right, the view is collapsed and there are no thumbnails (and subalbums fo the collapsed album) visible. A Ctrl-click (or Shift-click) on the arrow could in addition collapse / expand *all* albums' thumbnails of the current view. The arrow status (collapsed / expanded) would need to be saved in the albums' metadata. This slight UI change has several advantages: - less strings to translate, - metadata like date and number of images is easier to find (right-aligned), - less (vertical) screen space required (important for today's 16:9 displays) if album name, date and number of images tag fit beside (otherwise the date and the number of images would need to wrap), - I can view the contents of several albums at once (e.g. to compare or find images, or to split/merge albums), even if they are not chronologically beside each other. This is what I did in iPhoto (it used to have the same view) and actually my main reason for this suggestion. I think it would make a nice UI improvement for the albums view. What do you think? -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 361467] indicate (shade?) drop target when copying or moving images
https://bugs.kde.org/show_bug.cgi?id=361467 --- Comment #8 from Jens --- Still in 5.6.0 appimage .. anything I can do to help fix / improve this? -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 376049] Any album appears empty on startup until I select another album to view
https://bugs.kde.org/show_bug.cgi?id=376049 --- Comment #1 from Jens --- This still exists in the current 5.6.0 appimage. Any ideas why? Local misconfiguration? -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 378082] New: Several small new bugs in Geolocation Editor
https://bugs.kde.org/show_bug.cgi?id=378082 Bug ID: 378082 Summary: Several small new bugs in Geolocation Editor Product: digikam Version: 5.6.0 Platform: Other OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: Geolocation-Editor Assignee: digikam-de...@kde.org Reporter: jens-bugs.kde@spamfreemail.de Target Milestone: --- Since 5.5.0 appimages, some new bugs appear in the Geolocation Editor. 1. (since 5.5.0-pre) .mp4 videos in the files list have no date/time set and are always at the top of the list. 2. (since 5.6.0-pre) When saving, Digikam complains that the geodata of .mp4 files cannot be saved. But when I close without saving the .mp4 files have geodata set. 3. (since 5.5.0-pre) There is no zoom slider in the map (OSM). 4. (since 5.4.0-pre, I think) The map does not remember the last used zoom level any more (just the position). 5. (since 5.4.0) Switching between Google Maps and OSM sometimes loses the position of the map. Can you please check if any patches since the last releases created these bugs? Thanks! -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 361047] Wishlist: make grouped images more prominently visible [patch]
https://bugs.kde.org/show_bug.cgi?id=361047 --- Comment #81 from Jens --- I would really like to see/review this change. Is there a chance to replace 1-2 compiled files in the appimage (libraries etc) or will you compile new appimages anyway in a few days? Thanks! -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 377857] Ideas to improve usability of metadata sidebar
https://bugs.kde.org/show_bug.cgi?id=377857 --- Comment #4 from Jens --- Created attachment 104689 --> https://bugs.kde.org/attachment.cgi?id=104689&action=edit Dashboard screenshot for those without LibreOffice/OpenOffice (e.g. mobile devices) -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 377857] Ideas to improve usability of metadata sidebar
https://bugs.kde.org/show_bug.cgi?id=377857 --- Comment #2 from Jens --- Just out of curiosity: what is missing for 90%? 99%? 100%? :) -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 377857] New: Ideas to improve usability of metadata sidebar
https://bugs.kde.org/show_bug.cgi?id=377857 Bug ID: 377857 Summary: Ideas to improve usability of metadata sidebar Product: digikam Version: 5.5.0 Platform: Appimage OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: Usability Assignee: digikam-de...@kde.org Reporter: jens-bugs.kde@spamfreemail.de Target Milestone: --- Created attachment 104657 --> https://bugs.kde.org/attachment.cgi?id=104657&action=edit improved metadata sidebar - mockup & screenshot See also my post in digikam-users (and users's replies) starting 13.02.2017. I originally come from iPhoto and similar commercial apps. My workflow when importing images (and videos) into Digikam might reflect this a little - I find myself constantly switching between tabs in Digikam to perform simple image management / organizational tasks. I think this can be improved a lot by modifying the layout and usability of Digikam's "Properties" sidebar (the top one on the right) and converting it into a summary-/ dashboard kind of sidebar which covers 80-90% of all requirements in one single place. Currently the "Properties" sidebar is just a list of image and file properties and not used for editing at all - which makes it kind of superfluous (IMHO). I have created a mockup of how this sidebar can be improved by incorporating simple metadata editing tasks. The idea is that for simple asset management tasks (adding titles, ratings and tags, editing dates and viewing basic image metadata) you *only* need this single sidebar. The idea is *NOT* to squeeze all possible metadata into one dialog. This is a little inspired by iPhoto's organization of metadata which I found quite usable. Please have a look and tell me what you think. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 375703] Moving grouped images into another album removes groups
https://bugs.kde.org/show_bug.cgi?id=375703 --- Comment #22 from Jens --- Ricardo, I wasn't intending to (much) change the *visual* appearance of grouped images. Just the technical way of storing them. Right now, there are a huge heap of difficulties involved in managing grouped images and it is hard (if not impossible) to get at groups from without Digikam. Using folders (=albums) for groups, with a special tag, will keep files grouped if files are moved outside Digikam and not require a huge amount of database management when copying, moving or renaming albums with groups. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 361047] Wishlist: make grouped images more prominently visible [patch]
https://bugs.kde.org/show_bug.cgi?id=361047 --- Comment #76 from Jens --- How about we visually (!) treat an opened group like a subalbum at the respective position in the list of images? the master image should then also be in the subalbum and must still be highlighted somehow but this can be done with E. g. a thicker border frame (instead of another color). Yes, this would require a rearrangement of all thumbnails in the album (since a row is probably being split up) but it would be consistent. Another idea is to reduce the opacity of opened grouped thumbnails to e. g. 50 percent but only(!) while the mouse is not over one of the group. this does not affect visibility while relevant, it indicates clearly what is grouped, and it does not interfere with color schemes. Also, it creates the possibility of correctly sorting grouped images in between non grouped ones when the group is opened. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 377240] Deleting an image (DEL key) within LightTable resets zoom factor for following image
https://bugs.kde.org/show_bug.cgi?id=377240 --- Comment #2 from Jens --- Wow, that was fast. Thank you! -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 377228] Assign only deepest level reverse geotag to image to avoid tag spam
https://bugs.kde.org/show_bug.cgi?id=377228 --- Comment #7 from Jens --- Actually, I'm pretty fond of being able to use tags for many purposes and not having to reinvent the wheel for every other kind of metadata. (OTOH, if portability is an issue, the IPTC location tags should at least be written, if not used in Digikam too.) But if this means we have to treat some tags specially (-> Animal Farm) and this is not clearly visible for the user, then it is a bad solution. We already have "face tags" (which have additional parameters not clearly indicated to the user), now we're getting "location tags" ... at least the default icon should be different, in addition to them being displayed only where it makes sense. But this might be a different bug report. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 377240] New: Deleting an image (DEL key) within LightTable resets zoom factor for following image
https://bugs.kde.org/show_bug.cgi?id=377240 Bug ID: 377240 Summary: Deleting an image (DEL key) within LightTable resets zoom factor for following image Product: digikam Version: 5.5.0 Platform: Appimage OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: LightTable Assignee: digikam-de...@kde.org Reporter: jens-bugs.kde@spamfreemail.de Target Milestone: --- To reproduce: 1. Select some images (>= 3) 2. Open Light Table editor 3. Display in pairs must be disabled 4. Choose first image displayed on left side and second on right side 5. Press CTRL+, to zoom to 1:1 factor 6. Delete second image (DEL key) Result: third image is displayed on right side but in "zoom to fit", not 1:1 zoom factor. First image is still displayed in 1:1 zoom factor. Expected result: third image should inherit zoom factor from second image, and also view position. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 377228] Assign only deepest level reverse geotag to image to avoid tag spam
https://bugs.kde.org/show_bug.cgi?id=377228 --- Comment #3 from Jens --- Wolfgang, thank you for the handbook and your hard work! Your workaround doesn't work, however, since the alphabetical order is only applied to the actual tag (deepest level) and not the full tree. My top level tag is "Orte", but "Orte/Deutschland/Berlin" still comes before "Kochen" (because of "B"erlin). Or is this configurable? I didn't find anything. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 377228] Assign only deepest level reverse geotag to image to avoid tag spam
https://bugs.kde.org/show_bug.cgi?id=377228 --- Comment #1 from Jens --- Addendum: For option (a), reverse geocoding tags could possibly be displayed as a tooltip of the icon that indicates the image has embedded geoinformation. That is where they would belong. This would need to be an option to be set in the reverse geocoding dialog (globally, i.e. also for existing tags): [X] Hide geocoding tags below thumbnails (display only as geocoding icon tooltip) -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 377228] New: Assign only deepest level reverse geotag to image to avoid tag spam
https://bugs.kde.org/show_bug.cgi?id=377228 Bug ID: 377228 Summary: Assign only deepest level reverse geotag to image to avoid tag spam Product: digikam Version: 5.5.0 Platform: Appimage OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: Geolocation-Editor Assignee: digikam-de...@kde.org Reporter: jens-bugs.kde@spamfreemail.de Target Milestone: --- I have started reverse geotagging my images to be able to search for images within a certain city or location. This works great (once you have understood the UI), but it spams a lot of tags (TopLevelTag, Country, Country/City, Country/City/Street, Country/City/Street/Number) in my images, which makes the tags display below the thumbnails almost useless (since only the location tags are visible any more). I can think of two solutions to this problem: a) do not show reverse geocoding tags below images, or b) only assign *one* deepest level tag (in my example above, Number) to the images, and not all higher hierarchy level tags. With (b), images can still be filtered and found because searches may include the higher level tags. (Right?) What do you think? -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 377099] New: Hightlight certain albums / tags in tree view
https://bugs.kde.org/show_bug.cgi?id=377099 Bug ID: 377099 Summary: Hightlight certain albums / tags in tree view Product: digikam Version: 5.5.0 Platform: Appimage OS: Linux Status: UNCONFIRMED Severity: wishlist Priority: NOR Component: AlbumsView Assignee: digikam-de...@kde.org Reporter: jens-bugs.kde@spamfreemail.de Target Milestone: --- I create date-based hierarchical albums / folders for all my images according to the following scheme: ~/Pictures/Digikam//MM.DD_Description_of_album Just like in Animal Farm, all albums are equal, but some are more equal than others. ;-) I would like to visually highlight some albums (e.g. vacations, special trips, etc. - about 10% of my collection) among all my daily life children's playground and experimental images so they are easier to spot in the tree view. I use 16x16 icons so album thumbnails are not an option. Would it be possible to assign font color (just color, maybe bold/italic, not font or size!) to the album names in the left side tree view? Or maybe (even better) assign it to the album categories? This way I could set all vacation picture albums red/bold and all nature shootings green, etc. and highlight new albums just by assigning a category. Colors could be set in the settings, there is already a categories editor. The same, by the way, would be applicable to the tags tree. There are tags I use all the time, a highlighting option would be great here. Or maybe there is even a better idea to highlight certain albums? Thank you! -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 218819] Implement albums tree-view colapse/expand history
https://bugs.kde.org/show_bug.cgi?id=218819 Jens changed: What|Removed |Added CC||jens-bugs.kde.org@spamfreem ||ail.de --- Comment #1 from Jens --- I think this has been solved in the most recent Digikam version (5.4). Right? -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 361047] Wishlist: make grouped images more prominently visible [patch]
https://bugs.kde.org/show_bug.cgi?id=361047 --- Comment #63 from Jens --- Gilles, that sounds great! Can you create an appimage? I'll help you test it. Jens -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 376802] New: Add face detection/recognition and quality tags as optional import post processors
https://bugs.kde.org/show_bug.cgi?id=376802 Bug ID: 376802 Summary: Add face detection/recognition and quality tags as optional import post processors Product: digikam Version: 5.3.0 Platform: Other OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: Import-PostProcessing Assignee: digikam-de...@kde.org Reporter: jens-bugs.kde@spamfreemail.de Target Milestone: --- I think the face detection (with options) and sort by quality) maintenance options should be available from within import or be (optionally) automatically called after each import, since both are (typically) one-time operations that each image only needs to see once. Maybe other options too. I would like to get my image import workflow to be as streamlined as possible. Automatic face recognition and quality tags after import would help a lot here, since adding face tags to imported images afterwards always includes having to deselect and reselect the appropriate folders. With automatic post-import image recognition I would only have to confirm the faces as I go through the images anyway. Thank you! -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 376359] Sort by Image Quality (assign quality tags) ignores many images
https://bugs.kde.org/show_bug.cgi?id=376359 --- Comment #2 from Jens --- great, thank you! -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 375703] Moving grouped images into another album removes groups
https://bugs.kde.org/show_bug.cgi?id=375703 --- Comment #19 from Jens --- True - removing features must always be well thought out and there must be a migration path (= database migration). I thought about this some more. The concepts are indeed very similar, only little change would need to be done to enable "pseudo grouping" using subfolders: + Albums would get a new property setting whether - the album should be treated as a folder as it is now, with - a entry in the albums tree view - a separate section in the main view) or - as an image group inside the main thumbnails view, not in the albums sidebar - using the album's folder thumbnail image as thumbnail - and the thumbnail image's metadata to sort this thumbnail + Such "group" albums would also allow metadata changes to the main thumbnail image and optionally apply them to all images inside the group. + There must be a migration function which converts grouped images to "group folders" for all future Digikam versions (since we don't know what versions people will use) which automatically activates on startup so future Digikam versions don't modify old databases. Advantages: - We can get rid of a huge ton of complexity regarding grouped images (moving, copying, external manipulation, reimport, etc.) - Image groups are represented in the file system and not just in the database (better for external image manipulation) - Import grouped images into Digikam is much easier since (almost) all you need to do is create the appropriate subfolders. Maybe it would even be possible to create ".xmp" files inside folders with appropriate folder properties for Digikam, this would make data transfer even easier. Disadvantages: - There will be two types of "albums" for the future. This might require modification of existing code regarding albums. - I think it would be worth it. Image groups are a really great feature but right now the feature is somewhat unstable and so I am still a bit hesitant to use it intensively. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 376687] New: GPS tagging usability of bookmarks
https://bugs.kde.org/show_bug.cgi?id=376687 Bug ID: 376687 Summary: GPS tagging usability of bookmarks Product: digikam Version: 5.5.0 Platform: Other OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: Geolocation-Editor Assignee: digikam-de...@kde.org Reporter: jens-bugs.kde@spamfreemail.de Target Milestone: --- I'm a little confused how to use the bookmarks feature in the Geotagging editor. - You can create bookmarks in the map (using the context menu) and display them. But: - Bookmarks created on the map are gone when you restart Digikam. (Is this because of the Appimage concept which uses a temp mount?) - Bookmarks created on the map cannot be used to assign a location to the images below. The lists seem to be completely separate. What is the usage concept here? Or is this actually buggy? Thank you :) -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 375703] Moving grouped images into another album removes groups
https://bugs.kde.org/show_bug.cgi?id=375703 --- Comment #17 from Jens --- I agree to the previous points. But I have one thought I'd like to share. We are getting to the point where "groups" of images become basically identical to sub-albums (subfolders within an album) except for the fact that they are displayed within the main folder and sorted into the parent's images, not separately. So do we *want* the difference between grouped images and subfolders/albums to exist at all? Is there a difference? Does there need to be a difference? For me, - grouped images represent images that are very similar (e.g. taken with my camera's "machine gun mode" to catch the right moment) but I almost never want to see all of the images. They are part of an event (album) and a chronological series of images. - (sub)albums represent "subevents" of their own, part of a larger event (e.g. one day's tour within a vacation) with different and unique images that all want to be viewed (and some can be grouped). But both could be used for both purposes with very little change in the UI. Both subalbums and groups can have a "master image" (thumbnail) and both subalbums and groups can be opened and closed. Maybe the whole idea of grouped images needs to be rethought? Maybe we can solve many of the grouping issues by just redefining "groups === subalbums"? Very little would need to be done, IMHO: - Include an option for each album (and a global default) to display subalbums in the main thumbnail view (with a folder icon or the defined album thumbnail) as an image within the other images - allow ratings, tags, etc. to be applied to albums (which would effectively apply them to all contained images) Is this maybe worth a second thought? It would make the whole concept a lot simpler and - I think - solve a lot of the consistency issues that the concept of grouping images has right now. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 361047] Wishlist: make grouped images more prominently visible [patch]
https://bugs.kde.org/show_bug.cgi?id=361047 --- Comment #60 from Jens --- My originally suggested "rotated" frame can well be precomputed and just added around the image as a border. I wasn't implying the frame should be recomputed on every image (although this was the level of polish that iPhoto received from Apple ... ;) ) -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 375375] Various bugs detecting and tagging faces in current 5.4.0 Digikam appimage
https://bugs.kde.org/show_bug.cgi?id=375375
--- Comment #21 from Jens ---
Update as of today:
1. Selecting face names with the mouse now works fine.
2. Autocompletion of names when typing works but the dropdown disappears on
every second letter. Usable but a little buggy.
3. Still a little buggy. Many faces (e.g. slightly rotated, lying or upside
down) are not detected at all. Adjusting the detection sensitivity ("fast" vs
"precise") does not improve detection. Most of these faces were detected fine
by iPhoto. Is Digikam's OpenCV interface using eye detection first and using
the angle between eyes to compute the face rotation before finding the actual
face? This was suggested on StackOverflow.
4. fixed
5. Unknown faces still grab the cursor focus when browsing images using preview
mode, so they stop the browsing (with keyboard). Maybe the input field should
not grab non-alphanumeric key events.
Thank you!
--
You are receiving this mail because:
You are watching all bug changes.
[digikam] [Bug 376463] Improve keyboard assignment and useage of tags
https://bugs.kde.org/show_bug.cgi?id=376463 --- Comment #2 from Jens --- 1) OK, I didn't know this. Can this be made more obvious? It sounds quite efficient if you know about it. (Maybe as a placeholder text in the tags textfield, like "Enter tag, press ENTER twice to return to photos" or as a tooltip.) 2) Yes, maybe. It would perhaps be too confusing. There's always a tradeoff to be made between efficiency and intuition of a certain feature. 3) True. Why can't the single key shortcut be entered in the tag settings directly? -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 376463] New: Improve keyboard assignment and useage of tags
https://bugs.kde.org/show_bug.cgi?id=376463
Bug ID: 376463
Summary: Improve keyboard assignment and useage of tags
Product: digikam
Version: 5.5.0
Platform: Appimage
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: NOR
Component: Tags
Assignee: digikam-de...@kde.org
Reporter: jens-bugs.kde@spamfreemail.de
Target Milestone: ---
Currently (5.5.0 appimage) the tags input field can be activated by "T" but
there is no (obvious) way of getting back to the images index (except for
5x"Shift tab" or 7x "tab" to come full circle).
Is it possible to assign "ESC" as a way to leave the tags filter input field
and get the cursor focus back to the images thumbnails (to be able to navigate
between images again), or the currently viewed image (so you can select the
next image)?
Also, when the cursor focus is at the tags tree, the "up/down" cursor keys
could select tags, while the "left/right" cursor keys could select the
next/previous image (preview and thumbnail mode).
Also, there is no (obvious) way of assigning single key ("A", "L", "M")
keyboard shortcuts to tags. Keys with modifiers (Ctrl, Alt, Meta) work - is
there a reason why? I can assign single keys to other functions (e.g.
Lighttable or Batch manager).
Thanks!
--
You are receiving this mail because:
You are watching all bug changes.
[digikam] [Bug 361047] Wishlist: make grouped images more prominently visible [patch]
https://bugs.kde.org/show_bug.cgi?id=361047 --- Comment #58 from Jens --- I think modifying the thumbnail is essential here, otherwise it's not obvious that this is actually a group. An additional icon or *only* the background will not do. But if the thumbnail size cannot be changed or causes other headaches, how about a folded-corner effect like this one here?: http://www.freepik.com/free-vector/folded-corner_835380.htm The corner should not cover half the thumbnail of course, but it must be clearly visible and obvious in all thumbnail sizes (and the corner might even contain the number of grouped images). I would be willing to trade my original "rotated image frame stack" idea for this one. and it might be easier to implement because the thumbnail size doesn't change. Bonus points if the folded page corner actually displays the lower right bit of the *second* grouped image, maybe brightened up a little to differentiate it from the main thumbnail. :-) What do you think? -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 361047] Wishlist: make grouped images more prominently visible [patch]
https://bugs.kde.org/show_bug.cgi?id=361047 --- Comment #55 from Jens --- Any news here? Anything I can do to help? Thanks! -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 376359] New: Sort by Image Quality (assign quality tags) ignores many images
https://bugs.kde.org/show_bug.cgi?id=376359 Bug ID: 376359 Summary: Sort by Image Quality (assign quality tags) ignores many images Product: digikam Version: 5.5.0 Platform: Other OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: Maintenance Assignee: digikam-de...@kde.org Reporter: jens-bugs.kde@spamfreemail.de Target Milestone: --- When I choose to let my images be tagged according to image quality using Digikam's default settings, only very few images are actually tagged. I wonder if this is an expected behaviour? I would expect all images of all albums that I chose in the respective maintenance dialog to be tagged (with the colored flag, meaning "accepted", "pending" or "declined"). But most (>50%) images are not tagged at all. Thanks! -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 361467] indicate (shade?) drop target when copying or moving images
https://bugs.kde.org/show_bug.cgi?id=361467 --- Comment #7 from Jens --- Drop target is still not visible (current 5.5 appimage on Linux 64bit). I tested all "designs" (color themes, available from the settings menu) that are available. Any progress here, anything I can do to help? Thanks! -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 376049] New: Any album appears empty on startup until I select another album to view
https://bugs.kde.org/show_bug.cgi?id=376049 Bug ID: 376049 Summary: Any album appears empty on startup until I select another album to view Product: digikam Version: 5.5.0 Platform: Other OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: AlbumsView Assignee: digikam-de...@kde.org Reporter: jens-bugs.kde@spamfreemail.de Target Milestone: --- When I start up the current appimage, I don't see any image although an non-empty album is selected in the tree view at the left side. When I select another album, the view works perfectly. I would expect the contents of the selected album at bootup to be shown at once. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 375703] Moving grouped images into another album removes groups
https://bugs.kde.org/show_bug.cgi?id=375703 --- Comment #9 from Jens --- Is this (wrongly linked image IDs) an issue that should concern me? what exactly happens? Thank you :) -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 375703] Moving grouped images into another album removes groups
https://bugs.kde.org/show_bug.cgi?id=375703 --- Comment #4 from Jens --- Oh, that is perfect. Garbage collection was on my list too - especially since some garbage has accumulated while developing iphoto2xmp: https://github.com/jensb/iphoto2xmp :-) Thank you! Will try as soon as there is an appimage. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 375703] Moving grouped images into another album removes groups
https://bugs.kde.org/show_bug.cgi?id=375703 --- Comment #2 from Jens --- Is there no clean solution for this? AFAIK the groups only refer to the images anyway (not the paths). so if images are moved, only the image path must be updated. Group information in the database could stay completely unchanged. Right? -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 375704] New: Dragging the map over the zoom slider in Marble/OSM view will unintentionally zoom out/in
https://bugs.kde.org/show_bug.cgi?id=375704 Bug ID: 375704 Summary: Dragging the map over the zoom slider in Marble/OSM view will unintentionally zoom out/in Product: digikam Version: 5.5.0 Platform: Appimage OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: Geolocation-Editor Assignee: digikam-de...@kde.org Reporter: jens-bugs.kde@spamfreemail.de Target Milestone: --- If I use the geolocation editor and then drag the mouse to move the map, and unintentionally drag the mouse over the zoom slider, the map will zoom in or out - depending on where I touched the slider. This causes the map to lose its current position and you "get lost" on the map. It is very irritating. Please disable all map controls during mouse drag operations. Maybe even hide them completely. Thank you! :) -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 375703] New: Moving grouped images into another album removes groups
https://bugs.kde.org/show_bug.cgi?id=375703 Bug ID: 375703 Summary: Moving grouped images into another album removes groups Product: digikam Version: 5.5.0 Platform: Appimage OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: Usability Assignee: digikam-de...@kde.org Reporter: jens-bugs.kde@spamfreemail.de Target Milestone: --- When moving a set of grouped images into a different album, all images are moved (so this is not #294578) but the group property is not kept. In the new album I have to group all images again. I would expect the groups to be moved alongside with the images and all other metadata. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 375700] Digikam freezes for a long time (I/O wait) if similarity range is set too low
https://bugs.kde.org/show_bug.cgi?id=375700 --- Comment #2 from Jens --- Update: This is one example SQL query that freezes upon restart. But if I remove this query from digikam4.db / Searches table, then another one freezes, so I suspect a deeper issue. In any case, Digikam should not freeze or refuse to start up because of a saved search. IMHO. :) digikam.database: Search query: "SELECT DISTINCT Images.id, Images.name, Images.album, Albums.albumRoot,ImageInformation.rating, Images.category, ImageInformation.format, ImageInformation.creationDate, Images.modificationDate, Images.fileSize,ImageInformation.width, ImageInformation.height,ImagePositions.latitudeNumber, ImagePositions.longitudeNumber FROM ImagesLEFT JOIN ImageInformation ON Images.id=ImageInformation.imageidLEFT JOIN ImageMetadataON Images.id=ImageMetadata.imageidLEFT JOIN VideoMetadataON Images.id=VideoMetadata.imageidLEFT JOIN ImagePositions ON Images.id=ImagePositions.imageidINNER JOIN Albums ON Albums.id=Images.album WHERE Images.status=1 AND ( ( ( (Albums.relativePath LIKE ?) OR (Images.name LIKE ?) OR (Images.id IN(SELECT imageid FROM ImageTags WHERE tagid IN(SELECT id FROM Tags WHERE name LIKE ?))) OR (Albums.caption LIKE ?) OR (Albums.collection LIKE ?) OR (Images.id IN (SELECT imageid FROM ImageComments WHERE type=? AND comment LIKE ?)) OR (Images.id IN (SELECT imageid FROM ImageComments WHERE type=? AND comment LIKE ?)) ) ) );" (QVariant(QString, "%teppich%"), QVariant(QString, "%teppich%"), QVariant(QString, "%teppich%"), QVariant(QString, "%teppich%"), QVariant(QString, "%teppich%"), QVariant(int, 1), QVariant(QString, "%teppich%"), QVariant(int, 3), QVariant(QString, "%teppich%")) digikam.geoiface: "ROADMAP" digikam.geoiface: "setting backend marble" digikam.geoiface: "ROADMAP" digikam.geoiface: digikam.general: Cancel Main Thread digikam.geoiface: VACUUM resulted in Die Datenbank wurde unter Verwendung des VACUUM-Statements komprimiert. Vor dem Komprimieren: Seitenanzahl = 66474 Datenbankgröße = 68069376 Bytes Nachdem komprimieren:n Seitenanzahl = 970 Datenbankgröße = 993280 bytes -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 375700] Digikam freezes for a long time (I/O wait) if similarity range is set too low
https://bugs.kde.org/show_bug.cgi?id=375700 --- Comment #1 from Jens --- This is even worse - if I kill Digikam because the search takes too long, it will (apparently) restart the search upon next start, giving the impression that the application does not even start any more. Maybe also a maximum search time (timeout) for all fuzzy search operations, like 20 seconds, makes sense? At least to give the user some feedback. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 375700] New: Digikam freezes for a long time (I/O wait) if similarity range is set too low
https://bugs.kde.org/show_bug.cgi?id=375700 Bug ID: 375700 Summary: Digikam freezes for a long time (I/O wait) if similarity range is set too low Product: digikam Version: 5.5.0 Platform: Other OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: Searches-Fuzzy Assignee: digikam-de...@kde.org Reporter: jens-bugs.kde@spamfreemail.de Target Milestone: --- I have roughly 160GB of photos on my SSD disk on an Intel Haswell i5-4570 with 8G RAM (so enough horsepower). However, when I select an image and search for similar images using similarity search, and then set the similarity starting at 20% (up to 100%), the application freezes for almost a minute. While this might be technically correct behaviour, the user experience here is really bad. Please add a progress bar (if possible) and a "Cancel search" button. Maybe it is possible to perform this search in the background altogether (so you can return to the results later on)? Also, a warning maybe for similarities below 30% that they might take a long time to match would be helpful. Thank you! -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 375663] New: JJ: progress bars not initialized in ImageEditor at various places
https://bugs.kde.org/show_bug.cgi?id=375663 Bug ID: 375663 Summary: JJ: progress bars not initialized in ImageEditor at various places Product: digikam Version: 5.5.0 Platform: Other OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: ImageEditor-Tool-BCG Assignee: digikam-de...@kde.org Reporter: jens-bugs.kde@spamfreemail.de Target Milestone: --- In the image editor e.g. contrast/brightness tool, color tool, saturation tool, etc, many progress bars go from -100 to +100, and start at 0 (default value), but the bar itself is empty. It should be 50% filled. This is probably a junior job (thus JJ:) since easy to fix. But it is confusing at first. ;) -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 375656] New: Tags view (left side) includes grouped images when it shouldn't
https://bugs.kde.org/show_bug.cgi?id=375656 Bug ID: 375656 Summary: Tags view (left side) includes grouped images when it shouldn't Product: digikam Version: 5.5.0 Platform: Other OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: Tags Assignee: digikam-de...@kde.org Reporter: jens-bugs.kde@spamfreemail.de Target Milestone: --- If I tag an image which has images grouped underneath it (which do not have the same tag) I would not expect these images to show when filtering by tag using the left side tags view. But they do. I would only expect images to be shown that all have this tag applied. Example: - Create album with five images 1..5. - Tag image#1 with "Foobar" tag and drag images 2..5 on image#1 (to group them). - Go to tag "Foobar" in the left sidebar. - Image#1 is shown with a "grouped images" icon. This icon can be clicked to reveal images 2..5, which do not have this tag. I would expect the "grouped images" icon only to be visible if there are images grouped beneath image#1 that *also* have the same tag. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 375375] Various bugs detecting and tagging faces in current 5.4.0 Digikam appimage
https://bugs.kde.org/show_bug.cgi?id=375375 --- Comment #12 from Jens --- Perfect, thank you! With the new appimage, the menubar integration in Ubuntu also works again :-D Also "detect and recognize" now does detect faces. But no faces are recognized (although I already have a siginificant face corpus with confirmed faces). Also with recognized (unconfirmed and confirmed) photos a "group by face" option for the main view would be great, instead of "group by album" etc. Then it becomes much easier to confirm and reorder photos. Thank you! -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 375375] Various bugs detecting and tagging faces in current 5.4.0 Digikam appimage
https://bugs.kde.org/show_bug.cgi?id=375375 --- Comment #10 from Jens --- Great, I'd be happy to test an updated appimage. :) So: 1: fixed 2: no easy workaround for face tag dropdown not working on each second keypress 3: waiting for appimage to test 4: waiting for appimage to test 5: ? Thank you! -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 150531] SCHEMA : add album password-protect feature
https://bugs.kde.org/show_bug.cgi?id=150531 Jens changed: What|Removed |Added CC||jens-bugs.kde.org@spamfreem ||ail.de --- Comment #20 from Jens --- Seconded. Not just for other people browsing, but also for myself. I have a tag group called "for.." and subgroups called "All", "Family", "Friends" and "Nobody!!!". The last group shows images of family members bathing, for example. I never show my whole library to other people. Only the respective tag groups are shown. But quite often, I miss some pictures from this tag collection and have to resort searching my whole library - and have to tell everybody to look away for a while, which is cumbersome. A hidden option - something like "Hide images tagged with [___]" - would solve this. I could just hide the "Nobody!!!" images and people could view my library. File system access rights or groups do not work here at all (and are the wrong approach) because they would need to apply to thumbnails and metadata as well, which Digikam saves spread over several places. Far too complicated. Also, I am not concerned about hackers or malicious people, just about casual usage and accidental viewing of NSFF (not safe for family... ;) ) images. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 374712] Preview image does not work any more from thumbs view
https://bugs.kde.org/show_bug.cgi?id=374712 --- Comment #5 from Jens --- Done. So far, no more crashes. Also I'll continue using 5.5.0 appimage from now, to see if this bug is still there. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 375375] Various bugs detecting and tagging faces in current 5.4.0 Digikam appimage
https://bugs.kde.org/show_bug.cgi?id=375375 --- Comment #4 from Jens --- Done. Here is my feedback: 1: fixed 2: works, but typing a "b" opens the batch processing window. New bug. :) Also I cannot switch between face rectangles using the mouse. How about "tab"? 3: no difference detected yet. 4: still does not do anything. 5: still not working -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 374712] Preview image does not work any more from thumbs view
https://bugs.kde.org/show_bug.cgi?id=374712 --- Comment #3 from Jens --- /tmp/.mount_AeuF4H/usr/share/digikam/profiles$ ls -la insgesamt 3 drwxr-xr-x 1 root root 2048 Dez 18 14:26 . drwxr-xr-x 1 root root 2048 Dez 18 14:26 .. -rw-r--r-- 1 root root 580 Dez 18 14:26 compatibleWithAdobeRGB1998.icc -rw-r--r-- 1 root root 1132 Dez 18 14:26 prophoto.icm -rw-r--r-- 1 root root 6924 Dez 18 14:26 srgb-d65.icm -rw-r--r-- 1 root root 2044 Dez 18 14:26 widegamut.icm /tmp/.mount_AeuF4H/usr/share/digikam/profiles$ file * compatibleWithAdobeRGB1998.icc: Microsoft ICM Color Profile prophoto.icm: ICC Profile srgb-d65.icm: Microsoft ICM Color Profile widegamut.icm: Microsoft ICM Color Profile -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 375375] Various bugs detecting and tagging faces in current 5.4.0 Digikam appimage
https://bugs.kde.org/show_bug.cgi?id=375375 --- Comment #2 from Jens --- 5: when browsing images and face tags are active, the first "unknown" face rectangle's bottom combobox (to enter a name) grabs the cursor focus so you cannot navigate using the cursor keys any more. Possible solution: Do not let the face rectangle combobox grab the keys assigned to "next/previous/..." images, or generally, any non-character key events. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 375375] Various bugs detecting and tagging faces in current 5.4.0 Digikam appimage
https://bugs.kde.org/show_bug.cgi?id=375375 --- Comment #1 from Jens --- Update for #2: Autocomplete works in this case, but is case sensitive. I didn't realize this, can you make it case insensitive (but case retaining, ie. use the case of the word in the list, not the word that was typed)? -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 375375] New: Various bugs detecting and tagging faces in current 5.4.0 Digikam appimage
https://bugs.kde.org/show_bug.cgi?id=375375
Bug ID: 375375
Summary: Various bugs detecting and tagging faces in current
5.4.0 Digikam appimage
Product: digikam
Version: 5.4.0
Platform: Appimage
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: NOR
Component: Faces-Management
Assignee: digikam-de...@kde.org
Reporter: jens-bugs.kde@spamfreemail.de
Target Milestone: ---
Using the current appimage:
1. Cannot use mouse to select a name from dropdown menu.
I want to add a face rectangle to an existing image. so I click and drag a
rectangle and a combobox with name tags appears below it. I can open the menu
and scroll to a name, but I cannot select the name using the mouse. Nothing
happens.
I have to use the keyboard (ENTER) to select the name and then again the mouse
to click OK.
I would like to be able to use the mouse for the whole face tagging process
(for existing names).
2. Autocompletion of names does not work when typing inside the names combobox.
In the faces detection view, when hovering over a photo and typing into the
combobox that then appears, I can only type 1-2 letters before the input field
disappears again.
In the combobox that appears below existing faces rectangles in image previews,
I can type into the combobox, but the tag selection list does not filter
according to my entries.
3. Many faces are not detected - e.g. side portraits or upside-down faces.
Is this a known issue with the current faces detection library?
4. In the "Search faces" dialog which appears when opening the left side
"People" tag and clicking on "Search collection for faces" (approx.), only the
radio button option "Detect faces" works (ie. has any result). The second
option ("Detect and recognize faces") and third ("Recognize faces") always
yield 0 results at once.
I would like Digikam to detect and recognize faces. I have a corpus large
enough for it to learn. How do I do this?
Thank you!
--
You are receiving this mail because:
You are watching all bug changes.
[digikam] [Bug 374712] Preview image does not work any more from thumbs view
https://bugs.kde.org/show_bug.cgi?id=374712 --- Comment #1 from Jens --- I just experienced this again with the current 5.4.0 appimage (Ubuntu 16.04) after fullscreen viewing + tagging (rating) a number of images. Repeatable. I can rate about 10 images with the keyboard and then fullscreen view gets stuck at the current image, I cannot go to the next or previous image any more, when I exit the preview back to thumbnails, I cannot enter it any more (no image shown). The console shows the following last messages: digikam.metaengine: DateTime => Exif.Photo.DateTimeOriginal => QDateTime(2017-01-19 15:25:28.000 CET Qt::TimeSpec(LocalTime)) digikam.database: Scanning took 14 ms digikam.database: Finishing took 4 ms digikam.metaengine: Exif color-space tag is sRGB. Using default sRGB ICC profile. digikam.metaengine: Orientation => Exif.Image.Orientation => 1 digikam.dimg: Cannot open workspace color profile "/tmp/.mount_GaIDR1/usr/share/digikam/profiles/srgb-d65.icm" digikam.database: Starting scan! -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 375197] New: It is possible to rotate video thumbnails (but the video isn't rotated)
https://bugs.kde.org/show_bug.cgi?id=375197 Bug ID: 375197 Summary: It is possible to rotate video thumbnails (but the video isn't rotated) Product: digikam Version: 5.4.0 Platform: Appimage OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: Thumbnails Assignee: digikam-de...@kde.org Reporter: jens-bugs.kde@spamfreemail.de Target Milestone: --- In my current 5.4.0 appimage, I can use Shift+Ctrl+Cursor to rotate video thumbnails. But the video itself isn't rotated. Either the video orientation should be adjusted (I think Qt5Multimedia supports video orientation flags) or the thumbnail rotation should just be ignored - if many thumbnails are selected and one of them is a video, just this video thumbnail should not be rotated. And if the rotation is actually supported, the thumbnail should be recreated with the "movie" overlay again at the side of the thumbnail. Right now, after rotation, the overlay is at the top or bottom (inconsistent). Thank you :) -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 375154] New: Suggestions for improving the display of images in the trashcan
https://bugs.kde.org/show_bug.cgi?id=375154 Bug ID: 375154 Summary: Suggestions for improving the display of images in the trashcan Product: digikam Version: 5.4.0 Platform: Appimage OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: Usability Assignee: digikam-de...@kde.org Reporter: jens-bugs.kde@spamfreemail.de Target Milestone: --- First, I like the fact that Digikam 5 now has its own trash can (for those who don't use desktop file manages - or maybe KDE - this is a plus). However the display should be the same as selected on the toolbar. In my 5.4.0 appimage, the display is always tabular, even when "thumbnails" is selected (not "table" view). Also, XMP sidecar files are visible in the trash, these should IMHO be hidden and synchronized with the respective JPG or movie files. Metadata like deletion time and folder could be displayed below the images (like in thumbnails view) in addition to the other metadata (the trash display should display images exactly the same as the other folders, except for this metadat). Just my opinion, though ... it would be more consistent that way. Thank you :) -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 349924] Videos (mp4, mov, avi) do not play under OS X Yosemite when using digiKam
https://bugs.kde.org/show_bug.cgi?id=349924 --- Comment #35 from Jens --- ... however, I do not have any sound (appimage, Linux Ubuntu 16.04, 5.4.0 @22b397e1b). Any ideas? Sound is fine on Mac OS X. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 374712] New: Preview image does not work any more from thumbs view
https://bugs.kde.org/show_bug.cgi?id=374712
Bug ID: 374712
Summary: Preview image does not work any more from thumbs view
Product: digikam
Version: 5.4.0
Platform: Other
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: NOR
Component: Thumbnails
Assignee: digikam-de...@kde.org
Reporter: jens-bugs.kde@spamfreemail.de
Target Milestone: ---
In the current 4.4.0 appimage (64bit Linux, Ubuntu 16.04 amd64) since importing
the last batch of images from my camera, I cannot enter preview mode (with one
image enlarged and the rest as thumbnails at the top) any more.
When I try, simply nothing happens, except that the toolbar options are toggled
respectively ("Vorschaubild" becomes active).
Restarting digikam fixes this usually, but then sometimes the menu and toolbars
are gone.
--
You are receiving this mail because:
You are watching all bug changes.
[digikam] [Bug 349924] Videos (mp4, mov, avi) do not play under OS X Yosemite when using digiKam
https://bugs.kde.org/show_bug.cgi?id=349924 --- Comment #34 from Jens --- Works fine! Thank you! Plus, movies and movie thumbnails also work now under macOS. (tested with .mp4 H264 and .AVI MJPEG files) Great work! -- You are receiving this mail because: You are watching all bug changes.
[Breeze] [Bug 374300] Option to change the font color on the lock screen
https://bugs.kde.org/show_bug.cgi?id=374300 Jens Reuterberg changed: What|Removed |Added CC||jens...@kolabnow.com --- Comment #1 from Jens Reuterberg --- Currently the only option is to change the wallpaper you use (either by modding it to include lighter sections in the area where the dark text is or changing it entirely). The issue isn't that there is anything blocking a way to set it from a design perspective but rather where to include it currently and how hard it is to do from a technical standpoint. We have a massive problem with settings - and there has been quite the discussion about SDDM/Lockscreen/Wallpaper-settings which will probably affect this. Adding it in the "set wallpaper" section for Lockscreen and SDDM seems like a good temporary solution (since they are mostly empty space currently) but then again what will happen with the work when those are redesigned? TL;DR from a design perspective nothing blocks the idea that you can change font colour - at the same time, the programmers will have to reply on how complex it is to add - and whether the risk of a future overhaul will make that effort worthless. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 374071] New: Tags checkbox tristate incorrect when deselecting tagged images (off-by-one)
https://bugs.kde.org/show_bug.cgi?id=374071 Bug ID: 374071 Summary: Tags checkbox tristate incorrect when deselecting tagged images (off-by-one) Product: digikam Version: 5.4.0 Platform: Other OS: All Status: UNCONFIRMED Severity: normal Priority: NOR Component: Tags Assignee: digikam-de...@kde.org Reporter: jens-bugs.kde@spamfreemail.de Target Milestone: --- This happens since 5.4.0 (maybe 5.3.0?). 1. Open an album where there are *some* images with tags and some without. 2. Select all images (Ctl-A) 3. Open Tag Editor (right panel). The matching tags checkboxes will be grey (tristate). 4. Manually deselect all images matching the half-checked tag (Ctrl+Mouse) Result: The tag is still in tristate (grey box). Expected result: The tag should be unchecked since I deselected all tagged images. 5. Deselect one more image which does not have the tag. Result: The tag is unchecked. Expected Result: This should have happened after step 4 already. 6. Reselect the non-tagged image. Result: The tag is still unchecked. There seems to be an off-by-one error somewhere in a counter which decides whether to "half-check" the tag list. Can you find it? Thank you! -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 349924] Videos (mp4, mov, avi) do not play under OS X Yosemite when using digiKam
https://bugs.kde.org/show_bug.cgi?id=349924 --- Comment #31 from Jens --- 10.11.6 on Macbook Pro (Early 2013) 15" Retina -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 349924] Videos (mp4, mov, avi) do not play under OS X Yosemite when using digiKam
https://bugs.kde.org/show_bug.cgi?id=349924 --- Comment #29 from Jens --- This is great news, thank you! Unfortunately the MacOS package does not start. There seem to be unresolved symbols. The Linux x86-64 appimage works fine though. Unfortunately I cannot post the whole backtrace here because bugs.kde.org thinks it is spam. Dyld Error Message: Symbol not found: _clock_gettime Referenced from: /opt/digikam/*/libgnutls.30.dylib Expected in: /usr/lib/libSystem.B.dylib -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 361467] indicate (shade?) drop target when copying or moving images
https://bugs.kde.org/show_bug.cgi?id=361467 --- Comment #6 from Jens --- Can't reproduce on OS X with any color theme. No hover border visible here. -- You are receiving this mail because: You are watching all bug changes.
[Breeze] [Bug 373668] Tiny keyboard layout indicator is the Lock Screen
https://bugs.kde.org/show_bug.cgi?id=373668 Jens Reuterberg changed: What|Removed |Added CC||jens...@kolabnow.com --- Comment #8 from Jens Reuterberg --- Ok I think this discussion needs to mellow out a tad... BACKGROUND TO CURRENT PLACEMENT: The assumption was that the users who did need it would find it, where as the users who didn't need it wouldn't have the entire screen muddled up with different controls. This in combination with the motivation to make the act of starting and shutting down feel like one unified whole instead of different aspects of the DE handing over to each other. Now that was designed slightly before the fact that the keyboard layout isn't visible if you don't have another keyboard layout installed - which sorta turns the tables. That leaves another issue - will putting every single control on prime real estate solve the issue? It will for you (Anton) because that is what you personally need - but will it do that for all or will that as well as the switcher for different DE's (which would then have to be moved as well) just clog up the controls? WHAT TO DO: Looking at SDDM - the key task there is to fill in your password (which is why its centered). The second task is to switch users, the third is to shut down the computer, reboot etc. The date/time is there to ensure the similarity between the login and the lock screen visually. So whatever we change here - will affect the design of Lock Screen, etc. There is a future addon for the lock screen (not SDDM) where you can control the music player and that will be placed in the center column of the lock screen but underneath. We could dedicate that area to it BUT that may also result in some issues like a TON of stuff clogging it up. Making the buttons bigger would be interesting but that wont fix much either in the long run since the reason they are pushed away to the sides is to 1) get them out of the way as not being universally relevant objects and 2) get some kind of balance (and not make it look like a middle school book report (center aligned text everywhere)). So what we need is something that not only displays the lesser relevance of the keyboard layout in comparison with login etc - but also balances it out. TL;DR its an issue, but a slightly fiddlier one than one may think -- You are receiving this mail because: You are watching all bug changes.
[gwenview] [Bug 361887] gwenview shows wrong colours
https://bugs.kde.org/show_bug.cgi?id=361887 --- Comment #4 from Jens --- Hi Jan, that has been a long time since I posted my request. Thank you for answering :) But I did not install any colour profile on this system. All installed profiles are those from the installation CD or any of the system updates. I did add a colour profile for an elder monitor some months ago, but the monitor as well as the Kubuntu installation of the time of my post are broken by now. Nevertheless the problem remained with a new Kubuntu (14.04 LTS) and a new monitor. In the meantime I tried all Nvidia versions and now also without an Nvidia installation – still without any changes (if someone should come to this proposal). So after searching endlessly for a solution without any clue, I discarded the use of Gwenview and installed GPicView, XnView and even IrfanView which all are doing a fine job. Anyway I'm still and technically interested in a solution for this issue. So if someone still could find an answer I would be very thankful. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 361467] indicate (shade?) drop target when copying or moving images
https://bugs.kde.org/show_bug.cgi?id=361467 --- Comment #2 from Jens --- Yes. There is no indication as to where the images will actually be dropped. I would expect a background shading or border around the drop target while hovering over each target so you can see where images will be copied / moved before you release the mouse button. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 102500] ICONVIEW : more space conservative in thumbs view
https://bugs.kde.org/show_bug.cgi?id=102500 --- Comment #25 from Jens --- I consider the "no border around images" part of the bug (which I filed eleven years ago ;) ) as solved, Digikam 5.4.0 as below doesn't show a border any more. Also, overlay icons are shown inside images for portrait which saves some vertical space, very precious for today's 16:9 display world. The same might be possible for the rating stars - they would still be readably as overlay icons. Any chance? About the other ideas mentioned in this bug report, I don't see them as solved yet but most of them are gimmicks, not really providing a lot of advantage. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 370150] Digikam geolocation editor drag and drop works only at the first edit
https://bugs.kde.org/show_bug.cgi?id=370150 --- Comment #5 from Jens --- Not reproducible with the AppImage linked above. Also some other issues seem fixed (application basic font size, missing icons and icon size, etc.) -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 372701] New: Cannot drag images on map (OSM or Google)
https://bugs.kde.org/show_bug.cgi?id=372701 Bug ID: 372701 Summary: Cannot drag images on map (OSM or Google) Product: digikam Version: 5.3.0 Platform: Other OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: Geolocation-Editor Assignee: digikam-de...@kde.org Reporter: jens-bugs.kde@spamfreemail.de Target Milestone: --- Using the Geolocation editor on ubuntu 16.04, I cannot position images onto the map. The cursor always shows the "forbidden" overlay icon as soon as I start dragging. Also, the map does not remember my location between invocations and does not synchronize the location when toggling between OSM and Google. This used to work in 4.x. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 372485] Video thumbnails not created on OS X (Linux works fine since 5.3)
https://bugs.kde.org/show_bug.cgi?id=372485 --- Comment #4 from Jens --- OK thank you :) do you have any plans to do this in the near future? -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 372485] New: Video thumbnails not created on OS X (Linux works fine since 5.3)
https://bugs.kde.org/show_bug.cgi?id=372485 Bug ID: 372485 Summary: Video thumbnails not created on OS X (Linux works fine since 5.3) Product: digikam Version: 5.3.0 Platform: Other OS: OS X Status: UNCONFIRMED Severity: normal Priority: NOR Component: Thumbnails Assignee: digikam-de...@kde.org Reporter: jens-bugs.kde@spamfreemail.de Target Milestone: --- I installed the PKG on OS X 10.11.5 (and philip5's packages on Ubuntu 16.04 64bit) and video thumbnails only work on Linux. On OS X, no video thumbnails are created. Is this a known bug? If not, how can I get more detailed console output? -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 372440] New: Wishlist: ability to search for panoramic shots (search by aspect ratio *range*)
https://bugs.kde.org/show_bug.cgi?id=372440 Bug ID: 372440 Summary: Wishlist: ability to search for panoramic shots (search by aspect ratio *range*) Product: digikam Version: 5.3.0 Platform: Other OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: Searches Assignee: digikam-de...@kde.org Reporter: jens-bugs.kde@spamfreemail.de Target Milestone: --- I want to tag all images with aspect ratio greater than 16:9 (~2) as "Panoramic". Currently I can only search for an exact aspect ratio, not for a range (or greater than / smaller than). I would be able to find all such images if the extended search allowed for aspect ratio *ranges* to be entered. Can this be made possible? Thank you! -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 361047] Wishlist: make grouped images more prominently visible [patch]
https://bugs.kde.org/show_bug.cgi?id=361047 --- Comment #54 from Jens B. Benecke --- OK, no hurry. .) Anything I can do to help (non-coder)? I have some more time now. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 361047] Wishlist: make grouped images more prominently visible [patch]
https://bugs.kde.org/show_bug.cgi?id=361047 --- Comment #52 from Jens B. Benecke --- I just updated to Digikam 5.3 and this patch does not seem to be applied to it yet. Is there something I need to configure to have this functionality? -- You are receiving this mail because: You are watching all bug changes.
[Breeze] [Bug 371914] Icon request: Claws-mail
https://bugs.kde.org/show_bug.cgi?id=371914 Jens Reuterberg changed: What|Removed |Added CC||jens...@kolabnow.com --- Comment #2 from Jens Reuterberg --- Made an icon for it, its not perfect as on smaller sizes the rounded shape of the claw looks kinda blurry, so it looks like a batch of agave growing in an envelope but its up to the icon team what they think. http://imgur.com/a/vvrOE -- You are receiving this mail because: You are watching all bug changes.
[Breeze] [Bug 370374] GRUB menu has huge lag due to theme
https://bugs.kde.org/show_bug.cgi?id=370374 Jens Reuterberg changed: What|Removed |Added CC||jens...@kolabnow.com --- Comment #10 from Jens Reuterberg --- I'm interested whether this effect is true when using other grub themes? Because if it is, it's something way bigger than KDE/Plasma and something that would make sense to ask around about since many distros and DE's also provide their own themed grub. If on the other hand it isn't then obviously something is terribly wrong in OUR grub theme that needs figuring out. -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 368770] Kate uses default Qt File Dialog *not KDE file dialog* which breaks tons of features, including KIO
https://bugs.kde.org/show_bug.cgi?id=368770 --- Comment #14 from Marvin Jens --- Okay, I gave up and switched to KDE neon. Now everything is perfect. It seems one should currently regard kubuntu/backports as broken? Thanks for your time anyway... -- You are receiving this mail because: You are watching all bug changes.
[neon] [Bug 370358] GIve sddm user home folder and .face.icon ACL rights in order to load the avatar
https://bugs.kde.org/show_bug.cgi?id=370358 Jens Reuterberg changed: What|Removed |Added CC||jens...@kolabnow.com --- Comment #4 from Jens Reuterberg --- Can confirm that it's the same on a newly installed Arch machine here. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 369671] Tone down transparency of kicker/kickoff menu
https://bugs.kde.org/show_bug.cgi?id=369671 Jens Reuterberg changed: What|Removed |Added CC||jens...@kolabnow.com --- Comment #4 from Jens Reuterberg --- One way to solve this would be too turn off transparency completely when Blur/Background Contrast isn't enabled (for applauncher as well as panel etc) - but then again there are a few people who use it simply as is and I have no idea how tricky it is to create such a solution. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 360333] New system tray: icons do not scale with panel height, stay very small
https://bugs.kde.org/show_bug.cgi?id=360333 Jens Reuterberg changed: What|Removed |Added CC||jens...@kolabnow.com --- Comment #18 from Jens Reuterberg --- (In reply to Marco Martin from comment #6) > this bug is pretty much mutually exclusive with > https://bugs.kde.org/show_bug.cgi?id=353834 > I fear icons are either going to be too big for some people or too small for > some other people (and i don't want to add a configure icon size ui) I guess that any variant will rub some people wrong. We simply can't account for all tastes and any change will make one group or another angry. The question is: which group do we want to piss off, or do we accept the problems that come with such a configuration UI. Also if Guillame is correct above, that HiDPI screens make the icons stick to 16x16, that's the main issue since that would make them close to unusable. One solution would be to create a third size of 32x32 icons and simply skip to that size when the panel is resized to something that could accomade them. But that means recreating the icon theme (so its pixel aligned) and that will take a while (IIRC only a few of the panel icons exists in 32x32) -- You are receiving this mail because: You are watching all bug changes.
[marble] [Bug 368167] crash on startup in geoiface QMutex::lock [cause: digikamrc]
https://bugs.kde.org/show_bug.cgi?id=368167 --- Comment #8 from Jens B. Benecke --- It's in digikamrc, either in $HOME/.kde/config or in .config/digikam (I think). -- You are receiving this mail because: You are watching all bug changes.
