By default, Bugzilla does not search the list of RESOLVED bugs.
You can force it to do so by putting the upper-case word ALL in front of your search query, e.g.: ALL tdelibs
We recommend searching for bugs this way, as you may discover that your bug has already been resolved and fixed in a later release.
Bug 2596 - TDE unusable/unstable for minutes if panel is moved upright to the right screen edge
Summary: TDE unusable/unstable for minutes if panel is moved upright to the right scre...
Status: RESOLVED DUPLICATE of bug 2679
Alias: None
Product: TDE
Classification: Unclassified
Component: tdebase (show other bugs)
Version: R14.1.x [Trinity]
Hardware: All Linux
: P5 major
Assignee: Michele Calgaro
URL:
Depends on:
Blocks: R14.0.4
  Show dependency tree / graph
 
Reported: 2016-02-22 12:49 CST by ThoMaus
Modified: 2016-09-28 08:41 CDT (History)
3 users (show)

See Also:
Compiler Version:
TDE Version String: 14.0.2
Application Version:
Application Name: kicker (?)

Attachments
Screenshots and config files BEFORE moving the bottom panel to the right side (4.66 MB, application/x-gzip)
2016-02-24 09:40 CST, ThoMaus 		Details
Screenshots and configs DURING transition to new panel layout (14.83 MB, application/x-gzip)
2016-02-24 10:00 CST, ThoMaus 		Details
Screenshots and config AFTER the system has reached the final state and finished transistion (2.97 MB, application/x-gzip)
2016-02-24 10:26 CST, ThoMaus 		Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description ThoMaus 2016-02-22 12:49:04 CST 
If I place the "kicker" panel upright on the right screen edge the following happens (reproducible every time):

* "kicker" completely hogs 1 core (with ~4000 BogoMIPS) for around 150 seconds 
(yes 2:30!), just to layout and display the panel and react to interaction 
again
* the resulting layout is very far from optimal (to be polite)
* whenever I try to change any configuration option, either via 'kcontrol' or 
panel functions, a new "kicker" is spawned, incurring the 2:30 minutes 
paralysis penalty
* when trying to change the panel-clock configuration (hoping) to improve 
layout, the system after some minutes was driven into a trashing frenzy so 
bad, I had to physically switch of the machine (STRG+ALT+DEL or STRG+ALT+BS or 
switching to a VT were not possible anymore, terminal windows not reactive, 
even "top" was essentially frozen!)

Environment:
The TDE configuration was used for days without problems, with the panel sitting at the bottom. The problematic behavior started, when the panel was moved into the new position.

The panel is tied to the primary screen -- laptop-internal LCD 1366x768. There is a second external LCD 1920x1080, configured via "xrandr" to sit abut on top, without any overlap ("xrandr", because "tderandrtray" can't set up such configurations ...).

OpenSuSE Tumbleweed install with following additional repositories:
* the recommended ones below
      http://mirror.ppa.trinitydesktop.org/trinity/trinity/rpm/opensuse42.1/trinity-r14/
* the official OpenSuSE LEAP 42.1 repositories as second-tier, enabling trinity 
to install older library versions -- so far without any collisions or failed 
dependencies
Comment 1 Michele Calgaro 2016-02-23 04:31:01 CST 
Hi Thomas,
can you post a screenshot of the "Arrangement" and "Hiding" used for the menu panel? I am trying to reproduce the bug, but so far without luck. 
Thanks
Comment 2 ThoMaus 2016-02-24 09:40:42 CST 
Created attachment 2629 [details]
Screenshots and config files BEFORE moving the bottom panel to the right side

Hi Michele!

Find attached 3 archives with screenshots, kickerrc and kdesktoprc before, during and after the transition. Before the panel is at the bottom, then it is configured to anchor at the top of the right side and its width is increased (custom width). The screenshots are numbered consecutive.

The width seems to play a role: If I switch the position, leaving the width at normal, there is a noticable (in comparison to the bottom panel position), but much smaller (in comparison to the custom width panel on the right side) delay.


Invariant -- i.e. the same behavior results:
* Transparency (BTW having its own intermittent bug ...)
* Background picture for panel
* plain background color (both transparency and background picture deactivated)

Not tested:
* Hiding (I'm not using it (anymore -- once, on smaller screens, I was fond of it))
Comment 3 ThoMaus 2016-02-24 10:00:52 CST 
Created attachment 2630 [details]
Screenshots and configs DURING transition to new panel layout

The screenshots show the complete area of the dual head config -- not so much to show my copious and beautiful screen estate around ;-), but to let you see the "top" snapshot in one of the terminals, as well as some temporarily homeless taskbar processes manifesting themselves in tiny X-windows on the lower screen in the upper left corner.
Comment 4 ThoMaus 2016-02-24 10:26:02 CST 
Created attachment 2631 [details]
Screenshots and config AFTER the system has reached the final state and finished transistion
Comment 5 Michele Calgaro 2016-08-31 10:16:32 CDT 
Possibly related to bug 2679 ??
Comment 6 Michele Calgaro 2016-08-31 10:25:25 CDT 
Thomas, if you are still around (hope you are :-) ), could I ask you to check something?
From the screenshots, it looks like you may have configured the clock on the system tray using the "configure system tray" option and not as an applet.
If so, this may be the same issue as bug 2679 (the screenshots looks very similar to my testing).
Try disabling the clock from the "configure system tray" option (and eventually adding the clock as a panel applet if you want) and moving the panel to the right location again. 
Do you still see the same problem? If not, then this is definitely the same bug as 2679. Thanks
Comment 7 Michele Calgaro 2016-09-28 08:41:16 CDT 
I received communication from Thomas through private email regarding this bug.
Thomas was using the clock in the systray, not the external applet. Description of the problem and screenshots match what described in bug 2679, which has not been fixed.
Since this bug is likely to be a duplicate, I am closing the bug.
Thomas, should you ever come back to TDE and encounter this problem again (when using R14.0.4 or later versions), please reopen this bug :-)

*** This bug has been marked as a duplicate of bug 2679 ***