[plasmashell] [Bug 389066] Qt application without main window shown in icon-only task manager

[Daniel Lichtenberger]

https://bugs.kde.org/show_bug.cgi?id=389066

--- Comment #3 from Daniel Lichtenberger  ---
Hi Nate,
I haven't used the application for a long time and cannot easily retest this
locally - and I also haven't had this problem with other apps since then. I'd
suggest to close the issue.

-- 
You are receiving this mail because:
You are watching all bug changes.

[systemsettings] [Bug 297067] Installing bitmap fonts does not work when no bitmap fonts are installed

[Daniel Lichtenberger]

https://bugs.kde.org/show_bug.cgi?id=297067

Daniel Lichtenberger  changed:

   What|Removed |Added

 Status|NEEDSINFO   |REPORTED
 Resolution|WAITINGFORINFO  |---

--- Comment #2 from Daniel Lichtenberger  ---
Looking at the source of fontinst in 5.14.3, I believe the issue is still
present - if no bitmap fonts are available, fontinst will fail any installation
of a bitmap font because it assumes that they have been disabled.

However, I can no longer reproduce the issue here since my local installation
contains multiple bitmap fonts by default, as is (probably) the common case for
most distributions. Changing fontinst could break the error handling when
bitmap fonts are actually disabled, so perhaps this issue should be closed.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 361598] Alt+Tab does not always work when pressing it quickly

[Daniel Lichtenberger]

https://bugs.kde.org/show_bug.cgi?id=361598

--- Comment #11 from Daniel Lichtenberger  ---
Seems to have been fixed (my HW didn't change).

-- 
You are receiving this mail because:
You are watching all bug changes.

[plasmashell] [Bug 389066] New: Qt application without main window shown in icon-only task manager

[Daniel Lichtenberger]

https://bugs.kde.org/show_bug.cgi?id=389066

Bug ID: 389066
   Summary: Qt application without main window shown in icon-only
task manager
   Product: plasmashell
   Version: 5.11.5
  Platform: openSUSE RPMs
OS: Linux
Status: UNCONFIRMED
  Severity: minor
  Priority: NOR
 Component: Icons-only Task Manager
  Assignee: h...@kde.org
  Reporter: daniel.lichtenber...@gmx.net
CC: plasma-b...@kde.org
  Target Milestone: 1.0

The utility application "radeon-profile" [1] can be "minimized to tray". When
opening and minimizing the application normally, this works as expected: the
application is removed from the icons-only task manager when it is minimized.

However, when the application is started in the "minimized to tray" state, the
task manager entry never disappears. This worked correctly until recently (no
entry in the task manager), and I did not update radeon-profile in the meantime
- so I guess it's either due to a change in KDE, or in Qt (the radeon-profile
GUI is written in Qt). 

[1] https://github.com/marazmista/radeon-profile

-- 
You are receiving this mail because:
You are watching all bug changes.

[plasmashell] [Bug 381000] [Regression] High CPU when background is set to slideshow

[Daniel Lichtenberger]

https://bugs.kde.org/show_bug.cgi?id=381000

Daniel Lichtenberger <daniel.lichtenber...@gmx.net> changed:

   What|Removed |Added

 CC||daniel.lichtenber...@gmx.ne
   ||t

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 371199] Dragging windows on my left screen causes them to jump down to the bottom

[Daniel Lichtenberger]

https://bugs.kde.org/show_bug.cgi?id=371199

--- Comment #25 from Daniel Lichtenberger <daniel.lichtenber...@gmx.net> ---
Hi Martin,

thanks for the patch! This does seem to solve the issue for me.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 371199] Dragging windows on my left screen causes them to jump down to the bottom

[Daniel Lichtenberger]

https://bugs.kde.org/show_bug.cgi?id=371199

Daniel Lichtenberger <daniel.lichtenber...@gmx.net> changed:

   What|Removed |Added

 CC||daniel.lichtenber...@gmx.ne
   ||t

--- Comment #21 from Daniel Lichtenberger <daniel.lichtenber...@gmx.net> ---
AFAIUI the problematic code is in AbstractClient::handleMoveResize
(geometry.cpp) of kwin. As described in the blog post mentioned above, putting
a panel in the middle of the screen covers the entire left screen internally.
The code in AbstractClient doesn't seem to handle this: the entire left screen
is removed from the "available" area for moving, which causes issues down the
line.

