[KScreen] [Bug 406377] OSD and applet: add "Extend to top/bottom" options
https://bugs.kde.org/show_bug.cgi?id=406377 Milan Knížek changed: What|Removed |Added CC||kni...@volny.cz -- You are receiving this mail because: You are watching all bug changes.
[plasma-nm] [Bug 479179] KDE Network Manager creates unusable name for wireguard and fails to save
https://bugs.kde.org/show_bug.cgi?id=479179 Milan Knížek changed: What|Removed |Added CC||tiref45...@javadoq.com --- Comment #9 from Milan Knížek --- *** Bug 427231 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
[plasma-nm] [Bug 427231] Network Manager imposes unnecessary restrictions on connection names and fails ungracefully
https://bugs.kde.org/show_bug.cgi?id=427231 Milan Knížek changed: What|Removed |Added Status|REPORTED|RESOLVED Resolution|--- |DUPLICATE CC||kni...@volny.cz --- Comment #1 from Milan Knížek --- Possibly a duplicate of https://bugs.kde.org/show_bug.cgi?id=479179 *** This bug has been marked as a duplicate of bug 479179 *** -- You are receiving this mail because: You are watching all bug changes.
[plasma-nm] [Bug 479179] KDE Network Manager creates unusable name for wireguard and fails to save
https://bugs.kde.org/show_bug.cgi?id=479179 Milan Knížek changed: What|Removed |Added CC||kni...@volny.cz -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 456987] Open with... not working in AppImage
https://bugs.kde.org/show_bug.cgi?id=456987 Milan Knížek changed: What|Removed |Added Ever confirmed|0 |1 Status|RESOLVED|REOPENED Resolution|FIXED |--- Version|7.7.0 |8.0.0 --- Comment #21 from Milan Knížek --- The same bug is back in AppImage 8.0.0 - Kubuntu 22.04. -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 426174] invert scroll direction shows as enabled but is not actually working upon rebooting
https://bugs.kde.org/show_bug.cgi?id=426174 Milan Knížek changed: What|Removed |Added CC||kni...@volny.cz --- Comment #12 from Milan Knížek --- Similar behaviour here - Kubuntu 22.04. Natural scrolling works when I enable it and it is also kept after reboot as long as the USB wireless dongle remains plugged in. However, if I plug in the USB wireless dongle for the mouse after the computer is up & running, the option "Invert scroll direction" is not applied to it despite the fact that the option remains "enabled" in SystemSettings // Input Devices // Mouse. The same problems happens for the "known" (previously used) and also for a new USB Wireless mouse. Disabling and re-enabling the option "Invert scroll direction" resolves the problem. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 456987] Open with... not working in AppImage
https://bugs.kde.org/show_bug.cgi?id=456987 Milan Knížek changed: What|Removed |Added Status|REPORTED|RESOLVED Resolution|--- |FIXED --- Comment #20 from Milan Knížek --- Indeed! Thanks. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 456987] Open with... not working in AppImage
https://bugs.kde.org/show_bug.cgi?id=456987 --- Comment #3 from Milan Knížek --- Indeed, it works then. How do I find out which ksycoca* it actually is/will be (from within a bash script which will eventually run digiKam AppImage)? -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 456987] New: Open with... not working in AppImage
https://bugs.kde.org/show_bug.cgi?id=456987 Bug ID: 456987 Summary: Open with... not working in AppImage Product: digikam Version: 7.7.0 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Usability-OpenWith Assignee: digikam-bugs-n...@kde.org Reporter: kni...@volny.cz Target Milestone: --- SUMMARY *** NOTE: If you are reporting a crash, please try to attach a backtrace with debug symbols. See https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports *** STEPS TO REPRODUCE 1. Run `/Applications/digiKam-7.7.0-x86-64.appimage` from terminal 2. Select any album to show thumbnails of photos in main view. 3. Right click on a thumbnail and choose `Open With...` OBSERVED RESULT The list is empty. EXPECTED RESULT The list includes applications which can open the image type (JPEG in my case). SOFTWARE/OS VERSIONS Linux/KDE Plasma: Kubuntu 22.04 (minimal desktop installation) (available in About System) KDE Plasma Version: 5.24.4 (not listed in Help // About digiKam // Components, though) KDE Frameworks Version: 5.95.0 Qt Version: 5.15.3 (built against 5.15.3) ADDITIONAL INFORMATION Further info: - Open in File Manager => Dolphin opens with the respective folder, the image file is not pre-selected, though. - Open With... and manually typing in `/Applications/Darktable.appimage %U` opens darktable with the image displayed. The Open With... list remains empty afterwards, anyway. - In Dolphin: `Open With` shows a list of apps (GIMP, darktable, ...) as expected. -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 455073] Tooltips can't be disabled
https://bugs.kde.org/show_bug.cgi?id=455073 Milan Knížek changed: What|Removed |Added CC||kni...@volny.cz -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 454882] New: Requirements for MySQL Server omit USER
https://bugs.kde.org/show_bug.cgi?id=454882 Bug ID: 454882 Summary: Requirements for MySQL Server omit USER Product: digikam Version: 7.6.0 Platform: Archlinux Packages OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Database-Mysql Assignee: digikam-bugs-n...@kde.org Reporter: kni...@volny.cz Target Milestone: --- SUMMARY When configuring database for external MySQL Server, the second tab called "Requirements" lists these commands: CREATE USER ''@'' IDENTIFIED BY 'password'; GRANT ALL ON *.* TO ''@'' IDENTIFIED BY 'password'; CREATE DATABASE digikam; GRANT ALL PRIVILEGES ON digikam.* TO ''@''; FLUSH PRIVILEGES; OBSERVED RESULT Creating a USER w/o username fails. PROPOSED SOLUTION Modify the SQL commands to: CREATE USER 'digikam'@'' IDENTIFIED BY 'password'; GRANT ALL ON *.* TO 'digikam'@'' IDENTIFIED BY 'password'; CREATE DATABASE digikam; GRANT ALL PRIVILEGES ON digikam.* TO 'digikam'@''; FLUSH PRIVILEGES; -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 425168] Cannot type accented characters via dead-keys
https://bugs.kde.org/show_bug.cgi?id=425168 --- Comment #8 from Milan Knížek --- (In reply to caulier.gilles from comment #7) > You can test using 7.6.0 pre-release AppImage bundle available here : > https://files.kde.org/digikam/ I tried on Arch Linux (AppImage 7.6.0 20220211) and I cannot still type accented characters with the help of dead-keys (like pressing "ˇ" and then "C" should produce "Č", but instead only ASCII "C" is typed). Further, there are some troubles with bundled libraries: digikam: symbol lookup error: /usr/lib/libpangocairo-1.0.so.0: undefined symbol: pango_font_get_hb_font and digikam: symbol lookup error: /usr/lib/libgio-2.0.so.0: undefined symbol: g_module_open_full Which I resolved by removing libgmodule* and libpango* from the squash fs and repackaging the AppImage - i.e. loading the host libraries instead. P.S. Not reopening the bug report since I am not sure if removing the bundled libraries may have any impact on the bug itself. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 136260] EXIF, IPTC, and XMP editor embedded to Captions/Tags sidebar
https://bugs.kde.org/show_bug.cgi?id=136260 --- Comment #19 from Milan Knížek --- digiKam takes care about syncing the metadata accross various data structures (XMP Core/Adobe/whatever, IPTC, Exif), so direct editing of a particular subset does not seem a way to go anyway as it would break the sync. Batch application through standard UI (side bar: tags, caption; GPS location via menu Item / Geo) seems to work quite well - only the "changed metadata" are applied to selected images (replacing existing values, if any), other metadata are preserved. A more fine grained mass editing is better to be done in a script with exiftool/exiv2. IMHO, this bug report could be closed as Fixed (I am not the "reporter", though). -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 231114] TEMPLATE : Empty (unset) fields of template overwrite existing used fields when applying template
https://bugs.kde.org/show_bug.cgi?id=231114 Milan Knížek changed: What|Removed |Added Version|2.8.0 |7.2.0 Platform|Ubuntu Packages |Archlinux Packages -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 231114] TEMPLATE : Empty (unset) fields of template overwrite existing used fields when applying template
https://bugs.kde.org/show_bug.cgi?id=231114 Milan Knížek changed: What|Removed |Added Summary|TEMPLATE : Used fields |TEMPLATE : Empty (unset) |overwrite existing used |fields of template |fields when applying|overwrite existing used |template|fields when applying ||template --- Comment #10 from Milan Knížek --- In the current version of digiKam, the bug still exhibits as described. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 202709] Sharing images among computers and update of local databases
https://bugs.kde.org/show_bug.cgi?id=202709 Milan Knížek changed: What|Removed |Added Status|REPORTED|RESOLVED Resolution|--- |WORKSFORME --- Comment #4 from Milan Knížek --- Although this request is not yet implemented as a feature, reading and writing metadata from and to images seems reliable - I have used it several times. So, the user can solve the problem through: a) always 'write metadata to images' (or XMP) b) careful syncing of album tree or its part with some other computers c) and manually re-reading metadata. Since a dedicated tool within digikam has not gained much attention, I am closing the bug now. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 431753] Show overlay with metadata in Preview mode
https://bugs.kde.org/show_bug.cgi?id=431753 --- Comment #2 from Milan Knížek --- Sorry for the duplicate, I have completely forgotten I even commented the other open bug half year ago... -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 431753] New: Show overlay with metadata in Preview mode
https://bugs.kde.org/show_bug.cgi?id=431753 Bug ID: 431753 Summary: Show overlay with metadata in Preview mode Product: digikam Version: 7.1.0 Platform: Archlinux Packages OS: Linux Status: REPORTED Severity: wishlist Priority: NOR Component: Preview-Image Assignee: digikam-bugs-n...@kde.org Reporter: kni...@volny.cz Target Milestone: --- SUMMARY Allow the user to define what metadata should be displayed (comments, file name, tags, etc.) as an image overlay in `Preview` mode. STEPS TO REPRODUCE 1. Open image in Preview mode OBSERVED RESULT No metadata are displayed. EXPECTED RESULT Comments of all lang variants, assigned tags, ratings, color lables, file size etc. should be displayable. (Similar display options as of // Settings // Configure digiKam // Views // Icons should be available for Preview.) RATIONALE While adding/reviewing image metadata (tags, comments, face tags) in Preview mode it is rather slow to identify what user metadata are already filled in. I.e. I have to switch the side panels to Tags (check "Tags already assigned"), to Description (open the language code to see which lang variants are already filled in), etc. It is possible to increase the icon (thumbnail) size in "Thumbnails" mode to somewhat emulate a Preview mode, however: - the size is limited - the image quality is not the same as preview - it is not possible to add face tags. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 382179] Keep in Add a Face Tag mode after adding a face tag
https://bugs.kde.org/show_bug.cgi?id=382179 --- Comment #9 from Milan Knížek --- Although the "CTRL + mouse draw" to create a new face tag is great, I still believe a possibility to have a "locked add face tag" mode would be helpful. I am tagging a lot of photos in my archive during these days, and every saved step counts. By a lot :-) How about ctrl or shift + click on the "add face tag" icon? It could lock the adding mode until the user presses ESC. (All other things would remain as they are now: automatic focus on entry field once a region is drawn, arrow key to select a filtered face tag, enter to confirm and save, space bar to proceed to next image.) -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 430671] New: Add a Face Tag: default action for Enter key should be the highlighted tag
https://bugs.kde.org/show_bug.cgi?id=430671 Bug ID: 430671 Summary: Add a Face Tag: default action for Enter key should be the highlighted tag Product: digikam Version: 7.1.0 Platform: Archlinux Packages OS: Linux Status: REPORTED Severity: wishlist Priority: NOR Component: Faces-Workflow Assignee: digikam-bugs-n...@kde.org Reporter: kni...@volny.cz Target Milestone: --- SUMMARY While manually tagging faces on photos (ctrl + mouse drawn face region), digiKam filters the existing Face tags according to text entry in Name field. Typically, the most recent used tag is highlighted in bold and it is sorted as the first one in the filtered list. The last two items in the filtered list are always "Create XXX in Faces" and "Create XXX". (The filter works very well.) However, pressing enter does create a new tag in Faces. In order to choose the highlighted item, the user must press down arrow and press enter or choose the tag via mouse. STEPS TO REPRODUCE 1. Draw a rectangle on the image (ctrl + drag). 2. A window for adding a tag name will appear. Start typing an existing face tag. 3. A drop-down list will show existing tags in "Faces" matching the typed entry. 4. Few of them or just a single one - the top most - will be highlighted. 5. Press enter key. OBSERVED RESULT digiKam creates a new tag in Faces. EXPECTED RESULT digiKam assigns the first tag in the drop-down list of existing tags or creates a new tag in Faces, if the list is empty. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Archlinux KDE Frameworks Version: KDE Frameworks 5.77.0 Qt Version: Qt 5.15.2 (built against 5.15.2) -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 425168] Cannot type accented characters via dead-keys
https://bugs.kde.org/show_bug.cgi?id=425168 --- Comment #5 from Milan Knížek --- But with Flatpak, there seems to be some troubles with integration - I use quite often "Open with..." submenu to run actions outside of digiKam on the image or whole folder (based on standard .desktop files and mime db). With Flatpak, this seems to be quite complicated (it does not work to simply allow host:ro filesystem access). -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 425168] Cannot type accented characters via dead-keys
https://bugs.kde.org/show_bug.cgi?id=425168 --- Comment #4 from Milan Knížek --- Flatpak works okay. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 425168] Cannot type accented characters via dead-keys
https://bugs.kde.org/show_bug.cgi?id=425168 --- Comment #2 from Milan Knížek --- I have found a current Qt bug report with similar behaviour - that one is dependend on static (bug) or shared (works) linking: https://bugreports.qt.io/browse/QTBUG-83783 -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 425168] Cannot type accented characters via dead-keys
https://bugs.kde.org/show_bug.cgi?id=425168 Milan Knížek changed: What|Removed |Added Component|Tags-Captions |Usability-i18n -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 425168] New: Cannot type accented characters via dead-keys
https://bugs.kde.org/show_bug.cgi?id=425168
Bug ID: 425168
Summary: Cannot type accented characters via dead-keys
Product: digikam
Version: 7.0.0
Platform: Appimage
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: Tags-Captions
Assignee: digikam-bugs-n...@kde.org
Reporter: kni...@volny.cz
Target Milestone: ---
SUMMARY
Typing accented chars (like 'ěščřžýáíé') works well, however, I cannot type
these characters via a dead-key + non-accented key combination - which is
needed mainly for typing capital letters ('ĚŠČŘŽ...'
It is still possible to type the accented capital letters in other app and copy
them into digiKam text fields.
STEPS TO REPRODUCE
1. Open digiKam
2. Choose any image
3. Open Captions in side bar
4. Try to type 'Ž' via dead-key (located at shift + '+' on standard keyboard)
and Z.
OBSERVED RESULT
The non-accented character 'Z' is typed.
EXPECTED RESULT
The accented 'Ž' should have been typed.
SOFTWARE/OS VERSIONS
KDE Frameworks 5.70.0
Qt 5.14.2 (built against 5.14.2)
The xcb windowing system
I use AppImage to run digiKam in GNOME on Arch Linux, with english locale but
with a Czech keyboard layout.
--
You are receiving this mail because:
You are watching all bug changes.
[digikam] [Bug 271489] Repeated reverse geotagging may duplicate /location tags
https://bugs.kde.org/show_bug.cgi?id=271489 --- Comment #11 from Milan Knížek --- Unfortunatelly, the bug is the same as reported originally. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 382179] Keep in Add a Face Tag mode after adding a face tag
https://bugs.kde.org/show_bug.cgi?id=382179 Milan Knížek changed: What|Removed |Added CC||kni...@volny.cz Version|5.7.0 |6.4.0 --- Comment #7 from Milan Knížek --- Ctrl + mouse draw is a nice trick! Yet, if the "add a face tag" is kept, it would be useful. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 302559] Add overlay to edit properties as Labels and Tags
https://bugs.kde.org/show_bug.cgi?id=302559 Milan Knížek changed: What|Removed |Added Version|2.6.0 |6.4.0 -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 302559] Add overlay to edit properties as Labels and Tags
https://bugs.kde.org/show_bug.cgi?id=302559 Milan Knížek changed: What|Removed |Added CC||kni...@volny.cz --- Comment #15 from Milan Knížek --- I tend to add/modify metadata whenever I search through my albums - i.e. quite randomly when I have time for "house cleaning". It would be helpful if we can list various types of metadata in Image Preview (my choice: GPS icon, tags, title, comments) - just to see what metadata exists already. I know that I can list "already assigned tags" in the side bar, but that is too slow - I have to switch views (Captions/Description, Caption/Tags) and activate the "show already assigned" tags whenever I assign another tag. Or I can switch to Thumbnail View (but not all tags fit there anyway. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 400492] Rotation does not work
https://bugs.kde.org/show_bug.cgi?id=400492 --- Comment #11 from Milan Knížek --- Thanks Maik, the latest digikam-6.0.0-beta3-20181102T200629-x86-64 works fine. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 400492] Rotation does not work
https://bugs.kde.org/show_bug.cgi?id=400492 --- Comment #9 from Milan Knížek --- The thing is, the flag for thumbnail does not rotate - it stays as it was originally (from camera) and the thumbnail rotates physically. Try show the exif metadata in the right hand pane, filter for orientation flag and rotate the image. In other words, originally both flags might be "rotated right", but when I rotate the image, then the image flag gets set to 'normal', while the thumbnail flag remains 'rotated right'. In order to get the thumbnail displayed correctly (in Digikam), digiKam must actually physically rotate it, too. The trouble is, that the above behaviour unsyncs the flags and the thumbnail is not shown properly anymore (in Samsung Gallery app). -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 400492] Rotation does not work
https://bugs.kde.org/show_bug.cgi?id=400492 --- Comment #6 from Milan Knížek --- One app is confused with out of sync orientation flag - the default Gallery app in Samsung S7. It displays the embedded thumbnail as per Exif.Image.Orientation and ignores Exif.Thumbnail.Orientation. It is probably Samsung's bug, but anyway, wouldn't it be safer to have the image and embedded thumbnail orientation in sync? -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 400492] Rotation does not work
https://bugs.kde.org/show_bug.cgi?id=400492 --- Comment #5 from Milan Knížek --- This one works again. However, I am still wondering if it is a problem that even after rotation (which sets the Orientation Flag to "Normal"), the flag for thumbnail is still reported as "rotated" (even after rebuilding the thumbnails): $ exiv2 -pa z2.jpg | grep -a rientat Exif.Image.Orientation Short 1 top, left Exif.Thumbnail.Orientation Short 1 right, top Xmp.tiff.Orientation XmpText 1 top, left It does not seem to cause problem in digiKam Preview view, in EOG, in Geeqie - all show the thumbnail properly. The Exif.Thumbnail.Orientation flag is removed when the image is edited in digiKam's editor and saved. Shouldn't it be either synced with the image orientation or removed also within Rotation actions in digiKam? -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 400492] Rotation does not work
https://bugs.kde.org/show_bug.cgi?id=400492 --- Comment #1 from Milan Knížek --- The prior version digikam-6.0.0-beta2-20181015T071907-x86-64.appimage seems to work as expected. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 400492] Rotation does not work
https://bugs.kde.org/show_bug.cgi?id=400492 Milan Knížek changed: What|Removed |Added Attachment #115991|The file names are |Sample files (The file description|self-explanatory|names are self-explanatory) -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 400492] New: Rotation does not work
https://bugs.kde.org/show_bug.cgi?id=400492 Bug ID: 400492 Summary: Rotation does not work Product: digikam Version: 6.0.0 Platform: Appimage OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Metadata-Orientation Assignee: digikam-bugs-n...@kde.org Reporter: kni...@volny.cz Target Milestone: --- Created attachment 115991 --> https://bugs.kde.org/attachment.cgi?id=115991&action=edit The file names are self-explanatory SUMMARY Rotation functionality does not seem to work properly. Use the attached images for testing. In Settings // Configure digiKam // Metadata // Rotation set "write normal flag orientation after rotate". Other settings as per attached screenshot. STEPS TO REPRODUCE Try to manually rotate left or right, autorotate, set orientation flag. OBSERVED RESULT The image either does not rotate at all or rotate somewhat unexpectedly. The orientation flag as per Item // Adjust Exif Orientation Tag remains as "rotated right", although exiv2 confirms that after rotation, the flags are "top, left". Rebuilding thumbnail (Tools // Maintenance) does not change this behaviour. On some images, the thumbnail orientation flag may become inconsistent with other orientation flags. EXPECTED RESULT The image visually rotates as per instruction, the thumbnail is rebuilt and orientation flag is set to normal in all metadata types (Exif, Thumbnail, TIFF, etc.). SOFTWARE VERSIONS digikam-6.0.0-beta2-20181030T031645-x86-64.appimage OTHER INFORMATION The inconsistency of orientation flag in metadata seems to have different impact on different actions (autorotate, rotate manually in Thumbnails view, in Preview View). -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 396961] Empty space on interface on thumbnail view
https://bugs.kde.org/show_bug.cgi?id=396961 --- Comment #19 from Milan Knížek --- Seems okay for me. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 396961] Empty space on interface on thumbnail view
https://bugs.kde.org/show_bug.cgi?id=396961 --- Comment #15 from Milan Knížek --- digikam-6.0.0-beta1-20180926T221226-x86-64.appimage Removing digikamrc helped only temporarily - the issue with a blank area in Thumbnail view reappeared again after a few starts of digikam (not sure what was the trigger). Playing with thumbnail dock location (displaying via righ-click and dragging by mouse to left) did not help either - in one case I even had the thumbnails bar on the left and an empty space on top. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 399237] New: Thumbnails view shows an empty dock for thumbnails
https://bugs.kde.org/show_bug.cgi?id=399237 Bug ID: 399237 Summary: Thumbnails view shows an empty dock for thumbnails Product: digikam Version: 6.0.0 Platform: Appimage OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Albums-MainView Assignee: digikam-bugs-n...@kde.org Reporter: kni...@volny.cz Target Milestone: --- Created attachment 115323 --> https://bugs.kde.org/attachment.cgi?id=115323&action=edit Redundant empty thumbnails dock area SUMMARY In thumbnails view, the thumbnails are shown in the main area. In addition, digikam shows an empty space in area where typically the thumbnail dock is shown. STEPS TO REPRODUCE 1. Start digikam 2. Select any album 3. Switch to thumbnails view OBSERVED RESULT In location where thumbnails dock (while in Preview mode) remains an empty space. It is possible to right-click on the area and activate "Digikam Thumbnail Dock", which displays the thumbnails in the bar, but which does not make much sense in Thumbnails view, however. EXPECTED RESULT The area of thumbnails dock is hidden and the main Thumbnails view occupies all available area. SOFTWARE VERSIONS (available in About System) KDE Plasma Version: ?? KDE Frameworks Version: 5.49.0 Qt Version: 5.9.6 The xcb windowing system ADDITIONAL INFORMATION The latest 6.0.0-beta1 appimage (the same bug exhibits since cca July-18). -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 286529] Face tag rectangles not adjusted after to apply aspect ratio crop tool
https://bugs.kde.org/show_bug.cgi?id=286529 Milan Knížek changed: What|Removed |Added CC||kni...@volny.cz --- Comment #12 from Milan Knížek --- (In reply to hardy.public from comment #11) > Given this is 7 years old, isn't the interim answer to remove all the face > regions after crop? I'd rather have no face regions than incorrect face > regions. As long as the face tags would remain assigned to that image (i.e. only the regions would be invalidated/deleted), that might be a reasonable interim solution. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 395518] When manually typing face name, sort the filtered tags by recent usage
https://bugs.kde.org/show_bug.cgi?id=395518 Milan Knížek changed: What|Removed |Added Resolution|--- |WORKSFORME Status|UNCONFIRMED |RESOLVED --- Comment #3 from Milan Knížek --- With the recent beta (6.0.0) the behaviour is consistent as described in Maik's response. (Not sure if anything else has changed, but it now "works for me".) -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 397001] The "maximise" button is missing in decoration of the geolocation editor window
https://bugs.kde.org/show_bug.cgi?id=397001 Milan Knížek changed: What|Removed |Added Resolution|WORKSFORME |--- Ever confirmed|0 |1 Status|RESOLVED|REOPENED --- Comment #3 from Milan Knížek --- That guy had a problem with Cinnamon, which may not be the same as standard GNOME. I have gnome-tweaks installed, disabled "attach modal dialogs" (so that the dialog window moves separately from the parent window), enabled Maximise and Minimise buttons for the title bar already. That said, Tweaks do not seem to offer a solution for me. You are right, that GNOME treats Geolocation Editor as a dialog window (in Alt+Tab switcher, I can see both digikam and editor as a single icon). Right-clicking on Editor's title bar shows both Maximise and Minimise greyed out (disabled), double click does not maximise the window. Note that the window has a title bar and the close button. I searched a bit more, but no resolution yet. This one suggests that Mac OS might deal with modal windows similarly like GNOME does: https://musescore.org/en/node/56931 P.S. Re-opening the bug if you do not mind. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 397001] New: The "maximise" button is missing in decoration of the geolocation editor window
https://bugs.kde.org/show_bug.cgi?id=397001 Bug ID: 397001 Summary: The "maximise" button is missing in decoration of the geolocation editor window Product: digikam Version: 6.0.0 Platform: Appimage OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: Geolocation-Editor Assignee: digikam-bugs-n...@kde.org Reporter: kni...@volny.cz Target Milestone: --- Hi, It would be usefull to have the editor opened in a standard window - with minimise, maximise and restore buttons, rather than the close button only. Currently, the window never opens maximised and it has to be manually resized ba dragging the window borders. Arch Linux, GNOME, AppImage 6.0.0 beta. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 395501] Cannot define top level Tag name for faces
https://bugs.kde.org/show_bug.cgi?id=395501 --- Comment #2 from Milan Knížek --- That sounds like a good approach and I may like it. After a few more tests: you are right, my problem is that digikam occassionally creates an empty /People tag (a left-over in some image(s) which appears to survive the tag deletion, although I have 'write metadata to image & sidecar' active - I will have to solve that separately). But anyway, would it make sense to modify the behaviour to create new face tags under the tree where the most faces are? That is to ignore /People if it is not used at all (or even not so much)? -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 395518] When manually typing face name, sort the filtered tags by recent usage
https://bugs.kde.org/show_bug.cgi?id=395518 --- Comment #2 from Milan Knížek --- Hm. Isn't it that it shows the tags in the order of best match (to face)? I do not seem to get a consistent behaviour. (Alphabetical vs last use vs face match.) -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 395518] New: When manually typing face name, sort the filtered tags by recent usage
https://bugs.kde.org/show_bug.cgi?id=395518 Bug ID: 395518 Summary: When manually typing face name, sort the filtered tags by recent usage Product: digikam Version: 6.0.0 Platform: Other OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: Faces-Workflow Assignee: digikam-bugs-n...@kde.org Reporter: kni...@volny.cz Target Milestone: --- Hi, It would be usefull if there is an option to get the available face tags sorted by recent usage while typing into the face region tag field. That is, the most recently used tags would be shown on the first place. The current behaviour is alphabetical order. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 395501] New: Cannot define top level Tag name for faces
https://bugs.kde.org/show_bug.cgi?id=395501 Bug ID: 395501 Summary: Cannot define top level Tag name for faces Product: digikam Version: 6.0.0 Platform: Other OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: Faces-Workflow Assignee: digikam-bugs-n...@kde.org Reporter: kni...@volny.cz Target Milestone: --- Hi, There does not seem to be a method how to define the top level tag name for faces. The standard behaviour is to use language equivalent of "People" (not very good for those switching app language). It would be preferrable to let the user choose the top level folder, where the new (manually) created name tags would be assigned to. P.S. I temporarily succeeded by renaming "People" to "Regions", but that was not persistent. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 395263] GPSDOP is not shown in Geolocation editor image list and details tab
https://bugs.kde.org/show_bug.cgi?id=395263 --- Comment #1 from Milan Knížek --- (In reply to Milan Knížek from comment #0) a typo: > ... it is know shown in the image list pane and details tabe of the ... it is _not_ shown... -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 395263] New: GPSDOP is not shown in Geolocation editor image list and details tab
https://bugs.kde.org/show_bug.cgi?id=395263 Bug ID: 395263 Summary: GPSDOP is not shown in Geolocation editor image list and details tab Product: digikam Version: 6.0.0 Platform: Other OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: Geolocation-Editor Assignee: digikam-bugs-n...@kde.org Reporter: kni...@volny.cz Target Milestone: --- Hi, Although the image contains information about GPSDOP: $ exiv2 -pa *.jpg | grep -a "GPSDO" 20130717-143854.jpg Exif.GPSInfo.GPSDOP SRational 1 50/1 20130717-143854.jpg Exif.GPSInfo.GPSDOP SRational 1 50/1 ... it is know shown in the image list pane and details tabe of the Geolocation Editor (empty fields). P.S. The details tab can be used to modify a single image GPSDOP value, it gets saved, however on the next invocation of the Editor GPSDOP is not shown. digikam-6.0.0-git-20180610T092015-x86-64.appimage -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 395202] Cannot mass apply geolocation metadata in "Details" tab to multiple images
https://bugs.kde.org/show_bug.cgi?id=395202 --- Comment #9 from Milan Knížek --- The best solution would be if the Details tab behaves like the Tags: If multiple images with different GPS data are selected, the "tick" mark is semi-grey (selecting it would lead to override - either clear or set the same value; if untouched no change would be applied to images). If it is easier to implement, your suggestion to simply paste values to empty fields only would work for my use case, too. (Sometimes I do not have GPS data and do not care much about the exact location - I just need to place all images to some location on the map and set very low GPS precision (DOP) to indicate this is intentionally wrong.) P.S I will report the bug re. ignored GPSDOP value separately. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 395202] Cannot mass apply geolocation metadata in "Details" tab to multiple images
https://bugs.kde.org/show_bug.cgi?id=395202 --- Comment #7 from Milan Knížek --- Thanks for the AppImage, way easier than compiling in VM. However, the bug(s) are the same as described above. P.S. The AppImage seems partially broken: $ ./digikam-6.0.0-git-20180610T092015-x86-64.appimage -- digiKam AppImage Bundle -- Use 'help' as CLI argument to know all available options for digiKam application digikam: symbol lookup error: /usr/lib/libfontconfig.so.1: undefined symbol: FT_Done_MM_Var Preloading local version seems to work: $ LD_PRELOAD=/usr/lib/libfreetype.so ./digikam-6.0.0-git-20180610T092015-x86-64.appimage Uncle Google says there is something wrong with fontconfig versions: https://forum.manjaro.org/t/unable-to-start-appimage-usr-lib-libfontconfig-so-1-undefined-symbol-ft-done-mm-var/46611/5 -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 395202] Cannot mass apply geolocation metadata in "Details" tab to multiple images
https://bugs.kde.org/show_bug.cgi?id=395202 --- Comment #5 from Milan Knížek --- (In reply to caulier.gilles from comment #1) > Did you try "Item/Edit Geolocation" menu ? Yes, that's how I edit the geolocation. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 395202] Cannot mass apply geolocation metadata in "Details" tab to multiple images
https://bugs.kde.org/show_bug.cgi?id=395202 --- Comment #4 from Milan Knížek --- I checked in CLI, that only the single image has a new GPSDOP value, the others remained untouched by DigiKam // Geolocation editor. Even more, when I open the Geolocation editor again, then no GPSDOP value is shown in the image list - as if there was no value. $ exiv2 -pa 20170304_153820.jpg | grep -a "GPSDOP" $ exiv2 -pa 20170304_154107.jpg | grep -a "GPSDOP" Exif.GPSInfo.GPSDOP SRational 1 5/1 Xmp.exif.GPSDOP XmpText 3 5/1 -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 395202] Cannot mass apply geolocation metadata in "Details" tab to multiple images
https://bugs.kde.org/show_bug.cgi?id=395202 --- Comment #3 from Milan Knížek --- Created attachment 113187 --> https://bugs.kde.org/attachment.cgi?id=113187&action=edit GPS editing - after applying the new DOP value - only a single image is affected. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 395202] Cannot mass apply geolocation metadata in "Details" tab to multiple images
https://bugs.kde.org/show_bug.cgi?id=395202 --- Comment #2 from Milan Knížek --- Created attachment 113186 --> https://bugs.kde.org/attachment.cgi?id=113186&action=edit GPS editing - before applying the new DOP value (all images selected). -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 395202] New: Cannot mass apply geolocation metadata in "Details" tab to multiple images
https://bugs.kde.org/show_bug.cgi?id=395202 Bug ID: 395202 Summary: Cannot mass apply geolocation metadata in "Details" tab to multiple images Product: digikam Version: 5.9.0 Platform: Archlinux Packages OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: Geolocation-Editor Assignee: digikam-bugs-n...@kde.org Reporter: kni...@volny.cz Target Milestone: --- Hi, In Geolocation editor Details tab the user can manually edit the metadata like DOP. Unfortunatelly, after hitting Apply, the data are applied only to a single image, not to all selected imaged in the editor. Manual Copy&Paste coordinates from righ-click menu on image does not copy the other GPS metadata either. Batch processor does not seem to offer mass GPS metadata modification, too. As a result, setting DOP for hundreds of images is nearly impossible. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 303062] Add image direction in Map module (from EXIF of geotagging pictures with compass heading))
https://bugs.kde.org/show_bug.cgi?id=303062 Milan Knížek changed: What|Removed |Added CC||kni...@volny.cz --- Comment #7 from Milan Knížek --- Mee too - Eric described it very well! I got the Solmeta MAX-EOS but I use it only as a logger on my Olympus camera (Solmeta supports only Nikon & Canon) - the data are stored as NMEA log. Apart from digiKam not handling the GPSImgDirection tag yet, there is a problem that GPX standard does not define heading at all (older version did define course, but that's not the same as heading). So digiKam should allow to GPS Correlate also from other file types (various NMEA data, possibly others). -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 126149] Album icon view stores both jpeg and raw (nef), handle both as one [patch]
https://bugs.kde.org/show_bug.cgi?id=126149 Milan Knížek changed: What|Removed |Added CC|kni...@volny.cz | -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 318661] Send by mail tool does not convert to sRGB and strips existing ICC profile
https://bugs.kde.org/show_bug.cgi?id=318661 Milan Knížek changed: What|Removed |Added Platform|Other |Archlinux Packages --- Comment #4 from Milan Knížek --- Not sure when things changed, but currently digikam at least converts the image to sRGB, strips the profile and sets the JPEG tag to sRGB as well. So it seems "FIXED". -- You are receiving this mail because: You are watching all bug changes.
[kipiplugins] [Bug 377306] New: Optionally remove all metadata
https://bugs.kde.org/show_bug.cgi?id=377306 Bug ID: 377306 Summary: Optionally remove all metadata Product: kipiplugins Version: 5.4.0 Platform: Other OS: Linux Status: UNCONFIRMED Severity: wishlist Priority: NOR Component: SendImages Assignee: kde-imag...@kde.org Reporter: kni...@volny.cz Target Milestone: --- It is usefull to remove metadata from photos on-the-fly while emailing them. At the moment, it seems to be possible to remove metadata in batch manager of digikam: https://bugs.kde.org/show_bug.cgi?id=169230 However, this is clumsy as the user needs to create redundant copies and delete them manually after emailing. The candidates for removal are: * all metadata (like mogrify -strip image.jpeg) * privacy metadata (like geolocation, comments, copyright, tags, etc. leaving only technical metadata about the camera). -- You are receiving this mail because: You are watching all bug changes.
[kipiplugins] [Bug 377306] Optionally remove all metadata
https://bugs.kde.org/show_bug.cgi?id=377306 Milan Knížek changed: What|Removed |Added CC||kni...@volny.cz -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 365375] New: Open with... ignores parameters of Exec line in Desktop Entry
https://bugs.kde.org/show_bug.cgi?id=365375 Bug ID: 365375 Summary: Open with... ignores parameters of Exec line in Desktop Entry Product: digikam Version: 5.0.0 Platform: Archlinux Packages OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: Thumbnails Assignee: digikam-de...@kde.org Reporter: kni...@volny.cz Hi, it seems digiKam cannot run complete "Exec" keyword line from Linux Desktop Entry [1] file anymore. [1] https://specifications.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html In particular, the example line could be: Exec=/usr/bin/xterm -hold -e /usr/local/bin/myscript.sh %f What digikam actually runs seems to be: /usr/bin/xterm %f This bug does not appear when the Exec is run from a file manager (Caja in MATE desktop), only from within digiKam. Reproducible: Always Steps to Reproduce: 1. Create a simple Desktop file in $HOME/.local/share/applications: [Desktop Entry] Exec=/usr/bin/xterm -hold -e /usr/local/bin/myscript.sh %f MimeType=image/jpeg;image/x-canon-cr2;image/x-canon-crw;image/x-panasonic-raw;image/x-panasonic-raw2;image/x-olympus-raw ;image/x-olympus-orf Name=Do Something Type=Application Terminal=No NoDisplay=Yes Icon=camera-photo-symbolic 2. Create the script in /usr/local/bin/myscript.sh and make it executable #!/bin/bash echo $@ exit 3. Run digiKam, right-click on a JPEG file and choose Open with... / Do Something Actual Results: 4. Nothing happens in GUI. 5. On CLI digiKam spits a message: xterm: No absolute path found for shell: /path/to/your/albums/somephoto.jpg Which means that xterm expects a path, not a file. This is the std error when no options (-parameters) are given to xterm command. Expected Results: 6. To test that otherwise things work, run from CLI the contents of the Exec line (with some path/to/image.jpg) or from your file manager (via right-click Open with...). A new window with xterm opens and shows the full path to the image name. It used to work in the past... (Probably still with the old version of digiKam 4.x.x.) -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 360474] Initial setup: Splash shows "Loading tools..." but it is scanning images
https://bugs.kde.org/show_bug.cgi?id=360474 Milan Knížek changed: What|Removed |Added CC||kni...@volny.cz --- Comment #5 from Milan Knížek --- Sorry for commenting the closed bug: @Gilles: So, do I understand correctly that the initial scanning of albums actually scans the directories only? After boot, it takes some time before GUI is shown (1379 dirs, up to one minute). Next start of digiKam is almost immediate, I assume that the dirs are cached by the kernel already. It probably depends on HDD and filesystem type, but yet, it would be good if this directory parsing can be postponed to a later stage - the initial album list can be taken from the database and it could be updated on the fly after the directory structure is read. -- 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
https://bugs.kde.org/show_bug.cgi?id=360462 Milan Knížek changed: What|Removed |Added CC||kni...@volny.cz --- Comment #5 from Milan Knížek --- I wonder why this is marked as duplicate of bug 184833 which suggest "drag&drop" as one of wanted features for the geo-map sidebar in the album view. This bug is about Geo-tagging window, where this functionality used to work for Google Maps & OSM in the past already and it still works at least for OSM in digiKam 5.0. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 358486] New: Pressing ENTER while in Search Box of Geolocation closes the window instead of searching the location
https://bugs.kde.org/show_bug.cgi?id=358486 Bug ID: 358486 Summary: Pressing ENTER while in Search Box of Geolocation closes the window instead of searching the location Product: digikam Version: 5.0.0 Platform: Archlinux Packages OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: Geolocation Assignee: digikam-de...@kde.org Reporter: kni...@volny.cz The title says it all. Reproducible: Always Steps to Reproduce: 1. Select image in thumbnail view 2. Select Edit // Edit Geolocation 3. Switch to Search tab 4. Type some address in the search bar (OSM engine is preselected) 5. Press ENTER to carry out the search and get some results Actual Results: The Geolocation window closes suddenly, probably because pressing ENTER is the same as mouse clicking on "Close" button. Expected Results: When the cursor is in the search bar, pressing ENTER should be the same as mouse click on "Search" button. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 357738] Item // Edit Geolocation window does not remember its size
https://bugs.kde.org/show_bug.cgi?id=357738 --- Comment #3 from Milan Knížek --- Ok. Since it is not clear from your answers, I hope that if not position, then at least the size of the Geolocation-dialog window is remembered. It would help the user to save a mouse-click every time opening the dialog. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 357738] New: Item // Edit Geolocation window does not remember its size
https://bugs.kde.org/show_bug.cgi?id=357738 Bug ID: 357738 Summary: Item // Edit Geolocation window does not remember its size Product: digikam Version: 5.0.0 Platform: Archlinux Packages OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: Geolocation-Editor Assignee: digikam-de...@kde.org Reporter: kni...@volny.cz Choosing menu Item // Edit Geolocation opens a new window in the middle of the screen. The window does not have "minimise", "maximise" buttons in the window frame, although manual resizing is possible. After closing the window and opening it again, the window is sized and located the same as before. Proposal: add basic "mix", "max" buttons to the top bar of window frame and set the frame to remember its last position. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 354745] Thumbnails not shown in album view after startup
https://bugs.kde.org/show_bug.cgi?id=354745 Milan Knížek changed: What|Removed |Added Resolution|BACKTRACE |WONTFIX --- Comment #6 from Milan Knížek --- I eventually installed ver. 5 beta 2 rc and there the bug with "no images" does not exhibit. Assuming that final release is not so far, I propose to close as "won't fix". -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 354745] Thumbnails not shown in album view after startup
https://bugs.kde.org/show_bug.cgi?id=354745 --- Comment #5 from Milan Knížek --- I tried running digikam in Ubuntu 15.10 (Unity, w/o KDE unless pulled in as a digikam dependency) and it indeed works there just fine. At the moment, I am not able to recompile KDE stuff on Arch Linux to support debug trace, but I will try a bit harder again and get back then. -- You are receiving this mail because: You are watching all bug changes.
