[plasmashell] [Bug 481736] On X11, Notifications pop up in the middle of the screen after being away from pc for a while
https://bugs.kde.org/show_bug.cgi?id=481736 --- Comment #41 from Ancoron --- (In reply to ezzefmw9 from comment #37) > what fixed this for me is applying a fix for another bug I also had: > https://bugs.kde.org/show_bug.cgi?id=484323 > > The solution for some people there has been to disable Kscreen2 found at: > > Settings -> System -> Session -> Background Services You are my savior as well! Thanx a lot! -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 481736] On X11, Notifications pop up in the middle of the screen after being away from pc for a while
https://bugs.kde.org/show_bug.cgi?id=481736 --- Comment #29 from Ancoron --- Now this is weird, after a full system upgrade + reboot and some about 2-3 sleeps, the notification still where in it's correct place. Then I ran the test: notify-send -t $((60 * 1000)) "Test notification"; sleep 5; spectacle -bfn; xset dpms force off; sleep 30; xset dpms force on; sleep 5; spectacle -bfn ...which showed the notification after "xset dpms force on" only offset a bit (upwards). But then all following notifications again came back in the middle/center of my screen. If I remember correctly, then what I did for sleep just today was to first turn the monitor off and then press the sleep button. Usually I did tend to first put my machine to sleep and then turn the monitor off, which may be an indicator of the code path into play for this bug? But now after running the test, even a sleep after monitor off doesn't fix it, so have to reboot again. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 481736] On X11, Notifications pop up in the middle of the screen after being away from pc for a while
https://bugs.kde.org/show_bug.cgi?id=481736 Ancoron changed: What|Removed |Added CC||ancoron.lucife...@gmail.com --- Comment #28 from Ancoron --- I am also affected by this issue (have to use X11 until Wayland supports full session restore and some other apps solve their compatibility with Wayland). However, I have 2 different machines with pretty much identical system/software setup and only on one of them the issue occurs: Machine A → Main User → BAD Machine A → Secondary User → GOOD Machine B → Main User → GOOD So I suspect that this issue has to to with some leftover config from Plasma 5 which are only present for some users. Both machine setups where previously running Plasma 5 and have been upgraded. System info for Machine A: Operating System: Arch Linux KDE Plasma Version: 6.0.3 KDE Frameworks Version: 6.0.0 Qt Version: 6.6.3 Kernel Version: 6.8.4-arch1-1 (64-bit) Graphics Platform: X11 Processors: 16 × AMD Ryzen 7 5700G with Radeon Graphics Memory: 58.7 GiB of RAM Graphics Processor: AMD Radeon Graphics -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 468389] Foreground/background element drawing mixed up
https://bugs.kde.org/show_bug.cgi?id=468389 --- Comment #3 from Ancoron --- I was now able to reproduce the issue with a completely new user setup and indeed, it appears to be happening only for setups with multiple Activities, but not necessarily only after Activity switching (just takes longer to get triggered). Also, this new user setup did not have any custom KWin scripts installed, which could have messed with it. The issue does not occur when compositor is turned off, so it had to do with either the compositor itself or some of the desktop effects, which I then tested thoroughly. Finally, I found that the effect "Slide Back" in section "Focus" is causing this bug. After disabling the effect, the originally affected user session immediately became free of this issue. Although I'll observe it further, it looks like I have found at least one candidate here. Also, I am still running the Mudeer Tiling KWin script without any issue. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 468389] Foreground/background element drawing mixed up
https://bugs.kde.org/show_bug.cgi?id=468389 --- Comment #2 from Ancoron --- I am using X11, no 3rd party effects. The only custom KWin script I have is Mudeer for window positions/tiling: https://github.com/darkstego/Mudeer I have also tested without. With only one Activity, everything is as it should be, no issues here (running the same setup on a different machine). However, I just created another user and tried to reproduce it and I wasn't able to so far (including Mudeer as well). As this machine is set up from scratch just recently it can't be some leftover, however, before using Mudeer, I tested out https://github.com/Bismuth-Forge/bismuth and https://github.com/esjeon/krohnkite but didn't actually like it. Could it be some leftover from those that's colliding? Is there a way to reset only parts of the plasma/kwin configuration, so that I don't have to start all over again or is there some backup/restore mechanism (even low-level)? -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 468389] New: Foreground/background element drawing mixed up
https://bugs.kde.org/show_bug.cgi?id=468389 Bug ID: 468389 Summary: Foreground/background element drawing mixed up Classification: Plasma Product: kwin Version: 5.27.4 Platform: Archlinux OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: activities Assignee: kwin-bugs-n...@kde.org Reporter: ancoron.lucife...@gmail.com Target Milestone: --- Created attachment 158014 --> https://bugs.kde.org/attachment.cgi?id=158014=edit Konsole with context menu drawn in background SUMMARY After switching activities, new windows, popups and any other element (application-independent) are often drawn behind their parents as well as other (inactive) windows. STEPS TO REPRODUCE 1. have compositor enabled 2. create 2 or more activities 3. open some applications in each activity 4. switch activities back and forth 5. switch active window 6. open application menu or other popup OBSERVED RESULT 1. Like in the attached screenshot, popups are often drawn behind their patent window, but are still in mouse-focus, so invoking actions is working (even in blind mode for non-transparent windows). 2. The active window is not always drawn in front of others (no window preferences), which also includes the shadow and active titlebar coloring EXPECTED RESULT 1. Popups/menus/... are always drawn in front of any other window 2. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Arch Linux (kernel 6.2.10-arch1-1) KDE Plasma Version: 5.27.4 KDE Frameworks Version: 5.105.0 Qt Version: 5.15.8 ADDITIONAL INFORMATION A workaround is to disable and re-enable compositing after switching activities (by default via ALT+SHIFT+F12). -- You are receiving this mail because: You are watching all bug changes.
[gwenview] [Bug 441162] Png file with gamma show washed out colours
https://bugs.kde.org/show_bug.cgi?id=441162 --- Comment #12 from Ancoron --- @phd Yes, it looks like a Qt bug to me as well, since the code changes that supposedly introduced this regression only incorporate color correction using Qt interfaces. -- You are receiving this mail because: You are watching all bug changes.
[gwenview] [Bug 441162] Png file with gamma show washed out colours
https://bugs.kde.org/show_bug.cgi?id=441162 Ancoron changed: What|Removed |Added Summary|Png file with alpha removed |Png file with gamma show |through imagemagick show|washed out colours |washed out colours | -- You are receiving this mail because: You are watching all bug changes.
[gwenview] [Bug 441162] Png file with alpha removed through imagemagick show washed out colours
https://bugs.kde.org/show_bug.cgi?id=441162 --- Comment #8 from Ancoron --- The actual issue here is that gwenview (or Qt) interprets the gamma value incorrectly. ImageMagick (and other tools) set a default gamma of 2.2 for PNG's and/or other file formats that support this metadata. For the attached files, here's some metadata: test.png: Bit Depth : 8 Color Type : RGB with Alpha Compression : Deflate/Inflate Filter : Adaptive Interlace : Noninterlaced Pixels Per Unit X : 11811 Pixels Per Unit Y : 11811 Pixel Units : meters Image Size : 1800x2700 hires.png: Bit Depth : 8 Color Type : RGB Compression : Deflate/Inflate Filter : Adaptive Interlace : Noninterlaced Gamma : 2.2 <<< creating trouble for gwenview White Point X : 0.3127 White Point Y : 0.329 Red X : 0.64 Red Y : 0.33 Green X : 0.3 Green Y : 0.6 Blue X : 0.15 Blue Y : 0.06 Background Color: 255 255 255 Pixels Per Unit X : 11811 Pixels Per Unit Y : 11811 Pixel Units : meters Modify Date : 2021:08:19 10:24:04 Warning : [minor] Text chunk(s) found after PNG IDAT (may be ignored by some readers) Datecreate : 2021-08-19T10:23:53+00:00 Datemodify : 2021-08-19T08:57:54+00:00 Image Size : 1800x2700 You can "fix" the PNG's for gwenview usually with: `convert -set gamma 2.2 ` ...which actually sets the PNG gamma value to 0.4545, since it's the inverse (and which is what gwenview should be doing). However, that breaks the image for almost any other viewer/browser/editor that interpret the gamma value, since they then are doing the color correction in the inverse way with the inversed value. Some background on why it is the way it is: https://www.cambridgeincolour.com/tutorials/gamma-correction.htm -- You are receiving this mail because: You are watching all bug changes.
[gwenview] [Bug 450205] Gamma not applied correctly to PNG
https://bugs.kde.org/show_bug.cgi?id=450205 --- Comment #1 from Ancoron --- Just upgraded the system to check if anything has changed, but no. gwenview version: 21.12.2 SOFTWARE/OS VERSIONS Linux/KDE Plasma: Kubuntu 21.10 KDE Plasma Version: 5.24.0 KDE Frameworks Version: 5.91.0 Qt Version: 5.15.2 -- You are receiving this mail because: You are watching all bug changes.
[gwenview] [Bug 450205] New: Gamma not applied correctly to PNG
https://bugs.kde.org/show_bug.cgi?id=450205 Bug ID: 450205 Summary: Gamma not applied correctly to PNG Product: gwenview Version: 21.08.1 Platform: Kubuntu Packages OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: gwenview-bugs-n...@kde.org Reporter: ancoron.lucife...@gmail.com Target Milestone: --- Created attachment 146704 --> https://bugs.kde.org/attachment.cgi?id=146704=edit Original gradient with default gamma SUMMARY Gamma applied incorrectly. STEPS TO REPRODUCE 1. Create a gradient (sets gamma by default to 1/2.2): `convert -size 1280x720 -define gradient:vector=32,32,1248,688 gradient:#ff-#00 gradient.png` 2. Open image `gradient.png` in gwenview OBSERVED RESULT Colors are way too bright. EXPECTED RESULT Colors are correct. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Kubuntu 21.04 KDE Plasma Version: 5.22.5 KDE Frameworks Version: 5.86.0 Qt Version: 5.15.2 ADDITIONAL INFORMATION When inverting the gamma value the image is displayed correctly, but metadata is actually wrong and other programs will make the image look wrong: `convert gradient.png -set gamma 2.2 gradient-inverted-gamma.png` -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 398908] Dolphin uses up huge amounts of memory
https://bugs.kde.org/show_bug.cgi?id=398908 Ancoron changed: What|Removed |Added CC||ancoron.lucife...@gmail.com --- Comment #70 from Ancoron --- Also affected by this on multiple machines running Kubuntu. I also suspect mounts here (docker overlay, Linux nsfs, ...) which get created frequently when building docker images and starting/stopping docker containers and more so with docker-compose setups. -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 419871] New: Configuring indentation rules for JSON results in crash
https://bugs.kde.org/show_bug.cgi?id=419871 Bug ID: 419871 Summary: Configuring indentation rules for JSON results in crash Product: kate Version: 19.04.3 Platform: Ubuntu Packages OS: Linux Status: REPORTED Keywords: drkonqi Severity: crash Priority: NOR Component: general Assignee: kwrite-bugs-n...@kde.org Reporter: ancoron.lucife...@gmail.com Target Milestone: --- Application: kate (19.04.3) Qt Version: 5.12.4 Frameworks Version: 5.62.0 Operating System: Linux 5.6.0-ladydeath x86_64 Distribution: Ubuntu 19.10 -- Information about the crash: - What I was doing when the application crashed: 1. Open Kate 2. Open Configure Kate >> Open/Save >> Modes & Filetypes 3. Select "Markup/JSON" 4. Set "Variables" to "kate: space-indent true; indent-width 2; tab-width 2" 5. Click "OK" 6. Open a JSON file The crash can be reproduced every time. -- Backtrace: Application: Kate (kate), signal: Segmentation fault Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". [Current thread is 1 (Thread 0x7fb45a0f2300 (LWP 29167))] Thread 10 (Thread 0x7fb4377fe700 (LWP 29176)): #0 futex_wait_cancelable (private=, expected=0, futex_word=0x556024836130) at ../sysdeps/unix/sysv/linux/futex-internal.h:80 #1 __pthread_cond_wait_common (abstime=0x0, clockid=0, mutex=0x5560248360e0, cond=0x556024836108) at pthread_cond_wait.c:508 #2 __pthread_cond_wait (cond=0x556024836108, mutex=0x5560248360e0) at pthread_cond_wait.c:638 #3 0x7fb44b2b591b in ?? () from /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so #4 0x7fb44b2b553b in ?? () from /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so #5 0x7fb45caf3669 in start_thread (arg=) at pthread_create.c:479 #6 0x7fb45dd56323 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 Thread 9 (Thread 0x7fb437fff700 (LWP 29175)): #0 futex_wait_cancelable (private=, expected=0, futex_word=0x556024836130) at ../sysdeps/unix/sysv/linux/futex-internal.h:80 #1 __pthread_cond_wait_common (abstime=0x0, clockid=0, mutex=0x5560248360e0, cond=0x556024836108) at pthread_cond_wait.c:508 #2 __pthread_cond_wait (cond=0x556024836108, mutex=0x5560248360e0) at pthread_cond_wait.c:638 #3 0x7fb44b2b591b in ?? () from /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so #4 0x7fb44b2b553b in ?? () from /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so #5 0x7fb45caf3669 in start_thread (arg=) at pthread_create.c:479 #6 0x7fb45dd56323 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 Thread 8 (Thread 0x7fb444851700 (LWP 29174)): #0 futex_wait_cancelable (private=, expected=0, futex_word=0x556024835a30) at ../sysdeps/unix/sysv/linux/futex-internal.h:80 #1 __pthread_cond_wait_common (abstime=0x0, clockid=0, mutex=0x5560248359e0, cond=0x556024835a08) at pthread_cond_wait.c:508 #2 __pthread_cond_wait (cond=0x556024835a08, mutex=0x5560248359e0) at pthread_cond_wait.c:638 #3 0x7fb44b2b591b in ?? () from /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so #4 0x7fb44b2b553b in ?? () from /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so #5 0x7fb45caf3669 in start_thread (arg=) at pthread_create.c:479 #6 0x7fb45dd56323 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 Thread 7 (Thread 0x7fb445052700 (LWP 29173)): #0 futex_wait_cancelable (private=, expected=0, futex_word=0x556024835a30) at ../sysdeps/unix/sysv/linux/futex-internal.h:80 #1 __pthread_cond_wait_common (abstime=0x0, clockid=0, mutex=0x5560248359e0, cond=0x556024835a08) at pthread_cond_wait.c:508 #2 __pthread_cond_wait (cond=0x556024835a08, mutex=0x5560248359e0) at pthread_cond_wait.c:638 #3 0x7fb44b2b591b in ?? () from /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so #4 0x7fb44b2b553b in ?? () from /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so #5 0x7fb45caf3669 in start_thread (arg=) at pthread_create.c:479 #6 0x7fb45dd56323 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 Thread 6 (Thread 0x7fb445853700 (LWP 29172)): #0 futex_wait_cancelable (private=, expected=0, futex_word=0x556024835a30) at ../sysdeps/unix/sysv/linux/futex-internal.h:80 #1 __pthread_cond_wait_common (abstime=0x0, clockid=0, mutex=0x5560248359e0, cond=0x556024835a08) at pthread_cond_wait.c:508 #2 __pthread_cond_wait (cond=0x556024835a08, mutex=0x5560248359e0) at pthread_cond_wait.c:638 #3 0x7fb44b2b591b in ?? () from /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so #4 0x7fb44b2b553b in ?? () from /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so #5 0x7fb45caf3669 in start_thread (arg=) at pthread_create.c:479 #6 0x7fb45dd56323 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 Thread 5 (Thread 0x7fb446054700 (LWP 29171)): #0 futex_wait_cancelable (private=, expected=0, futex_word=0x556024097b28) at ../sysdeps/unix/sysv/linux/futex-internal.h:80 #1 __pthread_cond_wait_common (abstime=0x0,
[gwenview] [Bug 305072] Animated GIF is some milliseconds too slow
https://bugs.kde.org/show_bug.cgi?id=305072 Ancoron changed: What|Removed |Added CC||ancoron.lucife...@gmail.com --- Comment #7 from Ancoron --- Created attachment 123801 --> https://bugs.kde.org/attachment.cgi?id=123801=edit 60 seconds countdown analog clock I've also did some tests here using the attached 60-seconds-countdown.gif file. It really should be 60 seconds in playback length (by ImageMagick): $ identify -format ' + %T' 60-seconds-countdown.gif | sed 's/^/(0/; s/$/) \/ 100\n/' | bc -l 60. However, with Gwenview (up to 19.04.3), I got the following playback times (manually tracked, not precise to the deci-second) related to Gwenview window resolution: 256x256 - 01:20 (probably due to additional scaling) 512x512 - 01:16 1024x1024 - 01:30 2560x1600 - 03:45 Another thing I noticed was that reloading/restarting the GIF (using F5 key) the playback speed slowed down even more and the CPU usage went up. After 10 reloads, gwenview was using ~80% of a single CPU core and slowed down playback from ~01:30 initially to ~05:24 (at 1024x1024 window size), after 20 reloads to ~09:20 at ~88). -- You are receiving this mail because: You are watching all bug changes.
[akregator] [Bug 403723] New: Crash when opening links with external (default) browser
https://bugs.kde.org/show_bug.cgi?id=403723 Bug ID: 403723 Summary: Crash when opening links with external (default) browser Product: akregator Version: 5.7.3 Platform: Ubuntu Packages OS: Linux Status: REPORTED Keywords: drkonqi Severity: crash Priority: NOR Component: general Assignee: kdepim-b...@kde.org Reporter: ancoron.lucife...@gmail.com Target Milestone: --- Application: akregator (5.7.3) Qt Version: 5.9.5 Frameworks Version: 5.44.0 Operating System: Linux 4.15.0-34-generic x86_64 Distribution: Ubuntu 18.04.1 LTS -- Information about the crash: - What I was doing when the application crashed: Using the middle mouse button to open a link inside a news entry in the external default browser (Firefox with profile) The crash can be reproduced every time. -- Backtrace: Application: Akregator (akregator), signal: Segmentation fault Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". [Current thread is 1 (Thread 0x7f449d6d00c0 (LWP 25819))] Thread 33 (Thread 0x7f430e90c700 (LWP 14576)): #0 0x7f449386eed9 in futex_reltimed_wait_cancelable (private=, reltime=0x7f430e90b8c0, expected=0, futex_word=0x7f4334005764) at ../sysdeps/unix/sysv/linux/futex-internal.h:142 #1 0x7f449386eed9 in __pthread_cond_wait_common (abstime=0x7f430e90b980, mutex=0x7f4334005710, cond=0x7f4334005738) at pthread_cond_wait.c:533 #2 0x7f449386eed9 in __pthread_cond_timedwait (cond=0x7f4334005738, mutex=0x7f4334005710, abstime=0x7f430e90b980) at pthread_cond_wait.c:667 #3 0x7f4499c4c458 in QWaitCondition::wait(QMutex*, unsigned long) () at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #4 0x7f4499c4852d in () at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #5 0x7f4499c4b16d in () at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #6 0x7f44938686db in start_thread (arg=0x7f430e90c700) at pthread_create.c:463 #7 0x7f449954688f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 Thread 32 (Thread 0x7f443dffb700 (LWP 10988)): #0 0x7f449386eed9 in futex_reltimed_wait_cancelable (private=, reltime=0x7f443dffa7e0, expected=0, futex_word=0x7f44240046c0) at ../sysdeps/unix/sysv/linux/futex-internal.h:142 #1 0x7f449386eed9 in __pthread_cond_wait_common (abstime=0x7f443dffa880, mutex=0x7f4424004670, cond=0x7f4424004698) at pthread_cond_wait.c:533 #2 0x7f449386eed9 in __pthread_cond_timedwait (cond=0x7f4424004698, mutex=0x7f4424004670, abstime=0x7f443dffa880) at pthread_cond_wait.c:667 #3 0x7f4489e77652 in () at /usr/lib/x86_64-linux-gnu/libQt5WebEngineCore.so.5 #4 0x7f4489e4d799 in () at /usr/lib/x86_64-linux-gnu/libQt5WebEngineCore.so.5 #5 0x7f4489e4dcfb in () at /usr/lib/x86_64-linux-gnu/libQt5WebEngineCore.so.5 #6 0x7f4489e465eb in () at /usr/lib/x86_64-linux-gnu/libQt5WebEngineCore.so.5 #7 0x7f44938686db in start_thread (arg=0x7f443dffb700) at pthread_create.c:463 #8 0x7f449954688f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 Thread 31 (Thread 0x7f433a4e4700 (LWP 25874)): #0 0x7f4499539bf9 in __GI___poll (fds=0x7f43340027e0, nfds=1, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29 #1 0x7f44919c6539 in () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 #2 0x7f44919c664c in g_main_context_iteration () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 #3 0x7f4499e8290b in QEventDispatcherGlib::processEvents(QFlags) () at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #4 0x7f4499e279ea in QEventLoop::exec(QFlags) () at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #5 0x7f4499c4622a in QThread::exec() () at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #6 0x7f4496103e8f in () at /usr/lib/x86_64-linux-gnu/libKF5KIOCore.so.5 #7 0x7f4499c4b16d in () at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #8 0x7f44938686db in start_thread (arg=0x7f433a4e4700) at pthread_create.c:463 #9 0x7f449954688f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 Thread 30 (Thread 0x7f4340c70700 (LWP 25873)): #0 0x7f449386e9f3 in futex_wait_cancelable (private=, expected=0, futex_word=0x557eba36eff8) at ../sysdeps/unix/sysv/linux/futex-internal.h:88 #1 0x7f449386e9f3 in __pthread_cond_wait_common (abstime=0x0, mutex=0x557eba36efa8, cond=0x557eba36efd0) at pthread_cond_wait.c:502 #2 0x7f449386e9f3 in __pthread_cond_wait (cond=0x557eba36efd0, mutex=0x557eba36efa8) at pthread_cond_wait.c:655 #3 0x7f4489e48c95 in () at /usr/lib/x86_64-linux-gnu/libQt5WebEngineCore.so.5 #4 0x7f4489e49177 in () at /usr/lib/x86_64-linux-gnu/libQt5WebEngineCore.so.5 #5 0x7f4489e49f11 in () at /usr/lib/x86_64-linux-gnu/libQt5WebEngineCore.so.5 #6 0x7f4489e465eb in () at /usr/lib/x86_64-linux-gnu/libQt5WebEngineCore.so.5 #7 0x7f44938686db in start_thread (arg=0x7f4340c70700) at pthread_create.c:463 #8 0x7f449954688f
[plasmashell] [Bug 348016] Window positions not applied on secondary monitor
https://bugs.kde.org/show_bug.cgi?id=348016 Ancoron changed: What|Removed |Added Resolution|WAITINGFORINFO |FIXED Status|NEEDSINFO |RESOLVED --- Comment #13 from Ancoron --- Although window positions and sizes are almost always still messed up after logout/login cycle, the application windows are placed inside the correct displays. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 348016] Window positions not applied on secondary monitor
https://bugs.kde.org/show_bug.cgi?id=348016 --- Comment #11 from Ancoron <ancoron.lucife...@gmail.com> --- Yes, it is still the same. However, I just did a logout-login cycle and noticed something new to me: Activities and open applications at logout time: * Activity #1 (active): Firefox, Konsole, Thunderbird, Dolphin * Activity #2: Firefox, Konsole, Dolphin * Activity #3: n/a * Activity #4: Firefox, Konsole, Dolphin Activities and open applications after re-login: * Activity #1: Firefox, Thunderbird * Activity #2 (active): Firefox, Konsole, Konsole, Konsole, Dolphin, Dolphin, Dolphin * Activity #3: n/a * Activity #4: Firefox So, only Firefox and Thunderbird actually stayed in the Activity they where left. All other application windows that I had open where restored in the Activity that was active after login. However, the really interesting part is that it switched to Activity #2, although I left the "session" in Activity #1. In addition, the main panel just switched from the primary to the secondary monitor. Really confusing. And still, all restored application windows are located on the primary monitor and also the concrete positions (if they where on the primary monitor before) are not remembered correctly except for Thunderbird, which restores exactly as it has been left. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-plasma] [Bug 347783] Icons + text too small after correcting dual-head DPI
https://bugs.kde.org/show_bug.cgi?id=347783 --- Comment #5 from Ancoron <ancoron.lucife...@gmail.com> --- Looks like the problem is solved. Thank you. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-plasma] [Bug 347783] Icons + text too small after correcting dual-head DPI
https://bugs.kde.org/show_bug.cgi?id=347783 Ancoron <ancoron.lucife...@gmail.com> changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 340982] I cannot set my short date to YYYY-MM-DD, nor my time to HH:MM
https://bugs.kde.org/show_bug.cgi?id=340982 --- Comment #62 from Ancoron <ancoron.lucife...@gmail.com> --- I would agree to that, but don't forget the ISO-8601 time format. -- You are receiving this mail because: You are watching all bug changes.
[kscreenlocker] [Bug 348053] Screen locker freeze results into inaccessible session
https://bugs.kde.org/show_bug.cgi?id=348053 --- Comment #6 from Ancoron <ancoron.lucife...@gmail.com> --- For me, the issue seems to have been resolved by itself. Thanx anyway for checking back. :-) -- You are receiving this mail because: You are watching all bug changes.
