[plasma-systemmonitor] [Bug 487011] New: Systemmonitor has much longer loading times wrt ksysguard
https://bugs.kde.org/show_bug.cgi?id=487011 Bug ID: 487011 Summary: Systemmonitor has much longer loading times wrt ksysguard Classification: Applications Product: plasma-systemmonitor Version: 6.0.4 Platform: Manjaro OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: ksysguard-b...@kde.org Reporter: i6ic...@mailezee.com CC: ahiems...@heimr.nl, plasma-b...@kde.org Target Milestone: --- SUMMARY Systemmonitor is slow at loading, whenever is opening the application or load an unloaded tab. I cannot give you some exact numbers, also because ksysguard is not available anymore in kde 6, but opening ksysguard was immediate from when i clicked on its icon to when its window happeared, systemmonitor instead takes from half to a whole second to open and loading its tabs (the process table seems to be the slowest to load). Note that I'm only preloading only the same pages that I had on ksysguard (with the equivalent sensors and graph), so the performances should be quite similar. In particular I'm using the process table, the history tab and a custom tab with a graph for each cpu core that shows its usage (as I said, I had the same tab also on ksysguard). SOFTWARE/OS VERSIONS Linux: 6.9.0 KDE Plasma Version: 6.0.4 KDE Frameworks Version: 6.1.0 Qt Version: 6.7.0 -- You are receiving this mail because: You are watching all bug changes.
[plasma-systemmonitor] [Bug 439795] Show expanded process info in tooltip
https://bugs.kde.org/show_bug.cgi?id=439795 SolidTemperature0 changed: What|Removed |Added Status|REPORTED|CONFIRMED CC||i6ic...@mailezee.com Ever confirmed|0 |1 --- Comment #1 from SolidTemperature0 --- I confirm this feature was very useful in ksysguard. Moreover, I'd remember there was a similar tooltip on the cpu usage that shown the kernel and user times. I'm not sure anymore, but there may be one also for the memory usage. -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 424090] Add emoji font selection
https://bugs.kde.org/show_bug.cgi?id=424090 SolidTemperature0 changed: What|Removed |Added CC||i6ic...@mailezee.com --- Comment #5 from SolidTemperature0 --- I upvote this too. It's probably a so basic feature that should be added to the 15 minutes bugs list, as configuring the emoji font it's something that a user would immediately do together with the other system fonts -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 422543] Ctrl+click and shift+click should open the folder in a new tab and a new window respectively
https://bugs.kde.org/show_bug.cgi?id=422543 SolidTemperature0 changed: What|Removed |Added Status|REPORTED|RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are watching all bug changes.
[ark] [Bug 470654] Progress bars are severely broken
https://bugs.kde.org/show_bug.cgi?id=470654 --- Comment #1 from SolidTemperature0 --- I think this bug maybe should be part of the "15-Minute Bug Initiative" because compressing and uncompromising files with ark is a very basic task that most users do daily and having a broken progress bar is quite a problem. -- You are receiving this mail because: You are watching all bug changes.
[ark] [Bug 470654] Progress bars are severely broken
https://bugs.kde.org/show_bug.cgi?id=470654 SolidTemperature0 changed: What|Removed |Added Ever confirmed|0 |1 CC||i6ic...@mailezee.com, ||n...@kde.org Status|REPORTED|CONFIRMED -- You are receiving this mail because: You are watching all bug changes.
[plasma-nm] [Bug 464245] Toggle for Mac-Randomization
https://bugs.kde.org/show_bug.cgi?id=464245
SolidTemperature0 changed:
What|Removed |Added
Status|REPORTED|CONFIRMED
CC||i6ic...@mailezee.com
Ever confirmed|0 |1
--- Comment #1 from SolidTemperature0 ---
Adding the setting "wifi.cloned-mac-address=random" makes so that each
connection gets a different mac address each time you connect. It would
definitely be useful if such setting could be set in a GUI. It also supports
the option "stable" that create a random mac address for each connection only
once. In general, the features that I'd like to see would be:
1. A setting for enable and disable random mac address when scanning
("wifi.scan-rand-mac-address=yes")
2. A setting for enable random mac from wifi and ethernet connections (with
settable mask, so that if someone wants they can force a specific vendor for
example), for both "random" e "stable" options.
2.1 If such a setting it's enable it should be noticeable also in the setting
of a specific connection where you could:
a) randomize again the mac address if you want (if cloned-mac-address is
both "random" or "stale")
b) change/add a mask for the randomization of that specific connection (if
the "stale" setting is enable or the automatic randomization is disable then
you should also suggest the user the generate a new mac
c) enable the randomization for that newtork if disbaled (both "stale" and
"random" option should be available), disable the randomization for that
specific connection if enable (and show also the real mac address that is used)
and switch from "stale" and "random" setting for that specific connection.
d) in the cases of b) and c), if something different from the default option
is selected, then it should somehow be highlighted.
--
You are receiving this mail because:
You are watching all bug changes.
[systemsettings] [Bug 468809] New: flatpak-kcm doesn't show all the filesystem permissions Flatseal does + cannot edit them
https://bugs.kde.org/show_bug.cgi?id=468809 Bug ID: 468809 Summary: flatpak-kcm doesn't show all the filesystem permissions Flatseal does + cannot edit them Classification: Applications Product: systemsettings Version: 5.27.4 Platform: Manjaro OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: kcm_flatpak Assignee: plasma-b...@kde.org Reporter: i6ic...@mailezee.com CC: joshiesuha...@gmail.com, m...@ratijas.tk Target Milestone: --- SUMMARY Flatseal shows me more more filesystem permisons that flatpak-kcm. For example flatpak-kcm doesn't seem to be able to show me the "xdg-config/gtk-3.0:ro" field Flatseal does. Moreover Flatseal also allow the possibilities to edit those "other files" fields, while flatpak-kcm shows them together with the defaults ones and doesn't allow you to modify or remove them, only to add more. STEPS TO REPRODUCE 1. Open flatpak-kcm 2. Select any installed flatpak program OBSERVED RESULT Cannot find some filesystem fields, like "xdg-config/gtk-3.0:ro", cannot edit or modify "other files" fields, that are shown in the same way as the default fields. EXPECTED RESULT Be able to see all the filesystem fields, like "xdg-config/gtk-3.0:ro", edit or modify "other files" fields that should be shown differently from the default ones (All users files, all system files, etc.) SOFTWARE/OS VERSIONS Operating System: Manjaro Linux KDE Plasma Version: 5.27.4 KDE Frameworks Version: 5.104.0 Qt Version: 5.15.8 Kernel Version: 6.2.10-1-MANJARO (64-bit) Flatpak Version: 1:1.15.4-1 -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 468808] New: flatpak-kcm bus sections have several problems
https://bugs.kde.org/show_bug.cgi?id=468808 Bug ID: 468808 Summary: flatpak-kcm bus sections have several problems Classification: Applications Product: systemsettings Version: 5.27.4 Platform: Manjaro OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: kcm_flatpak Assignee: plasma-b...@kde.org Reporter: i6ic...@mailezee.com CC: joshiesuha...@gmail.com, m...@ratijas.tk Target Milestone: --- SUMMARY flatpak-kcm bus sections (the sessions and the system ones) have multiple problems: 1. You cannot remove or delete the entries already present, only add more. 2. The type of permission (talks, owns, etc.) is not shown in the combobox, that appears empty instead. 2b. Probably adopt the same design as flatseal would be better, with a different list for each kind of permission. 3. Session bus list is bugged: it does show the string "all the system configuration" (the string may be different, because I'm translating it) instead of the actual name of the bus. STEPS TO REPRODUCE 1. Open flatpak-kcm 2. Select any installed flatpak program SOFTWARE/OS VERSIONS Operating System: Manjaro Linux KDE Plasma Version: 5.27.4 KDE Frameworks Version: 5.104.0 Qt Version: 5.15.8 Kernel Version: 6.2.10-1-MANJARO (64-bit) Flatpak Version: 1:1.15.4-1 -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 468806] New: flatpak-kcm doesn't support editing the persistent storage folders of flatpak programs
https://bugs.kde.org/show_bug.cgi?id=468806 Bug ID: 468806 Summary: flatpak-kcm doesn't support editing the persistent storage folders of flatpak programs Classification: Applications Product: systemsettings Version: 5.27.4 Platform: Manjaro OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: kcm_flatpak Assignee: plasma-b...@kde.org Reporter: i6ic...@mailezee.com CC: joshiesuha...@gmail.com, m...@ratijas.tk Target Milestone: --- SUMMARY Flatseal offers the possibility to add and remove access to persistent folders in the user home of any flatpak program installed, flatpak-kcm doesn't offer this instead. STEPS TO REPRODUCE 1. Open flatpak-kcm 2. Select any installed flatpak program OBSERVED RESULT Cannot find the section about the persistent storage of that program EXPECTED RESULT Find the section about the persistent storage of that program where you can add or remove folders. SOFTWARE/OS VERSIONS Operating System: Manjaro Linux KDE Plasma Version: 5.27.4 KDE Frameworks Version: 5.104.0 Qt Version: 5.15.8 Kernel Version: 6.2.10-1-MANJARO (64-bit) Flatpak Version: 1:1.15.4-1 -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 468805] New: flatpak-kcm doesn't support editing xdg portals permissions of flatpak programs
https://bugs.kde.org/show_bug.cgi?id=468805 Bug ID: 468805 Summary: flatpak-kcm doesn't support editing xdg portals permissions of flatpak programs Classification: Applications Product: systemsettings Version: 5.27.4 Platform: Manjaro OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: kcm_flatpak Assignee: plasma-b...@kde.org Reporter: i6ic...@mailezee.com CC: joshiesuha...@gmail.com, m...@ratijas.tk Target Milestone: --- SUMMARY Flatseal offers enable or disable portals permissions of any flatpak program installed, flatpak-kcm doesn't offer this instead. STEPS TO REPRODUCE 1. Open flatpak-kcm 2. Select any installed flatpak program OBSERVED RESULT Cannot find the section about the xdg portals permissions of that program EXPECTED RESULT Find the section about the xdg portals permissions of that program where you can enable or disable them. SOFTWARE/OS VERSIONS Operating System: Manjaro Linux KDE Plasma Version: 5.27.4 KDE Frameworks Version: 5.104.0 Qt Version: 5.15.8 Kernel Version: 6.2.10-1-MANJARO (64-bit) Flatpak Version: 1:1.15.4-1 -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 468804] New: flatpak-kcm doesn't support editing environment variables of flatpak programs
https://bugs.kde.org/show_bug.cgi?id=468804 Bug ID: 468804 Summary: flatpak-kcm doesn't support editing environment variables of flatpak programs Classification: Applications Product: systemsettings Version: 5.27.4 Platform: Manjaro OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: kcm_flatpak Assignee: plasma-b...@kde.org Reporter: i6ic...@mailezee.com CC: joshiesuha...@gmail.com, m...@ratijas.tk Target Milestone: --- SUMMARY Flatseal offers the possibility to add, remove and edit the environment variables of any flatpak program installed, flatpak-kcm doesn't offer this instead. STEPS TO REPRODUCE 1. Open flatpak-kcm 2. Select any installed flatpak program OBSERVED RESULT Cannot find the section about the environment variables of that program EXPECTED RESULT Find the section about the environment variables of that program where you can add, remove or delete said variables. SOFTWARE/OS VERSIONS Operating System: Manjaro Linux KDE Plasma Version: 5.27.4 KDE Frameworks Version: 5.104.0 Qt Version: 5.15.8 Kernel Version: 6.2.10-1-MANJARO (64-bit) Flatpak Version: 1:1.15.4-1 -- You are receiving this mail because: You are watching all bug changes.
[Breeze] [Bug 459109] New: Inactive tabs background color looks bad in breeze 5.25.5
https://bugs.kde.org/show_bug.cgi?id=459109 Bug ID: 459109 Summary: Inactive tabs background color looks bad in breeze 5.25.5 Product: Breeze Version: 5.25.5 Platform: Manjaro OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: plasma-b...@kde.org Reporter: i6ic...@mailezee.com CC: uhh...@gmail.com Target Milestone: --- Created attachment 152052 --> https://bugs.kde.org/attachment.cgi?id=152052&action=edit Example of the tabs bakground color I just updated to Plasma 5.25.5 and I noticed that know the color of the background of the not active tabs has become almost black (and look quite ugly with my other colors), instead of the one I was using since now with my color scheme. This happens on all the applications that shows multiple tabs, like windows folders or even in KColorSchemeEditor. Is this something wanted? Can it be disabled? If this is wanted probably a new color in the color scheme should be added in order to customized this behavior. As i said, my color scheme (Nord Dark) the tabs looks quite bad and out of place this way, and I haven't found a way to change that. I attached a screenshot of the problem, unfortunately I don't have anymore available an old version of plasma and breeze to show the difference from before. STEPS TO REPRODUCE 1. Open any application with multiple tabs (like Dolphin with multiple folders or KColorSchemeEditor) OBSERVED RESULT The inactive tabs background color is too dark. EXPECTED RESULT The inactive tabs background color shouldn't be this dark, or, even better, it should be customizable. SOFTWARE/OS VERSIONS KDE Plasma Version: 5.25.5 KDE Frameworks Version: 5.97.0 Qt Version: 5.15.5 -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 458611] New: Can't interact anymore with a VLC window after dropping a video file
https://bugs.kde.org/show_bug.cgi?id=458611 Bug ID: 458611 Summary: Can't interact anymore with a VLC window after dropping a video file Product: kwin Version: 5.24.6 Platform: Manjaro OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: wayland-generic Assignee: kwin-bugs-n...@kde.org Reporter: i6ic...@mailezee.com Target Milestone: --- SUMMARY Trying to open a video file (I tried with multiple .mkv that I know vlc can open because thy work when I open them on vlc by double click) by drag and dropping on a vlc window from dolphin results with the impossibility to interact with vlc anymore (from it's gui or trying to closing it from the title bar). Note that the dropped video doesn't get opened by vlc, but, if you already have opened a video in background, that video continues to play just fine, meaning that vlc hasn't crashed. STEPS TO REPRODUCE 1. Open vlc 2. Drag and drop a video into the vlc window OBSERVED RESULT Can't interact anymore with the vlc window EXPECTED RESULT Vlc opens the video as expected. SOFTWARE/OS VERSIONS Linux: 5.19.1-3-Manjaro KDE Plasma Version: 5.24.6 KDE Frameworks Version: 5.96.0 Qt Version: 5.15.5 Graphic Platform: Wayland VLC: 3.0.17.4 -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 458610] New: Screen froze after moving mouse when the screen was locking automatically, on Wayland
https://bugs.kde.org/show_bug.cgi?id=458610 Bug ID: 458610 Summary: Screen froze after moving mouse when the screen was locking automatically, on Wayland Product: kwin Version: 5.24.6 Platform: Manjaro OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: wayland-generic Assignee: kwin-bugs-n...@kde.org Reporter: i6ic...@mailezee.com Target Milestone: --- SUMMARY Note: it happened only once to me, I'll try to reproduce it again. While using the plasma wayland session, in the exact moment when the screen locked automatically after the timeout ended I moved the mouse to avoid that the screen actually locked. The whole screen instead actually froze, letting me only move the mouse cursor, but I couldn't interact with the open window (or the plasma panel) anymore. I ended up restarting the pc from another tty. STEPS TO REPRODUCE 1. Wait for the timeout of the automatic screen lock 2. In the moment when the screen start to lock move the mouse OBSERVED RESULT The screen, except the mouse cursor, froze. EXPECTED RESULT The locking procedure stops and it is still possible to interact with the opened windows and plasma SOFTWARE/OS VERSIONS Linux: 5.19.1-3-Manjaro KDE Plasma Version: 5.24.6 KDE Frameworks Version: 5.96.0 Qt Version: 5.15.5 Graphic Platform: Wayland -- You are receiving this mail because: You are watching all bug changes.
[frameworks-solid] [Bug 446834] Windows C drive is named "Basic data Partition"
https://bugs.kde.org/show_bug.cgi?id=446834 --- Comment #3 from SolidTemperature0 --- (In reply to Ahmad Samir from comment #2) > I don't see how this can be fixed in Solid. The easiest way is for the user > to set a label for the partition. Yeah, it should be a specif code just to handle this particular windows behavior, and I'm not a big fan of this idea, but still make the users fix this by themself isn't a solution too (and moreover I have no idea how windows would react to it) -- You are receiving this mail because: You are watching all bug changes.
[plasma-nm] [Bug 446741] [OpenConnect] OpenConnect keeps showing the autentication window even if the credentials are saved
https://bugs.kde.org/show_bug.cgi?id=446741 --- Comment #1 from SolidTemperature0 --- This bug maybe should be part of the "15-Minute Bug Initiative", it depends from how used are openconnect vpn, because like this is a suboptimal experience wrt openvpn for example. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-solid] [Bug 446834] Windows C drive is named "Basic data Partition"
https://bugs.kde.org/show_bug.cgi?id=446834 --- Comment #1 from SolidTemperature0 --- I guess this bug should be part of the "15-Minute Bug Initiative", it affects every dualboot setup with windows by default and it's something basic that's looks broken/misleading -- You are receiving this mail because: You are watching all bug changes.
[Plasma Vault] [Bug 446552] The context menu actions don't refresh the dolphin folder
https://bugs.kde.org/show_bug.cgi?id=446552 SolidTemperature0 changed: What|Removed |Added Resolution|WAITINGFORINFO |--- Status|NEEDSINFO |REPORTED -- You are receiving this mail because: You are watching all bug changes.
[Breeze] [Bug 446846] [PROPOSAL] Icons should only use colors that are defined in the color scheme
https://bugs.kde.org/show_bug.cgi?id=446846 --- Comment #4 from SolidTemperature0 --- Created attachment 144528 --> https://bugs.kde.org/attachment.cgi?id=144528&action=edit Okular's icon with breeze palette And this the current okular icon, just for reference. -- You are receiving this mail because: You are watching all bug changes.
[Breeze] [Bug 446846] [PROPOSAL] Icons should only use colors that are defined in the color scheme
https://bugs.kde.org/show_bug.cgi?id=446846 --- Comment #3 from SolidTemperature0 --- Created attachment 144527 --> https://bugs.kde.org/attachment.cgi?id=144527&action=edit Okular's icon using nord palette That's the reason of the new colors field. Having a "red" or "green" field prevents color scheme makers to set them to some strange color (at least if they are not completely sure about what they are doing). At the end we would end up with icons that adapts automatically to the palette of the used color scheme (if they have been correctly defined in the color scheme). This is an example of what should happen using Okular's icon and the nord palette (I have done this simple changing the color of the icon from their original value to the respective one in nord) -- You are receiving this mail because: You are watching all bug changes.
[Breeze] [Bug 446846] [PROPOSAL] Icons should only use colors that are defined in the color scheme
https://bugs.kde.org/show_bug.cgi?id=446846 --- Comment #1 from SolidTemperature0 --- This could also been used to fix bug 429016 (and similar problem of dark icons over dark backgrounds) by using light background when using dark color schemes (maybe we should add an option to the color schemes to identify itself as dark or light). For example the Konsole icon can automatically became dark theme compatible by using a white/light gray background an a black/dark gray angle bracket. -- You are receiving this mail because: You are watching all bug changes.
[Breeze] [Bug 446846] New: [PROPOSAL] Icons should only use colors that are defined in the color scheme
https://bugs.kde.org/show_bug.cgi?id=446846 Bug ID: 446846 Summary: [PROPOSAL] Icons should only use colors that are defined in the color scheme Product: Breeze Version: unspecified Platform: Other OS: Other Status: REPORTED Severity: wishlist Priority: NOR Component: Icons Assignee: visual-des...@kde.org Reporter: i6ic...@mailezee.com CC: kain...@gmail.com Target Milestone: --- After bug 395569 and https://invent.kde.org/frameworks/breeze-icons/-/merge_requests/192 the next, definitely ambitious, move would be to have all the icons colors depend on the current color scheme used by the user. I'm not even sure if this is actually possible, or better, if it would look good, with the currents icons. For sure we would need to expand the colors schemes to not only include colors that have a role, but also colors that will be used in place of similar shade of that color. For example a color scheme would need to define a color "Red" that will be used everytime an icon (or an application) needs the color red (right know someone could define the accent color, or ForegroundNegative, but nothing can, correctly, prevent them to be defined as a shade of yellow for example). A good question that I can't answer is which colors would be needed to be defined. A good start I think may be the seven rainbow colors plus black, gray and white. Others may be needed too. Note also that breeze already has at least those colors defined already https://develop.kde.org/hig/style/color/default/ Finally note that this would also help the creators of custom icons pack that don't have to care anymore about support various color schemes. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-solid] [Bug 446834] New: Windows C drive is named "Basic data Partition"
https://bugs.kde.org/show_bug.cgi?id=446834
Bug ID: 446834
Summary: Windows C drive is named "Basic data Partition"
Product: frameworks-solid
Version: 5.88.0
Platform: Manjaro
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: general
Assignee: lu...@kde.org
Reporter: i6ic...@mailezee.com
CC: kdelibs-b...@kde.org
Target Milestone: ---
SUMMARY
By default Windows does not assign a label to its C drive, but it assigns a
partition label ("Basic data Partition"). When connecting a Windows drive (e.g.
when dual-booting with Windows), Solid will name that drive using the partition
label, and this name will be shown into Dolphin, making hard do really
understand which that disk is (at least until you mount it and see what is
inside it).
STEPS TO REPRODUCE
1. Connect a drive with a standard windows installation
2. Look at the label used for the C drive in Dolphin
OBSERVED RESULT
The C drive is called "Basic data Partition"
EXPECTED RESULT
The C drive should get a more understandable name that would not confuse the
user
SOFTWARE/OS VERSIONS
Linux: 5.15.6
KDE Plasma Version: 5.23.4
KDE Frameworks Version: 5.88.0
Qt Version: 5.12.2
--
You are receiving this mail because:
You are watching all bug changes.
[plasma-nm] [Bug 446741] New: [OpenConnect] OpenConnect keeps showing the autentication window even if the credentials are saved
https://bugs.kde.org/show_bug.cgi?id=446741 Bug ID: 446741 Summary: [OpenConnect] OpenConnect keeps showing the autentication window even if the credentials are saved Product: plasma-nm Version: 5.23.3 Platform: Manjaro OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: jgrul...@redhat.com Reporter: i6ic...@mailezee.com Target Milestone: --- SUMMARY Whenever you try to connect to a OpenConnect VPN (I tested this with the gp protocol) the window for the authentication procedure is shown even if the credentials (pkcs#12 pass phrase, username and password, gateway) are already saved. For the sake of usability, that window should appear only the first time a user log in and not appear again if the credentials are saved (except if any sort of error happened). STEPS TO REPRODUCE 1. Connect to a OpenConnect VPN via the applet 2. The authentication window appears with all the fields already filled. OBSERVED RESULT The user need to keep press the "log-in" (I translated this back to english, so it maybe be different) button until the procedure it's completed. EXPECTED RESULT If the credentials are already saved, this windows should not be shown and just automatically connect (like with OpenVPN). SOFTWARE/OS VERSIONS Linux: 5.12.2 KDE Plasma Version: 5.23.3 KDE Frameworks Version: 5.88.0 Qt Version: 5.12.2 -- You are receiving this mail because: You are watching all bug changes.
[Plasma Vault] [Bug 446552] The context menu actions don't refresh the dolphin folder
https://bugs.kde.org/show_bug.cgi?id=446552 --- Comment #4 from SolidTemperature0 --- (In reply to Nate Graham from comment #3) > What does `sysctl fs.inotify.max_user_watches` say? fs.inotify.max_user_watches = 16384 > When it happens, what does `tail -f /var/log/dmesg` say? Used 'dmesg -w' instead, but it didn't show anything (only messages about pam because I used sudo to run it). I also checked with KSystemLog (with all priorities enabled) but it didn't seem to show any problem: 07/12/21 19:31 cryfs Filesystem started. 07/12/21 19:31 kded5 OUT: "CryFS Version 0.11.0\n\nPassword: \nDeriving encryption key (this can take some time)...done\n\n\nFilesystem configuration:\n\n- Filesystem format version: 0.10\n- Created with: CryFS 0.11.0\n- Last opened with: CryFS 0.11.0\n- Cipher: xchacha20-poly1305\n- Blocksize: 16384 bytes\n- Filesystem Id: 2F8A58DA5A9A259B91AF52CED41B6973\n\n\nMounting filesystem. To unmount, call:\n$ cryfs-unmount \"/home/user/Vaults/test\"\n\n" 07/12/21 19:31 kded5 ERR: "" 07/12/21 19:31 dolphin kf.service.services: The desktop entry file "/home/user/Vaults/test/.directory" has Type= "Application" but no Exec line 07/12/21 19:32 systemd home-user-Vaults-test.mount: Deactivated successfully. 07/12/21 19:32 cryfs Filesystem stopped. (The log has been made while opening the vault by the context menu, manually refresh dolphin and then close it by the context menu again, and the bug still appeared both when opening and closing the vault) -- You are receiving this mail because: You are watching all bug changes.
[Plasma Vault] [Bug 446552] The context menu actions don't refresh the dolphin folder
https://bugs.kde.org/show_bug.cgi?id=446552 --- Comment #2 from SolidTemperature0 --- (In reply to Nate Graham from comment #1) > This works for me. I wonder if your system ran out of kernel filesystem > watches... How can I check this/give you a better bug report? -- You are receiving this mail because: You are watching all bug changes.
[Plasma Vault] [Bug 446552] New: The context menu actions don't refresh the dolphin folder
https://bugs.kde.org/show_bug.cgi?id=446552 Bug ID: 446552 Summary: The context menu actions don't refresh the dolphin folder Product: Plasma Vault Version: unspecified Platform: Manjaro OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: ivan.cu...@kde.org Reporter: i6ic...@mailezee.com Target Milestone: --- SUMMARY When opening or closing a vault via the context menu you expected that the action effect is reflected into dolphin (changing the vault icon) as soon as it completed, instead nothing change until you manually refresh the folder, not providing the user any feedback about the completion of the action. STEPS TO REPRODUCE (case a) 1. Open a vault in any way 2. Go to the vault's parent folder in dolphin 3. Right click on the vault and select "Close this Plasma Vault" OBSERVED RESULT (case a) The folder doesn't refresh and so the vault folder icon remain the one of a open vault. EXPECTED RESULT (case a) Dolphin is refreshed and so the vault folder is now shown as a regular folder (as any close vault mount point is shown usually) STEPS TO REPRODUCE (case b) 1. Go to a vault's parent folder in dolphin 2. Right click on the vault and select "Open this Plasma Vault" 3. Insert the password and press "ok" OBSERVED RESULT (case b) The folder doesn't refresh and so the vault folder icon remain the one of a regular folder. EXPECTED RESULT (case b) Dolphin is refreshed and so the vault folder is now shown using the open vault icon. SOFTWARE/OS VERSIONS Linux: 5.15.2 KDE Plasma Version: 5.23.3 KDE Frameworks Version: 5.88.0 Qt Version: 5.15.2 -- You are receiving this mail because: You are watching all bug changes.
[Elisa] [Bug 418800] Elisa does not show cover art for files with embedded album art
https://bugs.kde.org/show_bug.cgi?id=418800 --- Comment #19 from SolidTemperature0 --- Bug still present with Elisa 21.04.3 (as usual I also tried to deleting Elisa's db to re-import all the tracks). Here the updated information about my system: SOFTWARE/OS VERSIONS Elisa: 21.04.3 Linux/KDE Plasma: Manjaro (Stable, up-to-date on 2021/7/27) (Kernel 5.13.4) KDE Plasma Version: 5.22.3 KDE Frameworks Version: 5.84.0 Qt Version: 5.15.0 PS: I think also that reimporting the tracks make some of cover arts blurry: did something change in algorithm used for the scaling of the images or is it just my imagination? -- You are receiving this mail because: You are watching all bug changes.
[elisa] [Bug 418800] Elisa does not show some random cover arts
https://bugs.kde.org/show_bug.cgi?id=418800 --- Comment #12 from SolidTemperature0 --- (In reply to FlyingWaffle from comment #11) > I had encountered the same issue on my Gentoo machine just recently and I > think I've figured out what is going on. When I checked my tags using Kid3 > I realized that all of my albums that were not showing artwork had the cover > art tagged as "Picture" (with 'other' on the dropdown). After editing the > tags on all the affected albums to "Picture: Cover (front)", refreshing my > collection, and restarting Elisa everything works as expected and all my > album art shows up! > > So Elisa seems to look for album art specifically tagged as "Picture: Cover > (front)" and ignores everything else. Nice catch, FlyingWaffle. It seams to be exactly my case: all the covers that did not appears in my case were tagged as "Picture: other", while the ones that works are "Picture: Cover (front)", so I would say that the problem is precisely this. -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 422543] Ctrl+click and shift+click should open the folder in a new tab and a new window respectively
https://bugs.kde.org/show_bug.cgi?id=422543 --- Comment #2 from SolidTemperature0 --- (In reply to Yash Tiwari from comment #1) > If you middle-click on a folder, the folder opens in a new tab. It is still uncomfortable on a laptop (especially if you need to enable a virtual middle-click through some other means) and, I think, does not provide a way to open the folder in a new window (that is the feature I would use the most), but thanks anyway for showing me this feature. -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 422543] New: Ctrl+click and shift+click should open the folder in a new tab and a new window respectively
https://bugs.kde.org/show_bug.cgi?id=422543 Bug ID: 422543 Summary: Ctrl+click and shift+click should open the folder in a new tab and a new window respectively Product: dolphin Version: 20.04.1 Platform: Manjaro OS: Linux Status: REPORTED Severity: wishlist Priority: NOR Component: general Assignee: dolphin-bugs-n...@kde.org Reporter: i6ic...@mailezee.com CC: kfm-de...@kde.org Target Milestone: --- SUMMARY At the moment, open a folder in a new window or a new folder requires two mouse clicks (the right-click to open the context menu and a left-click to select the desired option): shortcuts for these actions could be very helpful when browsing multiple folders at same time. The decision to suggest ctrl+click to open the folder in a new tab and shift+click to open it in a new windows comes from the shortcuts used by most web browsers (at least Firefox, Chrome and Chromium): in this way the user will be already familiar with these. I also suggest to add an option to disable and/or re-map these shortcut, but my idea is to enable them by default. STEPS TO REPRODUCE 1. Click on a folder in Dolphin in order to open it, while keep pressed ctrl or shift key OBSERVED RESULT The folder opens in the same window and tab it was before EXPECTED RESULT If the ctrl key is pressed during the click the folder should be opened in a new tab of the same dolphin window, otherwise, if the shift key is pressed, a new dolphin window should be opened showing the folder that has been clicked. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Manjaro (Stable, up-to-date on 2020/6/6) (Kernel 5.6.15) (available in About System) KDE Plasma Version: 5.16.5 KDE Frameworks Version: 5.70.0 Qt Version: 5.14.2 -- You are receiving this mail because: You are watching all bug changes.
[elisa] [Bug 418800] Elisa does not show some random cover arts
https://bugs.kde.org/show_bug.cgi?id=418800 --- Comment #10 from SolidTemperature0 --- Bug still present with Elisa 20.04 (as usual I also tried to deleting Elisa's db to re-import all the tracks). Here the updated information about my system: SOFTWARE/OS VERSIONS Elisa: 20.04.0 Linux/KDE Plasma: Manjaro (Stable, up-to-date on 2020/4/26) (Kernel 5.6.7) (available in About System) KDE Plasma Version: 5.18.4 KDE Frameworks Version: 5.69.0 Qt Version: 5.14.2 -- You are receiving this mail because: You are watching all bug changes.
[elisa] [Bug 418800] Elisa does not show some random cover arts
https://bugs.kde.org/show_bug.cgi?id=418800 --- Comment #9 from SolidTemperature0 --- (In reply to Matthieu Gallien from comment #8) > I forgot to ask if the covers are files alongside the music files or > embedded as tags inside the music files ? In my library are present various album that have, in the same folder as the actual song files, some "Folder.jpg" or "AlbumArtSmall.jpg" files that are a copy of the cover art, but still ALL the music files in my library are tagged with the album cover art also if these files are present. In the case of the albums that are affected by this bug, NONE of them have a separate cover art image in their folder: they just use the embedded tag. Please note that there are other albums that does not have any "Folder.jpg" or "AlbumArtSmall.jpg" and just rely on the embedded tag, but their cover arts are shown correctly. -- You are receiving this mail because: You are watching all bug changes.
[elisa] [Bug 418800] Elisa does not show some random cover arts
https://bugs.kde.org/show_bug.cgi?id=418800 --- Comment #6 from SolidTemperature0 --- I have updated my system and the bug is still present (always the same albums are affected, I also tried to delete Elisa's db to re-import all the songs, but nothing changed) Here the updated information about my system: SOFTWARE/OS VERSIONS Elisa: 19.12.3 Linux/KDE Plasma: Manjaro (Stable, up-to-date on 2020/3/24) (Kernel 5.5.11) (available in About System) KDE Plasma Version: 5.18.3 KDE Frameworks Version: 5.68.0 Qt Version: 5.14.1 -- You are receiving this mail because: You are watching all bug changes.
[elisa] [Bug 418800] Elisa does not show some random cover arts
https://bugs.kde.org/show_bug.cgi?id=418800 --- Comment #5 from SolidTemperature0 --- (In reply to SolidTemperature0 from comment #1) > The bug is still present in Elisa 19.12.3 (always the same albums are > affected, I also tried to delete Elisa's db to re-import all the songs) > Also the rest of the system has been updated, here the updated information: > SOFTWARE/OS VERSIONS > Linux/KDE Plasma: Manjaro (Stable, up-to-date on 2020/3/15) (Kernel 5.5.8) > (available in About System) > KDE Plasma Version: 5.18.3 > KDE Frameworks Version: 5.67.0 > Qt Version: 5.14.1 Right know this is still my setup -- You are receiving this mail because: You are watching all bug changes.
[elisa] [Bug 418800] Elisa does not show some random cover arts
https://bugs.kde.org/show_bug.cgi?id=418800 --- Comment #3 from SolidTemperature0 --- (In reply to Matthieu Gallien from comment #2) > Thanks for your report. > > I will see if I can find the issue but most probably will have to add some > logging capabilities to help diagnose that. > > Are you able to compile an Elisa patched version if needed ? > > In the meantime, I will have a look at the code to see if I can get some > ideas on how to fix that. I will happily build Elisa with any provided patch, test it and report here the log. My only concern is that, using Manjaro, I maybe not have available the latest version of KDE Frameworks, but I don't know if/how much this could be a problem. -- You are receiving this mail because: You are watching all bug changes.
[elisa] [Bug 418800] Elisa does not show some random cover arts
https://bugs.kde.org/show_bug.cgi?id=418800 --- Comment #1 from SolidTemperature0 --- The bug is still present in Elisa 19.12.3 (always the same albums are affected, I also tried to delete Elisa's db to re-import all the songs) Also the rest of the system has been updated, here the updated information: SOFTWARE/OS VERSIONS Linux/KDE Plasma: Manjaro (Stable, up-to-date on 2020/3/15) (Kernel 5.5.8) (available in About System) KDE Plasma Version: 5.18.3 KDE Frameworks Version: 5.67.0 Qt Version: 5.14.1 -- You are receiving this mail because: You are watching all bug changes.
[elisa] [Bug 418800] New: Elisa does not show some random cover arts
https://bugs.kde.org/show_bug.cgi?id=418800 Bug ID: 418800 Summary: Elisa does not show some random cover arts Product: elisa Version: 19.12.2 Platform: Manjaro OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: matthieu_gall...@yahoo.fr Reporter: i6ic...@mailezee.com Target Milestone: --- SUMMARY In my installation Elisa seems not be able to show the cover arts of some correctly tagged album (the covers are present and correctly shown by: iTunes on Windows, Dolphin on Linux and VLC on both). The album arts that are not shown are always the same every time I start Elisa. If I close Elisa, manually delete the its db, restart it and let it do a new scan of my library folder the bug reappears on the same albums. I could not found any sort of pattern in the affected albums: not every album have a symbol in its name/path/tags (as in this bug https://bugs.kde.org/show_bug.cgi?id=417409), the format of the files was different (it affects both mp3 and m4a), albums of the same artist seems to be more probably affected together, but it does not happen every time (it happens that some albums of one artist are affected and other no). STEPS TO REPRODUCE 1. Open Elisa 2. (If the first boot wait for the scan to end) OBSERVED RESULT Some albums are not shown with their cover art (but with the default one). EXPECTED RESULT All the correctly tagged files should be shown with their album art. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Manjaro (Stable, up-to-date on 2020/3/13) (Kernel 5.5.7) (available in About System) KDE Plasma Version: 5.17.5 KDE Frameworks Version: 5.66.0 Qt Version: 5.14.1 ADDITIONAL INFORMATION -- You are receiving this mail because: You are watching all bug changes.
