[Spectacle] [Bug 490483] New: [Feature Request] Open straight into edit mode in fullscreen
https://bugs.kde.org/show_bug.cgi?id=490483 Bug ID: 490483 Summary: [Feature Request] Open straight into edit mode in fullscreen Classification: Applications Product: Spectacle Version: unspecified Platform: Manjaro OS: Linux Status: REPORTED Severity: wishlist Priority: NOR Component: General Assignee: noaha...@gmail.com Reporter: pri...@jdrabner.eu CC: k...@david-redondo.de Target Milestone: --- SUMMARY I'd like to be able to open Spectacle from the command line straight into its editing mode in fullscreen, without having to manually go into the edit mode and maximizing Spectacle. There does not seem to be any command line argument to achieve this at the moment. My current workaround is to take a screenshot with Spectacle in the background and then open that created file in an editor (eg. "spectacle -a -b -n -o bla.png && krita --nosplash bla.png"). This command I have laid on a shortcut so I can trigger it easily on a single button press and can get right into annotation. While this works, Krita is certainly overkill for quick screenshot annotation. You can get closer to the desired result with this: "spectacle -a -b -n -o bla.png && spectacle -E bla.png", however this will open Spectacle in some default size and not maximized. Something like this would be nice "spectacle -a --maximized --edit_mode". Or maybe instead of "--edit_mode" allow the "-E" argument to not load an existing file, instead using whatever screenshot was taken by the other arguments. -- You are receiving this mail because: You are watching all bug changes.
[Spectacle] [Bug 490483] [Feature Request] Open straight into edit mode in fullscreen
https://bugs.kde.org/show_bug.cgi?id=490483 --- Comment #3 from J D --- (In reply to Noah Davis from comment #2) > Is your request only for CLI or do you also need a way to do this for the > GUI? > For me, it's mostly about the CLI so I can put it on a shortcut. But of course, UI functionality that goes immediately into editing mode after taking a screenshot would not be a bad idea, either. Maybe an additional checkbox in the "Screenshot settings" section below the "Take a new screenshot" buttons? > Maybe I'll also shorten --edit-existing to --edit to make the name more > generic. I'll probably leave --edit-existing > available as a deprecated command for a while if I do that. Sounds good to me. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 501792] Webcam LED permanently turned on without usage (only when plasmashell is running)
https://bugs.kde.org/show_bug.cgi?id=501792 --- Comment #1 from J D --- Note that this might very well be not a plasmashell issue, but of something it relies on. But I don't know anywhere near enough about Plasma internals to determine this. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 501792] New: Webcam LED permanently turned on without usage (only when plasmashell is running)
https://bugs.kde.org/show_bug.cgi?id=501792 Bug ID: 501792 Summary: Webcam LED permanently turned on without usage (only when plasmashell is running) Classification: Plasma Product: plasmashell Version: 6.3.3 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: plasma-b...@kde.org Reporter: pri...@jdrabner.eu CC: k...@davidedmundson.co.uk Target Milestone: 1.0 SUMMARY (It was suggested on the Manjaro forums I post this as a bug report here, see original topic: https://forum.manjaro.org/t/plasma-related-webcam-led-permanently-turned-on-without-usage/175870 ) Since the latest stable update, I have a bit of an unsettling issue: My webcam’s LED is permanently on after reboot. v4l2-ctl --list-devices Microsoft® LifeCam Studio(TM): (usb-:02:00.0-5): /dev/video0 /dev/video1 /dev/media0 Checking lsof and fuser shows none of these are actually being used, so there is nothing nefarious going on. But still, very unsettling. One way I found to turn off the cam’s LED is to un- and re-plug it. That will make the LED flash shortly while it’s being “recognized” but then turn off. Which is what used to happen upon startup, but since the recent update the LED will no longer turn off on its own after it turns on during startup. Another way to turn off the LED - and this is the reason I put this into the KDE Plasma section - is to kill plasmashell. A killall plasmashell will turn the LED off (but also plasma is gone obviously) and a plasmashell --replace will turn it back on permanently. I did not install anything recently that would be audio/video/webcam related, so I can only guess one of the packages updated with the recent (18th March) update for Manjaro is responsible, likely somehow related to Plasma or one of its widgets as killing that "solves" the issue. OBSERVED RESULT See summary. EXPECTED RESULT The LED should not be on permanently after plasmashell starts, only blinking shortly (while "detecting/activating" the device) and then be off unless actively used. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Manjaro Linux x86_64, 6.12.19-1-MANJARO KDE Plasma Version: 6.33 -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 501792] Webcam LED permanently turned on without usage (only when plasmashell is running)
https://bugs.kde.org/show_bug.cgi?id=501792 --- Comment #3 from J D --- (In reply to David Edmundson from comment #2) > There's a plasmoid in the system tray "Camera Indicator" can you confirm if > disabling that makes a difference? I did that and confirmed in the Add Or Manage Widgets... view that no instances are running anymore (also restarted plasmashell). Unfortunately, it made no difference. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 501792] Webcam LED permanently turned on without usage (only when plasmashell is running)
https://bugs.kde.org/show_bug.cgi?id=501792 J D changed: What|Removed |Added Status|NEEDSINFO |REPORTED Resolution|WAITINGFORINFO |--- --- Comment #5 from J D --- I tried disabling a whole bunch of widgets, but could not find the culprit. For now, I am hotfixing this with a service script running on autostart that simulates unplugging the camera and plugging it back a good time after startup in via: ``` echo 0 > "$USB_PATH/authorized" sleep 2 echo 1 > "$USB_PATH/authorized" ``` It's awkward but works. -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 468156] New: Changing custom project folder does not activate “Apply” button
https://bugs.kde.org/show_bug.cgi?id=468156 Bug ID: 468156 Summary: Changing custom project folder does not activate “Apply” button Classification: Applications Product: kdenlive Version: 21.12.3 Platform: Kubuntu OS: Linux Status: REPORTED Severity: minor Priority: NOR Component: User Interface Assignee: j...@kdenlive.org Reporter: jdavid.eisenb...@gmail.com Target Milestone: --- When the “Custom Project Folder” checkbox is already checked, a change to the path does not activate the “Apply” button. STEPS TO REPRODUCE 1. Go to Settings -> Configure kdenlive -> Project Defaults 2. Change the path in “Custom Project Folder” OBSERVED RESULT “Ápply” button is not active. EXPECTED RESULT Activate the button so that the custom folder can be changed without having to exit and restart kdenlive to have the application read the new path. SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: Kubuntu 22.04 (available in About System) KDE Plasma Version: 5.24.7 KDE Frameworks Version: 5.92.0 Qt Version: 5.15.3 ADDITIONAL INFORMATION -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 468156] Changing custom project folder does not activate “Apply” button
https://bugs.kde.org/show_bug.cgi?id=468156 --- Comment #1 from J D Eisenberg --- Appears to be fixed in 22.12.3; feel free to delete this report. -- You are receiving this mail because: You are watching all bug changes.
[kcolorchooser] [Bug 469267] New: Incorrect screen color report on dual monitor (probably) due to incorrect offset calculations
https://bugs.kde.org/show_bug.cgi?id=469267 Bug ID: 469267 Summary: Incorrect screen color report on dual monitor (probably) due to incorrect offset calculations Classification: Applications Product: kcolorchooser Version: 23.04.0 Platform: openSUSE OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: unassigned-b...@kde.org Reporter: k...@jeffreycook.com Target Milestone: --- SUMMARY My display setup is two 3840x2160 monitors side by side, ie a left monitor and a right one. STEPS TO REPRODUCE 1. Open kcolorchooser and select "Pick Screen Color" 2. Move mouse to upper left of left screen and note offsets - 0,0 (correct) 3. Move mouse to lower right of left screen and note offsets - 1919,1080 (wrong) 4. Move mouse to lower left of right screen and note offsets - 3840,1080 (wrong) OBSERVED RESULT Both monitor sizes used appear to be 1920x1080 (wrong) with a starting offset for the right screen of 3841,0 (correct) EXPECTED RESULT 1. - 2. - 3. 3839,2159 (or perhaps 3840,2160) 4. 3840,2160 (or perhaps 3841,2159) SOFTWARE/OS VERSIONS Linux/KDE Plasma: 6.2.12-1-default/ (available in About System) KDE Plasma Version: 5.27.4 KDE Frameworks Version: 5.105.0 Qt Version: 5.15.9 ADDITIONAL INFORMATION -- You are receiving this mail because: You are watching all bug changes.