For example, with my setup (1280x1024 left-of 1680x1050), a panel on the
left-hand side of the right monitor has a "strut" of (0,0 1330x1049). Removing
this area from the available area will cause issues. Setting the left edge of
the strut to 1280 (the width of the left monitor) seemed to fix the issue for
me but probably isn't a solution if this scenario is essentially not covered by
the spec.

Pressing "Alt" while moving triggers an unrestricted move mode that just uses
the entire (virtual) screen for moving and ignores the panel altogether, thus
avoiding the issue.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 361598] Alt+Tab does not always work when pressing it quickly

[Daniel Lichtenberger]

https://bugs.kde.org/show_bug.cgi?id=361598

--- Comment #6 from Daniel Lichtenberger <daniel.lichtenber...@gmx.net> ---
The only two lines kwin logs when switching windows with the script from my
previous comment are (after enabling debug options as described in
https://github.com/lxde/lxqt/issues/836#issuecomment-144931359):

kwin_tabbox: areKeySymXsDepressed:  any of  2
kwin_tabbox: 0 : keySymX=0x "ffe9"  i= 8  mask=0x "1"  keymap[i]=0x "1"


_Sometimes_ the last number is "0" instead of "1", as in:

kwin_tabbox: areKeySymXsDepressed:  any of  2
kwin_tabbox: 0 : keySymX=0x "ffe9"  i= 8  mask=0x "1"  keymap[i]=0x "0"

However, there doesn't seem to be a direct link between the issue and this
change in output (sometimes switching fails when it printed "0" before,
sometimes when it printed "1").

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 361598] Alt+Tab does not always work when pressing it quickly

[Daniel Lichtenberger]

https://bugs.kde.org/show_bug.cgi?id=361598

Daniel Lichtenberger <daniel.lichtenber...@gmx.net> changed:

   What|Removed |Added

 CC||daniel.lichtenber...@gmx.ne
   ||t

--- Comment #4 from Daniel Lichtenberger <daniel.lichtenber...@gmx.net> ---
I also experience this problem with Plasma 5.9.4. I tried disabling/modifying
various desktop effects, reducing or increasing animation speed, as well as
using the compact application switcher. 

When the application switcher fails, the Alt+Tab command seems to be
registered.  The current window briefly loses focus, but it is re-focused after
a short delay instead of switching to the previous window. 

I can kind of reliably reproduce the issue using xdotool, to rule out keyboard
or keypress timing issues:

for i in {1..10}; do echo 'Switching...'; xdotool key 'alt+Tab'; sleep 1; done

Usually this works as expected, toggling between the konsole window and the
previously selected window, but sometimes the same window gets focused multiple
times. I used several applications as the previous window (Dolphin, Firefox, VS
Code, ...), but couldn't notice a pattern. Is there any debug output that could
help diagnose the problem?

-- 
You are receiving this mail because:
You are watching all bug changes.

[plasmashell] [Bug 362051] panel appears on the wrong screen/display after reboot

