[digikam] [Bug 485591] New: Many windows, UI elements are unusably small on high DPI screens
https://bugs.kde.org/show_bug.cgi?id=485591 Bug ID: 485591 Summary: Many windows, UI elements are unusably small on high DPI screens Classification: Applications Product: digikam Version: 8.3.0 Platform: Kubuntu OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Usability-Ergonomy Assignee: digikam-bugs-n...@kde.org Reporter: barn...@waterpigs.co.uk Target Milestone: --- Created attachment 168552 --> https://bugs.kde.org/attachment.cgi?id=168552&action=edit renaming template selection window unusably small SUMMARY When using the DigiKam 8.3.0 AppImage on a laptop with a high DPI screen, many windows and UI elements are so small as to be near-unusable by default. Some of these (window sizes) can be mitigated by the user by resizing them, but in many cases this must be done every single time the window is opened. Other non-resizable UI elements cannot be mitigated like this. These occur regardless of whether the “use high DPI scaling from the screen factor” setting is enabled, and regardless of the application font size (in my case Noto Sans at 12). Adjusting the app’s QT Scale Factor (e.g. to 1.5 or 2) via an environment variable in the .desktop file results in everything being much too large. The UI is correctly scaled in non-AppImage versions, but I ended up needing to use AppImage digiKam to get access to a newer version than the packaged version available on current kubuntu. SOFTWARE/OS VERSIONS digiKam 8.3.0 Build date: 14/03/2024 17:13 (target: RelWithDebInfo) Revision: 9e9222fa4002acf2fcca6741b79260f01817eb30 Branch: HEAD Operating System: Kubuntu 23.10 KDE Plasma Version: 5.27.8 KDE Frameworks Version: 5.110.0 Qt Version: 5.15.10 Kernel Version: 6.5.0-27-generic (64-bit) Graphics Platform: Wayland Processors: 20 × 12th Gen Intel® Core™ i7-12700H Memory: 31.1 GiB of RAM Graphics Processor: Mesa Intel® Graphics -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 485591] Many windows, UI elements are unusably small on high DPI screens
https://bugs.kde.org/show_bug.cgi?id=485591 --- Comment #1 from Barnaby --- Created attachment 168553 --> https://bugs.kde.org/attachment.cgi?id=168553&action=edit import images from files window much too small -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 485591] Many windows, UI elements are unusably small on high DPI screens
https://bugs.kde.org/show_bug.cgi?id=485591 --- Comment #2 from Barnaby --- Created attachment 168554 --> https://bugs.kde.org/attachment.cgi?id=168554&action=edit image editor filter options unreadable -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 485591] Many windows, UI elements are unusably small on high DPI screens
https://bugs.kde.org/show_bug.cgi?id=485591 --- Comment #3 from Barnaby --- Created attachment 168555 --> https://bugs.kde.org/attachment.cgi?id=168555&action=edit image editor crop grab handles unusably small (mouse pointer in the position shown is not close enough to grab onto them) -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 485591] Many windows, UI elements are unusably small on high DPI screens
https://bugs.kde.org/show_bug.cgi?id=485591 --- Comment #4 from Barnaby --- Created attachment 168556 --> https://bugs.kde.org/attachment.cgi?id=168556&action=edit font selection window unusably small -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 485591] Many windows, UI elements are unusably small on high DPI screens
https://bugs.kde.org/show_bug.cgi?id=485591 --- Comment #5 from Barnaby --- Created attachment 168557 --> https://bugs.kde.org/attachment.cgi?id=168557&action=edit renaming window template selection buttons have no padding -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 485591] Many windows, UI elements are unusably small on high DPI screens
https://bugs.kde.org/show_bug.cgi?id=485591 --- Comment #6 from Barnaby --- Created attachment 168558 --> https://bugs.kde.org/attachment.cgi?id=168558&action=edit renaming window EXIF property selection checkboxes unusably small, not checked when clicking on property name -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 485593] New: Map view cannot zoom in far enough to be useful
https://bugs.kde.org/show_bug.cgi?id=485593 Bug ID: 485593 Summary: Map view cannot zoom in far enough to be useful Classification: Applications Product: digikam Version: 8.3.0 Platform: Kubuntu OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Geolocation-Workflow Assignee: digikam-bugs-n...@kde.org Reporter: barn...@waterpigs.co.uk Target Milestone: --- Created attachment 168559 --> https://bugs.kde.org/attachment.cgi?id=168559&action=edit maximum zoom level SUMMARY The map view’s maximum zoom level is still much too far out to be useful in many cases. With the map sidebar resized to a usable width, the furthest I can zoom in still shows an area 90km wide! As is visible in the screenshot, I have more than 2000 photos in the smallest viewable map area, so it’s not very helpful for filtering. I would suggest allowing the map view to be zoomed in at least 10x the current amount, ideally to a similar zoom level as the open street map website (1m ≈ 4px on my screen). -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 485593] Map view cannot zoom in far enough to be useful
https://bugs.kde.org/show_bug.cgi?id=485593 Barnaby changed: What|Removed |Added Platform|Kubuntu |Appimage -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 485593] Map view cannot zoom in far enough to be useful
https://bugs.kde.org/show_bug.cgi?id=485593 --- Comment #2 from Barnaby --- oh that’s much better, thanks! Two questions: is the OSM version not the default because it can only be used when online? for the offline maps, presumably it’s the tile resolution which is the limiting factor? personally I’d expect to be able to zoom further in even if that resulted in pixellated map tiles (at which point I might realise that they‘re low-resolution offline tiles and go looking for different ones). Having the zoom level limited by default makes me assume that the limitation is with the app, not the map tile source. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 485591] Many windows, UI elements are unusably small on high DPI screens
https://bugs.kde.org/show_bug.cgi?id=485591 --- Comment #8 from Barnaby --- Created attachment 168570 --> https://bugs.kde.org/attachment.cgi?id=168570&action=edit QT_SCALE_FACTOR=1.5 photo list -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 485591] Many windows, UI elements are unusably small on high DPI screens
https://bugs.kde.org/show_bug.cgi?id=485591 --- Comment #9 from Barnaby --- Created attachment 168571 --> https://bugs.kde.org/attachment.cgi?id=168571&action=edit QT_SCALE_FACTOR=1.5 default image editor size -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 485591] Many windows, UI elements are unusably small on high DPI screens
https://bugs.kde.org/show_bug.cgi?id=485591 --- Comment #10 from Barnaby --- Created attachment 168572 --> https://bugs.kde.org/attachment.cgi?id=168572&action=edit QT_SCALE_FACTOR=1.5 enlarged image editor window -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 485591] Many windows, UI elements are unusably small on high DPI screens
https://bugs.kde.org/show_bug.cgi?id=485591 --- Comment #11 from Barnaby --- I added some reference screenshots launching digiKam with QT_SCALE_FACTOR=1.5. Generally speaking the sizes of icons and UI elements is better, but default window sizes and icon spacing are just as bad. I changed the application font size to 9 which improves things slightly, but it’s still borderline unusable IMO. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 485591] Many windows, UI elements are unusably small on high DPI screens
https://bugs.kde.org/show_bug.cgi?id=485591 --- Comment #14 from Barnaby --- (In reply to caulier.gilles from comment #13) > The digiKam 8.4.0 Appimage bundle pre-release is now based on last modern > frameworks Qt 6.7.0 and KDE 6.2.0. > > Can you reproduce the dysfonction with this version? This version is definitely better! A lot of the windows which were previously unusably small by default (e.g. the font selection one) are now slightly larger – still undersize IMO, but usable without having to resize them every single time. The sidebar buttons in the main window are still all cut off (the text for ”Tags” doesn’t show up at all, only the tags icon). Opening the image editor for the first time on the new version, it started with the right tools sidebar taking up most of the screen, with the photo being squashed down to a tiny thumbnail. When the sidebar is resized to only take up ~20% of the screen, the tool icons are still readable and stack much better. IMO they’re unnecessarily spaced out (there are huge, unclickable gutters between them which IIRC were not in the non-flatpak version) but it is readable and usable. I was hoping that this update might also fix the issues I’ve been having dragging+dropping photos into some other applications, but sadly it’s still very unreliable. I can make a separate bug for that if there isn’t one already. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 485591] Many windows, UI elements are unusably small on high DPI screens
https://bugs.kde.org/show_bug.cgi?id=485591 --- Comment #15 from Barnaby --- Created attachment 168750 --> https://bugs.kde.org/attachment.cgi?id=168750&action=edit 8.4.0 Qt6 Main View unreadable sidebar icons -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 485591] Many windows, UI elements are unusably small on high DPI screens
https://bugs.kde.org/show_bug.cgi?id=485591 --- Comment #16 from Barnaby --- Created attachment 168751 --> https://bugs.kde.org/attachment.cgi?id=168751&action=edit 8.4.0 Qt6 image editor resized toolbar spaced-out tool icons -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 485591] Many windows, UI elements are unusably small on high DPI screens
https://bugs.kde.org/show_bug.cgi?id=485591 --- Comment #17 from Barnaby --- Ah I also noticed that this latest build seems to have a custom pointer set, which can be seen in my latest screenshots (compare with the default KDE Breeze pointer in the older screenshots). Not sure if that is intentional or not, but I prefer that applications use the system pointers unless they have some good reason not to. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 485246] New: Main photo view shows original and all versions of edited photos even when the corresponding settings are disabled
https://bugs.kde.org/show_bug.cgi?id=485246 Bug ID: 485246 Summary: Main photo view shows original and all versions of edited photos even when the corresponding settings are disabled Classification: Applications Product: digikam Version: 8.1.0 Platform: Kubuntu OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: ImageEditor-Save Assignee: digikam-bugs-n...@kde.org Reporter: barn...@waterpigs.co.uk Target Milestone: --- STEPS TO REPRODUCE 1. Disable the Settings -> Image Editor -> Versioning -> In Main View -> ”Always show original image” and ”Always show intermediate snapshots” settings 2. Open an image in the Image Editor 3. Make any change e.g. a crop 4. Click “Save Changes“ or “Save Changes as a new version” (both exhibit the exact same behaviour) OBSERVED RESULT Both the original and the edited image are shown in the photo list, rather than only the edited version. The edited version has _v1 appended to the file name. It does NOT occur when non-destructive editing is disabled entirely - in that case, the image editor simply overwrites the original as expected. EXPECTED RESULT Only the final edited version of the photo should be visible in the main view, no original, duplicates or intermediate stages. SOFTWARE/OS VERSIONS Operating System: Kubuntu 23.10 KDE Plasma Version: 5.27.8 KDE Frameworks Version: 5.110.0 Qt Version: 5.15.10 Kernel Version: 6.5.0-26-generic (64-bit) Graphics Platform: Wayland Processors: 20 × 12th Gen Intel® Core™ i7-12700H -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 485246] Main photo view shows original and all versions of edited photos even when the corresponding settings are disabled
https://bugs.kde.org/show_bug.cgi?id=485246 --- Comment #2 from Barnaby --- > It is possible that your "original" image is not an original and already has > an image history, then it will not be hidden. Interesting, how do I tell if this is the case? as far as I can remember, this has been the same every time I edit and save a photo, whether it’s fresh off the camera or if I’ve already edited it. Even if the image I’m editing already has a history, surely one of “Save” or ”Save as new version” should save it in a way which doesn’t appear to duplicate it? -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 485246] Main photo view shows original and all versions of edited photos even when the corresponding settings are disabled
https://bugs.kde.org/show_bug.cgi?id=485246 --- Comment #4 from Barnaby --- I tried it again now and this time the ”Save” option worked exactly as I expected, which definitely wasn’t the case last time. Could it be that changing version visibility settings requires a restart of the app or computer in order to take effect? I’m pretty sure I restarted DigiKam after changing the settings while testing for this bug without seeing any difference. Tangentially related: when DigiKam is configured to not show original photos if an edited one is present, is there a way of easily reverting the photo to a previous state? The Versions sidebar seems to only show versions, but not allow any actions to be taken on them. Also, the documentation claims https://docs.digikam.org/en/setup_application/editor_settings.html#image-versioning-settings that only showing the most recent edit in the main view is the default setting, which I agree is a sensible default. However that wasn‘t the case for me, on Kubuntu DigiKam came with both ”In Main View” checkboxes checked, which is a big part of what led to this confusion. -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 476881] File list isn’t correctly refreshed on scroll
https://bugs.kde.org/show_bug.cgi?id=476881 --- Comment #3 from Barnaby --- One way I’ve found to 100% reproduce this is to use the preview sidebar to play a WAV file. Doing so always causes this exact rendering glitch on my computer. -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 480018] New: Files ripped from a CD are read-only
https://bugs.kde.org/show_bug.cgi?id=480018 Bug ID: 480018 Summary: Files ripped from a CD are read-only Classification: Applications Product: dolphin Version: 23.08.1 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: dolphin-bugs-n...@kde.org Reporter: barn...@waterpigs.co.uk CC: kfm-de...@kde.org Target Milestone: --- SUMMARY When using Dolphin to rip files from a CD, the files retain their read-only permissions once copied to the user’s disk. This can cause confusion when e.g. using tools like Picard to tag and rename files, as it will complain that the files are “corrupted or inaccessible”. I would expect ripped files to be given the same permissions as any other files created in Dolphin. STEPS TO REPRODUCE 1. Open CD in Dolphin 2. Drag files off it into folder on disk OBSERVED RESULT The files are read-only EXPECTED RESULT The files have the same permissions as any new file created by dolphin (rw-rw-r--) SOFTWARE/OS VERSIONS Operating System: Kubuntu 23.10 KDE Plasma Version: 5.27.8 KDE Frameworks Version: 5.110.0 Qt Version: 5.15.10 Kernel Version: 6.5.0-14-generic (64-bit) Graphics Platform: Wayland Processors: 20 × 12th Gen Intel® Core™ i7-12700H Memory: 31.1 GiB of RAM ADDITIONAL INFORMATION -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 476881] New: File list isn’t correctly refreshed on scroll
https://bugs.kde.org/show_bug.cgi?id=476881 Bug ID: 476881 Summary: File list isn’t correctly refreshed on scroll Classification: Applications Product: dolphin Version: 23.08.1 Platform: Kubuntu OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: dolphin-bugs-n...@kde.org Reporter: barn...@waterpigs.co.uk CC: kfm-de...@kde.org Target Milestone: --- Created attachment 163076 --> https://bugs.kde.org/attachment.cgi?id=163076&action=edit broken rendering after having switched between view modes SUMMARY In some cases, both the dolphin application and the dolphin file picker called from other applications (e.g. to upload files from firefox) stops rendering the file list correctly, only refreshing a small portion of the screen when scrolling, changing location etc. STEPS TO REPRODUCE I haven’t managed to find a 100% reliable way of reproducing this yet. It definitely happens most often in file pickers called from Firefox, but I have seen it in the standalone Dolphin app too. In some cases it seems to be folder-specific, where one folder will work file, then I move to a folder which triggers the bug (often my Downloads folder), and from then on the UI is broken. Resizing the window causes a full-window refresh, but rendering is broken again as soon as I scroll. The rendering issue happens in all view modes, and, once triggered, persists when switching view modes. OBSERVED RESULT Broken rendering EXPECTED RESULT Normal rendering SOFTWARE/OS VERSIONS Operating System: Kubuntu 23.10 KDE Plasma Version: 5.27.8 KDE Frameworks Version: 5.110.0 Qt Version: 5.15.10 Kernel Version: 6.5.0-10-generic (64-bit) Graphics Platform: Wayland Processors: 20 × 12th Gen Intel® Core™ i7-12700H Memory: 31.1 GiB of RAM Graphics Processor: Mesa Intel® Graphics -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 476881] File list isn’t correctly refreshed on scroll
https://bugs.kde.org/show_bug.cgi?id=476881 --- Comment #1 from Barnaby --- Created attachment 163077 --> https://bugs.kde.org/attachment.cgi?id=163077&action=edit broken rendering after scrolling -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 476881] File list isn’t correctly refreshed on scroll
https://bugs.kde.org/show_bug.cgi?id=476881 --- Comment #2 from Barnaby --- Created attachment 163078 --> https://bugs.kde.org/attachment.cgi?id=163078&action=edit multi-layered broken rendering after switching view mode and scrolling -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 321171] When in detail view: Pasting of copied files using the keyboard copies the file into the parent folder instead of the selected (highlighted) folder.
https://bugs.kde.org/show_bug.cgi?id=321171 Barnaby changed: What|Removed |Added CC||barn...@waterpigs.co.uk --- Comment #3 from Barnaby --- Apologies for the necrobump, I was just about to file a duplicate of this bug and assumed that continuing discussion here would be more appropriate. I too would expect control+V when a subfolder is selected in details mode to paste the item there, with the same result as having right-clicked on the subfolder and selected “Paste Here” (for which there is no default keyboard shortcut). I’m coming from a decade of using mac os finder‘s miller column view, where it is always very clear exactly where you are in the hierarchy and what result your actions will have. It is very annoying to select the location for an item, to paste it, have it not show up (because it was pasted to the parent folder and has ended up far off-screen), and then have to either right click and ”Paste Here” then delete the unwanted file, or to have to move it with the mouse, when dolphin doesn’t seem to support simultaneous dragging and scrolling. However, I can see how changing this could cause just as much inconsistent or unexpected behaviour, such as files getting lost in an off-screen selected subfolder when you actually want them copied to the parent folder. Re-implementing miller columns per bug 381187 would be my preferred solution to this (and the many, many other Dolphin usability issues which frustrate me daily), but obviously that’s a lot of work which nobody wants to do. Perhaps setting a default keyboard shortcut for ”Paste Here” could help for this particular issue? -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 321171] When in detail view: Pasting of copied files using the keyboard copies the file into the parent folder instead of the selected (highlighted) folder.
https://bugs.kde.org/show_bug.cgi?id=321171 --- Comment #4 from Barnaby --- While experimenting with this, I found one related inconsistency: pressing F10 (create new folder) with a subfolder selected in detail mode will create a new folder in the window location, not the selected subfolder. However, when right-clicking on a subfolder and selecting Create New -> Folder, the new folder will be created in the subfolder as expected. That’s fine as it is, however the subfolder context menu Create New -> Folder item displays the F10 shortcut tooltip, despite the two having different results. This seems inconsistent with the control+v vs context menu Paste Here UI, and IMO is another flaw of detail mode. Unsure if this is worth reporting as a separate bug, any opinions? -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kded] [Bug 465646] Run kbuildsycoca5 automatically upon manual changes to files in ~/.local/share/applications
https://bugs.kde.org/show_bug.cgi?id=465646 Barnaby changed: What|Removed |Added CC||barn...@waterpigs.co.uk --- Comment #4 from Barnaby --- I ran into the same issue recently when making a custom .desktop file to open an application with the correct UI scaling for my screen. My problem-oriented summary of the issue would be as follows: When moving, saving or otherwise updating a .desktop file in ~/.local/share/applications, I expect the DE to automatically detect the change and update itself, exactly as it does when adding custom service menus in ~/.local/share/kio/servicemenus. In my case, adding and changing a .desktop file in ~/.local/share/applications had no immediate effect, and (not knowing about kbuildsycoca5 and not being able to find any GUI for refreshing a cache) I had to reboot my computer for the changes to take effect. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kded] [Bug 465646] Run kbuildsycoca5 automatically upon manual changes to files in ~/.local/share/applications
https://bugs.kde.org/show_bug.cgi?id=465646 --- Comment #5 from Barnaby --- (In reply to Nate Graham from comment #3) > I think this situation falls into the "I know just enough to hurt myself" > valley. :) > > If you know the technical details about what .desktop files are and the > hidden location where they live, it's expected that you also know to run > kbuildsycoca5 manually (or just restart the system) after making changes. If > you don't know to do that, then the expected UX is to use KMenuEdit, which > handles running kbuildsycoca5 for you. In the case of Dolphin context menus, this is not the case according to the documentation: https://develop.kde.org/docs/apps/dolphin/service-menus/, which proudly (and, for context menus, correctly) states “you don't need to be a software developer to create new actions”. kbuildsycoca5 isn’t mentioned on the entire page. Presumably the folders for context menu .desktop files are watched and automatically updated, which led me to assume that all common locations for .desktop files are similarly watched and updated. -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 387455] Column view in Dolphin
https://bugs.kde.org/show_bug.cgi?id=387455 Barnaby changed: What|Removed |Added CC||barn...@waterpigs.co.uk -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 474507] New: Mouseover item overrides item currently selected via keyboard for preview
https://bugs.kde.org/show_bug.cgi?id=474507 Bug ID: 474507 Summary: Mouseover item overrides item currently selected via keyboard for preview Classification: Applications Product: dolphin Version: 22.12.3 Platform: Kubuntu OS: Linux Status: REPORTED Severity: minor Priority: NOR Component: panels: information Assignee: dolphin-bugs-n...@kde.org Reporter: barn...@waterpigs.co.uk CC: kfm-de...@kde.org Target Milestone: --- SUMMARY At least in Details mode, with the preview sidebar open: any item currently under the mouse cursor has permanent preview priority, even if you use the keyboard to change the current selection to a different item. STEPS TO REPRODUCE 1. In a folder with several files, click once with the cursor to select one. The preview sidebar shows a preview and information for it 2. Using the arrow keys, move the selection up and down to different files, while leaving the cursor in place OBSERVED RESULT The preview/info sidebar still shows info and a preview for the file under the cursor, even when a different file was more recently selected via the keyboard. EXPECTED RESULT When the current selection was updated using the keyboard more recently than the last mouseover event, the currently selected item should be shown in the preview bar, not the one which happens to be under the mouse cursor. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Kubuntu 23.04 KDE Plasma Version: 5.27.4 KDE Frameworks Version: 5.104.0 Qt Version: 5.15.8 -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 476881] File list isn’t correctly refreshed on scroll
https://bugs.kde.org/show_bug.cgi?id=476881 --- Comment #5 from Barnaby --- (In reply to David Edmundson from comment #4) > I recall a bug triggering this in our media preview libraries, can you > confirm if this bug is still valid? I haven’t run into this for a while now and trying to preview various different file types which seemed to lead to the problem before works fine now, so perhaps it’s fixed as of my current software version: Operating System: Kubuntu 24.04 KDE Plasma Version: 5.27.11 KDE Frameworks Version: 5.115.0 Qt Version: 5.15.13 -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 503173] New: Option to order People tags by quantity
https://bugs.kde.org/show_bug.cgi?id=503173 Bug ID: 503173 Summary: Option to order People tags by quantity Classification: Applications Product: digikam Version: unspecified Platform: Other OS: Linux Status: REPORTED Severity: wishlist Priority: NOR Component: Faces-Workflow Assignee: digikam-bugs-n...@kde.org Reporter: barn...@waterpigs.co.uk Target Milestone: --- In the People/Facial Recognition sidebar, all person tags are ordered alphabetically (after the special Unconfirmed/Unknown/Ignored tags). It would be very useful to have an additional “Quantity” column in that table, and to be able to sort by it, so that the most commonly tagged people are at the top. -- You are receiving this mail because: You are watching all bug changes.
[korganizer] [Bug 449024] Unable to fetch google calendar events
https://bugs.kde.org/show_bug.cgi?id=449024 Terry Barnaby changed: What|Removed |Added CC||te...@beam.ltd.uk --- Comment #11 from Terry Barnaby --- Same issue on Fedora35, recently stopped working. -- You are receiving this mail because: You are watching all bug changes.
[korganizer] [Bug 449024] Unable to fetch google calendar events
https://bugs.kde.org/show_bug.cgi?id=449024 --- Comment #12 from Terry Barnaby --- Actually it may be a slightly different bug on Fedora35 this is using kdepim-runtime-21.08.3-2.fc35.x86_64.rpm and looking at the code the "m_handlers.push_back(GenericHandler::Ptr(new ContactHandler(m_iface, m_settings)));" line as patched in the above patch is not present. Otherwise the result is the same: The calendar is in the Settings and you can use the restart button and the calendar is reported as Ready, but it does not appear in the KOganizer's main window bottom left panel and no calendar items appear. No error messages, just nothing happening (Oh why doesn't software print/display error messages and issue info these days :( ). Not sure where the Akonadi log mentioned above is, but the file ~.local/share/akonadi/Akonadi.error does not appear to have any errors reported. -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 422050] Scrolling issues with PageDown/PageUp navigation
https://bugs.kde.org/show_bug.cgi?id=422050 Terry Barnaby changed: What|Removed |Added CC||te...@beam.ltd.uk --- Comment #23 from Terry Barnaby --- Another person to add support to be able to disable this horrible animation. Simple and quick jump scrolling is much better for my usage and helps save the planet saving all those unnecessary CPU and graphics chip processing cycles. -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 422050] Scrolling issues with PageDown/PageUp navigation
https://bugs.kde.org/show_bug.cgi?id=422050 --- Comment #25 from Terry Barnaby --- Many thanks. I will build an RPM for our Fedora33 systems. -- You are receiving this mail because: You are watching all bug changes.
[kompare] [Bug 402363] File mode always set to 0600 when saving changes
https://bugs.kde.org/show_bug.cgi?id=402363 Terry Barnaby changed: What|Removed |Added CC||te...@beam.ltd.uk --- Comment #2 from Terry Barnaby --- Created attachment 124765 --> https://bugs.kde.org/attachment.cgi?id=124765&action=edit libkomparediff2 patch to set file permisions on copy This is a patch that sets the file permissions on file_copy to be the same as the original file. This may not be the correct way of doing this. I can't find any documentation on what the permissions = -1 argument to KIO::file_copy is actually supposed to do. This setting "may" have been meant to keep the files permissions unchanged but it seem to set them to 0600. Maybe someone who knows how KIO is supposed to work can answer this ? -- You are receiving this mail because: You are watching all bug changes.
[kompare] [Bug 402363] File mode always set to 0600 when saving changes
https://bugs.kde.org/show_bug.cgi?id=402363 --- Comment #3 from Terry Barnaby --- Forgot to say, this patch is to the libkomparediff2-19.04.3 library that kompare uses. -- You are receiving this mail because: You are watching all bug changes.
[kompare] [Bug 402363] File mode always set to 0600 when saving changes
https://bugs.kde.org/show_bug.cgi?id=402363 --- Comment #5 from Terry Barnaby --- Hi Kevin, no I don't have git write permissions. Feel free to push it if you think it is valid (I have very little knowledge on how the KDE KIO system works). Terry -- You are receiving this mail because: You are watching all bug changes.
[plasma-nm] [Bug 390518] Fedora27: By default connection editor sets Ethernet to "no auto", 100MBits/s half duplex
https://bugs.kde.org/show_bug.cgi?id=390518 --- Comment #5 from Terry Barnaby --- Hi, The output of "nmcli -f all connection show" is given below, but this does not appear to have any information on the Ethernet physical link settings so I'm not sure what help that is ? Creating a new "Wired Ethernet" connection using plasma-nm appears to set the "Auto negotiation" on by default as it should. It seems as if plasma-nm fails in this re-guard if there is already a ifcfg-* file that does not have a "ETHTOOL_OPTS" entry. Terry NAMEUUID TYPE TIMESTAMP TIMESTAMP-REALAUTOCONNECT AUTOCONNECT-PRIORITY READONLY DBUS-PATH ACTIVE DEVICE STATE ACTIVE-PATH SLAVE Wired connection 1 9c0bb5e9-eca6-34ed-bfc6-585da165064d 802-3-ethernet 1519578907 Sun 25 Feb 2018 17:15:07 GMT yes 4294967196no /org/freedesktop/NetworkManager/Settings/3 yes enp2s0 activated /org/freedesktop/NetworkManager/ActiveConnection/1 -- ens3a0956992-9b49-3e17-9055-f5193034b1eb 802-3-ethernet 1513600123 Mon 18 Dec 2017 12:28:43 GMT yes 4294966297no /org/freedesktop/NetworkManager/Settings/4 no -- -- -- -- sonoff-4856 9ddc993a-11e2-478f-ac94-2d1380c57b8e 802-11-wireless 1517149559 Sun 28 Jan 2018 14:25:59 GMT yes 0 no /org/freedesktop/NetworkManager/Settings/1 no -- -- -- -- sonoff-5383 efa54c02-fb7b-4981-848a-7f796936385d 802-11-wireless 1514716354 Sun 31 Dec 2017 10:32:34 GMT yes 0 no /org/freedesktop/NetworkManager/Settings/2 no -- -- -- -- You are receiving this mail because: You are watching all bug changes.
[plasma-nm] [Bug 390518] Fedora27: By default connection editor sets Ethernet to "no auto", 100MBits/s half duplex
https://bugs.kde.org/show_bug.cgi?id=390518 --- Comment #7 from Terry Barnaby --- The results of that com,mand for the Ethernet interface in question is: nmcli -f all connection show "Wired connection 1" connection.id: Wired connection 1 connection.uuid:9c0bb5e9-eca6-34ed-bfc6-585da165064d connection.stable-id: -- connection.interface-name: -- connection.type:802-3-ethernet connection.autoconnect: yes connection.autoconnect-priority:-100 connection.autoconnect-retries: -1 (default) connection.timestamp: 1519803330 connection.read-only: no connection.permissions: -- connection.zone:-- connection.master: -- connection.slave-type: -- connection.autoconnect-slaves: -1 (default) connection.secondaries: -- connection.gateway-ping-timeout:0 connection.metered: unknown connection.lldp:-1 (default) 802-3-ethernet.port:-- 802-3-ethernet.speed: 0 802-3-ethernet.duplex: -- 802-3-ethernet.auto-negotiate: yes 802-3-ethernet.mac-address: 90:2B:34:65:B5:09 802-3-ethernet.cloned-mac-address: -- 802-3-ethernet.generate-mac-address-mask:-- 802-3-ethernet.mac-address-blacklist: -- 802-3-ethernet.mtu: auto 802-3-ethernet.s390-subchannels:-- 802-3-ethernet.s390-nettype:-- 802-3-ethernet.s390-options:-- 802-3-ethernet.wake-on-lan: 1 (default) 802-3-ethernet.wake-on-lan-password:-- ipv4.method:auto ipv4.dns: -- ipv4.dns-search:-- ipv4.dns-options: (default) ipv4.dns-priority: 0 ipv4.addresses: -- ipv4.gateway: -- ipv4.routes:-- ipv4.route-metric: -1 ipv4.ignore-auto-routes:no ipv4.ignore-auto-dns: no ipv4.dhcp-client-id:-- ipv4.dhcp-timeout: 0 ipv4.dhcp-send-hostname:yes ipv4.dhcp-hostname: -- ipv4.dhcp-fqdn: -- ipv4.never-default: no ipv4.may-fail: yes ipv4.dad-timeout: -1 (default) ipv6.method:auto ipv6.dns: -- ipv6.dns-search:-- ipv6.dns-options: (default) ipv6.dns-priority: 0 ipv6.addresses: -- ipv6.gateway: -- ipv6.routes:-- ipv6.route-metric: -1 ipv6.ignore-auto-routes:no ipv6.ignore-auto-dns: no ipv6.never-default: no ipv6.may-fail: yes ipv6.ip6-privacy: -1 (unknown) ipv6.addr-gen-mode: stable-privacy ipv6.dhcp-send-hostname:yes ipv6.dhcp-hostname: -- ipv6.token: -- proxy.method: none proxy.browser-only: no proxy.pac-url: -- proxy.pac-script: -- All looks reasonable to me. -- You are receiving this mail because: You are watching all bug changes.
[plasma-nm] [Bug 390518] Fedora27: By default connection editor sets Ethernet to "no auto", 100MBits/s half duplex
https://bugs.kde.org/show_bug.cgi?id=390518 --- Comment #10 from Terry Barnaby --- Yes, I have edited the connection both with plasma-nm and with a simple text editor on the ifcfg-* files on all of my systems and all is ok on those. However I suspect others will see this issue and it is a bug that can catch people out. It was only while doing some network performance tests that I noticed the system had set the Network down to 100 Mbits/s and I suspect many other peoples systems are running with slow networking as a result of this bug. -- You are receiving this mail because: You are watching all bug changes.
[plasma-nm] [Bug 390518] New: Fedora27: By default connection editor sets Ethernet to "no auto", 100MBits/s half duplex
https://bugs.kde.org/show_bug.cgi?id=390518 Bug ID: 390518 Summary: Fedora27: By default connection editor sets Ethernet to "no auto", 100MBits/s half duplex Product: plasma-nm Version: 5.11.5 Platform: Fedora RPMs OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: kcm Assignee: jgrul...@redhat.com Reporter: te...@beam.ltd.uk Target Milestone: --- If the /etc/sysconfig/ifcfg-Wired_connection_1 or appropriate file does not contain an "ETHTOOL_OPTS" entry then the connection editor defaults to "autoneg off, 100 MBits/s, half duplex" for an Ethernet interface. This also occurs when creating a new "ifcfg-*" file when none exist. It is easy to miss this and the interface gets hard coded to 100 MBits/s operation. I think the default should be "autoneg on" when not actually configured. This seems like a recent change in behaviour (don't remember seeing the 100Mbits option before). I noticed 4 of my systems had changed to 100MBits/ half duplex when they should have been "autoneg" at 1GBits/s. This change "appears" to have been written into the ifcfg-* files somehow during a RPM update in the past 2 weeks rather than user driven but it is difficult to confirm this. See: k...@lists.fedoraproject.org, "Fedora27: KDE-Plasma/networkManager: Ethernet interfaces set to 100MBits/sec half duplex" -- You are receiving this mail because: You are watching all bug changes.
[ksysguard] [Bug 364384] New: Ksysguard application memory usage incorrect
https://bugs.kde.org/show_bug.cgi?id=364384 Bug ID: 364384 Summary: Ksysguard application memory usage incorrect Product: ksysguard Version: 5.6.4 Platform: Fedora RPMs OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: ksysguard Assignee: ksysguard-b...@kde.org Reporter: te...@beam.ltd.uk The ksysguard application and the "System Load" widget both report incorrect values for application memory usage. They have not been updated to use the latest kernel's /proc/meminfo's MemAvailable parameter. This means the Application memory value can be significantly larger than it should be (seen 11G rather than 4G on a server running NFS/SMB) as it includes memory that is effectively being used for caching rather than actually needed and in use by applications. Other applications such as top are ok. I will attach a patch that tries to fix this. This needs looking at to make sure it functions as desired and correctly. Reproducible: Always -- You are receiving this mail because: You are watching all bug changes.
[ksysguard] [Bug 364384] Ksysguard application memory usage incorrect
https://bugs.kde.org/show_bug.cgi?id=364384 --- Comment #1 from Terry Barnaby --- Created attachment 99533 --> https://bugs.kde.org/attachment.cgi?id=99533&action=edit Initial idea for a patch This patches ksysguard so that the application memory usage is calculated better. It may be wrong/have issues and other KDE code (System Load) may also need changing. It is supplied as an example of what I think needs to be done, but it will likely need more work. -- You are receiving this mail because: You are watching all bug changes.
[KScreen] [Bug 346961] Multi Monitor configuration lost on reboot, must reconfigure after startup
https://bugs.kde.org/show_bug.cgi?id=346961 Terry Barnaby changed: What|Removed |Added CC||te...@beam.ltd.uk --- Comment #66 from Terry Barnaby --- We have this problem as well. I don't know why kscreen is saving the monitors configuration state, why does it need to do this ? If it needs to for some reason, can't it save it in a separate file to the user defined configuration ? It can then use the users configuration if available overriding any other "automaticially" saved config. -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 345403] "Terminal Size" setting in profile ignored
https://bugs.kde.org/show_bug.cgi?id=345403 Terry Barnaby changed: What|Removed |Added CC||te...@beam.ltd.uk --- Comment #26 from Terry Barnaby --- Another reminder that this is causing users pain. -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 358555] New: kconsole's background is transparent on second screen
https://bugs.kde.org/show_bug.cgi?id=358555 Bug ID: 358555 Summary: kconsole's background is transparent on second screen Product: konsole Version: unspecified Platform: Fedora RPMs OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: general Assignee: konsole-de...@kde.org Reporter: te...@beam.ltd.uk On a Fedora 23 system with kconsole 15.12.1. I have a conventional twin monitor setup with the desktop extending across both monitors. If you try and start a kconsole application on the second monitor it starts with a transparent background and with no text content and is unusable. If you start the kconsole of the main lefthand screen and drag it across to the second monitor it works fine. After using the desktop for 10 mins or so, this fault is cleared and all works ok. No idea what causes the system to fix itself. Tested on two systems with two different user configurations. One system using ATI graphics and the other using Intel graphics. Not sure if this is a kconsole or a Plasma desktop issue. -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 358649] New: Middle button on toolbar "GoUp" no longer functions
https://bugs.kde.org/show_bug.cgi?id=358649 Bug ID: 358649 Summary: Middle button on toolbar "GoUp" no longer functions Product: dolphin Version: 15.12.1 Platform: Fedora RPMs OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: general Assignee: dolphin-bugs-n...@kde.org Reporter: te...@beam.ltd.uk With the Kde 4 version of dolphin, clicking with the middle mouse button on the "goup" toolbar icon resulted in a new tab being opened one level above the current location. This very useful functionality is missing with the Kde 5 version of dolphin. Reproducible: Always -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 358649] Middle button on toolbar "GoUp" no longer functions
https://bugs.kde.org/show_bug.cgi?id=358649 --- Comment #2 from Terry Barnaby --- Many thanks for your reply, the reasons and your work on this. Ok, will try and submit a bug/feature request in kf5. Any idea which of the many areas of kf5 this would be attributed to (frameworks-package ?) I will add a "new tab" button to my dolphin toolbar to workaround this. -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 345403] "Terminal Size" setting in profile ignored
https://bugs.kde.org/show_bug.cgi?id=345403 --- Comment #28 from Terry Barnaby --- Thanks for the patch. I have created an updated kconsole5 rpm with this and am trying it out now. So far its appears to work fine :) -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 358555] kconsole's background is transparent on second screen
https://bugs.kde.org/show_bug.cgi?id=358555 --- Comment #3 from Terry Barnaby --- Many thanks for the response. Yes, turning the compositor off fixes the problem. Also running "QT_STYLE_OVERRIDE=Fusion konsole" fixes the problem. Error messages when kconsole fails include: 0x55f01f446ec0 void QWindowPrivate::setTopLevelScreen(QScreen*, bool) ( QScreen(0x55f01f1670c0) ): Attempt to set a screen on a child window. QXcbConnection: XCB error: 8 (BadMatch), sequence: 1637, resource id: 69206113, major code: 130 (Unknown), minor code: 3 QXcbConnection: XCB error: 8 (BadMatch), sequence: 1645, resource id: 69206113, major code: 130 (Unknown), minor code: 3 Yes, this sound exactly like Bug#357388. -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 358649] Middle button on toolbar "GoUp" no longer functions
https://bugs.kde.org/show_bug.cgi?id=358649 --- Comment #4 from Terry Barnaby --- Many thanks for the comprehensive reply, I can see how it will be awkward to fix properly. I do think this facility should be there though however implemented. Web browsers and other major programs use a middle click on toolbar, links other "icons" to open a new tab etc. and it is inconsistent that kde applications don't (any more). It is a useful desktop productivity feature IMO. I guess the QAction triggered() signal could pass the QEvent that caused it, giving most flexibility. But, I assume getting the Qt API changed is much harder and requires much more thought than getting KDE frameworks changed ? In this case changing KDE frameworks first in such a way with a simple KAction that has an API that could be also implemented in Qt's QAction in the future might be best approach ? -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 358008] SDDM KCM doesn't load until window is resized and also doesn't respond to user requests
https://bugs.kde.org/show_bug.cgi?id=358008 Terry Barnaby changed: What|Removed |Added CC||te...@beam.ltd.uk --- Comment #2 from Terry Barnaby --- Have the same problem. Cannot use Login Screen (SDDM) configuration from system ssettings in Fedora 23. -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 358008] SDDM KCM doesn't load until window is resized and also doesn't respond to user requests
https://bugs.kde.org/show_bug.cgi?id=358008 --- Comment #3 from Terry Barnaby --- This has been fixed in Fedora 23 with the sddm-kcm-5.5.4-1.fc23.x86_64 package. -- You are receiving this mail because: You are watching all bug changes.
