[kio-admin] [Bug 485237] Show some UI clue that Dolphin runs with super privileges
https://bugs.kde.org/show_bug.cgi?id=485237 cipricus changed: What|Removed |Added CC||cipri...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[kio-admin] [Bug 485237] New: Show some UI clue that Dolphin runs with super privileges
https://bugs.kde.org/show_bug.cgi?id=485237 Bug ID: 485237 Summary: Show some UI clue that Dolphin runs with super privileges Classification: Frameworks and Libraries Product: kio-admin Version: unspecified Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: unassigned-b...@kde.org Reporter: cipri...@gmail.com CC: sit...@kde.org Target Milestone: --- Created attachment 168288 --> https://bugs.kde.org/attachment.cgi?id=168288=edit Dolphin looks the same as root Related to this Discuss post: https://discuss.kde.org/t/make-dolphin-show-some-clue-that-its-opened-as-adminstrator/13723 Dolphin running as administrator (after installing kio-slave) takes the default theme and looks exactly like a normal Dolphin session, which can be misleading and dangerous. Expected result: Dolphin UI shows some clue that it runs with super privileges. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 408928] On X11, Keyboard layout OSD doesn't work
https://bugs.kde.org/show_bug.cgi?id=408928 --- Comment #21 from cipricus --- The per-layout shortcuts do not trigger the OSD either (in X11). Plasma 5.27.10. Only the alternative shortcut does. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 408928] On X11, Keyboard layout OSD doesn't work
https://bugs.kde.org/show_bug.cgi?id=408928 cipricus changed: What|Removed |Added CC||cipri...@gmail.com --- Comment #20 from cipricus --- (In reply to phrxmd from comment #7) > I just filed bug 423611 where I see a similar behaviour (no OSD), but only > when the keyboard shortcut is from the "main" shortcut list. If I switch > keyboards using a user-defined "alternative" shortcut, the OSD appears. This > might be the same bug, and also the reason why not everybody can reproduce > this. I have the same problem in 5.27.10. The difference between main and alternative shortcuts is that the main ones are pre-defined (have to be checked in a list), while the alternative shortcut has to "manually", actively introduced, that is used, sampled. -- You are receiving this mail because: You are watching all bug changes.
[Bluedevil] [Bug 477442] Bluetooth speaker loses audio after media pause (on Macbook with UE Boom)
https://bugs.kde.org/show_bug.cgi?id=477442 --- Comment #2 from cipricus --- More testing: a video projector with BT speaker is not affected either. -- You are receiving this mail because: You are watching all bug changes.
[Bluedevil] [Bug 477442] Bluetooth speaker loses audio after media pause (on Macbook with UE Boom)
https://bugs.kde.org/show_bug.cgi?id=477442 --- Comment #1 from cipricus --- UPDATE: This is limited to some BT speakers, maybe just to UE Boom 2 and 3. Beside BT ear-phones,there are some external BT speakers (tested: Jabra Speaker) that are not affected. -- You are receiving this mail because: You are watching all bug changes.
[Bluedevil] [Bug 477442] Bluetooth speaker loses audio after media pause (on Macbook with UE Boom)
https://bugs.kde.org/show_bug.cgi?id=477442 cipricus changed: What|Removed |Added Platform|Other |unspecified CC||cipri...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[Bluedevil] [Bug 477442] New: Bluetooth speaker loses audio after media pause (on Macbook with UE Boom)
https://bugs.kde.org/show_bug.cgi?id=477442 Bug ID: 477442 Summary: Bluetooth speaker loses audio after media pause (on Macbook with UE Boom) Classification: Plasma Product: Bluedevil Version: unspecified Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: now...@gmail.com Reporter: cipri...@gmail.com CC: plasma-b...@kde.org Target Milestone: --- SUMMARY With Kubuntu 22.04 up to 23.10 (but also for testing purposes with KaOS latest Plasma) on a Macbook Air I have a problem with a UE Boom 2 bluetooth speaker (and then with a Boom 3) which isn't affecting a PC laptop: sound is not heard after media playback is paused for more than a few seconds. I mean that after un-pausing the local or online media player there is no sound or he sound is severely distorted (cracks and pauses as if the signal is lost). - The only fix is to disconnect and reconnect the bluetooth speaker. –Or, in order to avoid this, as a workaround: before pausing, even before playing the file that might be paused, to start in the background, muted, another audio file. - This problem doesn't in fact happen if audio playback is muted, but only if it's paused! STEPS TO REPRODUCE 1. Connect to the bluetooth speaker through the Plasma bluetooth tool 2. play an audio stream (or video+audio file) – no mater the program – through the BT device 3. pause the playback for more than a few seconds (let’s say 10-15 seconds) OBSERVED RESULT The sound is not heard or is totally distorted (cracking sounds with long pauses). In order to fix this, the BT device has to be disconnected and reconnected. This can be fixed by installing `blueman`, starting and keeping `blueman-manager` running. (`blueman-manager` process is stopped by closing its window: and clicking the `blueman-tray` button also closes the `blueman-manager` window and thus the process! - The method I use to hide `blueman-manager` window without killing the `blueman-manager` is to dock it to tray with `kdocker`). If `blueman-manager` window is not closed (including by clicking its tray button) but simply ‘docked’ with kdocker program, the `blueman-manager` keeps running and the problem is gone: the audio can be paused/unpaused without the BT speaker losing sound. (But oddly, closing `blueman-tray` (right-click its icon and select Exit) doesn't kill `blueman-manager`, but left-clicking it does, even if `blueman-manager` is already docked. I have to avoid that to fix this.) `blueman-manager` is the only process needed to solve the problem, while `blueman-applet` and `blueman-tray` may be closed if necessary EXPECTED RESULT The audio sound should continue normally when un-paused (without running `blueman-manager`). Bluedevil should be able to do by itself that which in case is achieved only by `blueman-manager`. SOFTWARE/OS VERSIONS Linux/KDE Plasma: whatever that was in Kubuntu 22.04, Plasma 5.27.8 in Kubuntu 23.10, also 5.27.9 in Kaos (available in About System) -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 395497] Menubar - No text - Editing the shell toolbar from Configure Toolbars sometimes corrupts shell.rc
https://bugs.kde.org/show_bug.cgi?id=395497 --- Comment #57 from cipricus --- > Editing ~/.local/share/kxmlgui5/okular/shell.rc and removing noMerge="1" > fixes this issue. In that file I have 5 occurrences: `` line 4 ` ` line 20 line 25 line 38 line 53 What should I remove to fix it? Is that a permanent fix, so I don't have to reset my toolbar? -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 395497] Menubar - No text - Editing the shell toolbar from Configure Toolbars sometimes corrupts shell.rc
https://bugs.kde.org/show_bug.cgi?id=395497 --- Comment #56 from cipricus --- (In reply to Albert Astals Cid from comment #14) > Can you send your .local/share/kxmlgui5/okular/part.rc file over? > > Do you remember doing any customization to your menus/toolbar/shortcuts? > > Can you confirm that removing your .local/share/kxmlgui5/okular/part.rc file > (save it first somewhere else) fixes this? I can confirm that on at least one occasion removing just part.rc file fixed it, and that on at least another one occasion I had to delete the shell.rc too (or maybe only that should have been removed, something confirmed by people on a reddit afaicr). Re-setting to defaults (Settings-Configure toolbars-Default) fixes it too, because that removes both files. -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 395497] Menubar - No text - Editing the shell toolbar from Configure Toolbars sometimes corrupts shell.rc
https://bugs.kde.org/show_bug.cgi?id=395497 --- Comment #55 from cipricus --- (In reply to cipricus from comment #54) > (In reply to medin from comment #50) > > I solved my problem by removing "~/.local/share/kxmlgui5/okular/shell.rc" > > file then Okular showed the correct menu entries, but that removed file is > > never recreated again. > > In my case the file was recreated. Okular 23.08.1. Kubuntu 23.10. The problem is also recurrent. I have removed the whole "~/.local/share/kxmlgui5/okular/" folder yesterday to fix the problem and now the problem and the folder is in place with both files part.rc and shell.rc. I think that what causes this is the configuring of the toolbar (adding buttons). I'll test that leaving it default is a "solution". -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 395497] Menubar - No text - Editing the shell toolbar from Configure Toolbars sometimes corrupts shell.rc
https://bugs.kde.org/show_bug.cgi?id=395497 --- Comment #54 from cipricus --- (In reply to medin from comment #50) > I solved my problem by removing "~/.local/share/kxmlgui5/okular/shell.rc" > file then Okular showed the correct menu entries, but that removed file is > never recreated again. In my case the file was recreated. Okular 23.08.1. -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 395497] Menubar - No text - Editing the shell toolbar from Configure Toolbars sometimes corrupts shell.rc
https://bugs.kde.org/show_bug.cgi?id=395497 cipricus changed: What|Removed |Added CC||cipri...@gmail.com --- Comment #53 from cipricus --- (In reply to medin from comment #50) > I solved my problem by removing "~/.local/share/kxmlgui5/okular/shell.rc" > file then Okular showed the correct menu entries, but that removed file is > never recreated again. Seeing this again in 23.08.1. -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 450455] Recent files and locations listed in Dolphin panel "Recent" are very old
https://bugs.kde.org/show_bug.cgi?id=450455 --- Comment #4 from cipricus --- This should be closed: I have no confirmations from other users of the problem from that versions of Plasma and Dolphin, and the problem is gone in later versions. -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 450455] Recent files and locations listed in Dolphin panel "Recent" are very old
https://bugs.kde.org/show_bug.cgi?id=450455 --- Comment #3 from cipricus --- (In reply to Méven Car from comment #2) > One thing to note, the accessed date in recentlyused:/ is their file access > date, only the "modified" column reflects dates that reflect when those > files were last modified/accessed. > Try sorting on the "modified" column. > > Do you use baloo, or some file scanning/indexer program ? > If so that would explain why the access date of those files changed. I am not affected by this bug because I have upgraded my system to Kubuntu 23.10, Plasma 5.27, where this is fixed for me The problem mentioned initially by me here was much more severe than what your description of the difference between "Accessed" and "Modified" columns suggests: there was simply no update of recent files and locations at that point. I think that after deleting baloo database those Dolphin lists became void! I tried to use timeline instead etc. (https://unix.stackexchange.com/a/691084/341192). -- You are receiving this mail because: You are watching all bug changes.
[Discover] [Bug 418081] packagekit: Apps installed from a file don't get listed
https://bugs.kde.org/show_bug.cgi?id=418081 cipricus changed: What|Removed |Added CC||cipri...@gmail.com --- Comment #3 from cipricus --- So, the bug it's not that applications installed from deb don't have a proper icon in Discover, but that they are not listed at all. On Kubuntu 23.04 what I notice is that: - For an application that IS already present in default sources (e.g. in Kubuntu, Strawberry) and listed (as uninstalled), if that is installed from file (e.g. deb, a later version), then the new installed program is listed as installed. No bug in this case. - For an application that IS already present in default sources and is listed (as uninstalled), if that is installed NOT from a local file like a deb, but by a different method, like that for Calibre (https://calibre-ebook.com/download_linux), then the new installed version of the program is not listed as installed, but the old version is listed as before (uninstalled, if the case). That could be a different bug. - For an application that IS NOT already present in default sources (e.g. in Kubuntu, Opera, Chrome, Megasync, FreeOffice), if that is installed from file (e.g. deb), then the new installed program is not listed. This is the bug reported here. Operating System: Kubuntu 23.04 KDE Plasma Version: 5.27.4 KDE Frameworks Version: 5.104.0 Qt Version: 5.15.8 Kernel Version: 6.2.0-20-generic (64-bit) -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 469665] Changing username doesn't work and should be removed
https://bugs.kde.org/show_bug.cgi?id=469665 cipricus changed: What|Removed |Added CC||cipri...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 469665] New: Changing username doesn't work and should be removed
https://bugs.kde.org/show_bug.cgi?id=469665 Bug ID: 469665 Summary: Changing username doesn't work and should be removed Classification: Applications Product: systemsettings Version: 5.27.5 Platform: Ubuntu OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: kcm_users Assignee: plasma-b...@kde.org Reporter: cipri...@gmail.com CC: uhh...@gmail.com Target Milestone: --- Created attachment 158890 --> https://bugs.kde.org/attachment.cgi?id=158890=edit image of users settings error SUMMARY Opening Users settings and changing username givers error. `org.kde.kcm_users: "org.freedesktop.Accounts.Error.Failed" "running '/usr/sbin/usermod' failed: Child process exited with code 8"` Changing the account name involves security risks that explains the fact that the name cannot be changed, I guess, but the entry is still there. It shouldn't be there, either because it doesn't work and/or because it is risky to be present as a such obvious option (if it worked). Linux/KDE Plasma: Kubuntu 23.04 (available in About System) 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.
[Haruna] [Bug 464665] Question: can mpv CLI options be used with Haruna to add subtitle background?
https://bugs.kde.org/show_bug.cgi?id=464665 --- Comment #6 from cipricus --- Thank you! Sorry for my ignorance, I was thinking "set" to be a mpv option other than what can be associated with subtitles backgrounds, I was expecting something identical to arguments for mpv as such (like cellulid and smplayer do it). -- You are receiving this mail because: You are watching all bug changes.
[Haruna] [Bug 464665] Question: can mpv CLI options be used with Haruna to add subtitle background?
https://bugs.kde.org/show_bug.cgi?id=464665 cipricus changed: What|Removed |Added Summary|Question: can mpv CLI |Question: can mpv CLI |options be used with|options be used with Haruna |Haruna? |to add subtitle background? -- You are receiving this mail because: You are watching all bug changes.
[Haruna] [Bug 464665] Question: can mpv CLI options be used with Haruna?
https://bugs.kde.org/show_bug.cgi?id=464665 --- Comment #4 from cipricus --- ` sub-back-color=#131415`, doesn't work. -- You are receiving this mail because: You are watching all bug changes.
[Haruna] [Bug 464665] Question: can mpv CLI options be used with Haruna?
https://bugs.kde.org/show_bug.cgi?id=464665 --- Comment #3 from cipricus --- Please note that I don't want to have mpv as such always showing subs background, I would like to have that just in Haruna (and that triggered with a shortcut, if possible). Maybe I should post that as a different issue? -- You are receiving this mail because: You are watching all bug changes.
[Haruna] [Bug 464665] Question: can mpv CLI options be used with Haruna?
https://bugs.kde.org/show_bug.cgi?id=464665 --- Comment #2 from cipricus --- (In reply to george fb from comment #1) > That's what the custom commands settings do. There's placeholder showing the > format to use and a help page going into details. Thank you for the swift reply! I have seen the format example, but it looked obscure to me, because it is different from what I had in mind (see below). The help is very limited. The place holder has an example: `add volume +10`, which corresponds to the note in the help saying: >Not all commands will work as some are specific for mpv. >Most useful are the commands to manipulate properties, like set, add, cycle. In fact, I am trying to add subtitles background (https://mpv.io/manual/stable/#options-sub-back-color). I have tested that in mpv (`mpv --sub-back-color=#131415`) and it works as such, but not in Haruna. I have tried ` --sub-back-color=#131415` also, doesn't work. 1. Is this type of option supposed to work? 2. If yes, what is the form of the command to be added according to the example above? Thank you. -- You are receiving this mail because: You are watching all bug changes.
[Haruna] [Bug 464665] New: Question: can mpv CLI options be used with Haruna?
https://bugs.kde.org/show_bug.cgi?id=464665 Bug ID: 464665 Summary: Question: can mpv CLI options be used with Haruna? Classification: Applications Product: Haruna Version: unspecified Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: generic Assignee: georgefb...@gmail.com Reporter: cipri...@gmail.com Target Milestone: --- Can mpv options (like this: https://mpv.io/manual/master/#options-sub-back-color) be used with Haruna? -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 462304] Okular and other poppler related tools cannot handle some pdf pages
https://bugs.kde.org/show_bug.cgi?id=462304 --- Comment #10 from cipricus --- (In reply to Oliver Sander from comment #7) > Yes please. You should be able to reproduce the bug with the `pdftoppm` > tool (which is part of poppler). That way, your bug report becomes > independent from Okular. I have posted as a popple bug here: https://gitlab.freedesktop.org/poppler/poppler/-/issues/1319 -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 462304] Okular and other poppler related tools cannot handle some pdf pages
https://bugs.kde.org/show_bug.cgi?id=462304 --- Comment #9 from cipricus --- (In reply to Oliver Sander from comment #7) > Yes please. You should be able to reproduce the bug with the `pdftoppm` > tool (which is part of poppler). That way, your bug report becomes > independent from Okular. Sorry, what is the exact package affected by the bug? Is it called "poppler"? Or "poppler-utils"? Should the bug report be posted here? Or because it'd not a kde bug must be posted under a different bug-reporting website? -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 462304] Okular and other poppler related tools cannot handle some pdf pages
https://bugs.kde.org/show_bug.cgi?id=462304 --- Comment #8 from cipricus --- (In reply to Oliver Sander from comment #7) > Yes please. You should be able to reproduce the bug with the `pdftoppm` > tool (which is part of poppler). That way, your bug report becomes > independent from Okular. I see, I have tested with Atril and Evince and they are no better than Okular, clearly this is not Okular-specific. -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 462304] Okular and other poppler related tools cannot handle some pdf pages
https://bugs.kde.org/show_bug.cgi?id=462304 --- Comment #6 from cipricus --- (In reply to Oliver Sander from comment #5) > Can you post a poppler bug for this, please? Are you addressing me or the previous comment? Should I post that bug? -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 462304] Okular and other poppler related tools cannot handle some pdf pages
https://bugs.kde.org/show_bug.cgi?id=462304 --- Comment #3 from cipricus --- If that page is printed as pdf in Firefox or (after selecting "print as image") in Chromium/Chrome-based browsers, the resulting pdf is seen ok in Okular. -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 462304] Okular and other poppler related tools cannot handle some pdf pages
https://bugs.kde.org/show_bug.cgi?id=462304 --- Comment #2 from cipricus --- Comment on attachment 154078 --> https://bugs.kde.org/attachment.cgi?id=154078 example of the pdf page Okular views as blank Open that in Okular or qpdfview: only a footer is see. Open it in an internet browser other than Falkon, in adobe Reader, Foxit reader, mupdf, Master pdf etc and the page is seen in full. -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 462304] Okular and other poppler related tools cannot handle some pdf pages
https://bugs.kde.org/show_bug.cgi?id=462304 --- Comment #1 from cipricus --- > internet browser except Falkon, Adobe Reader, Foxit, Master PDF, WPS PDF, > LibreOffice Draw, ImageMagick, mupdf, PDF Studio Viewer What I mean is: only Okular, qpdfview, Falkon and Evince seem affected; the rest of the tools that I've tested (internet browsers - excepting Falkon -, Adobe Reader, Foxit, Master PDF, WPS PDF, LibreOffice Draw, ImageMagick, mupdf, PDF Studio Viewer) are not affected. -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 462304] New: Okular and other poppler related tools cannot handle some pdf pages
https://bugs.kde.org/show_bug.cgi?id=462304 Bug ID: 462304 Summary: Okular and other poppler related tools cannot handle some pdf pages Classification: Applications Product: okular Version: 22.08.1 Platform: Ubuntu OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: PDF backend Assignee: okular-de...@kde.org Reporter: cipri...@gmail.com Target Milestone: --- Created attachment 154078 --> https://bugs.kde.org/attachment.cgi?id=154078=edit example of the pdf page Okular views as blank Okular cannot see the content of many pages of an old scanned book. they appear blank although many other tools can see them just fine (internet browser except Falkon, Adobe Reader, Foxit, Master PDF, WPS PDF, LibreOffice Draw, ImageMagick, mupdf, PDF Studio Viewer). The problem seems to be with poppler, because qpdfviewer and Falkon have the same problem. As far as I could test Evince cannot even open that pdf. I couldn't get technical details on that type of page, so I'll upload here a sample. More details at links posted here: https://www.reddit.com/r/kde/comments/z591ia/how_come_only_okular_cannot_see_this_pdf_page/?utm_source=share_medium=web2x=3 -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 461876] New: Full-screen should also hide tabs
https://bugs.kde.org/show_bug.cgi?id=461876 Bug ID: 461876 Summary: Full-screen should also hide tabs Classification: Applications Product: okular Version: 22.08.2 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: PDF backend Assignee: okular-de...@kde.org Reporter: cipri...@gmail.com Target Milestone: --- If opening new files in tabs is enabled, full-screen doesn't hide the tabs, which beats the purpose of using full-sceen. The expected result is to have the "full" full-srceen, no matter if tabs are enabled or not: as far as I know from other applications that support both tabs and full-screen view, tabs being part of the main GUI and full-screen being a way to hide that GUI, tabs should be hidden in full-screen, like it happens in internet browsers. It makes little sense to hide panels (and thus panel-tabs as it were, of other applications), window manager borders and the rest, while keeping different tabs within Okular visible. In full-screen view tabs should be hidden - and become visible only when pushing the upper margin. -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 457018] Full screen fails and displays a window without toolbar
https://bugs.kde.org/show_bug.cgi?id=457018 cipricus changed: What|Removed |Added Platform|Fedora RPMs |unspecified -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 457018] Full screen fails and displays a window without toolbar
https://bugs.kde.org/show_bug.cgi?id=457018 --- Comment #6 from cipricus --- I have this bug again from time to time always in relation to Okular being closed while in fullscreen. Kubuntu 22.10 with backports repos. Plasma 5.26.2 Okular 22.08.2 looking back this is an very very old bug! for example a report from 2009: https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/329337 -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 461012] Feature request: Add a possibility for image to ignore color change
https://bugs.kde.org/show_bug.cgi?id=461012 --- Comment #3 from cipricus --- (In reply to David Hurka from comment #2) > You forget the superweapon of digitalization: scanned PDFs. ;) There are indeed many pdf files made out of images (that is: images of text), but not most of them, and many are a mix of text (not image) and image (pictures, pictural forms, not text). For the latter it makes no sense whatsoever to see them inverted or with their colors modified according to a setting that makes sense only for text. Therefore an option not to apply to image the color for text (non-image text) would be great. (e.g. such option is present in Foxit Reader for Linux). -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 461015] Feature request: add option to set colors of background and text no matter their initial color
https://bugs.kde.org/show_bug.cgi?id=461015 --- Comment #1 from cipricus --- Correction: STEPS TO REPRODUCE 1. Open a page like that in part 1 of attachment, setting a "light" (background) color of #1b1e20, and a "dark" (font) color of #d5e9fc -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 461015] New: Feature request: add option to set colors of background and text no matter their initial color
https://bugs.kde.org/show_bug.cgi?id=461015 Bug ID: 461015 Summary: Feature request: add option to set colors of background and text no matter their initial color Classification: Applications Product: okular Version: 22.08.2 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: PDF backend Assignee: okular-de...@kde.org Reporter: cipri...@gmail.com Target Milestone: --- Created attachment 153215 --> https://bugs.kde.org/attachment.cgi?id=153215=edit image with pdf page colors Some pdf files have text pages that are in fact images of book text pages with multiple colors and shades. Inverting the colors or changing the colors only imposes two selected colors onto that and readability is not improved. STEPS TO REPRODUCE 1. Open a page like that in part 1 of attachment, setting a "light" (background) color of #1b1e20, and a "dark" (font) color of #1b1e20 OR: 2. invert colors. OBSERVED RESULT 1. it looks like the page part 2 of attachment; the background color is not uniform and lighter than expected (mostly about #434A50); the text color is darker than expected (about #C5D8E9) OR: 2. it looks like part 3 of attachment; the background is bright blue (#1F446E) EXPECTED RESULT The colors should be those selected initially. SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: (available in About System) KDE Plasma Version: 5.26.1 KDE Frameworks Version: Qt Version: ADDITIONAL INFORMATION -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 461012] Feature request: Add a possibility for image to ignore color change
https://bugs.kde.org/show_bug.cgi?id=461012 cipricus changed: What|Removed |Added Summary|Add a possibility for image |Feature request: Add a |to ignore color change |possibility for image to ||ignore color change -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 461012] Add a possibility for image to ignore color change
https://bugs.kde.org/show_bug.cgi?id=461012 --- Comment #1 from cipricus --- The only use for color change in images seem to be when the images are images of text. In many cases they are not, so changing their colors is not useful and should be optional. -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 461012] Add a possibility for image to ignore color change
https://bugs.kde.org/show_bug.cgi?id=461012 cipricus changed: What|Removed |Added CC||cipri...@gmail.com Summary|Add a possibility for image |Add a possibility for image |to ignore color mode|to ignore color change -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 451573] Okular setting Accessibility - Change dark and light colors - should be renamed to 'Change text and background colors'
https://bugs.kde.org/show_bug.cgi?id=451573 cipricus changed: What|Removed |Added Summary|Okular setting |Okular setting |Accessibility - Change dark |Accessibility - Change dark |and light colors - should |and light colors - should |be renamed to 'Change |be renamed to 'Change text |foreground and background |and background colors' |colors' | -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 451573] Okular setting Accessibility - Change dark and light colors - should be renamed to 'Change foreground and background colors'
https://bugs.kde.org/show_bug.cgi?id=451573 cipricus changed: What|Removed |Added Version|21.12.3 |22.08.2 -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 451573] Okular setting Accessibility - Change dark and light colors - should be renamed to 'Change foreground and background colors'
https://bugs.kde.org/show_bug.cgi?id=451573 --- Comment #6 from cipricus --- There is a case where images should be affected by color change: when these images are images of text, where again "background color" and "text color" would be useful terminology. -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 451573] Okular setting Accessibility - Change dark and light colors - should be renamed to 'Change foreground and background colors'
https://bugs.kde.org/show_bug.cgi?id=451573 --- Comment #5 from cipricus --- I am changing my mind back - the settings should be called "background" and "text" - based on new arguments, detailed here: https://www.reddit.com/r/kde/comments/ydv4g7/comment/itubc9q/?utm_source=share_medium=web2x=3 https://www.reddit.com/r/kde/comments/ydqsvc/comment/itubuzf/?utm_source=share_medium=web2x=3 In fact this is related to the fact whether images should be affected by color change or not. it seems obvious to me that thay should not, as asked here: https://www.reddit.com/r/kde/comments/ydqsvc/okular_invert_colors_but_not_for_images/?utm_source=share_medium=web2x=3 The contrary argument (namely: that the background can be light or dark) makes sense only for images. But if images should not be affected by color change then the color change settings are really only about background and foreground=text. -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 457018] Full screen fails and displays a window without toolbar
https://bugs.kde.org/show_bug.cgi?id=457018 --- Comment #4 from cipricus --- (In reply to cipricus from comment #3) > (In reply to Albert Astals Cid from comment #2) > > i guess you're using Plasma/Wayland instead of Plasma/X11? Can you confirm > > all works fine in Plasma/X11? > > No, it is not in Wayland, I only use X11. Fedora 36 KDE, Plasma 5.25.3, Okular 22.04.1. I though this issue more severe before realizing I can set a shortcut for restoring toolbar. -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 457018] Full screen fails and displays a window without toolbar
https://bugs.kde.org/show_bug.cgi?id=457018 --- Comment #3 from cipricus --- (In reply to Albert Astals Cid from comment #2) > i guess you're using Plasma/Wayland instead of Plasma/X11? Can you confirm > all works fine in Plasma/X11? No, it is not in Wayland, I only use X11. -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 457018] Full screen fails and displays a window without toolbar
https://bugs.kde.org/show_bug.cgi?id=457018 --- Comment #1 from cipricus --- If a fullscreen document is closed and then re-opened it opens in fullscreen. But if instead a new one is opened (if the first one is closed and stays closed) this (the second one) is not fullscreen and has no toolbar. If the first document opened in fullscreen is not closed, then the second one is also opened in fullscreen. -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 457018] New: Full screen fails and displays a window without toolbar
https://bugs.kde.org/show_bug.cgi?id=457018 Bug ID: 457018 Summary: Full screen fails and displays a window without toolbar Product: okular Version: 22.04.1 Platform: Fedora RPMs OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: okular-de...@kde.org Reporter: cipri...@gmail.com Target Milestone: --- SUMMARY https://www.reddit.com/r/kde/comments/w5ab68/okuar_if_in_full_screen_while_tabs_are_disabled/ STEPS TO REPRODUCE 1. Option to open new documents in tab is disabled 2. Full screen is enabled for an open document (this first document can be then closed; the result is the same) 3. Open a new document from the file manager OBSERVED RESULT The new document is not full screen and it has no toolbar. If this is closed and the initial document is opened it is also affected. Menus and fullscreen can be triggered with shortcut. Toolbar can also be restored from shortcut - if that was set. EXPECTED RESULT The second document should be fullscreen or in normal view If a fullscreen document is closed and then re-opened it opens in fullscreen. But if instead a new one is opened this is not fullscreen and has no toolbar. SOFTWARE/OS VERSIONS Linux/KDE Plasma: (available in About System) KDE Plasma Version: 5.25.3 KDE Frameworks Version: 5.96 Qt Version: 5.15.3 ADDITIONAL INFORMATION -- You are receiving this mail because: You are watching all bug changes.
[Haruna] [Bug 456384] Feature request: aspect ratio setting
https://bugs.kde.org/show_bug.cgi?id=456384 cipricus changed: What|Removed |Added Platform|Other |Flatpak -- You are receiving this mail because: You are watching all bug changes.
[Haruna] [Bug 456384] New: Feature request: aspect ratio setting
https://bugs.kde.org/show_bug.cgi?id=456384 Bug ID: 456384 Summary: Feature request: aspect ratio setting Product: Haruna Version: 0.8.0 Platform: Other OS: Linux Status: REPORTED Severity: wishlist Priority: NOR Component: generic Assignee: georgefb...@gmail.com Reporter: cipri...@gmail.com Target Milestone: --- STEPS TO REPRODUCE 1. open a video that has an improper aspect ratio, e.g. it's flat and needs aspect ratio be changed to 4:3 2. 3. OBSERVED RESULT No such setting in Haruna, no way to change aspect ratio EXPECTED RESULT SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: (available in About System) KDE Plasma Version: KDE Frameworks Version: Qt Version: ADDITIONAL INFORMATION -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 456312] Opening a folder that is already opened in Dolphin should focus its window no matter the option "Open new folders in tabs"
https://bugs.kde.org/show_bug.cgi?id=456312 cipricus changed: What|Removed |Added CC||cipri...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 456312] Opening a folder that is already opened in Dolphin should focus its window no matter the option "Open new folders in tabs"
https://bugs.kde.org/show_bug.cgi?id=456312 --- Comment #1 from cipricus --- Having a folder on the desktop called "test" which is not opened in Dolphin: double clicking it a first time opens a new tab or a new window, based on the option Settings > "Startup" > "Open new folders in tabs". Double clicking it a second time should either focus the already opened tab/window (no matter the option Settings > "Startup" > "Open new folders in tabs"), or open a new tab or a new window (depending on the option Settings > "Startup" > "Open new folders in tabs"). But the option Settings > "Startup" > "Open new folders in tabs" should not affect focus. -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 456312] New: Opening a folder that is already opened in Dolphin should focus its window no matter the option "Open new folders in tabs"
https://bugs.kde.org/show_bug.cgi?id=456312 Bug ID: 456312 Summary: Opening a folder that is already opened in Dolphin should focus its window no matter the option "Open new folders in tabs" Product: dolphin Version: 21.12.3 Platform: Ubuntu Packages OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: dolphin-bugs-n...@kde.org Reporter: cipri...@gmail.com CC: kfm-de...@kde.org Target Milestone: --- If the option "Open new folders in tabs" is enabled: clicking to open on the desktop a folder that is already open in Dolphin focuses that window. If the option "Open new folders in tabs" is disabled: clicking to open on the desktop a folder that is already open in Dolphin opens that folder in a new window. That is unexpected: the option to open a new folder in a tab or a window should not affect the fact that if a folder is opened in Dolphin its window should be focused instead of it being opened in a new window . Focus an already opened window/tab should always happen or, if that's not true, it's incoherent to have that focus when the option "Open new folders in tabs" is enabled: logically that focus should happen in both cases or in none. STEPS TO REPRODUCE 1. enable or disable the Settings > "Startup" > "Open new folders in tabs" option OBSERVED RESULT 1. if enabled, clicking to open on the desktop a folder that is already open in Dolphin focuses that window. 2, if disabled, clicking to open on the desktop a folder that is already open in Dolphin opens that folder in a new window EXPECTED RESULT That option should not change the fact that the window/tab of an already open folder should be focused (instead of a new one being opened) when opening that folder again. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Kubuntu 22.04 (available in About System) KDE Plasma Version: 5.24.4 KDE Frameworks Version: 5.92.0 Qt Version: 5.15.3 -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 451651] "Dark color" should be changed to "Black" and "Light color" to "White" under "Okular setting Accessibility - Change dark and light colors'
https://bugs.kde.org/show_bug.cgi?id=451651 --- Comment #3 from cipricus --- In the present form, a real color (expressed in numerical form of complete clarity) is supposed to replace something called "dark" or "light color", which is not a real color but a relation between two colors, and thus cannot be replaced by a real color. (What that specific, numerically defined, real color replaces is pure black or pure white). -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 451651] "Dark color" should be changed to "Black" and "Light color" to "White" under "Okular setting Accessibility - Change dark and light colors'
https://bugs.kde.org/show_bug.cgi?id=451651 --- Comment #2 from cipricus --- I mean that the name of the option 'Color mode: Change dark and light colors' should NOT be changed, because it describes well *what* it does, but that the 2 color selection options (which describe *how* it does it) should be renamed to "black" and "white". -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 451651] "Dark color" should be changed to "Black" and "Light color" to "White" under "Okular setting Accessibility - Change dark and light colors'
https://bugs.kde.org/show_bug.cgi?id=451651 --- Comment #1 from cipricus --- The setting discussed here imposes degrees of just 2 colors on a dark/light structure — and this structure can only by a monochrome one, with degrees of black and white. The 2 colors that can be selected here are proportionally replacing black and white within the monochrome structure. When we set a color (e.g. red, #aa) under "dark color" option, #aa will effectively replace absolute black (#00), and if we set it under "light color" it will replace full white (#ff). -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 451651] New: "Dark color" should be changed to "Black" and "Light color" to "White" under "Okular setting Accessibility - Change dark and light colors'
https://bugs.kde.org/show_bug.cgi?id=451651 Bug ID: 451651 Summary: "Dark color" should be changed to "Black" and "Light color" to "White" under "Okular setting Accessibility - Change dark and light colors' Product: okular Version: 21.12.3 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: okular-de...@kde.org Reporter: cipri...@gmail.com Target Milestone: --- Created attachment 147581 --> https://bugs.kde.org/attachment.cgi?id=147581=edit the setting discussed here Within the discussion (https://invent.kde.org/graphics/okular/-/merge_requests/587#) of my previous bug report (https://bugs.kde.org/show_bug.cgi?id=451573) I was convinced that I was wrong, but the same line of argument that has convinced me imposes a further clarification. Those settings are not about foreground and background, nor about text or images. Any text or image would be treated as a monochrome one (with degrees of black and white), "Dark color" setting will replace black, "Light color" setting will replace white. For example, if "Dark color" is set to red and "Light color" is set to purple, the proportion of red and purple will follow the initial proportions of black and white from the monochrome base. That means that "black" should be used for "dark" and "white" for "light" as more adequate naming of those settings, because that's what is happening in fact: the color selected under "light color" setting (purple in example) will 100% replace light color only if that is fully white, otherwise (if it has some degree of black) it will mix it with the color set under the "dark color" setting (red in example)! The advantage of that would be to add more clarity: dark and light are relative terms, black and white correspond exactly to what is happening here. -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 451573] Okular setting Accessibility - Change dark and light colors - should be renamed to 'Change foreground and background colors'
https://bugs.kde.org/show_bug.cgi?id=451573 --- Comment #4 from cipricus --- I think this is not the case, and should be closed. I have argued here: https://invent.kde.org/graphics/okular/-/merge_requests/587#note_417031 -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 451573] Okular setting Accessibility - Change dark and light colors - should be renamed to 'Change foreground and background colors'
https://bugs.kde.org/show_bug.cgi?id=451573 --- Comment #3 from cipricus --- (In reply to Bug Janitor Service from comment #2) > A possibly relevant merge request was started @ > https://invent.kde.org/graphics/okular/-/merge_requests/587 I have changed my mind after seeing reply by @davidhurka (https://invent.kde.org/graphics/okular/-/merge_requests/587#note_416624). I now think that the present terminology is preferable to the one mentioned in this bug report and that a change could be proposed in favor of "black" and "white'. My argument is here: https://invent.kde.org/graphics/okular/-/merge_requests/587#note_417031 -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 451573] Okular setting Accessibility - Change dark and light colors - should be renamed to 'Change foreground and background colors'
https://bugs.kde.org/show_bug.cgi?id=451573 --- Comment #1 from cipricus --- So, instead of : * "Change dark and light colors" >"Change foreground and background colors" * "Dark color">"Foreground color" * "Light color" >"Background color" -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 451573] Okular setting Accessibility - Change dark and light colors - should be renamed to 'Change foreground and background colors'
https://bugs.kde.org/show_bug.cgi?id=451573 cipricus changed: What|Removed |Added CC||cipri...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 451573] New: Okular setting Accessibility - Change dark and light colors - should be renamed to 'Change foreground and background colors'
https://bugs.kde.org/show_bug.cgi?id=451573 Bug ID: 451573 Summary: Okular setting Accessibility - Change dark and light colors - should be renamed to 'Change foreground and background colors' Product: okular Version: 21.12.3 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: okular-de...@kde.org Reporter: cipri...@gmail.com Target Milestone: --- Created attachment 147527 --> https://bugs.kde.org/attachment.cgi?id=147527=edit Settings - Configure Okular - Accessibility - Change colors - 'Change dark and light colors' Settings - Configure Okular - Accessibility - Change colors - 'Change dark and light colors' is an excellent option to display text in full yet adjustable dark mode. But the way the options are named is confusing, because it makes little sense saying "dark" or "light" when any color can be set there. In fact under "dark color" it's the font (foreground) color setting - the one under "light color" it's the background color. And that's how they should be called. -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 450455] Recent files and locations listed in Dolphin panel "Recent" are very old
https://bugs.kde.org/show_bug.cgi?id=450455 --- Comment #1 from cipricus --- Maybe this is not a bug at all, just a corruption on my system? As a workaround I have added `timeline:/calendar/` and `timeline:/today/` to "Places" in Dolphin, which adds them automatically under the "Recent" panel (therefore this shouldn't be hidden), which makes me think the `timeline` protocol is the one used by that panel anyway. (For some reason the default entries do not work normally on my system.) The main difference between the default view and the one provided by `timeline:/` is that this does not separate files from folders. -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 450455] Recent files and locations listed in Dolphin panel "Recent" are very old
https://bugs.kde.org/show_bug.cgi?id=450455 cipricus changed: What|Removed |Added CC||cipri...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 450455] New: Recent files and locations listed in Dolphin panel "Recent" are very old
https://bugs.kde.org/show_bug.cgi?id=450455 Bug ID: 450455 Summary: Recent files and locations listed in Dolphin panel "Recent" are very old Product: dolphin Version: 21.12.2 Platform: Ubuntu Packages OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: view-engine: general Assignee: dolphin-bugs-n...@kde.org Reporter: cipri...@gmail.com CC: kfm-de...@kde.org Target Milestone: --- Created attachment 146864 --> https://bugs.kde.org/attachment.cgi?id=146864=edit screenshot with dolphin and dashboard widget Recent files and locations shown in Dolphin panel "Recent" (and thus in KDE file dialog too) under 'Recent files' and 'Recent locations' are not recent at all. All I see is files (in 'Recent Files') and folders (in 'Recent Locations') from my system but that I am 100% sure I have not accessed in months, while the system seems to think that happened a few minutes ago. (I have also noticed that recent files and recent applications are also askew in the Application Dashboard launcher too: they are too old, 'recent files' there are those from the list in Dolphin, the 'recent applications' have not been used at all lately.) STEPS TO REPRODUCE 1. access various files and folders in the last hours and even days 2. remember or make a note of folders and files used in this way OBSERVED RESULT Recent files and locations shown in Dolphin panel "Recent" and in KDE file dialog (as well as, regarding files, in launcher widgets like Application Dashboard that show recent files), are far too old, maybe months. EXPECTED RESULT Folders and files accessed in recent hours or days should be listed instead. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Kubuntu 22.04 (available in About System) KDE Plasma Version: 5.24.1 KDE Frameworks Version: 5.91 Qt Version: 5.15.2 ADDITIONAL INFORMATION I am now in Plasma 5.24 but have seen this in 5.18 and others. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 341143] Bring back per-virtual-desktop wallpapers
https://bugs.kde.org/show_bug.cgi?id=341143 cipricus changed: What|Removed |Added CC||cipri...@gmail.com --- Comment #466 from cipricus --- (In reply to David Edmundson from comment #13) > Your best bet will be to argue this line with a valid reason. > > >different workspaces with different containment/wallpaper can be done with > >activities, and that's what's supported. > > So far the only argument I've seen is "I don't see a reason to use them" > which doesn't stand up as a reason when it solves exactly what you're asking > for. Desktops/workspaces do need wallpaper differentiation —as much as activities do. Saying that one should use activities for wallpapers is like saying "don't use desktops" or like saying "use workspaces instead" when one would complain that there is no activity grid and no other easy way like a shortcut to move windows between activities. Both activities and workspaces need wallpapers and grid, and "send-window" shortcut. As they are they are both imperfect and incapable of compensating each other's faults: https://www.reddit.com/r/kde/comments/rcezjw/are_activities_supposed_to_combine_with_virtual/?utm_source=share_medium=web2x=3 -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 443704] Click current directory to switch to edit mode
https://bugs.kde.org/show_bug.cgi?id=443704 --- Comment #2 from cipricus --- Created attachment 142607 --> https://bugs.kde.org/attachment.cgi?id=142607=edit dolphin location bar, click to edit -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 443704] Click current directory to switch to edit mode
https://bugs.kde.org/show_bug.cgi?id=443704 cipricus changed: What|Removed |Added CC||cipri...@gmail.com --- Comment #1 from cipricus --- (In reply to deresiant from comment #0) > Make clicking the current directory box in the location bar switch to edit > mode. Not sure what it means exactly, "current directory box". I see the location bar, and hovering over it says "Click to edit location"; and that's what happens. -- You are receiving this mail because: You are watching all bug changes.
[Elisa] [Bug 443194] Feature request: display items as list, not just icons, for "Artists", "Genres", and "Files"
https://bugs.kde.org/show_bug.cgi?id=443194 cipricus changed: What|Removed |Added Summary|Feature request: add option |Feature request: display |to display items as list, |items as list, not just |not just icons, for |icons, for "Artists", |"Artists", "Genres", and|"Genres", and "Files" |"Files" | -- You are receiving this mail because: You are watching all bug changes.
[Elisa] [Bug 443194] Feature request: add option to display items as list, not just icons, for "Artists", "Genres", and "Files"
https://bugs.kde.org/show_bug.cgi?id=443194 cipricus changed: What|Removed |Added CC||cipri...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[Elisa] [Bug 443194] Feature request: add option to display items as list, not just icons, for "Artists", "Genres", and "Files"
https://bugs.kde.org/show_bug.cgi?id=443194 --- Comment #2 from cipricus --- AI am not sure, but this may also count as a bug, and not just a feature request, given that the difference between the views (with just some showing lists, without clear reason) might be seen as an inconsistency of design. -- You are receiving this mail because: You are watching all bug changes.
[Elisa] [Bug 443194] Feature request: add option to display items as list, not just icons, for "Artists", "Genres", and "Files"
https://bugs.kde.org/show_bug.cgi?id=443194 --- Comment #1 from cipricus --- Sorry, I have put under "additional info" what should have been under "expected result". -- You are receiving this mail because: You are watching all bug changes.
[Elisa] [Bug 443194] New: Feature request: add option to display items as list, not just icons, for "Artists", "Genres", and "Files"
https://bugs.kde.org/show_bug.cgi?id=443194
Bug ID: 443194
Summary: Feature request: add option to display items as list,
not just icons, for "Artists", "Genres", and "Files"
Product: Elisa
Version: unspecified
Platform: Other
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: general
Assignee: matthieu_gall...@yahoo.fr
Reporter: cipri...@gmail.com
Target Milestone: ---
Created attachment 142059
--> https://bugs.kde.org/attachment.cgi?id=142059=edit
screenshot with the different present views
SUMMARY
When selecting "Recently played", "Frequently played", "Tracks", and "Radios"
a list is displayed; clicking "Albums" a list is displayed at files level; but
in the other cases ("Artists", "Genres", and "Files") the items are listed as
big icons, and there is no option to change that.
STEPS TO REPRODUCE
1. Clicking "Genres", or "Files" on the left options
OBSERVED RESULT
Large icons are displayed for folders or files
EXPECTED RESULT
SOFTWARE/OS VERSIONS
Windows:
macOS:
Linux/KDE Plasma: KaOS
(available in About System)
KDE Plasma Version: 5.22.5
KDE Frameworks Version: 5.86
Qt Version: 5.15.2
ADDITIONAL INFORMATION
A special option to switch the display between icons and list would be the
best. Or at least the last level (for files) should be displayed as list.
--
You are receiving this mail because:
You are watching all bug changes.
[frameworks-kio] [Bug 413885] At least for some versions ~/.cache/kioexec/krun/ was not cleaned up
https://bugs.kde.org/show_bug.cgi?id=413885 cipricus changed: What|Removed |Added CC||cipri...@gmail.com --- Comment #8 from cipricus --- Kubuntu 20.04 affected by this. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 390177] Upgrade to 5.12 activated window decoration menu button, making in-app menu bars disappear
https://bugs.kde.org/show_bug.cgi?id=390177 --- Comment #49 from cipricus --- >From older experience I seem to remember some conflict between this feature (the burger button for global menus) and the Global Menu widget for the panel. Now this seems to be default and cannot be removed. I have posted on askubuntu: https://askubuntu.com/q/1327806/925128 (Is Plasma Global Menu widget installed by default and can it be safely removed?) -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 390177] Upgrade to 5.12 activated window decoration menu button, making in-app menu bars disappear
https://bugs.kde.org/show_bug.cgi?id=390177 cipricus changed: What|Removed |Added CC||cipri...@gmail.com --- Comment #48 from cipricus --- In Kubuntu 20.04, Plasma 5.18.5, adding the burger button makes menus disappear (from settings too) while the button is not seen. The pin button if added is also absent. -- You are receiving this mail because: You are watching all bug changes.
[kmymoney] [Bug 434259] Disabling notifications for transfers should open a window in all cases
https://bugs.kde.org/show_bug.cgi?id=434259 --- Comment #3 from cipricus --- (In reply to cipricus from comment #2) > @Jack > I'm sorry for my error - I'm a newbie here, when I've noticed it was filed > under KMyMoney I was not able to change it. The issue involves plasmashell > (notifications) and the specific settings in systemsettings5. > I don't know if these are chapters to filing thereunder nor how to do that > if they are. > > Thank you. Maybe it's about "plasma-integration"? -- You are receiving this mail because: You are watching all bug changes.
[kmymoney] [Bug 434259] Disabling notifications for transfers should open a window in all cases
https://bugs.kde.org/show_bug.cgi?id=434259 --- Comment #2 from cipricus --- @Jack I'm sorry for my error - I'm a newbie here, when I've noticed it was filed under KMyMoney I was not able to change it. The issue involves plasmashell (notifications) and the specific settings in systemsettings5. I don't know if these are chapters to filing thereunder nor how to do that if they are. Thank you. -- You are receiving this mail because: You are watching all bug changes.
[kmymoney] [Bug 434259] New: Disabling notifications for transfers should open a window in all cases
https://bugs.kde.org/show_bug.cgi?id=434259 Bug ID: 434259 Summary: Disabling notifications for transfers should open a window in all cases Product: kmymoney Version: unspecified Platform: Kubuntu Packages OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: kmymoney-de...@kde.org Reporter: cipri...@gmail.com Target Milestone: --- SUMMARY STEPS TO REPRODUCE 1. disabling applications transfer for notifications (System Settings → Notifications, under "Application progress", uncheck the "Show in Notifications" checkbox.) there is no more info about transfers in Dolphin at all (except in the task manager, but they cannot be then monitored, stopped etc). 2. leaving "Show in task manager" checked OBSERVED RESULT there is no more info about transfers in Dolphin at all (except in the task manager, but they cannot be then monitored, stopped etc). EXPECTED RESULT a separate window should open with all transfer details like in the case when both task manager and notifications are disabled for applications progress SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: Kubuntu 20.04 (available in About System) KDE Plasma Version: 5.18.5 KDE Frameworks Version: 5.68.0 Qt Version: 5.12.8 (but in later Plasma it's the same) ADDITIONAL INFORMATION more details: https://forum.kde.org/viewtopic.php?f=83=170403=443653#p443653 https://askubuntu.com/a/1322627/925128 -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 396808] New: Edit current profile option opens the editing of a new profile which hasn't a name yet
https://bugs.kde.org/show_bug.cgi?id=396808 Bug ID: 396808 Summary: Edit current profile option opens the editing of a new profile which hasn't a name yet Product: konsole Version: 17.12.3 Platform: Other OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: general Assignee: konsole-de...@kde.org Reporter: cipri...@gmail.com Target Milestone: --- Created attachment 114091 --> https://bugs.kde.org/attachment.cgi?id=114091=edit screenshot of window opened when selecting "Edit current profile" When right-clicking the window (or Settings) and selecting "Edit current profile" the profile opened for editing is not the current profile, but a new one without any name yet. In order to save edits to the current profile in this way, one has to save the new profile with the same name as the current one. That is not expected behavior. The expected behavior would be to select "Edit current profile" and get the options for that very profile (that is - what is triggered by going to "Settings-Manage profiles - selecting the desired profile - Edit"). -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 386838] Dolphin doesn't update view (doesn't show new files)
https://bugs.kde.org/show_bug.cgi?id=386838 cipricus <cipri...@gmail.com> changed: What|Removed |Added CC||cipri...@gmail.com --- Comment #23 from cipricus <cipri...@gmail.com> --- It is still present in Ubuntu 18.04. Dolphin 17.12.3 KDE Plasma 5.12.4 KDE Framework 5.44.0 Qt 5.9.5 Kernel 4.15.0-20-generic 64-bit Opening in parallel Dolphin and PCManFM (or other program able to create files and folders, including in terminal), and creating a new file or folder in the latter, that file or folder is not visible in Dolphin until refreshing with F5. If the file or folder is created with Dolphin, or if Dolphin is started after the creation of the file or folder, Dolphin displays it. - files/folders have to be created in a different program - automatic refresh: absent in Dolphin (restart or refresh needed) -- You are receiving this mail because: You are watching all bug changes.