[Daniel Lichtenberger via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=362051

--- Comment #5 from Daniel Lichtenberger <daniel.lichtenber...@gmx.net> ---
I use the radeon driver. I stopped seeing this issue about a month ago as well.
 My current versions are:

- Frameworks 5.25.0
- Qt 5.6.1
- Plasma 5.7.4
- Kernel 4.7.3

-- 
You are receiving this mail because:
You are watching all bug changes.

[kmail2] [Bug 354400] In Kmail 5.0.2 autocompletion only shows recent email addresses but not stored emails in Kaddressbook

[Daniel Lichtenberger via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=354400

Daniel Lichtenberger <daniel.lichtenber...@gmx.net> changed:

   What|Removed |Added

 CC||daniel.lichtenber...@gmx.ne
   ||t

-- 
You are receiving this mail because:
You are watching all bug changes.

[plasmashell] [Bug 363935] Vertical panel covers maximized windows with new Qt multiscreen support

[Daniel Lichtenberger via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=363935

--- Comment #3 from Daniel Lichtenberger <daniel.lichtenber...@gmx.net> ---
Created attachment 99378
  --> https://bugs.kde.org/attachment.cgi?id=99378=edit
Patch: use QScreen::virtualGeometry in PanelView::updateStruts

-- 
You are receiving this mail because:
You are watching all bug changes.

[plasmashell] [Bug 363935] Vertical panel covers maximized windows with new Qt multiscreen support

[Daniel Lichtenberger via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=363935

Daniel Lichtenberger <daniel.lichtenber...@gmx.net> changed:

   What|Removed |Added

 CC||plasma-b...@kde.org
  Component|Panel   |Multi-screen support

--- Comment #2 from Daniel Lichtenberger <daniel.lichtenber...@gmx.net> ---
The issue is related to my multiscreen setup. I moved the panel to the right
border of my right screen, and the new code in PanelView::updateStruts fails to
take that into account: "wholeScreen" loads the current screen geometry, not
the whole (virtual) screen geometry, and "rightOffset" ends up being negative.

Against the advice in the comments, I changed the initiatlization of
wholeScreen to screen()->virtualGeometry() - it seems to work for me, but I
don't know about the reasons why virtualGeometry() was deemed unreliable.

-- 
You are receiving this mail because:
You are watching all bug changes.

[plasmashell] [Bug 363935] Vertical panel covers maximized windows with new Qt multiscreen support

[Daniel Lichtenberger via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=363935

--- Comment #1 from Daniel Lichtenberger <daniel.lichtenber...@gmx.net> ---
Created attachment 99364
  --> https://bugs.kde.org/attachment.cgi?id=99364=edit
Screenshot showing the issue

-- 
You are receiving this mail because:
You are watching all bug changes.

[plasmashell] [Bug 363935] New: Vertical panel covers maximized windows with new Qt multiscreen support

[Daniel Lichtenberger via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=363935

Bug ID: 363935
   Summary: Vertical panel covers maximized windows with new Qt
multiscreen support
   Product: plasmashell
   Version: master
  Platform: Other
OS: Linux
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: Panel
  Assignee: plasma-b...@kde.org
  Reporter: daniel.lichtenber...@gmx.net

I've been using the new Qt-based screen code from
https://git.reviewboard.kde.org/r/125451/ for a few weeks now. So far no issues
and less flickering, but now I noticed an issue with a vertical panel attached
to the right screen edge: maximized windows slip below the panel, the panel's
area is not excluded from the desktop size (see attached screenshot).

Reverting the QScreen change fixes the issue. I also have this problem with the
current master version (0d0c4f4a).

Reproducible: Always

Steps to Reproduce:
1. Move the panel to the right screen edge
2. Maximize a window


Actual Results:  
The maximized window covers the whole screen, including the panel

Expected Results:  
The window should not cover the panel

-- 
You are receiving this mail because:
You are watching all bug changes.

[plasmashell] [Bug 362051] panel appears on the wrong screen/display after reboot

[Daniel Lichtenberger via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=362051

--- Comment #3 from Daniel Lichtenberger <daniel.lichtenber...@gmx.net> ---
I'm having the same issue and I also suspect it's some kind of race condition.
For me the panel is stored on the wrong (left) screen about 50% of boots.
Killing and restarting plasmashell does not trigger the issue.

I'm currently also using the following patch to replace kscreen with QT
5.6-based screen handling in plasmashell, but it didn't solve the issue:

https://git.reviewboard.kde.org/r/125451/

I added debug statements to the PanelView constructor and to the screen
change-listener of plasmashell.  Here's the output of a successful boot (panel
restored on the right screen):

> Creating panelView, setting screen to QRect(1280,0 1680x1050)

Here's the output of an unsucessful boot (panel restored on the left screen):

> Creating panelView, setting screen to QRect(1280,0 1680x1050)
> Screen changed: old= QRect(1280,0 1680x1050) , new= QRect(0,0 1280x1024) , 
> geometry= QRect(1280,1020 1x30)
> Screen changed: old= QRect(0,0 1280x1024) , new= QRect(1280,0 1680x1050) , 
> geometry= QRect(0,994 1x30)
> Screen changed: old= QRect(1280,0 1680x1050) , new= QRect(0,0 1280x1024) , 
> geometry= QRect(0,994 1x30)

The panel briefly oscillates between the two screens before staying on the
"wrong" screen.

I also got a stacktrace in the screen change listener, it seems like the
'TopLevelScreen' is being changed:

 /usr/bin/plasmashell() [0x431c74]
 /usr/bin/plasmashell() [0x435144]
 /usr/bin/plasmashell() [0x43a147]
 /usr/bin/plasmashell() [0x43a044]
 /usr/bin/plasmashell() [0x439e63]

/usr/lib64/libQt5Core.so.5(_ZN11QMetaObject8activateEP7QObjectiiPPv+0x98e)
[0x7f9412607ace]
 /usr/lib64/libQt5Gui.so.5(_ZN7QWindow13screenChangedEP7QScreen+0x2f)
[0x7f9412b322bf]

/usr/lib64/libQt5Gui.so.5(_ZN14QWindowPrivate26emitScreenChangedRecursionEP7QScreen+0x15)
[0x7f9412b328a5]

/usr/lib64/libQt5Gui.so.5(_ZN14QWindowPrivate17setTopLevelScreenEP7QScreenb+0x1bd)
[0x7f9412b383fd]

/usr/lib64/libQt5Gui.so.5(_ZN22QGuiApplicationPrivate31processWindowScreenChangedEventEPN29QWindowSystemInterfacePrivate24WindowScreenChangedEventE+0x201)
[0x7f9412b2bda1]

/usr/lib64/libQt5Gui.so.5(_ZN22QGuiApplicationPrivate24processWindowSystemEventEPN29QWindowSystemInterfacePrivate17WindowSystemEventE+0x145)
[0x7f9412b305c5]

/usr/lib64/libQt5Gui.so.5(_ZN22QWindowSystemInterface22sendWindowSystemEventsE6QFlagsIN10QEventLoop17ProcessEventsFlagEE+0xbb)
[0x7f9412b0effb]
 /usr/lib64/libQt5XcbQpa.so.5(+0x6fa10) [0x7f9404f08a10]
 /usr/lib64/libglib-2.0.so.0(g_main_context_dispatch+0x287)
[0x7f940de9e227]
 /usr/lib64/libglib-2.0.so.0(+0x4c458) [0x7f940de9e458]
 /usr/lib64/libglib-2.0.so.0(g_main_context_iteration+0x2c)
[0x7f940de9e4fc]

/usr/lib64/libQt5Core.so.5(_ZN20QEventDispatcherGlib13processEventsE6QFlagsIN10QEventLoop17ProcessEventsFlagEE+0x5f)
[0x7f941262ec3f]

/usr/lib64/libQt5Core.so.5(_ZN10QEventLoop4execE6QFlagsINS_17ProcessEventsFlagEE+0xea)
[0x7f94125da79a]
 /usr/lib64/libQt5Core.so.5(_ZN16QCoreApplication4execEv+0x8d)
[0x7f94125e2a6d]
 /usr/bin/plasmashell() [0x4232e6]
 /lib64/libc.so.6(__libc_start_main+0xf0) [0x7f9411748710]
 /usr/bin/plasmashell(_start+0x29) [0x41e859]

I'm on openSUSE Tumbleweed, Plasma 5.6.3, Qt 5.6.  I did not have the issue
with Plasma 5.5 or before.

-- 
You are receiving this mail because:
You are watching all bug changes.

[plasmashell] [Bug 362128] Task manager restored to wrong screen

[Daniel Lichtenberger via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=362128

--- Comment #2 from Daniel Lichtenberger <daniel.lichtenber...@gmx.net> ---
I still have this issue, but I noticed that the commit I mentioned was not part
of 5.6.2 and does not seem to be related to my problem.

-- 
You are receiving this mail because:
You are watching all bug changes.

[plasmashell] [Bug 362128] New: Task manager restored to wrong screen

[Daniel Lichtenberger via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=362128

Bug ID: 362128
   Summary: Task manager restored to wrong screen
   Product: plasmashell
   Version: 5.6.2
  Platform: openSUSE RPMs
OS: Linux
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: Task Manager
  Assignee: h...@kde.org
  Reporter: daniel.lichtenber...@gmx.net
CC: plasma-b...@kde.org

Since 5.6.2, my task manager bar is always restored to screen 1 (which is
left-of screen 0) instead of screen 0. I can drag it back to screen 0 (and the
lastScreen config entry is updated correctly), but on restart it's back on
screen 1. I guess this could be related to this commit:

commit 046260f397491c185e77b72110f7a2a0dfadb82b
Author: Marco Martin 
Date:   Thu Feb 4 15:50:28 2016 +0100

insist to have lastScreen -1

never risk to go in a panel by itself

diff --git a/systemtray.cpp b/systemtray.cpp
index 1e10f66..79f6c82 100644
--- a/systemtray.cpp
+++ b/systemtray.cpp
@@ -56,6 +56,7 @@ SystemTray::~SystemTray()

 void SystemTray::init()
 {
+config().writeEntry("lastScreen", -1);
 Containment::init();
 actions()->removeAction(actions()->action("add widgets"));
 actions()->removeAction(actions()->action("add panel"));


Reproducible: Always

Steps to Reproduce:
1. Drag task manager to screen 1
2. Restart the computer
3.

Actual Results:  
Task manager is restored on screen 0.

Expected Results:  
Task manager should be restored on screen 1.

-- 
You are receiving this mail because:
You are watching all bug changes.

[okular] [Bug 314943] Visibility of "This document has embedded files" should be configurable, or at least remembered across sessions

[Daniel Lichtenberger via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=314943

Daniel Lichtenberger <daniel.lichtenber...@gmx.net> changed:

   What|Removed |Added

 CC||daniel.lichtenber...@gmx.ne
   ||t

--- Comment #1 from Daniel Lichtenberger <daniel.lichtenber...@gmx.net> ---
These message boxes can be turned off globally via Settings -> Configure Okular
-> General -> Show hints and info messages. It would still be nice to remember
the setting per document, though.

-- 
You are receiving this mail because:
You are watching all bug changes.

[okular] [Bug 295567] Add ability to view embedded PDF files

[Daniel Lichtenberger via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=295567

Daniel Lichtenberger <daniel.lichtenber...@gmx.net> changed:

   What|Removed |Added

 CC||daniel.lichtenber...@gmx.ne
   ||t

--- Comment #3 from Daniel Lichtenberger <daniel.lichtenber...@gmx.net> ---
A "View file" button really improves the experience of working with embedded
files.  I  posted a patch to https://git.reviewboard.kde.org/r/127351/ that
adds a view button for any embedded file (not just PDF).

-- 
You are receiving this mail because:
You are watching all bug changes.

[Baloo] [Bug 359888] Infinite loop in baloo_file_extractor caused by tags file

[Daniel Lichtenberger via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=359888

--- Comment #3 from Daniel Lichtenberger <daniel.lichtenber...@gmx.net> ---
Created attachment 97591
  --> https://bugs.kde.org/attachment.cgi?id=97591=edit
tags file that triggered the infinite loop

-- 
You are receiving this mail because:
You are watching all bug changes.

[Baloo] [Bug 359888] Infinite loop in baloo_file_extractor caused by tags file

[Daniel Lichtenberger via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=359888

--- Comment #2 from Daniel Lichtenberger <daniel.lichtenber...@gmx.net> ---
Created attachment 97590
  --> https://bugs.kde.org/attachment.cgi?id=97590=edit
backtrace of crash

-- 
You are receiving this mail because:
You are watching all bug changes.

[Baloo] [Bug 359888] Infinite loop in baloo_file_extractor caused by tags file

[Daniel Lichtenberger via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=359888

--- Comment #1 from Daniel Lichtenberger <daniel.lichtenber...@gmx.net> ---
Created attachment 97589
  --> https://bugs.kde.org/attachment.cgi?id=97589=edit
strace output

-- 
You are receiving this mail because:
You are watching all bug changes.

[Baloo] [Bug 359888] New: Infinite loop in baloo_file_extractor caused by tags file

[Daniel Lichtenberger via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=359888

Bug ID: 359888
   Summary: Infinite loop in baloo_file_extractor caused by tags
file
   Product: Baloo
   Version: unspecified
  Platform: openSUSE RPMs
OS: Linux
Status: UNCONFIRMED
  Severity: crash
  Priority: NOR
 Component: Baloo File Daemon
  Assignee: m...@vhanda.in
  Reporter: daniel.lichtenber...@gmx.net
CC: pinak.ah...@gmail.com

I noticed baloo_file_extractor (OpenSUSE Tumbleweed, package version
5.19.0-1.1) stuck at 100% for about 30 minutes trying to index a small tags
file (the file exists and is readable, it was updated once). After about 30
minutes, the baloo file indexing daemon crashed (attached backtrace from KCrash
reporter).

Reproducible: Sometimes




I attached an excerpt from strace and a backtrace of a crash that happened
after ~30 minutes.

-- 
You are receiving this mail because:
You are watching all bug changes.