[plasmashell] [Bug 478875] SDDM and kscreenlocker does not accept enter key in X11
https://bugs.kde.org/show_bug.cgi?id=478875 Lukas Sabota changed: What|Removed |Added CC||lu...@lwsabota.com -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 479183] With Qt 6.7, no "Add to favorites" and "Remove from favorites" menu items
https://bugs.kde.org/show_bug.cgi?id=479183 Lukas Sabota changed: What|Removed |Added CC||lu...@lwsabota.com -- You are receiving this mail because: You are watching all bug changes.
[Breeze] [Bug 457565] Multiscreen: Window's shadow and outline bleed over when window is maximized or tiled to an edge adjacent to another screen
https://bugs.kde.org/show_bug.cgi?id=457565 Lukas Sabota changed: What|Removed |Added CC||lu...@lwsabota.com -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 463799] Command-line kwin_x11 option to disable painting root/desktop windows
https://bugs.kde.org/show_bug.cgi?id=463799 --- Comment #6 from Lukas Sabota --- I'd also like to add that this background behavior occurs with the OpenGL renderer disabled, so the background is being painted black in more areas of the source than the single function Vlad pointed out. Thanks! -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 463799] Command-line kwin_x11 option to disable painting root/desktop windows
https://bugs.kde.org/show_bug.cgi?id=463799 --- Comment #5 from Lukas Sabota --- Hi, Just to clarify (because there may be some confusion based on the most recent response): this bug report is not describing that a user cannot run kwin standalone without a background. The bug describes that a user running kwin in standalone mode is forced to use a black background. I'm not sure an option to "run without a background" was suggested, but rather some sort of facility to be able to adjust wallpaper for a running kwin session. I completely understand if the KDE team does not want to support non-plasma use-cases (although wish they wouldn't), but I just want to make sure that my request is being understand properly before being rejected. Thank you! -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 463799] Command-line kwin_x11 option to disable painting root/desktop windows
https://bugs.kde.org/show_bug.cgi?id=463799 --- Comment #3 from Lukas Sabota --- I use both kwin_x11 as just a window manager and I also use it as a window manager and compositing manager: because they both seem to work exceptionally well. I was pleasantly surprised to see how well the compositing effects (such as the META+W overview / virtual desktop animations / transparency effects) worked with kwin_x11 in standalone mode. There did appear to be some very minor artifacting during the transition to overview mode, but it didn't prevent overview from functioning at all. Running kwin_x11 will exhibit this black background behavior both when compositing is enabled, and it's when disabled. I also couldn't seem to find where in kwin source code that the root window gets painted black. I've been doing some trial and error with gdb when I've had a spare chance, but haven't yet been able to dedicate much time to investigating. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 463799] Command-line kwin_x11 option to disable painting root/desktop windows
https://bugs.kde.org/show_bug.cgi?id=463799 --- Comment #1 from Lukas Sabota --- I just wanted to add another comment to further clarify: The main issue with running kwin standalone is that the background will be black - no matter what. If kwin could be configured to not touch the root window (as mentioned originally in this ticket) then great! However, another solution would be to allow the user to set the wallpaper through kwin (perhaps through qdbus?). I know there are currently dbus calls for plasma.desktop that can change the wallpaper, but I'm not aware of any that would change the wallpaper in a standalone kwin session. I'm not sure which of these approaches would be more feasible for the kwin codebase and maintainer priorities, but I wanted to indicate that the solution could be different than what's posted in the original bug title. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 463799] New: [FEATURE REQUEST] Command-line kwin_x11 option to disable painting root/desktop windows
https://bugs.kde.org/show_bug.cgi?id=463799 Bug ID: 463799 Summary: [FEATURE REQUEST] Command-line kwin_x11 option to disable painting root/desktop windows Classification: Plasma Product: kwin Version: 5.26.5 Platform: Archlinux OS: Linux Status: REPORTED Severity: wishlist Priority: NOR Component: platform-x11-standalone Assignee: kwin-bugs-n...@kde.org Reporter: lu...@lwsabota.com Target Milestone: --- When kwin_x11 is run outside of a normal plasma session, it is an extremely capable standalone window manager. Currently, the only issue is that kwin paints the desktop background (X11 root window) for each monitor. When kwin_x11 is run outside of a normal plasma session, this results in each monitor having a black background. It's impossible to set the background using normal X11 tools such as hsetroot/feh/fbsetroot while kwin_x11 is active because of the black background that kwin is painting. I'm not sure if it's possible (because I'm still unsure of the exact reason why kwin_x11 has this behavior), but it would be great if there was a command-line option to temporarily disable kwin handling the root windows so that X11 setroot utilities could function. I do realize that kwin is intended for use as the Plasma window manager and compositor and not a standalone window manager. That being said, kwin is one of the best window managers available for X11 and it would be great to be able to utilize kwin in isolation for special use-cases while retaining the ability to control the root windows. If this isn't possible, I'd be interested to know why (I can imagine it might have something to do with the effects or virtual desktop handling, but still haven't looked in to the source enough). Thanks again for the plasma team's hard work on kwin and plasma in general! 1. Start X11 with "exec xterm" as your ".xinitrc" or desktop session 2. Run "hsetroot -solid blue" to change the X11 root window. 3. Run "kwin_x11" and notice the root window change from blue to black. OBSERVED RESULT Root window changes from blue to black EXPECTED RESULT Would be great if there was a command-line option to kwin_x11 to allow the root window to stay blue. SOFTWARE/OS VERSIONS Linux/KDE Plasma: 5.26 KDE Plasma Version: 5.26 Qt Version: 5.15.7 ADDITIONAL INFORMATION -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 452118] On X11, all windows moved to be mostly offscreen after disconnecting external monitor
https://bugs.kde.org/show_bug.cgi?id=452118 --- Comment #15 from Lukas Sabota --- I just wanted to add that if I remove "kscreen", this problem goes away. Of course, KDE display configuration also goes away, but that's an acceptable trade-off for me since I'm fine with using xrandr and scripts. I see the product here is marked as "KWin", but this may in fact be more "kscreen" related. I previously reported this occurs on Intel graphics, but this also occurs on my desktop with an AMD GPU (and open source drivers). This problem seems to occur every time the monitors awake from sleep as well. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 452118] On X11, all windows moved to be mostly offscreen after disconnecting external monitor
https://bugs.kde.org/show_bug.cgi?id=452118 Lukas Sabota changed: What|Removed |Added CC||lu...@lwsabota.com --- Comment #10 from Lukas Sabota --- I am also experiencing this issue on plasma 5.25.5 with X11 with intel graphics. When connecting a new monitor, existing windows on all workspaces are resized to a very small height Operating System: Arch Linux KDE Plasma Version: 5.25.5 KDE Frameworks Version: 5.98.0 Qt Version: 5.15.6 Kernel Version: 5.19.7-arch1-1 (64-bit) Graphics Platform: X11 Graphics Processor: Mesa Intel® HD Graphics 620 -- You are receiving this mail because: You are watching all bug changes.
[kstart] [Bug 456589] kstart5 fails to launch applications when arguments supplied
https://bugs.kde.org/show_bug.cgi?id=456589 Lukas Sabota changed: What|Removed |Added CC||lu...@lwsabota.com -- You are receiving this mail because: You are watching all bug changes.
[kstart] [Bug 456589] New: kstart5 fails to launch applications when arguments supplied
https://bugs.kde.org/show_bug.cgi?id=456589 Bug ID: 456589 Summary: kstart5 fails to launch applications when arguments supplied Product: kstart Version: 5.25.2 Platform: Archlinux Packages OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: unassigned-b...@kde.org Reporter: lu...@lwsabota.com Target Milestone: --- SUMMARY kstart5 is no longer able to start applications when arguments are supplied. See the below example: $ kstart5 konsole -e top kstart: Unknown option 'e'. Here's an attempt to quote the entire command on the command-line: $ kstart5 'konsole -e top' Omitting both --window and --windowclass arguments is not recommended kf.kio.gui: Could not find an executable named: "konsole -e top" QObject::connect(KProcessRunner, KJob): invalid nullptr parameter QObject::connect(KProcessRunner, KJob): invalid nullptr parameter This seems to affect kglobalaccel5 as well when launching .desktop files that contain commands with arguments. Here is an example of a .desktop file that can no longer be launched with a kglobalaccel shortcut key: $ cat ~/.local/share/applications/rofi-run.desktop [Desktop Entry] Categories=Utility; Comment=Dmenu replacement to run applications Exec=rofi -show run %u Keywords=Terminal Name=rofi-run NoDisplay=false Terminal=false Type=Application Version=1.0 When I press the shortcut associated with this desktop entry, the application is not launched and the following error message is displayed in the user journal: Jul 11 09:51:25 myhostname kglobalaccel5[23085]: kstart: Unknown options: s, o, w. This error messages matches the output of attempting to run the command in the desktop file with kstart5: $ kstart5 rofi -show run kstart: Unknown options: s, o, w However, the desktop file can be run through kstart5 by using the --application flag: $ kstart5 --application rofi-run Omitting both --window and --windowclass arguments is not recommended 24849 I'm not privy to the internals of how kglobalaccel and kstart5 communicate with one another, but it seems something has changed in a recent release. I'm not sure whether this bug should be considered in kstart5, or whether kglobalaccel should be passing different arguments to kstart5. Feel free to reassign this "product" as necessary. Let me know if there is any unclear information that I can clear up. Thanks! STEPS TO REPRODUCE 1. Configure a desktop file that requires multiple arguments in the Exec= field. 2. Assign the above desktop application to a plasma custom shortcut. 3. Press the assigned key combination. OBSERVED RESULT The application does not start and an error message is generated in the logs Jul 11 09:51:27 myhostname kglobalaccel5[23090]: kstart: Unknown options: s, o, w. EXPECTED RESULT Expected that the application launches as configured. SOFTWARE/OS VERSIONS Operating System: Arch Linux KDE Plasma Version: 5.25.2 KDE Frameworks Version: 5.96.0 Qt Version: 5.15.5 Kernel Version: 5.18.10-arch1-1 (64-bit) Graphics Platform: X11 ADDITIONAL INFORMATION -- You are receiving this mail because: You are watching all bug changes.
[krunner] [Bug 427069] [wayland] Krunner starts on the left-most screen instead of screen with the cursor on it
https://bugs.kde.org/show_bug.cgi?id=427069 Lukas Sabota changed: What|Removed |Added CC||lu...@lwsabota.com -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 450487] New: Window close shortcut should close focused window in Present Windows UI
https://bugs.kde.org/show_bug.cgi?id=450487 Bug ID: 450487 Summary: Window close shortcut should close focused window in Present Windows UI Product: kwin Version: 5.24.1 Platform: Archlinux Packages OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: effects-present-windows Assignee: kwin-bugs-n...@kde.org Reporter: lu...@lwsabota.com Target Milestone: --- SUMMARY In the present windows UI, there is currently no way (that I am aware of) to close a focused window using the keyboard. In order to close a window while in the Present Windows UI, the user must press the red close icon associated with the window they would like to close. I think it would be a usability improvement to be able to close windows using the configured "Close Window" keyboard shortcut. This would allow a user to be able to get a quick visual overview of the windows they have open on their desktop (or all desktops) and quickly be able to close unnecessary windows using a keyboard shortcut they are already familiar with. STEPS TO REPRODUCE 1. Open the present windows UI using the configured "Expose" or "ExposeAll" keyboard shortcut (or the hot corner). 2. Highlight a window. 3. Press the configured "Close Window" keyboard shortcut (Alt+f4 by default) OBSERVED RESULT The Close Window keyboard shortcut has no effect while the user is in the Present Windows UI. The user must use the mouse to close windows while in the Present Windows UI EXPECTED RESULT SOFTWARE/OS VERSIONS Operating System: Arch Linux KDE Plasma Version: 5.24.1 KDE Frameworks Version: 5.91.0 Qt Version: 5.15.2 Kernel Version: 5.16.9-arch1-1 (64-bit) Graphics Platform: X11 ADDITIONAL INFORMATION Thank you to everyone who has contributed to this awesome desktop environment! -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kglobalaccel] [Bug 441197] Custom Shortcuts Don't Exec .Desktop files that exec sh
https://bugs.kde.org/show_bug.cgi?id=441197 Lukas Sabota changed: What|Removed |Added CC||lu...@lwsabota.com -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kglobalaccel] [Bug 441197] New: Custom Shortcuts Don't Exec .Desktop files that exec sh
https://bugs.kde.org/show_bug.cgi?id=441197 Bug ID: 441197 Summary: Custom Shortcuts Don't Exec .Desktop files that exec sh Product: frameworks-kglobalaccel Version: 5.85.0 Platform: Archlinux Packages OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: kdelibs-b...@kde.org Reporter: lu...@lwsabota.com Target Milestone: --- SUMMARY When a custom shortcut is configured to use a user desktop entry that utilizes "sh" in the desktop file's Exec line, the shortcut does not spawn the program. Desktop files can use /bin/sh to resolve common variables, such as $HOME, that can be very useful to execute applications that are stored within a user's home directory. Here is an example of a desktop file for qrdp, a custom qt application that is located in a user's home directory: --- qrdp.desktop --- [Desktop Entry] Version=1.0 Name=QRdp Comment=Connect to an RDP server Keywords=Internet Exec=sh -c "~/.bin/qrdp" Icon=Qrdp Terminal=false X-MultipleArgs=false Type=Application Categories=Network; This file can be placed in ~/.local/share/applications and it properly parsed by the plasma start menu and krunner, as well as gtk-launch and dex. It can be validated with desktop-file-validate. However, if this desktop file is used in a custom shortcut, the program will not launch when the shortcut is pressed. Changing the exec line from 'Exec=sh -c "~/.bin/qrdp"' to a hardcoded home directory will allow the desktop file to be launched from a kglobalaccel shortcut: Exec=/home/mySpecificUser/.bin/qrdp STEPS TO REPRODUCE 1. Install a desktop file that utilizes /bin/sh in the Exec= line to ~/.local/share/applications 2. Add a shortcut for this desktop file in plasma shortcuts 3. Attempt to use the shortcut, notice the application does not launch OBSERVED RESULT The application contained in the desktop file does not launch when launched via a kglobalaccel shortcut EXPECTED RESULT The application contained in the desktop file is launched when configured as a kglobalaccel shortcut and the shortcut key is pressed SOFTWARE/OS VERSIONS Operating System: Arch Linux KDE Plasma Version: 5.22.4 KDE Frameworks Version: 5.85.0 Qt Version: 5.15.2 Kernel Version: 5.13.10-arch1-1 (64-bit) Graphics Platform: X11 Processors: 16 × AMD Ryzen 7 5800H with Radeon Graphics Memory: 15.5 GiB of RAM Graphics Processor: NVIDIA GeForce RTX 3060 Laptop GPU/PCIe/SSE2 ADDITIONAL INFORMATION -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kglobalaccel] [Bug 433362] Applications started through keyboard shortcuts are not placed in the correct CGroup
https://bugs.kde.org/show_bug.cgi?id=433362 Lukas Sabota changed: What|Removed |Added CC||lu...@lwsabota.com -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 430036] konsole no-toolbar setting missing or forgotten
https://bugs.kde.org/show_bug.cgi?id=430036 Lukas Sabota changed: What|Removed |Added CC||lu...@lwsabota.com --- Comment #45 from Lukas Sabota --- After updating to konsole 21.08.0 on arch linux today, I can also no longer hide any of the toolbars and no longer see a menu item to hide them under "Settings". Downgrading fixes the issue. It doesn't look like konsole 21.08.0 was ready for release... -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kglobalaccel] [Bug 438204] Desktop entry files with uppercase in filenames are not recognized by Shortcuts
https://bugs.kde.org/show_bug.cgi?id=438204 Lukas Sabota changed: What|Removed |Added CC||lu...@lwsabota.com --- Comment #3 from Lukas Sabota --- I can confirm this issue as well. It looks like the desktop filename is getting somehow converted to lowercase before it gets written to the configuration. Adding a shortcut to Alacritty.desktop in kde 5.22.2.1 writes the following in kglobalshortcutsrc: [alacritty.desktop] _k_friendly_name=Alacritty _launch=Meta+,, -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 438277] Plasma crashes in PopupProxy::parent() after the opening of the Klipper (Meta+V)
https://bugs.kde.org/show_bug.cgi?id=438277 Lukas Sabota changed: What|Removed |Added CC||lu...@lwsabota.com -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 424667] Can't access Konsole's settings after disabling the menu bar and window frame
https://bugs.kde.org/show_bug.cgi?id=424667 Lukas Sabota changed: What|Removed |Added CC||lu...@lwsabota.com --- Comment #2 from Lukas Sabota --- Hi, I also ran into this issue today. I believe this is due to the "Global Menu Widget" plasma widget being present. I originally ran into this issue after I added a new panel that contained "Global Menu Widget". When a "Global menu widget" is active on a plasma panel, Konsole does not show the "Show menu bar" item in the context menu. In addition, the CTRL+SHIFT+M keybind to toggle the menubar does not function to toggle the menu bar. Once I removed the "Global menu widget" from the panel and restarted konsole, I saw the "show menubar" context item in konsole and the CTRL+SHIFT+M keybind started working again. I would like to also point out that not all menu functionality for Konsole is available in the "Global menu widget" - so it doesn't make sense to hide Konsole's menubar functionality completely when the widget is active. Thanks to jankusanagi_ on freenode that pointed out that my menubar issue was related to the global menu widget. Much appreciated! -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 421392] plasmashell crashes when opening the thermal monitor widget settings
https://bugs.kde.org/show_bug.cgi?id=421392 Lukas Sabota changed: What|Removed |Added CC||lu...@lwsabota.com --- Comment #2 from Lukas Sabota --- I'm also experiencing this same issue, albeit with an AMD graphics card and not nvidia. I've tried using plasma5-applets-thermal-monitor 1.2.9 and the latest git version - both crash plasmashell when attempting to configure the applet. -- You are receiving this mail because: You are watching all bug changes.
[gwenview] [Bug 415812] New: Remote images are not displayed until "View" toolbar button is pressed
https://bugs.kde.org/show_bug.cgi?id=415812 Bug ID: 415812 Summary: Remote images are not displayed until "View" toolbar button is pressed Product: gwenview Version: 19.12.0 Platform: Archlinux Packages OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: gwenview-bugs-n...@kde.org Reporter: lu...@lwsabota.com Target Milestone: --- Created attachment 124857 --> https://bugs.kde.org/attachment.cgi?id=124857=edit Example of initial gwenview screen after opening remote image SUMMARY When opening remote images in gwenview, they are not initially displayed. Instead, the user must press the "View" button in the toolbar to display the remote image. The proper behavior can be observed when opening a local image. Opening a local image immediately shows the image in the gwenview window. Screenshot attached. STEPS TO REPRODUCE 1. Open a remote image on the command line or through the "File->Open" dialog. For example: "gwenview https://xannode.com/gwenview.png; OBSERVED RESULT The image is "partially" loaded. The titlebar reflects the image resolution and meta information is populated, but the image is not displayed in the main gwenview window. The "view" toolbar button must be pressed in order to display the remote image. EXPECTED RESULT It's expected that the remote image be loaded immediately. SOFTWARE/OS VERSIONS Linux/KDE Plasma: archlinux plasma (available in About System) KDE Plasma Version: 5.17.4 KDE Frameworks Version: 5.65.0 Qt Version: 5.14.0 ADDITIONAL INFORMATION I've experienced this on multiple arch linux machines. I've cleared out my gwenviewrc and still have this issue with a default config. I also saw this bug which is potentially related, but not totally sure (https://bugs.kde.org/show_bug.cgi?id=343796) -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 413258] Feature Request: Next/Previous Konsole Profile Shortcut
https://bugs.kde.org/show_bug.cgi?id=413258 Lukas Sabota changed: What|Removed |Added CC||lu...@lwsabota.com -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 413258] New: Feature Request: Next/Previous Konsole Profile Shortcut
https://bugs.kde.org/show_bug.cgi?id=413258 Bug ID: 413258 Summary: Feature Request: Next/Previous Konsole Profile Shortcut Product: konsole Version: master Platform: Archlinux Packages OS: Linux Status: REPORTED Severity: wishlist Priority: NOR Component: general Assignee: konsole-de...@kde.org Reporter: lu...@lwsabota.com Target Milestone: --- SUMMARY It would be fantastic to have the ability to bind a key to "previous profile" and "next profile" within Konsole. As far as I am aware, the only way to switch profiles is through the "Settings->Switch Profile" menu. I think it would be useful to have keybinds to be able to cycle through the available list of profiles. It may also be useful to have each individual profile be available within the "Configure Shortcuts" menu for hotkey assignment. STEPS TO REPRODUCE 1. N/A 2. 3. OBSERVED RESULT EXPECTED RESULT SOFTWARE/OS VERSIONS Operating System: Arch Linux KDE Plasma Version: 5.17.0 KDE Frameworks Version: 5.63.0 Qt Version: 5.13.1 Kernel Version: 5.3.6-arch1-1-ARCH OS Type: 64-bit Processors: 4 × Intel® Core™ i5-7300U CPU @ 2.60GHz Memory: 7.6 GiB of RAM ADDITIONAL INFORMATION -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 413018] Plasma crashes in slideshow
https://bugs.kde.org/show_bug.cgi?id=413018 Lukas Sabota changed: What|Removed |Added CC||lu...@lwsabota.com -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 406130] Keyboard shortcut for wallpaper change
https://bugs.kde.org/show_bug.cgi?id=406130 Lukas Sabota changed: What|Removed |Added CC||lu...@lwsabota.com -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 412644] "Focus Follows Mouse" Option for konsole split-view
https://bugs.kde.org/show_bug.cgi?id=412644 Lukas Sabota changed: What|Removed |Added Resolution|--- |DUPLICATE Status|REPORTED|RESOLVED --- Comment #1 from Lukas Sabota --- just found this dupe; sorry about that! *** This bug has been marked as a duplicate of bug 412523 *** -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 412523] Focus follows mouse support in Konsole split view
https://bugs.kde.org/show_bug.cgi?id=412523 Lukas Sabota changed: What|Removed |Added CC||lu...@lwsabota.com --- Comment #1 from Lukas Sabota --- *** Bug 412644 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 412644] New: "Focus Follows Mouse" Option for konsole split-view
https://bugs.kde.org/show_bug.cgi?id=412644 Bug ID: 412644 Summary: "Focus Follows Mouse" Option for konsole split-view Product: konsole Version: 19.08.1 Platform: Archlinux Packages OS: Linux Status: REPORTED Severity: wishlist Priority: NOR Component: split-view Assignee: konsole-de...@kde.org Reporter: lu...@lwsabota.com Target Milestone: --- SUMMARY Konsole currently uses a click-to-focus model for split panes. It would be fantastic to have a mouse-to-focus option that would fit in with workflows of users using mouse-to-focus in KWin. STEPS TO REPRODUCE 1. Open a Konsole window 2. Split the window with default hotkey Ctrl-( 3. Focus on each pane OBSERVED RESULT You have to click to focus on each pane. Which is fine, but... EXPECTED RESULT It would be fantastic to have an option for mouse-to-focus. ADDITIONAL INFORMATION Thank you for all the hard work on Konsole and KWin. Really enjoying the new split features! -- You are receiving this mail because: You are watching all bug changes.
[plasma-nm] [Bug 407561] Delete applet config window and move its two options into the KCM
https://bugs.kde.org/show_bug.cgi?id=407561 --- Comment #4 from Lukas Sabota --- Apologies for the dupe - thanks for marking it, Nate. Glad to see this is already being tracked -- You are receiving this mail because: You are watching all bug changes.
[plasma-nm] [Bug 412068] New: Usability: Difficult to distinguish intent between "Configure Networks..." and "Configure Network Connections"
https://bugs.kde.org/show_bug.cgi?id=412068
Bug ID: 412068
Summary: Usability: Difficult to distinguish intent between
"Configure Networks..." and "Configure Network
Connections"
Product: plasma-nm
Version: 5.16.5
Platform: Archlinux Packages
OS: Linux
Status: REPORTED
Severity: minor
Priority: NOR
Component: applet
Assignee: jgrul...@redhat.com
Reporter: lu...@lwsabota.com
Target Milestone: ---
When a user right clicks on "nm-applet" in the Tray, a context menu with a
"Configure Networks..." menu item and a "Configure Network Connections..." menu
item is displayed. When a user clicks on "Configure Network Connections...",
the "Connections - System Settings Module" is shown. When a user clicks on
"Configure Networks..." the configuration for the applet ("Networks Settings")
is shown.
Speaking from personal experience, I typically have to try both of these before
I find what I'm looking for - even though I'm a daily KDE/plasma user
Point 1: The words "Configure Network Connections" and "Configure Networks"
are very similar. It's difficult for a user to distinguish which one is which
without clicking on both to see. Perhaps a different phrase could be used for
"Configure Networks"? Maybe "Configure Networks Applet" or something?
Point 2: Does "Networks Settings" (the applet settings) really needs its own
configuration panel? In my instance, the general tab only shows "Ask for PIN
on modem detection" and "Show virtual connections". I actually don't know what
either of these do. There is also a "Keyboard Shortcuts" tab where you can set
a hotkey to raise the applet. I'm not suggesting that these configuration
options be removed, but maybe they can be refactored into other areas? The
keyboard shortcut could reside within "Global Shortcuts" and maybe the
"General" options could find a better home within the "Configuration Network
Connections" dialog itself?
I also want to point out that I bring this up for discussion - and realize that
usability can be quite subjection. However, I wanted to voice my concern and
see what the KDE team thinks.
STEPS TO REPRODUCE
1. Right click on plasma-nm applet
2. Notice "Configure Network Connections..."
3. Notice "Configure Networks..."
OBSERVED RESULT
EXPECTED RESULT
SOFTWARE/OS VERSIONS
Linux/KDE Plasma: 5.16.5
(available in About System)
KDE Plasma Version: 5.16.5
KDE Frameworks Version: 5.62.0
Qt Version: 5.13.1
ADDITIONAL INFORMATION
--
You are receiving this mail because:
You are watching all bug changes.
[plasmashell] [Bug 405268] Usability: "logout" search term in launcher ranks "Desktop Session" kcm over "logout"
https://bugs.kde.org/show_bug.cgi?id=405268 --- Comment #1 from Lukas Sabota --- Minor typo in bug report (and I don't see an edit function). Second sentence should be: "I imagine most users will more frequently want to log out of plasma when typing "logout" before adjusting their desktop session settings." -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 405268] Usability: "logout" search term in launcher ranks "Desktop Session" kcm over "logout"
https://bugs.kde.org/show_bug.cgi?id=405268 Lukas Sabota changed: What|Removed |Added CC||lu...@lwsabota.com -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 405268] New: Usability: "logout" search term in launcher ranks "Desktop Session" kcm over "logout"
https://bugs.kde.org/show_bug.cgi?id=405268 Bug ID: 405268 Summary: Usability: "logout" search term in launcher ranks "Desktop Session" kcm over "logout" Product: plasmashell Version: 5.15.2 Platform: Archlinux Packages OS: Linux Status: REPORTED Severity: minor Priority: NOR Component: Application Launcher (Kickoff) Assignee: k...@davidedmundson.co.uk Reporter: lu...@lwsabota.com CC: plasma-b...@kde.org Target Milestone: 1.0 SUMMARY When searching "logout" in the Application Launcher (at least in English), the "Desktop Session" kcm module is ranked higher than the "Logout" function. I imagine most users will more frequently want to log out of plasma when typing "plasma" before adjusting their desktop session settings. I'm not sure the details of how the search results for application launcher are ranked, but for usability reasons it would make sense to rank "logout" (which is an exact match) over "Desktop Session" STEPS TO REPRODUCE 1. Use English langauge (en_US in my case; haven't tried others) 2. Click the application launcher (or press the hotkey) 3. Type "logout" OBSERVED RESULT The first result is "Desktop Session" kcm session. The second result is "Logout". EXPECTED RESULT I'd expect the exact match and likely always more frequently used "logout" to be the first result. SOFTWARE/OS VERSIONS Operating System: Arch Linux KDE Plasma Version: 5.15.2 KDE Frameworks Version: 5.55.0 Qt Version: 5.12.1 ADDITIONAL INFORMATION This is a minor usability improvement -- You are receiving this mail because: You are watching all bug changes.
[kdeconnect] [Bug 405244] New: Opening settings on 1.11 crashes kdeconnect android app
https://bugs.kde.org/show_bug.cgi?id=405244 Bug ID: 405244 Summary: Opening settings on 1.11 crashes kdeconnect android app Product: kdeconnect Version: unspecified Platform: Android OS: Android 9.x Status: REPORTED Severity: crash Priority: NOR Component: android-application Assignee: albertv...@gmail.com Reporter: lu...@lwsabota.com Target Milestone: --- SUMMARY When entering the "Settings" menu of KDEConnect on 1.11, the application force closes on my Pixel XL running the official March update of Android Pie. This occured after I upgraded from 1.10.1. I uninstalled completely and reinstalled, and I am still getting this issue. Only downgrading to 1.10 resolves this for me. I'd be happy to provide any additional information if that is required. Note: Version is "unspecified" on this bug report as 1.11 hasn't been added to the bug tracker yet. STEPS TO REPRODUCE 1. Install KDEConnect 1.11 (via F-Droid in my case) 2. Open KDEConnect 3. Enter the settings menu OBSERVED RESULT The application force closes EXPECTED RESULT Expected to see the settings menu SOFTWARE/OS VERSIONS Android: 9.0 (March update) Please let me know if there is any additional information I can provide to assist in debugging this issue. Thanks! -- You are receiving this mail because: You are watching all bug changes.
[kdeconnect] [Bug 405244] Opening settings on 1.11 crashes kdeconnect android app
https://bugs.kde.org/show_bug.cgi?id=405244 Lukas Sabota changed: What|Removed |Added CC||lu...@lwsabota.com -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 403113] After logging out of plasma session, plasma is restarted.
https://bugs.kde.org/show_bug.cgi?id=403113 --- Comment #3 from Lukas Sabota --- (Actually; it looks like I can't change the bug status to CLOSED - so if a mod could step in here at some point that would be great) -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 403113] After logging out of plasma session, plasma is restarted.
https://bugs.kde.org/show_bug.cgi?id=403113
--- Comment #2 from Lukas Sabota ---
UPDATE:
This is a case of user error, but a very difficult case to track down.
I had a "~/.xsession" file for the user that was experiencing this issue that
had just "startkde" in it. So the login manager (both SDDM and LightDM) were
correctly parsing this file which caused two sessions to be launched.
Not sure how kde or sddm/lightdm could have possibly prevented this - since
sddm/lightdm were doing the "right thing" here as far as I know.
I hope somebody having a similar issue will find this PEBKAC bug and think to
check their .xsession :D
I'm going to go ahead and close this - sorry for the noise and hopefully this
helps someone in the future. If anything, SDDM/LightDm could potentially be
more verbose in its logs ("parsing entries from ~/.xsession" or something would
have immediately clued me or any user to check that file).
--
You are receiving this mail because:
You are watching all bug changes.
[plasmashell] [Bug 403113] After logging out of plasma session, plasma is restarted.
https://bugs.kde.org/show_bug.cgi?id=403113 Lukas Sabota changed: What|Removed |Added CC||lu...@lwsabota.com -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 403113] After logging out of plasma session, plasma is restarted.
https://bugs.kde.org/show_bug.cgi?id=403113 --- Comment #1 from Lukas Sabota --- Created attachment 117408 --> https://bugs.kde.org/attachment.cgi?id=117408=edit journalctl -b output I am attaching the journalctl output from a boot where I did the following: 1) Turned the computer on and booted into linux w/ sddm enabled 2) Logged into plasma 3) attempted to log out of plasma, which failed 4) attempted to log out of plasma again, which succeeded at that point I switched to VT2 and ran "journalctl -b > thisBootDump2.txt" to get the log information Please let me know what other information I can provide to assist in identifying the issue - I do realize how difficult it is to look into an issue without firm steps to reproduce -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 403113] New: After logging out of plasma session, plasma is restarted.
https://bugs.kde.org/show_bug.cgi?id=403113 Bug ID: 403113 Summary: After logging out of plasma session, plasma is restarted. Product: plasmashell Version: 5.14.5 Platform: Archlinux Packages OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Lock/logout applet Assignee: plasma-b...@kde.org Reporter: lu...@lwsabota.com Target Milestone: 1.0 Created attachment 117407 --> https://bugs.kde.org/attachment.cgi?id=117407=edit SDDM's ~/.local/share/sddm/xorg-session.log when this issue occurs I am running into an annoying issue where I cannot log out of plasma properly. When I attempt to log out of plasma (using Start->Leave->Logout), I am logged back into plasma. The second time I attempt to logout, the logout succeeds. I initially thought this was a issue related to SDDM. However, I am able to reproduce this issue with LightDM as well. STEPS TO REPRODUCE 1. Start a plasma session (X11) from a Display Manager 2. Attempt to log out of the session (I use "Start->Leave->Logout") OBSERVED RESULT After attempting to log out, the applications for the session are killed.. However, another session is immediately started under the same X11 server. At this point, if you logout of plasma, the session will be properly terminated EXPECTED RESULT I expected the session to logout NOTE: I am unable to reproduce this issue with a brand new user and a brand new plasma configuration. However, plasma should never open an additional session after a user logs out, regardless of the user configuration. I will be happy to provide any additional information to assist in debugging this issue. SOFTWARE/OS VERSIONS Linux/KDE Plasma: 5.14.5 (available in About System) KDE Plasma Version: 5.14.5 KDE Frameworks Version: 5.53.0 Qt Version: 5.12.0 ADDITIONAL INFORMATION I have been experiencing this issue for a few months now - this is not a new issue with the latest plasma/kde packages -- You are receiving this mail because: You are watching all bug changes.
[k3b] [Bug 400553] Can't add certain .wav files to project - get no details in error message
https://bugs.kde.org/show_bug.cgi?id=400553 --- Comment #2 from Lukas Sabota --- Created attachment 116026 --> https://bugs.kde.org/attachment.cgi?id=116026=edit example of wav file that CANNOT be imported into k3b audio project -- You are receiving this mail because: You are watching all bug changes.
[k3b] [Bug 400553] Can't add certain .wav files to project - get no details in error message
https://bugs.kde.org/show_bug.cgi?id=400553 Lukas Sabota changed: What|Removed |Added CC||lu...@lwsabota.com -- You are receiving this mail because: You are watching all bug changes.
[k3b] [Bug 400553] Can't add certain .wav files to project - get no details in error message
https://bugs.kde.org/show_bug.cgi?id=400553 --- Comment #1 from Lukas Sabota --- Created attachment 116025 --> https://bugs.kde.org/attachment.cgi?id=116025=edit example of wav file that can be imported into k3b -- You are receiving this mail because: You are watching all bug changes.
[k3b] [Bug 400553] New: Can't add certain .wav files to project - get no details in error message
https://bugs.kde.org/show_bug.cgi?id=400553 Bug ID: 400553 Summary: Can't add certain .wav files to project - get no details in error message Product: k3b Version: 18.08.1 Platform: Archlinux Packages OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Audio Project Assignee: k...@kde.org Reporter: lu...@lwsabota.com CC: mich...@jabster.pl, tr...@kde.org Target Milestone: --- SUMMARY Some types of wav files are not accepted by k3b in "Audio Project" mode. When attempting to add certain wav files to a k3b project, an error dialog titled "Sorry - K3b" with the text "Problems while adding files to the project." is shown - and no details are provided (even after clicking the details button). Not *all* wav files exhibit this issue, but some do. I will be attaching two separate files: one is an example of something that works, and one is an example that does *not* work. WORKING EXAMPLE filename: Yamaha-V50-Synbass-1-C2.wav "file" output: RIFF (little-endian) data, WAVE audio, Microsoft PCM, 16 bit, stereo 44100 Hz NON WORKING EXAMPLE: filename: perfectRoll.wav "file" output: RIFF (little-endian) data, WAVE audio STEPS TO REPRODUCE 1. Have "perfectRoll.wav" available on your system. 2. Open K3b and select new audio project 3. Drag and drop "perfectRoll.wav" into the audio project OBSERVED RESULT Error dialog titled "Sorry - K3b" with the text "Problems while adding files to the project." is shown - and no details are provided (even after clicking the details button). EXPECTED RESULT File to be added to project SOFTWARE VERSIONS Operating System: Arch Linux KDE Plasma Version: 5.14.2 Qt Version: 5.11.2 KDE Frameworks Version: 5.51.0 Kernel Version: 4.18.16-arch1-1-ARCH OS Type: 64-bit Processors: 12 × Intel® Core™ i7-8700K CPU @ 3.70GHz Memory: 15.6 GiB of RAM ADDITIONAL INFORMATION Sample files (perfectRoll may be too large to upload to tracker) https://xannode.com/Yamaha-V50-Synbass-1-C2.wav https://xannode.com/perfectRoll.wav -- You are receiving this mail because: You are watching all bug changes.
[dragonplayer] [Bug 400350] Volume Scroll-wheel Usability Issues in "Play Media" view
https://bugs.kde.org/show_bug.cgi?id=400350 --- Comment #2 from Lukas Sabota --- Thanks - I wasn't aware of the Qt issue. Much appreciated and sorry for the noise. -- You are receiving this mail because: You are watching all bug changes.
[dragonplayer] [Bug 400350] New: Volume Scroll-wheel Usability Issues in "Play Media" view
https://bugs.kde.org/show_bug.cgi?id=400350 Bug ID: 400350 Summary: Volume Scroll-wheel Usability Issues in "Play Media" view Product: dragonplayer Version: 18.08 Platform: Archlinux Packages OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: sit...@kde.org Reporter: lu...@lwsabota.com CC: myr...@kde.org Target Milestone: --- The scroll wheel in the "Play Media" playlist view of DragonPlayer controls both the volume *and* the scrollbar on the listview when the mouse is in the playlist listview. This is even more confusing when the volume bar is not visible. The user can be scrolling up and down the playlist of files and accidentally adjust the volume when the scrollbar reaches the top or bottom. STEPS TO REPRODUCE 1. Click the "Play Media" button to show the playlist listview. 2. Add enough files to Dragon player or resize the window so that the scrollbar appears. 3. Position the mouse over the listview and scroll up and down. 4. (Bonus) Hide the volume slider to showcase additional potential confusion. OBSERVED RESULT Notice that once the scrollbar reaches the top of the playlist listview, the volume begins to increase. Once the scrollbar reaches the bottom, the volume decreases. EXPECTED RESULT The scroll wheel on the mouse should not control the volume while the mouse is within the playlist listview. Additionally, it would be nice if the entire scroll-to-change volume behavior was togglable. However even with a toggle, the scroll wheel should not control volume while inside the playlist listview. SOFTWARE VERSIONS (available in About System) KDE Plasma Version: 5.14.2 KDE Frameworks Version: 5.51.0 Qt Version: 5.11.2 -- You are receiving this mail because: You are watching all bug changes.
[dragonplayer] [Bug 400350] Volume Scroll-wheel Usability Issues in "Play Media" view
https://bugs.kde.org/show_bug.cgi?id=400350 Lukas Sabota changed: What|Removed |Added CC||lu...@lwsabota.com -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 309264] Don't show "Move to trash" in removable devices and show "Delete" instead
https://bugs.kde.org/show_bug.cgi?id=309264 Lukas Sabota changed: What|Removed |Added CC||lu...@lwsabota.com --- Comment #3 from Lukas Sabota --- This also occurs for MTP devices. I can't imagine a situation where one would want a trash on a MTP (Zune, Android, etc) filestyle -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 399197] [Feature Request] Add toggle box to change "Move to trash" to "Delete" globally
https://bugs.kde.org/show_bug.cgi?id=399197 --- Comment #5 from Lukas Sabota --- Completely understand with this RESOLVED INTENTIONAL SHIFT+DEL is apparently somewhat ubiquitous among linux DE (GNOME at least). Thanks for the consideration, polite explanation, and thank you to the KDE team in general for everyone's hard work. -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 399197] [Feature Request] Add toggle box to change "Move to trash" to "Delete" globally
https://bugs.kde.org/show_bug.cgi?id=399197
--- Comment #3 from Lukas Sabota ---
(In reply to Christoph Feck from comment #2)
> It is already possible to add an 'Delete' entry to the context menu:
> Configure > Dolphin > Services > Delete
You're right. That's one place. The other is the "DEL" key bind can be
changed from "Move to trash" to "delete". In order to change the default
behavior in general (from the keyboard and the context menu), you must change
it within two places.
There could potentially be some UI dolphin preferences ("trash" submenu") to
change the default behavior of the context menu and the DEL key from "Move to
trash" to "delete". This could even potentially be UI without introducing a
new configuration option
I'm just throwing this out as an idea - I do realize that you can make this
change in two places (services and keybinds) to do this, but it could be a
useful addition to the "trash" dolphin submenu.
--
You are receiving this mail because:
You are watching all bug changes.
[dolphin] [Bug 399197] [Feature Request] Add toggle box to change "Move to trash" to "Delete" globally
https://bugs.kde.org/show_bug.cgi?id=399197 --- Comment #1 from Lukas Sabota --- A user in #plasma IRC has pointed out to me that within "Dolphin Preferences -> Services" there is a "Trash" "service" that is shown in right click file menu. A user could potentially change the "Delete" key mapping to actually delete instead of move to trash and enable this service... But I'm still convinced that a checkbox would be helpful to toggle this default behavior. I realize that UX can be very subjective so I want to bring this up to the dolphin team at large. I suppose this is more of a UX idea than a "bug" -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 399197] New: [Feature Request] Add toggle box to change "Move to trash" to "Delete" globally
https://bugs.kde.org/show_bug.cgi?id=399197 Bug ID: 399197 Summary: [Feature Request] Add toggle box to change "Move to trash" to "Delete" globally Product: dolphin Version: 18.08.1 Platform: Archlinux Packages OS: Linux Status: REPORTED Severity: wishlist Priority: NOR Component: general Assignee: dolphin-bugs-n...@kde.org Reporter: lu...@lwsabota.com CC: elvis.angelac...@kde.org Target Milestone: --- In dolphin, shift+delete is used to delete instead of moving the file to the trash. It would be great if there was an option in dolphin that changed the default behavior. Perhaps a toggle option could be added to "Configure Dolphin -> Trash" that gives the user an option to prefer deletion instead of moving to the trash. Maybe a toggle option like this? [ ] Delete files by default instead of moving to trash Thanks again for everyone for their efforts on KDE and plasma -- You are receiving this mail because: You are watching all bug changes.
[skrooge] [Bug 398683] Periodic crashes on dashboard
https://bugs.kde.org/show_bug.cgi?id=398683 --- Comment #27 from Lukas Sabota --- I have not yet been able to reproduce the issue with the latest git commit. Great news! I will continue to test and report back if I run into issues. Thank you for looking into this and addressing this issue! -- You are receiving this mail because: You are watching all bug changes.
[skrooge] [Bug 398683] Periodic crashes on dashboard
https://bugs.kde.org/show_bug.cgi?id=398683 --- Comment #24 from Lukas Sabota --- Created attachment 115055 --> https://bugs.kde.org/attachment.cgi?id=115055=edit another strace output -- You are receiving this mail because: You are watching all bug changes.
[skrooge] [Bug 398683] Periodic crashes on dashboard
https://bugs.kde.org/show_bug.cgi?id=398683 --- Comment #23 from Lukas Sabota --- Created attachment 115054 --> https://bugs.kde.org/attachment.cgi?id=115054=edit strace output running latest git After completely uninstalling all traces of skrooge on my system, I recompiled skrooge from git (5425fbfcb3405379639a71f1fa5d0852a5a393b6) and compiled with the steps you have provided and installed skrooge to /usr on my system. I am able to get the crash to occur - this time on an import. I *do* however see "WARNING: QSqlDatabasePrivate::database: requested database does not belong to the calling thread." in the strace output. I'm not sure why but I can assure that the skrooge package has been removed and I am running the git version: /usr/bin/skrooge --version skrooge 2.16.0BETA -- You are receiving this mail because: You are watching all bug changes.
[skrooge] [Bug 398683] Periodic crashes on dashboard
https://bugs.kde.org/show_bug.cgi?id=398683 --- Comment #22 from Lukas Sabota --- Thank you! I was using horribly outdated information/instructions from https://techbase.kde.org/Projects/Skrooge Again - I apologize for all the noise on this thread but will report back with my findings. I really appreciate your time in helping me. -- You are receiving this mail because: You are watching all bug changes.
[skrooge] [Bug 398683] Periodic crashes on dashboard
https://bugs.kde.org/show_bug.cgi?id=398683 --- Comment #20 from Lukas Sabota --- I've noticed that plugin .so files get installed to "/usr/lib/plugins" instead of "/usr/lib/qt/plugins" (arch linux package location for release skrooge). Not sure what the best way to proceed here is -- You are receiving this mail because: You are watching all bug changes.
[skrooge] [Bug 398683] Periodic crashes on dashboard
https://bugs.kde.org/show_bug.cgi?id=398683 --- Comment #19 from Lukas Sabota --- I apologize for any time wasted with this so far. I've removed release skrooge from my system so we eliminate the possibility of anything being loaded from non-git version. When I try to install from git (mkdir build; cd build; cmake ../; make; sudo make install), I get an error on first run: Information: Loading plugin Skrooge bank plugin failed because the factory could not be found in skrooge_bank: The shared library was not found. Information: Loading plugin Bookmark plugin failed because the factory could not be found in skg_bookmark: The shared library was not found. Information: Loading plugin Undo redo plugin failed because the factory could not be found in skg_undoredo: The shared library was not found. Information: Loading plugin Monthly plugin failed because the factory could not be found in skg_monthly: The shared library was not found. Information: Loading plugin Skrooge scheduled plugin failed because the factory could not be found in skrooge_scheduled: The shared library was not found. Information: Loading plugin Highlight plugin failed because the factory could not be found in skg_highlight: The shared library was not found. Information: Loading plugin Skrooge calculator plugin failed because the factory could not be found in skrooge_calculator: The shared library was not found. Information: Loading plugin Delete plugin failed because the factory could not be found in skg_delete: The shared library was not found. Information: Loading plugin Statistic plugin failed because the factory could not be found in skg_statistic: The shared library was not found. Information: Loading plugin Skrooge payee plugin failed because the factory could not be found in skrooge_payee: The shared library was not found. Information: Loading plugin Dashboard plugin failed because the factory could not be found in skg_dashboard: The shared library was not found. Information: Loading plugin Advice plugin failed because the factory could not be found in skg_advice: The shared library was not found. Information: Loading plugin Skrooge search plugin failed because the factory could not be found in skrooge_search: The shared library was not found. Information: Loading plugin Properties plugin failed because the factory could not be found in skg_properties: The shared library was not found. Information: Loading plugin Skrooge budget plugin failed because the factory could not be found in skrooge_budget: The shared library was not found. Information: Loading plugin Skrooge print plugin failed because the factory could not be found in skg_print: The shared library was not found. Information: Loading plugin Skrooge tracker plugin failed because the factory could not be found in skrooge_tracker: The shared library was not found. Information: Loading plugin Debug plugin failed because the factory could not be found in skg_debug: The shared library was not found. Information: Loading plugin File plugin failed because the factory could not be found in skg_file: The shared library was not found. Information: Loading plugin Skrooge categories plugin failed because the factory could not be found in skrooge_categories: The shared library was not found. Information: Loading plugin Skrooge unit plugin failed because the factory could not be found in skrooge_unit: The shared library was not found. Information: Loading plugin Skrooge report plugin failed because the factory could not be found in skrooge_report: The shared library was not found. Information: Loading plugin Selectall plugin failed because the factory could not be found in skg_selectall: The shared library was not found. Information: Loading plugin Skrooge operation plugin failed because the factory could not be found in skrooge_operation: The shared library was not found. Information: Loading plugin Skrooge import and export plugin failed because the factory could not be found in skrooge_importexport: The shared library was not found Any ideas on what I'm missing here? Thanks again -- You are receiving this mail because: You are watching all bug changes.
[skrooge] [Bug 398683] Periodic crashes on dashboard
https://bugs.kde.org/show_bug.cgi?id=398683 --- Comment #18 from Lukas Sabota --- When I run, I do see 2.16.0BETA as the release in the about. I have been compiling and building to ~/kde with "kdesrc-build" and running with source ~/kde/.setup-env export SKGTRACE=5 ~/kde/usr/bin/skrooge 2>&1 > traces.txt I will try building configured for /usr/ and "make install"ing to rule out; maybe some components are somehow being loaded from /usr in my environment -- You are receiving this mail because: You are watching all bug changes.
[skrooge] [Bug 398683] Periodic crashes on dashboard
https://bugs.kde.org/show_bug.cgi?id=398683 --- Comment #16 from Lukas Sabota --- Created attachment 115053 --> https://bugs.kde.org/attachment.cgi?id=115053=edit strace actually 5425fbfcb340537 My script was wrong before and running the wrong binary. I can confirm this is the git binary that is being run in this case -- You are receiving this mail because: You are watching all bug changes.
[skrooge] [Bug 398683] Periodic crashes on dashboard
https://bugs.kde.org/show_bug.cgi?id=398683 --- Comment #15 from Lukas Sabota --- Oops - yeah you're right. The last two were accidentily with the release version I named my scripts wrong :X sorry about that - I will test again and report back -- You are receiving this mail because: You are watching all bug changes.
[skrooge] [Bug 398683] Periodic crashes on dashboard
https://bugs.kde.org/show_bug.cgi?id=398683 --- Comment #13 from Lukas Sabota --- Created attachment 115052 --> https://bugs.kde.org/attachment.cgi?id=115052=edit strace output of dashboard crash As I was doing more testing, I was able to get a crash from just clicking the dashboard tab. The previous strace was a different scenario to trigger the trash. -- You are receiving this mail because: You are watching all bug changes.
[skrooge] [Bug 398683] Periodic crashes on dashboard
https://bugs.kde.org/show_bug.cgi?id=398683 --- Comment #12 from Lukas Sabota --- Created attachment 115051 --> https://bugs.kde.org/attachment.cgi?id=115051=edit strace output of crash on import When testing 5425fbfcb3405379639a71f1fa5d0852a5a393b6 I did not get a crash on the Dashboard yet - but as I mentioned I don't have a reliable set of steps to reproduce. However, I imported some Quicken transactions which triggered this crash. -- You are receiving this mail because: You are watching all bug changes.
[skrooge] [Bug 398683] Periodic crashes on dashboard
https://bugs.kde.org/show_bug.cgi?id=398683 --- Comment #10 from Lukas Sabota --- Created attachment 115047 --> https://bugs.kde.org/attachment.cgi?id=115047=edit strace output on crash runing 1c5fa5e git Hi, I was able to test with latest git (revision 1c5fa5e1f5f1c6e76b64bd3c74539bd75775c78d ) and was able to reproduce when clicking on the dashboard tab. Note that I can't reproduce this reliably - but usually can get it to happen after clicking around. I've attached the strace output. Hope this helps - please let me know if there is additional information I can provide. Thanks! -- You are receiving this mail because: You are watching all bug changes.
[skrooge] [Bug 398683] Periodic crashes on dashboard
https://bugs.kde.org/show_bug.cgi?id=398683 --- Comment #7 from Lukas Sabota --- Hi Stephane, Thanks for the quick response! I am familiar with both building KDE software and git. I would be happy to test out any potential changes you have. Let me know how I can access them (what branch to compile with, etc) and I will see if I can reproduce. Thanks! -- You are receiving this mail because: You are watching all bug changes.
[skrooge] [Bug 398683] Periodic crashes on dashboard
https://bugs.kde.org/show_bug.cgi?id=398683 --- Comment #5 from Lukas Sabota --- happened again when returning to the dashboard - this time after messing around with budgets -- You are receiving this mail because: You are watching all bug changes.
[skrooge] [Bug 398683] Periodic crashes on dashboard
https://bugs.kde.org/show_bug.cgi?id=398683 --- Comment #4 from Lukas Sabota --- Created attachment 114984 --> https://bugs.kde.org/attachment.cgi?id=114984=edit enhanced strace output -- You are receiving this mail because: You are watching all bug changes.
[skrooge] [Bug 398683] Periodic crashes on dashboard
https://bugs.kde.org/show_bug.cgi?id=398683 --- Comment #3 from Lukas Sabota --- Thanks - I will continue to run with SKGTRACE=5 and in strace and will provide the output the next time I can get it to crash. I can usually get it to crash within 15 minutes or so of use. Much appreciated; will report back with better output -- You are receiving this mail because: You are watching all bug changes.
[skrooge] [Bug 398683] Periodic crashes on dashboard
https://bugs.kde.org/show_bug.cgi?id=398683 --- Comment #1 from Lukas Sabota --- Just a reminder to check the bottom of this strace output - no idea what's going on here -- You are receiving this mail because: You are watching all bug changes.
[skrooge] [Bug 398683] New: Periodic crashes on dashboard
https://bugs.kde.org/show_bug.cgi?id=398683 Bug ID: 398683 Summary: Periodic crashes on dashboard Product: skrooge Version: unspecified Platform: Archlinux Packages OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: general Assignee: guillaume.deb...@gmail.com Reporter: lu...@lwsabota.com CC: steph...@mankowski.fr Target Milestone: --- Created attachment 114982 --> https://bugs.kde.org/attachment.cgi?id=114982=edit strace output during the crash I have been experiencing crashes when running skrooge 2.15.0 on Arch Linux 64. This most recent crash occurred when clicking the "Dashboard" button after checking some transactions. I w as running in Strace and I noticed some extremely strange output of a ton of asian characters. I have attached the tail of the output to this bug report. FWIW the account I am using is normal characters, english transactions. I imported 3 Quicken files for this skrooge file. I would be happy to provide any additional information to help in resolving this issue. I'm going to try to see if I can catch this issue in gdb so I can post a stacktrace. -- You are receiving this mail because: You are watching all bug changes.
[phonon-backend-gstreamer] [Bug 397746] Notification sounds crash applications when using JACK (Previously "Confirm Paste dialog crashes konsole")
https://bugs.kde.org/show_bug.cgi?id=397746 --- Comment #11 from Lukas Sabota --- I have been doing further testing with JACK and phonon-gstreamer on my system. phonon-gstreamer seems to work fine outputting to a JACK sink in most circumstances. I tested the "Test" button in the Multimedia kcm module, tested playing music with dragon, and tested playing blinken with sound enabled. I believe all of these use phonon (and I was set to use gstreamer backend) and they all played audio to my JACK server. For whatever reason it is only notifications played within applications while using phonon-gstreamer and JACK where we have crashing applications. -- You are receiving this mail because: You are watching all bug changes.
[phonon-backend-gstreamer] [Bug 397746] Notification sounds crash applications when using JACK (Previously "Confirm Paste dialog crashes konsole")
https://bugs.kde.org/show_bug.cgi?id=397746 --- Comment #10 from Lukas Sabota --- (In reply to Kai Uwe Broulik from comment #9) > You need libcanberra (including its dev packages installed) and then build > the knotifications framework Thanks Kai! I was able to build knotifications with the august 8th commit for libcanberra support (f03443cfb) and then build konsole against that. When konsole is built against knotifications that is using libcanberra, notifications are played when the JACK server is running and I do not encounter a crash and the notification is played on the JACK server (as expected) -- You are receiving this mail because: You are watching all bug changes.
[phonon-backend-gstreamer] [Bug 397746] Notification sounds crash applications when using JACK (Previously "Confirm Paste dialog crashes konsole")
https://bugs.kde.org/show_bug.cgi?id=397746 --- Comment #8 from Lukas Sabota --- (In reply to Kai Uwe Broulik from comment #7) > I ported KNotifications to use libcanberra lately, can you retry with KDE > Frameworks 5.50? I would be happy to try this. What git repos would I need to compile for "KDE Frameworks"? I have a "kdesrc-build" tree in my home directory but I'm not sure what I would need to build to pick up this libcanberra backend for notifications Thanks! -- You are receiving this mail because: You are watching all bug changes.
[phonon-backend-gstreamer] [Bug 397746] Notification sounds crash applications when using JACK (Previously "Confirm Paste dialog crashes konsole")
https://bugs.kde.org/show_bug.cgi?id=397746 Lukas Sabota changed: What|Removed |Added Summary|Notification crash |Notification sounds crash |applications when using |applications when using |JACK (Previously "Confirm |JACK (Previously "Confirm |Paste dialog crashes|Paste dialog crashes |konsole") |konsole") -- You are receiving this mail because: You are watching all bug changes.
[phonon-backend-gstreamer] [Bug 397746] Notification crash applications when using JACK (Previously "Confirm Paste dialog crashes konsole")
https://bugs.kde.org/show_bug.cgi?id=397746 Lukas Sabota changed: What|Removed |Added CC||myr...@kde.org, ||romain.per...@gmail.com, ||sit...@kde.org, ||tdfisc...@kde.org Component|copy-paste |general Assignee|konsole-de...@kde.org |dvra...@kde.org Product|konsole |phonon-backend-gstreamer Summary|Confirm Paste dialog|Notification crash |crashes konsole |applications when using ||JACK (Previously "Confirm ||Paste dialog crashes ||konsole") Version|18.08.0 |4.9.0 --- Comment #6 from Lukas Sabota --- In testing this with a totally new user on my machine, I have noticed that I had to be running JACK in order to run into this issue with the gstreamer backend. It seems (in my case anyway) that the VLC backend has no problem passing the audio to a Jack sink. But when using the gstreamer backend, phonon is unable to pass audio to the jack sink (and crashes applications in trying to do so). I think one should be able to reproduce this issue with the following steps: 1) Have JACK installed and phonon-gstreamer 2) Start JACK 3) Ensure that phonon-gstreamer backend is enabled in "System Settings -> Multimedia -> Audio and Video - > Backend" 4) Ensure that "Jack sink" is the default audio playback preference in "System Settings -> Multimedia -> Audio and Video -> Device Preference" 5) Apply audio and video settings 6) We need to trigger a KMessageBox that plays a sound. An easy way to do this is with konsole. Open a new console process and go to "Settings->Edit Current Profile" 7) Attempt to change profile name to "" and hit "Apply" The KMessageBox should hang and the subsequent kwin_kill_helper dialogs will also hang while attempting to play the notification sound with the JACK sink enabled. I'm changing component to "phonon-gstreamer" in attempt to clean up this bug. Hope the noise isn't too bad - I keep uncovering more useful information about this issue Note that this does work with the VLC backend (not only does it not crash, but the sound does play) -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 397746] Confirm Paste dialog crashes konsole
https://bugs.kde.org/show_bug.cgi?id=397746 --- Comment #5 from Lukas Sabota --- (continued) However - for some reason when i am using the phonon-gstreamer backend, I do not hear any notification sound when the KMessageBox dialogs are raised and the KMessageBox also hangs the application. It seems that whatever is trying to play the notification sound is getting hung up. I would hope that if the phonon backend is not able to play a sound that instead of crashing the application, it would just not play the sound so the application could continue running. I will be using Phonon-VLC as my preferred phonon as a workaround to this issue - however I would like to get the bottom of the gstreamer issue to prevent a sound backend problem from crashing kde applications Again - I apologize for all of the noise on this issue - but this has been a very serious issue in my use-case and I would really like to get it resolved so no one has to deal with this headache -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 397746] Confirm Paste dialog crashes konsole
https://bugs.kde.org/show_bug.cgi?id=397746 --- Comment #4 from Lukas Sabota --- I apologize for all the noise on this thread but I believe I have found the culprit: phonon-gstreamer When KMessageBox is raised, it attempts to play the default notification sound. In my configuration, when I have "phonon-vlc" as the preferred backend in kcm module "Multimedia->Audio and Video->Backend", the sound is played properly and the "Paste Warning" dialogs and "Sorry" dialogs do not crash the application. However - for some reason when i am using the phonon-gstreamer backend, I do not hear any notification sound when the KMessageBox dialogs are raised and the KMessageBox also hangs the application. It seems that whatever is trying to playy -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 397746] Confirm Paste dialog crashes konsole
https://bugs.kde.org/show_bug.cgi?id=397746 --- Comment #3 from Lukas Sabota --- I would like to add that I am not able to reproduce this issue on my other PC running Arch Linux 64 and plasma. That being said - this is extremely strange behavior with a high chance of losing work if you are affected by this bug - so I want to try to get to the bottom of the issue. I'm not entirely sure what output would help in resolving this issue - but please let me know if anyone has any ideas -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 397746] Confirm Paste dialog crashes konsole
https://bugs.kde.org/show_bug.cgi?id=397746
--- Comment #2 from Lukas Sabota ---
Okay - I have found another way to reproduce this bug that might shed some
light to what is actually going on.
When I try to save a profile with an empty profile name, a KMessageBox is
raised ("Sorry - Konsole") that says "Each profile must have a name before it
can be saved into disk". This KMessageBox fails in the exact same way as the
"Paste Warning" dialog. Here's steps to reproduce:
1) Open Konsole
2) In the menu: Settings -> Edit current profile
3) Under general, clear out what it is "Profile Name" so its empty.
4) Click apply
5) "Sorry - Konsole" KMessageBox appears and is unresponsive
I'm starting to wonder if this is related to KMessageBox - which both
kwin_kill_helper and konsole both use.
--
You are receiving this mail because:
You are watching all bug changes.
[konsole] [Bug 397746] Confirm Paste dialog crashes konsole
https://bugs.kde.org/show_bug.cgi?id=397746 --- Comment #1 from Lukas Sabota --- Created attachment 114544 --> https://bugs.kde.org/attachment.cgi?id=114544=edit strace output of pasting 160k characters This is the output of strace when starting a konsole and pasting 160k characters in order to trigger the "Paste Warning" dialog. Not sure how helpful the output is but maybe someone might see something -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 397746] Confirm Paste dialog crashes konsole
https://bugs.kde.org/show_bug.cgi?id=397746 Lukas Sabota changed: What|Removed |Added CC||lu...@lwsabota.com -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 397746] New: Confirm Paste dialog crashes konsole
https://bugs.kde.org/show_bug.cgi?id=397746 Bug ID: 397746 Summary: Confirm Paste dialog crashes konsole Product: konsole Version: 18.08.0 Platform: Archlinux Packages OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: copy-paste Assignee: konsole-de...@kde.org Reporter: lu...@lwsabota.com Target Milestone: --- When pasting a large amount of text in Konsole, the "Confirm Paste - Konsole" dialog is raised which asks "Are you sure you want to paste characters?". However, every time this dialog appears, I am unable to click on "Continue" or "Cancel" and the parent Konsole also crashes. In addition (may be a separate bug?) - when attempting to close the "Confirm Paste" dialog with the close button on the window titelbar, kwin raises a "Warning - Window Manager" dialog to inform that "Application 'konsole' is not responding". However, I unable to click on "Terminate" or "Wait longer". Shortly after attempting to click on the unresponsive KWin dialog, another "Warning - Window Manager" dialog is raised, but this time because "Application kwin_killer_helper" is not responding. If I click on the new dialog, it will not respond and another "kwin_killer_helper" dialog will appear. I am able to reproduce this Konsole issue reliably with about 20k characters. I am also able to reproduce this kwin issue on any hanging window - not just Konsole windows. I'm not sure if this is a Konsole bug, a KMessageBox bug (or some other KDE API), a Kwin bug, or a Konsole and Kwin bug - but I wanted to get a discussion rolling about this issue and see if others are able to reproduce. Please let me know if there is any additional information to provide - I would be happy to assist troubleshooting this issue. Cheers -- You are receiving this mail because: You are watching all bug changes.
[kdeconnect] [Bug 377058] KDE Connect : SD card empty
https://bugs.kde.org/show_bug.cgi?id=377058 Lukas Sabota changed: What|Removed |Added CC||lu...@lwsabota.com -- You are receiving this mail because: You are watching all bug changes.
[ark] [Bug 396579] Ark fails to password protect files added through Drag and Drop
https://bugs.kde.org/show_bug.cgi?id=396579 --- Comment #10 from Lukas Sabota --- Bingo Chris! Thanks for providing that information. After setting the proper environment variables, I was able to confirm that this patch solves this password zip issue. Thank you so much! Cheers everyone and great job! -- You are receiving this mail because: You are watching all bug changes.
[ark] [Bug 396579] Ark fails to password protect files added through Drag and Drop
https://bugs.kde.org/show_bug.cgi?id=396579 --- Comment #7 from Lukas Sabota --- Elvis, Thanks - you are likely right. I did make sure that I was running the newly compiled Ark binary, but I'm not confident that the newly compiled ark binary was loading the newly compiled plugin. When I try to run Ark after uninstalling the distribution-provided Ark and reinstalling the Ark I compiled from git with "make install", I get an error message when running Ark "Unable to find Ark's KPart component". If someone is aware of what's going wrong here, let me know. Otherwise, I don't want to get this issue too off-topic. The patch seems to directly address the issue and I don't want to cause too much noise hand-holding me through the debugging process. Cheers! -- You are receiving this mail because: You are watching all bug changes.
[ark] [Bug 396579] Ark fails to password protect files added through Drag and Drop
https://bugs.kde.org/show_bug.cgi?id=396579 --- Comment #5 from Lukas Sabota --- Hi Elvis, Really pleased to see a patch for this already! However - I'm actually still able to reproduce this on Ark built against 20c6faa54cc80b5d525e0cddca052c0e5b2888c8. The diff does appear to be addressing the issue. There could be some user error going on in my test, but I wanted to pass back my findings when testing the change. FWIW, when I built I specifically did a "git checkout 20c6faa54" to ensure I had this diff -- You are receiving this mail because: You are watching all bug changes.
[ark] [Bug 396579] Ark fails to password protect files added through Drag and Drop
https://bugs.kde.org/show_bug.cgi?id=396579 Lukas Sabota changed: What|Removed |Added Component|general |plugins Assignee|elvis.angelac...@kde.org|rthoms...@gmail.com CC||elvis.angelac...@kde.org --- Comment #3 from Lukas Sabota --- This issue appears to be related to each specific file involved - and not the entire archive. When creating a multiple file password protected zip file with some files added through the "Add Files..." menu item and some files through drag and drop, the dropped files will not require a password when extracting. -- You are receiving this mail because: You are watching all bug changes.
[ark] [Bug 396579] Ark fails to password protect files added through Drag and Drop
https://bugs.kde.org/show_bug.cgi?id=396579 --- Comment #2 from Lukas Sabota --- Created attachment 113977 --> https://bugs.kde.org/attachment.cgi?id=113977=edit Debug log of reproducing this issue I have attached the debug output when reproducing this issue. The first run of ark is creating the zip file. The second run of ark is testing that the zip file contents are not password protected -- You are receiving this mail because: You are watching all bug changes.
[ark] [Bug 396579] Ark fails to password protect files added through Drag and Drop
https://bugs.kde.org/show_bug.cgi?id=396579 --- Comment #1 from Lukas Sabota --- I was not able to reproduce this issue with 7zip archives. I tested with index being password protected and non protected, and both of them worked as expected. I was also unable to reproduce this issue with Jar archives. On my system, the only other option is tar which does not support passwords. This problem seems exclusive to zip archives. I also tested on the git as of now (55613a057013) and the problem exists there as well. -- You are receiving this mail because: You are watching all bug changes.
[ark] [Bug 396579] New: Ark fails to password protect files added through Drag and Drop
https://bugs.kde.org/show_bug.cgi?id=396579 Bug ID: 396579 Summary: Ark fails to password protect files added through Drag and Drop Product: ark Version: 18.04.3 Platform: Archlinux Packages OS: Linux Status: UNCONFIRMED Severity: major Priority: NOR Component: general Assignee: elvis.angelac...@kde.org Reporter: lu...@lwsabota.com CC: rthoms...@gmail.com Target Milestone: --- Hi, When dealing with a password protected archive, ark will only password protect the files that are added from the "Archive->Add Files" menu item or the CTRL-A shortcut. If you add files by dragging and dropping from dolphin, the files will *not* be encrypted. Steps to reproduce: 1) Open Ark and click "Archive -> New" 2) Choose any filename and change Type to "Zip archive" (i've only tested with zip so far) 3) Click "password protection" and set a password and verify it. 4) Click OK 5) Drag and drop a file from dolpin into Ark. 6) Quit Ark, and open the newly created archive At this point, you will be able to open any of the files within the archive without entering the password. I marked this major because a user could think that his data is password protected when in reality there is no password. -- You are receiving this mail because: You are watching all bug changes.
[ark] [Bug 396579] Ark fails to password protect files added through Drag and Drop
https://bugs.kde.org/show_bug.cgi?id=396579 Lukas Sabota changed: What|Removed |Added CC||lu...@lwsabota.com -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 373232] Horizontal lines with fractional HiDPI scaling
https://bugs.kde.org/show_bug.cgi?id=373232 Lukas Sabota changed: What|Removed |Added CC||lu...@lwsabota.com -- You are receiving this mail because: You are watching all bug changes.
[kdeconnect] [Bug 394954] WRITE_EXTERNAL_STORAGE permissions not properly requested
https://bugs.kde.org/show_bug.cgi?id=394954 Lukas Sabota changed: What|Removed |Added CC||lu...@lwsabota.com --- Comment #3 from Lukas Sabota --- I'm also running into this issue on my Nokia 6.1 (2018), but sadly there is not a safe root option for the device yet to work around this. I am fairly sure non-system applications are able to write to external storage. The "FX File Manager" for Android is able to write to external storage (after asking permission): https://play.google.com/store/apps/details?id=nextapp.fx I don't believe FX is installed as a system application. Sadly it's not an open source example, but I think it may show that it is *possible* -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 395175] support opening multiple files from "File->Open" dialog
https://bugs.kde.org/show_bug.cgi?id=395175 --- Comment #3 from Lukas Sabota --- https://phabricator.kde.org/D13667 works for me -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 395175] support opening multiple files from "File->Open" dialog
https://bugs.kde.org/show_bug.cgi?id=395175 Lukas Sabota changed: What|Removed |Added CC||lu...@lwsabota.com -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 395175] New: support opening multiple files from "File->Open" dialog
https://bugs.kde.org/show_bug.cgi?id=395175 Bug ID: 395175 Summary: support opening multiple files from "File->Open" dialog Product: okular Version: 1.4.1 Platform: Archlinux Packages OS: Linux Status: UNCONFIRMED Severity: wishlist Priority: NOR Component: general Assignee: okular-de...@kde.org Reporter: lu...@lwsabota.com Target Milestone: --- Okular supports opening multiple files at the same time on the command line by specifying multiple PDF files as arguments. However, if one wants to open multiple PDFs within the Okular QT GUI, one must open each one one at a time through the Open dialog since it is a single-file open dialog. I suggest this Open dialog be changed to support multiple files so that users can quickly open a set of PDFs in a directory without having to run okular from the terminal. -- You are receiving this mail because: You are watching all bug changes.
[kdeconnect] [Bug 368438] KDE Connect does not communicate while running in background on phone
https://bugs.kde.org/show_bug.cgi?id=368438 Lukas Sabota changed: What|Removed |Added CC||lu...@lwsabota.com -- You are receiving this mail because: You are watching all bug changes.
[plasma-nm] [Bug 394677] Plasma-nm missing support enabling/disabling/activating bridges
https://bugs.kde.org/show_bug.cgi?id=394677 --- Comment #3 from Lukas Sabota <lu...@lwsabota.com> --- edit: found it - looks like the option isn't in system settings, but it's in "Netowkr Settings - Plasma" config dialog. You can get to this from right clicking on plasma-nm and selecting "Configure Networks" (just in case someone reading this also can't find it) -- You are receiving this mail because: You are watching all bug changes.
