[krita] [Bug 475930] New: brush doesn't change after resizing
https://bugs.kde.org/show_bug.cgi?id=475930 Bug ID: 475930 Summary: brush doesn't change after resizing Classification: Applications Product: krita Version: 5.2.0 Platform: Compiled Sources OS: All Status: REPORTED Severity: normal Priority: NOR Component: Brush Engine/Bristle Assignee: krita-bugs-n...@kde.org Reporter: gwendolyn070...@gmail.com Target Milestone: --- I have been using Krita for around 1 year now and this problem only comes up today, I cannot resize my brush even if I press it. it stays on size 0,01 or another size.. I don;y know how to change this but I can't change it -- You are receiving this mail because: You are watching all bug changes.
[kde] [Bug 466037] New: sudden shift of unselected elements while the program were on and I was switching on/off some layers
https://bugs.kde.org/show_bug.cgi?id=466037 Bug ID: 466037 Summary: sudden shift of unselected elements while the program were on and I was switching on/off some layers Classification: I don't know Product: kde Version: unspecified Platform: Microsoft Windows OS: Microsoft Windows Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: unassigned-b...@kde.org Reporter: stefaniaerre...@gmail.com 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. turn on layer 2. the layer with the drawing and other layers are modified without im not doing anything but on/off layers 3. opened other layers in the same group, and the ending was the same 4. I cried. OBSERVED RESULT The drawing on three different layer, that were in the same group layer with other layers that haven't been modificated, has been modificated without any action i did, just I opened notes on the pc and writed and a part of the drawing on different layers seemed to be selected and moved. This bug happened in a few seconds while I was turning on/off some layers in that group EXPECTED RESULT The drawing should have stayed the same SOFTWARE/OS VERSIONS Windows: 10 Pro Linux/KDE Plasma: (available in About System) KDE Plasma Version: KDE Frameworks Version: Qt Version: ADDITIONAL INFORMATION I showed the drawings a second ago, and nothing appened, then i just tried to switch on a layer, an that was randomly moved, and the autosave saved the drawing as it was, with the problem. I created the account after the bug, so there isn't the history Sorry for my clumsy english, I come from Italy -- You are receiving this mail because: You are watching all bug changes.
[kscreenlocker] [Bug 463944] New: When logging in as a user with a fingerprint enrolled, login screen appears to hang, but is actually waiting for a fingerprint scan
https://bugs.kde.org/show_bug.cgi?id=463944 Bug ID: 463944 Summary: When logging in as a user with a fingerprint enrolled, login screen appears to hang, but is actually waiting for a fingerprint scan Classification: Plasma Product: kscreenlocker Version: 5.26.3 Platform: NixOS OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: plasma-b...@kde.org Reporter: he...@kindrobot.ca Target Milestone: --- SUMMARY I am using a Framework laptop and have successfully enrolled my fingerprint. It's working great for sudo and unlocking a locked screen. However, on boot, I am prompted for a password, and no matter what password I put in the box (correct or incorrect) the login window appears to hang (i.e. the cursor is still responsive, but everything else is disabled). I've discovered that it's actually waiting for me to scan my fingerprint. It doesn't matter what I put in the password field beforehand, as long as my fingerprint matches, it'll continue to log-in. STEPS TO REPRODUCE 1. Enroll fingerprint 2. Restart computer OBSERVED RESULT Prompts for password, but does not accept password, instead waits for me to scan my fingerprint without printing any instructions to do so. EXPECTED RESULT A prompt to scan my fingerprint or have it accept my password to log in without a fingerprint. SOFTWARE/OS VERSIONS Linux/KDE Plasma: NixOS 22.11 KDE Plasma Version: 5.26.3 KDE Frameworks Version: 5.99.0 Qt Version: 5.15.7 ADDITIONAL INFORMATION The copy on the fingerprint enrollment may also be out of date. It says "Logging into the system with your fingerprint is not supported," but it appears not only to work, but to be the _only_ way to log into the system. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 446466] Pictures on NFS share with special characters in their album name don't show icon/image previews
https://bugs.kde.org/show_bug.cgi?id=446466 stef changed: What|Removed |Added Status|REPORTED|RESOLVED Resolution|--- |FIXED --- Comment #3 from stef --- Hi Maik That was it - the nfc option does the trick on nfs. It seems though, that I need to migrate folders with special characters that they work in digikam and other programs. Switching to smb seems to be easier. Thanks' a lot for your fast reply! Regards, Stefan -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 446466] New: Pictures on NFS share with special characters in their album name don't show icon/image previews
https://bugs.kde.org/show_bug.cgi?id=446466 Bug ID: 446466 Summary: Pictures on NFS share with special characters in their album name don't show icon/image previews Product: digikam Version: 7.3.0 Platform: macOS (DMG) OS: macOS Status: REPORTED Severity: normal Priority: NOR Component: Albums-IconView Assignee: digikam-bugs-n...@kde.org Reporter: kdebugs@meissner.click Target Milestone: --- Created attachment 144205 --> https://bugs.kde.org/attachment.cgi?id=144205=edit Screenshots illustrating the bug reported SUMMARY Icon and image preview are broken for albums on a nfs share containing special characters as German umlauts (e.g. ä, ü). See screenshots in the attachment. STEPS TO REPRODUCE 1. In a network share collection (NFS mount), I create an album with the name Test_ä or Test_ü 2. I add some pictures/movies to new album using drag-and-drop from MacOS Finder to digikam (not relevant how this is done though) 3. In digikam's album view, I check the icon area and the image preview area for the added pictures/movies OBSERVED RESULT The green placeholder icons are show for the added images/movies only and in the preview area it says "Failed to load image" EXPECTED RESULT Regular icons and an image preview reflecting the added pictures/movies content are shown SOFTWARE/OS VERSIONS digikam version 7.3.0 CPU cores: 8 DNG SDK: 1.5.1 Eigen: 3.3.9 ExifTool: 12.34 Exiv2 supports Base Media: Yes Exiv2 supports XMP metadata: Yes HEIF encoding support: Yes ImageMagick codecs: 6.9.11 KF5: 5.80.0 LensFun: 0.3.95-0 LibCImg: 130 LibJPEG: 80 LibJasper: 2.0.14 LibLCMS: 2120 LibLqr support: No LibPGF: 7.21.07 LibPNG: 1.6.37 LibRaw: 0.21.0 LibTIFF: 4.2.0 Marble: 0.27.20 Parallelized demosaicing: Yes Qt: 5.15.2 Qt WebEngine support: Yes Rajce support: Yes VKontakte support: No XMP SDK: 5.6.0 AkonadiContact support: No Baloo support: No Calendar support: Yes DBus support: No Database backend: QSQLITE HTML Gallery support: Yes LibAVCodec: 58.91.100 LibAVFormat: 58.45.100 LibAVUtil: 56.51.100 LibGphoto2: 2.5.27 LibOpenCV: 4.5.1 LibQtAV: 1.13.0 Media player support: Yes Panorama support: Yes ADDITIONAL INFORMATION - Moving the folder Test_ä to a local collection makes the issue disappear; moving it back to the nfs share als brings the issue back - Renaming the folder to not contain the umlaut character solves the problem; when the umlaut is added again, the issue is also back - mount statement used for the nfs share is: nas:/photo on /Volumes/photo (nfs, nodev, nosuid, mounted by stefan) - Checking the mounted nfs share within a console shows regular file names incl. special characters -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 431003] New: Running status of digikam not reflected in MacOS task bar
https://bugs.kde.org/show_bug.cgi?id=431003
Bug ID: 431003
Summary: Running status of digikam not reflected in MacOS task
bar
Product: digikam
Version: 7.2.0
Platform: macOS (DMG)
OS: macOS
Status: REPORTED
Severity: normal
Priority: NOR
Component: Bundle-MacOS
Assignee: digikam-bugs-n...@kde.org
Reporter: kdebugs@meissner.click
Target Milestone: ---
STEPS TO REPRODUCE
1. Install digiKam-7.2.0-beta2-MacOS-x86-64.pkg
2. Add the digikam app icon to the MacOS task bar
3. Start digikam and observe the dot indicator ("app running") besides the app
icon on the MacOS task bar
OBSERVED RESULT
The dot is breifly shown but disappears right away despite digikam being
normally running.
EXPECTED RESULT
The dot besides the digikam icon should be present as long as the app is
running.
SOFTWARE/OS VERSIONS
digikam: 7.2.0-beta2
macOS: 10.14.6 (Mojave)
KDE Frameworks Version: 5.77.0
Qt Version: 5.15.2
ADDITIONAL INFORMATION
-
--
You are receiving this mail because:
You are watching all bug changes.
[frameworks-kio] [Bug 178678] Navigating mounted network locations is extremely slow in Dolphin compared to command line
https://bugs.kde.org/show_bug.cgi?id=178678 --- Comment #93 from Stef Bon --- I know I have to see/eperience why it is running slow. I'm not using gdb to do run code, just to analyze a coredump. The way I follow code is adding extra logmessages to syslog which always give me enough info, well at least till now. The info you point at is usefull Harald (the see-alsos). Do you have also some information how the interaction is with the kio-slaves? (As developer of FUSE filesystems I have something against these. It is far better to leave looking up of fileinfo to the kernel and a FUSE service. Then Dolphin can concentrate more on the way it presents the fileinfo. But it's the way it is.) And is there a developerscorner where I can write down everything I see/discover/find/my opinion and discus? Stef Bon -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kio] [Bug 178678] Navigating mounted network locations is extremely slow in Dolphin compared to command line
https://bugs.kde.org/show_bug.cgi?id=178678
--- Comment #91 from Stef Bon ---
Ok Germano,
better be honoust. I respect that. But I want some help.
For example where do I start to look for? I do not have to look at the classes
for the ui for example. I can remember:
- dolpinpart.cpp
- kitemviews/{kfileitemmodel.cpp, kstandarditemmodel.cpp}
I believe. Can someone point me a bit in the right direction (to find out why
it takes too long for certain (network) filesystems == places where there is a
lot of io for determing the mimetype). If you can point me also to other
sources like designnotes, important discussions etc please let me know.
And where can I write and share my idea's. That's not here. Is there a
developerscorner or something simular for dolphin?
Thanks in advance,
Stef Bon
the Netherlands
--
You are receiving this mail because:
You are watching all bug changes.
[frameworks-kio] [Bug 178678] Navigating mounted network locations is extremely slow in Dolphin compared to command line
https://bugs.kde.org/show_bug.cgi?id=178678 --- Comment #89 from Stef Bon --- Serious. Germano and others. This has taken too far long. We should team up and try to solve this issue. I'm a writer of FUSE filesystems, now busy writing a ssh server, to provide a more flexible server than openssh one for fuse clients and io sollutions I also work on. My speciallity is C, a bit of C++ (although I prefer C very much), FUSE, SSH, SFTP and network filesystems. Can someone help me to address this issue? Stef Bon PS1 I think it's important to first analyze the problem thorough before doing anything, and then plan the action and keep coordinated -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kio] [Bug 178678] Navigating mounted network locations is extremely slow in Dolphin compared to command line
https://bugs.kde.org/show_bug.cgi?id=178678 --- Comment #88 from Stef Bon --- Now plans enough. We should start working on this issue, and then I mean really. Not only posting, but really start. I can write a bit c++, and think that the code is a mess, but maybe we can do a bit of a ceanup as well. What about that? Stef -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kio] [Bug 178678] Navigating mounted network locations is extremely slow in Dolphin compared to command line
https://bugs.kde.org/show_bug.cgi?id=178678 --- Comment #87 from Stef Bon --- I agree. That should be an option. So give the user a choice: lookups of mime/icon should be one of: - do always, no matter what - do heuristic, when too slow do either: - switch over to a simple determing of mime by looking at extension (in stead of the first x bytes and anlyzing them) - disable - never do on network filesystems (which are?) Stef -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kio] [Bug 178678] Navigating mounted network locations is extremely slow in Dolphin compared to command line
https://bugs.kde.org/show_bug.cgi?id=178678 --- Comment #85 from Stef Bon --- Hi, it's a long time since I've looked at the problem. What has been changed since then? I saw that there is not a seperation between the default attributes like size, permissions and owner/group and c/mtimes, and more in depth information like mimetype, which require much more io. What I beleive I've mentioned before is that these lookup processes should be handled seperated: so some threads do the lookup of default attributes, and others do the determing of the mimetypes/icon etc. This can be done with different queues of "lookup" tasks, and when doing the lookups of mimetype.icon takes too much time, it can switch over to do a much more simple lookup by checking the extension for example. That saves a lot of io. But I've seen the code and it's horrible to do this imo. Stef -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 379614] Windows shortcuts are not memorized
https://bugs.kde.org/show_bug.cgi?id=379614 --- Comment #4 from stef <s...@vogliaditerra.com> --- Ok, so this is no bug and can be closed, sorry for the noise, but I was remembering that time ago (kde3.5 or 4) this was permanent as application shortcut (in 95% of siituations application=window, since we have tabs). On a sidenote: when opening submenu "window shortcut" the focus is not in the shortcut field and it needs another click first for inserting shortcut. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 379614] Windows shortcuts are not memorized
https://bugs.kde.org/show_bug.cgi?id=379614 --- Comment #2 from stef <s...@vogliaditerra.com> --- 1) Step to reproduce: click app icon on the left side of the title bar, choose "other actions", "window shortcut", insert any shortcut e.g. alt+T, click ok. 2) Expected Result: alt+T opens chosen application window 3) Result: alt+T does not open this application window, returning to 1) shortcut field is empty as before. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 379614] New: Windows shortcuts are not memorized
https://bugs.kde.org/show_bug.cgi?id=379614 Bug ID: 379614 Summary: Windows shortcuts are not memorized Product: kwin Version: 5.9.5 Platform: Archlinux Packages OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: general Assignee: kwin-bugs-n...@kde.org Reporter: s...@vogliaditerra.com Target Milestone: --- Clicking the app icon on the left in title bar> other actions > window shortcut does never memorize inserted shortcut. But it still warns when a given shortcut is already in use, the dialog finishes well but the shortcut is not working and field for shortcut next time is empty again. Found on arch with up-to-date plasma, found on Kubuntu 16.04 as well. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 375248] New: kwin crashes when a new window is opened e.g. skype conversation window
https://bugs.kde.org/show_bug.cgi?id=375248 Bug ID: 375248 Summary: kwin crashes when a new window is opened e.g. skype conversation window Product: kwin Version: unspecified Platform: Kubuntu Packages OS: Linux Status: UNCONFIRMED Severity: minor Priority: NOR Component: activities Assignee: kwin-bugs-n...@kde.org Reporter: le...@leeon.de Target Milestone: --- Created attachment 103491 --> https://bugs.kde.org/attachment.cgi?id=103491=edit kwin crash traceback bug occurs sometimes when one window is opened. -- You are receiving this mail because: You are watching all bug changes.
[muon] [Bug 358359] HIgh cpu consumption and apt-check process infinte fork
https://bugs.kde.org/show_bug.cgi?id=358359 stef <s...@vogliaditerra.com> changed: What|Removed |Added CC||s...@vogliaditerra.com --- Comment #1 from stef <s...@vogliaditerra.com> --- Same behaviour here: http://forum.ubuntu-it.org/viewtopic.php?f=30=606905 -- You are receiving this mail because: You are watching all bug changes.
