[dolphin] [Bug 322922] Dolphin should not store .directory files inside the actual directory to avoid cluttering and polluting the filesystem; should instead store this data in extended attributes
https://bugs.kde.org/show_bug.cgi?id=322922 Manuel C changed: What|Removed |Added CC||manuel.manu.del...@gmail.co ||m -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 461198] Wayland: Night Colour filter is restored incorrectly to reconnected display
https://bugs.kde.org/show_bug.cgi?id=461198 Manuel C changed: What|Removed |Added Status|NEEDSINFO |RESOLVED Resolution|WAITINGFORINFO |FIXED --- Comment #3 from Manuel C --- Sorry this took me a bit to come back to, with some testing it seems like this is no longer an issue on my end with Plasma 5.27.9. I did encounter another oddity where several times I couldn't re-enable night light until restarting the desktop, after some amount of toggling it in the task bar. But I'll see if I can figure out a way to reproduce this reliably, and file another issue then :> -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 461157] Wayland: Panel set to "Windows can Cover" does not release focus properly, compared to X11
https://bugs.kde.org/show_bug.cgi?id=461157 Manuel C changed: What|Removed |Added CC|manuel.manu.del...@gmail.co | |m | -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 461259] New: Allow assignment of modifier keys to tablet buttons on Wayland
https://bugs.kde.org/show_bug.cgi?id=461259 Bug ID: 461259 Summary: Allow assignment of modifier keys to tablet buttons on Wayland Classification: Applications Product: systemsettings Version: 5.26.2 Platform: Archlinux OS: Linux Status: REPORTED Keywords: usability, wayland Severity: minor Priority: NOR Component: kcm_tablet Assignee: plasma-b...@kde.org Reporter: manuel.manu.del...@gmail.com CC: aleix...@kde.org Target Milestone: --- Created attachment 153361 --> https://bugs.kde.org/attachment.cgi?id=153361=edit Screenshot of tablet button config screen and the associated config file section SUMMARY Under X11, the kcm-wacomtablet used to allow assigning a modifier key (like Ctrl) to a tablet button. The new interface used for Wayland does not, but I was able to set this up by editing the config file manually. This binding is not properly displayed in the settings [see attachment] but works fine otherwise. EXPECTED RESULT Allow for this assignment in the config interface, and show it properly. SOFTWARE/OS VERSIONS Linux: 6.0.5-arch1-1 (64-bit) KDE Plasma Version: 5.26.2 KDE Frameworks Version: 5.99.0 Qt Version: 5.15.6 ADDITIONAL INFORMATION Graphics Platform: Wayland -- You are receiving this mail because: You are watching all bug changes.
[kdeplasma-addons] [Bug 461198] New: Wayland: Night Colour filter is restored incorrectly to reconnected display
https://bugs.kde.org/show_bug.cgi?id=461198 Bug ID: 461198 Summary: Wayland: Night Colour filter is restored incorrectly to reconnected display Classification: Plasma Product: kdeplasma-addons Version: 5.26.2 Platform: Archlinux OS: Linux Status: REPORTED Keywords: reproducible, wayland Severity: normal Priority: NOR Component: Night Color Control Assignee: plasma-b...@kde.org Reporter: manuel.manu.del...@gmail.com CC: kwin-bugs-n...@kde.org, vlad.zahorod...@kde.org Target Milestone: --- SUMMARY I recently switched from X11 to Wayland and found a regression with the Night Colour filter being applied incorrectly. I run a multi-monitor setup, where I usually turn off my monitor at night (when Night Colour is active). When it is reconnected the next day (when Night Colour is off), the monitor still has the Night Colour filter active. This did not happen under X11. To reset this state, I currently manually toggle Night Colour on and then back off. I also tested the reverse, (disconnect while filter off, reconnect with it on) and it still happens. I assume there is just no check if the filter still applies when the display is reconnected. STEPS TO REPRODUCE 1. Have 2 monitors 2. Turn on Night Colour 3. Disconnect, or disable the second monitor 4. Turn off Night Colour 5. Reconnect the monitor OBSERVED RESULT The reconnected display still has the blue light filter applied, while on the other one it is off EXPECTED RESULT The reconnected display has no blue light filter applied, like on the still connected display. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Arch Linux, Kernel 6.0.5-arch1-1 (amd64) KDE Plasma Version: 5.26.2 KDE Frameworks Version: 5.99.0 Qt Version: 5.15.6 ADDITIONAL INFORMATION Graphics Platform: Wayland (1.21.0) -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 461157] Wayland: Panel set to "Windows can Cover" does not release focus properly, compared to X11
https://bugs.kde.org/show_bug.cgi?id=461157 Manuel C changed: What|Removed |Added CC||manuel.manu.del...@gmail.co ||m -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 461157] Wayland: Panel set to "Windows can Cover" does not release focus properly, compared to X11
https://bugs.kde.org/show_bug.cgi?id=461157 Manuel C changed: What|Removed |Added Summary|Switching focus to a window |Wayland: Panel set to |that covers a panel, hides |"Windows can Cover" does |the panel (wayland) |not release focus properly, ||compared to X11 --- Comment #2 from Manuel C --- One more thing I found, that should probably be tacked onto this issue, since it kinda depends on the same functionality: When moving the mouse to the screen edge of the panel, it gets raised into focus. On X11, unless you click on it to raise it explicitly, it goes back to its previous position, shortly after moving the mouse off it. On Wayland, it moves to the top and stays there indefinitely, until I click on a window to cover it again. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 461157] Switching focus to a window that covers a panel, hides the panel (wayland)
https://bugs.kde.org/show_bug.cgi?id=461157 --- Comment #1 from Manuel C --- ADDENDUM: On X11, the panel stays open while the mouse is over it, regardles of windows covering it, and then once the mouse moves off it, after a short delay, it lowers itself to its covered position. I really hope this behaviour can be replicated in Wayland. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 461157] Switching focus to a window that covers a panel, hides the panel (wayland)
https://bugs.kde.org/show_bug.cgi?id=461157 Manuel C changed: What|Removed |Added Keywords||wayland -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 461157] New: Switching focus to a window that covers a panel, hides the panel (wayland)
https://bugs.kde.org/show_bug.cgi?id=461157 Bug ID: 461157 Summary: Switching focus to a window that covers a panel, hides the panel (wayland) Classification: Plasma Product: plasmashell Version: 5.26.2 Platform: Archlinux OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Panel Assignee: plasma-b...@kde.org Reporter: manuel.manu.del...@gmail.com CC: niccolo.venera...@gmail.com Target Milestone: 1.0 SUMMARY I just switched from X11 to wayland, and noticed a regression: I have a panel that is set to "Windows can Cover." When switching to a window that covers this panel, either by clicking or scrolling through the on-panel task manager, the panel instantly gets covered. This didn't happen on X11, where it stayed above the window, until I move the mouse off. This means I can now no longer switch through several windows by scrolling, if one of them is maximized over the panel. I don't know if this changes this behaviour in general, but in "Window Behaviour," I have the window activation policy set to "Focus follows mouse (mouse precedence)" in addition to "Click raises active window." STEPS TO REPRODUCE 1. Set panel to "Window can cover" 2. Open any window covering the panel 3. Switch to the window, clicking on its task manager entry OBSERVED RESULT The panel instantly gets covered and looses focus EXPECTED RESULT The panel stays in focus above the window SOFTWARE/OS VERSIONS Linux: Arch Linux, Kernel 6.0.5-arch1-1 (amd64) (available in About System) KDE Plasma Version: 5.26.2 KDE Frameworks Version: 5.99.0 Qt Version: 5.15.6 ADDITIONAL INFORMATION Graphics Platform: Wayland (1.21.0) -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 428968] New: Show audio activity like pavucontrol
https://bugs.kde.org/show_bug.cgi?id=428968 Bug ID: 428968 Summary: Show audio activity like pavucontrol Product: systemsettings Version: 5.20.2 Platform: Archlinux Packages OS: Linux Status: REPORTED Severity: wishlist Priority: NOR Component: kcm_pulseaudio Assignee: now...@gmail.com Reporter: manuel.manu.del...@gmail.com CC: plasma-b...@kde.org Target Milestone: --- I sometimes need to redirect some audio streams to a different output devices, and in particular with firefox it's difficult to tell which device corresponds to which playback without having a monitor bar like in pavucontrol. I am currently using pavucontrol for this, but with > 8 playback streams the interface becomes difficult to use, as pavucontrol's volume bars react to scrolling, causing accidental mayhem way too often. I would prefer to use the SystemSettings Audio panel for this, mainly since it does not react badly to scrolling, but also because it is just better integrated (tray > Configure audio) Linux: 5.9.4-arch1-1 KDE Plasma Version: 5.20.2 KDE Frameworks Version: 5.75.0 Qt Version: 5.15.1 -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 196998] Konsole should reflow the text when resizing
https://bugs.kde.org/show_bug.cgi?id=196998 Manuel C changed: What|Removed |Added CC||manuel.manu.del...@gmail.co ||m -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 410603] New: Certain components unexpectedly block window move
https://bugs.kde.org/show_bug.cgi?id=410603 Bug ID: 410603 Summary: Certain components unexpectedly block window move Product: systemsettings Version: 5.16.3 Platform: Archlinux Packages OS: Linux Status: REPORTED Severity: minor Priority: NOR Component: general Assignee: plasma-b...@kde.org Reporter: manuel.manu.del...@gmail.com Target Milestone: --- SUMMARY Some of the kcm modules are build such that seemingly free areas that previously could be used to move the window, now many are blocking this with different interactions, like drag scroll or text selection. STEPS TO REPRODUCE 1. Open System Settings 2. Open "Desktop Behaviour" category 3. Open "Workspace" entry OBSERVED RESULT Left mouse drag on the empty area below the options attempts to scroll them, and drag to the right of the header text is just discarded. EXPECTED RESULT Both of these areas used to be usable for window movement, this is still possible for example in the "Screen Locking" entry. SOFTWARE/OS VERSIONS Linux: 5.2.3.arch1-1 KDE Plasma Version: 5.16.3 KDE Frameworks Version: 5.60.0 Qt Version: 5.13.0 -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 359882] can't change auto hide panel activation zone size without resizing panel
https://bugs.kde.org/show_bug.cgi?id=359882 Manuel C changed: What|Removed |Added Status|NEEDSINFO |RESOLVED Resolution|WAITINGFORINFO |WORKSFORME -- You are receiving this mail because: You are watching all bug changes.
[gwenview] [Bug 369688] New: Gwenview crash on zooming particular set of images
https://bugs.kde.org/show_bug.cgi?id=369688 Bug ID: 369688 Summary: Gwenview crash on zooming particular set of images Product: gwenview Version: unspecified Platform: Fedora RPMs OS: Linux Status: UNCONFIRMED Keywords: drkonqi Severity: crash Priority: NOR Component: general Assignee: gwenview-bugs-n...@kde.org Reporter: manuel.manu.del...@gmail.com CC: myr...@kde.org Application: gwenview (16.04.3) Qt Version: 5.6.1 Frameworks Version: 5.26.0 Operating System: Linux 4.7.4-200.fc24.x86_64 x86_64 Distribution: "Fedora release 24 (Twenty Four)" -- Information about the crash: When looking at JPEG files with these exact properties (filesize differs): 'file' output: : JPEG image data, JFIF standard 1.02, resolution (DPI), density 144x144, segment length 16, baseline, precision 8, 1864x1400, frames 3 and imagemagicks 'identify' output: JPEG 880x1400 880x1400+0+0 8-bit Gray 256c 0.000u 0:00.000 gvenview locks up and immediately crashes as soon as the zoom level reaches 50% The crash can be reproduced every time. -- Backtrace: Application: Gwenview (gwenview), signal: Segmentation fault Using host libthread_db library "/lib64/libthread_db.so.1". [Current thread is 1 (Thread 0x7f402afa19c0 (LWP 21860))] Thread 4 (Thread 0x7f4000b3b700 (LWP 21864)): #0 0x7f4022870bd0 in pthread_cond_wait@@GLIBC_2.3.2 () at /lib64/libpthread.so.0 #1 0x7f40039396c3 in radeon_drm_cs_emit_ioctl () at /usr/lib64/dri/r600_dri.so #2 0x7f4003938e07 in impl_thrd_routine () at /usr/lib64/dri/r600_dri.so #3 0x7f402286b5ca in start_thread () at /lib64/libpthread.so.0 #4 0x7f4023e9ef6d in clone () at /lib64/libc.so.6 Thread 3 (Thread 0x7f400b2db700 (LWP 21862)): #0 0x7f4023e933ed in poll () at /lib64/libc.so.6 #1 0x7f401ff95a06 in g_main_context_iterate.isra () at /lib64/libglib-2.0.so.0 #2 0x7f401ff95b1c in g_main_context_iteration () at /lib64/libglib-2.0.so.0 #3 0x7f4024ca724b in QEventDispatcherGlib::processEvents(QFlags) () at /lib64/libQt5Core.so.5 #4 0x7f4024c565ea in QEventLoop::exec(QFlags) () at /lib64/libQt5Core.so.5 #5 0x7f4024ab5343 in QThread::exec() () at /lib64/libQt5Core.so.5 #6 0x7f40253a9559 in QDBusConnectionManager::run() () at /lib64/libQt5DBus.so.5 #7 0x7f4024ab999a in QThreadPrivate::start(void*) () at /lib64/libQt5Core.so.5 #8 0x7f402286b5ca in start_thread () at /lib64/libpthread.so.0 #9 0x7f4023e9ef6d in clone () at /lib64/libc.so.6 Thread 2 (Thread 0x7f400c1bb700 (LWP 21861)): #0 0x7f4023e933ed in poll () at /lib64/libc.so.6 #1 0x7f4021655f80 in _xcb_conn_wait () at /lib64/libxcb.so.1 #2 0x7f4021657b79 in xcb_wait_for_event () at /lib64/libxcb.so.1 #3 0x7f400ef4eda9 in QXcbEventReader::run() () at /lib64/libQt5XcbQpa.so.5 #4 0x7f4024ab999a in QThreadPrivate::start(void*) () at /lib64/libQt5Core.so.5 #5 0x7f402286b5ca in start_thread () at /lib64/libpthread.so.0 #6 0x7f4023e9ef6d in clone () at /lib64/libc.so.6 Thread 1 (Thread 0x7f402afa19c0 (LWP 21860)): [KCrash Handler] #6 0x7f402944c4c0 in Unroll3BytesSkip1SwapSwapFirst () at /lib64/liblcms2.so.2 #7 0x7f4029453194 in PrecalculatedXFORM () at /lib64/liblcms2.so.2 #8 0x7f402945413d in cmsDoTransform () at /lib64/liblcms2.so.2 #9 0x7f402c069f02 in Gwenview::RasterImageView::updateFromScaler(int, int, QImage const&) () at /lib64/libgwenviewlib.so.5 #10 0x7f4024c7febc in QMetaObject::activate(QObject*, int, int, void**) () at /lib64/libQt5Core.so.5 #11 0x7f402c0d1751 in Gwenview::ImageScaler::scaledRect(int, int, QImage const&) () at /lib64/libgwenviewlib.so.5 #12 0x7f402c08d7d7 in Gwenview::ImageScaler::scaleRect(QRect const&) () at /lib64/libgwenviewlib.so.5 #13 0x7f402c08de37 in Gwenview::ImageScaler::doScale() () at /lib64/libgwenviewlib.so.5 #14 0x7f402c0689f4 in Gwenview::RasterImageView::updateBuffer(QRegion const&) () at /lib64/libgwenviewlib.so.5 #15 0x7f402c068b63 in Gwenview::RasterImageView::onZoomChanged() () at /lib64/libgwenviewlib.so.5 #16 0x7f402c05b335 in Gwenview::AbstractImageView::setZoom(double, QPointF const&, Gwenview::AbstractImageView::UpdateType) () at /lib64/libgwenviewlib.so.5 #17 0x7f402c06309a in Gwenview::DocumentView::zoomIn(QPointF const&) () at /lib64/libgwenviewlib.so.5 #18 0x7f402c0d524e in Gwenview::DocumentView::qt_static_metacall(QObject*, QMetaObject::Call, int, void**) () at /lib64/libgwenviewlib.so.5 #19 0x7f4024c7fb92 in QMetaObject::activate(QObject*, int, int, void**) () at /lib64/libQt5Core.so.5 #20 0x7f40260df672 in QAction::triggered(bool) () at /lib64/libQt5Widgets.so.5 #21 0x7f40260e2292 in QAction::activate(QAction::ActionEvent) () at /lib64/libQt5Widgets.so.5 #22 0x7f40260e2c1c in QAction::event(QEvent*) () at /lib64/libQt5Widgets.so.5 #23 0x7f40260e8c0c in
[plasmashell] [Bug 359882] can't change auto hide panel activation zone size without resizing panel
https://bugs.kde.org/show_bug.cgi?id=359882 --- Comment #2 from Manuel C <manuel.manu.del...@gmail.com> --- Yeah, that. I have some applications that have buttons on the bottom corners and I always activate the taskbar instead... Maybe there could be some kind of activation delay instead though... -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 359882] can't change auto hide panel activation zone size without resizing panel
https://bugs.kde.org/show_bug.cgi?id=359882 Manuel C <manuel.manu.del...@gmail.com> changed: What|Removed |Added Flags||VisualDesign+ -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 359882] New: can't change auto hide panel activation zone size without resizing panel
https://bugs.kde.org/show_bug.cgi?id=359882 Bug ID: 359882 Summary: can't change auto hide panel activation zone size without resizing panel Product: plasmashell Version: 5.5.4 Platform: Fedora RPMs OS: Linux Status: UNCONFIRMED Severity: wishlist Priority: NOR Component: Panel Assignee: plasma-b...@kde.org Reporter: manuel.manu.del...@gmail.com I would like it if you could resize the activation zone on its own but I'd like to keep the panel full length. But I suppose the other way might also be useful... Reproducible: Always Steps to Reproduce: 1. Set panel visibility to auto hide -- You are receiving this mail because: You are watching all bug changes.
