Bug 51423 - windows improperly maximize when using child panels
Summary: windows improperly maximize when using child panels
Status: RESOLVED DUPLICATE of bug 41201
Alias: None
Product: kicker
Classification: Unmaintained
Component: general (show other bugs)
Version: unspecified
Platform: Compiled Sources Linux
: NOR wishlist
Target Milestone: ---
Assignee: John Firebaugh
URL:
Keywords:
: 74513 (view as bug list)
Depends on:
Blocks:
 
Reported: 2002-12-02 07:03 UTC by jb1
Modified: 2004-11-26 05:59 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:

Attachments
Example of problem (82.51 KB, image/png)
2002-12-02 07:05 UTC, jb1 		Details
Another Example - with Desktop Menu (56.67 KB, image/png)
2002-12-02 07:08 UTC, jb1 		Details
this easily shows the problem - 2 monitors (213.37 KB, image/jpeg)
2004-04-29 20:25 UTC, michael mastrangelo 		Details
View All Add an attachment

Note You need to log in before you can comment on or make changes to this bug.
Description jb1 2002-12-02 07:03:41 UTC 
Version:            (using KDE Devel)
Installed from:    Compiled sources
Compiler:          gcc3.2 CFLAGS="-mcpu=athlon-xp -O3 -pipe" 
OS:          Linux

I've noticed that windows maximize improperly when using a child panel (probably does same thing with regular panel).  Also, the desktop menu's drop down bars are improperly placed.  I can attach screenshots of the problem to explain more clearly.

Thx in advance!!
Comment 1 jb1 2002-12-02 07:05:45 UTC 
Created attachment 554 [details]
Example of problem
Comment 2 jb1 2002-12-02 07:08:10 UTC 
Created attachment 555 [details]
Another Example - with Desktop Menu
Comment 3 Kevin Puetz 2002-12-12 01:09:12 UTC 
yeah, this code sucks... it's even worse on multihead displays. NETWM only gives a reserved 
width along each border, nothing more. We really need reserved regions, rather than just 
distances from the borders. 
 
Confirm, but I don't know when or what will be done about it. I'll try to keep this in mind when I 
give the multihead issues (which are even worse) a staredown
Comment 4 bo 2004-01-07 10:32:46 UTC 
One easy way to see the problem (if you have xinerama set up):

I have Xinerama with two identical monitors. I have set up kicker to only show on my right monitor. With this setup, kwin does not use the area on the left monitor that kicker occupies on the right one. Not use means not to auto place in it and not to maximize in it.
Comment 5 michael mastrangelo 2004-02-08 21:01:43 UTC 
same problem as bo@sonofthor.dk

it happens with main kicker, child panels, and other panels.
Comment 6 michael mastrangelo 2004-04-29 20:25:29 UTC 
Created attachment 5818 [details]
this easily shows the problem - 2 monitors

Using 2 monitors - this is extremely easy to show...
Comment 7 michael mastrangelo 2004-04-29 20:27:25 UTC 
I think this may be the cause of non "Tetris effects" of kicker and panels - look at bug 74513 for an example of the "Tetris effect" wanted to see how solving one of the two bugs may solve the other.
Comment 8 Mathieu Jobin 2004-08-31 19:23:38 UTC 
I think this is fixed in 3.3, however i can't test it, since I can make a panel with a width different of 100%,... for a reason, its broken in 3.3
Comment 9 Mathieu Jobin 2004-08-31 19:30:51 UTC 
sorry, this is still valid
if the panels are on different screen (xinerama) its better than in 3.2
but on a same screen, the same problem exist.
plus maximizing the window verticaly does not do what is expected on comment #1
Comment 10 Aaron J. Seigo 2004-09-15 00:49:02 UTC 
*** Bug 74513 has been marked as a duplicate of this bug. ***
Comment 11 Aaron J. Seigo 2004-11-26 05:59:05 UTC 

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