Bug 41201 - improve strut management for multiple panels
Summary: improve strut management for multiple panels
Status: RESOLVED FIXED
Alias: None
Product: kicker
Classification: Plasma
Component: Panel Strut Management (show other bugs)
Version: 1.1
Platform: Compiled Sources Linux
: NOR normal
Target Milestone: ---
Assignee: John Firebaugh
URL:
Keywords:
: 43575 51423 63466 85511 (view as bug list)
Depends on:
Blocks:
 
Reported: 2002-04-18 06:18 UTC by Felix Seeger
Modified: 2006-09-26 16:48 UTC (History)
7 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
This screenshot illustrates better the problem. (207.68 KB, image/png)
2003-09-04 14:10 UTC, Tiago Freire
Details
This screenshot illustrates better the problem(2). (207.68 KB, image/png)
2003-09-04 14:11 UTC, Tiago Freire
Details
workaround for this problem (569.72 KB, image/png)
2004-10-25 16:36 UTC, jghobrial
Details
Erratic panel behaviour in KDE 3.4 (beta1) (345.46 KB, image/png)
2005-01-20 16:14 UTC, Hugo Costelha
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Felix Seeger 2002-04-18 06:06:51 UTC
(*** This bug was imported into bugs.kde.org ***)

Package:           kicker
Version:           1.1 (using KDE 3.0.1 (CVS >= 20020327))
Severity:          normal
Installed from:    compiled sources
Compiler:          gcc version 2.95.4 20011002 (Debian prerelease)
OS:                Linux (i686) release 2.4.18
OS/Compiler notes: 

Imaging your kicker has a size of 90/80%
Now you have an extra bar for cpustats dictd and audio controll.
The extra bar is scrolled to the left.
This looks like this:

|Extra bar|         |-----------------kicker-----------------|

Now changing some things in the kicker prefer. or restarting kde brings this:

|Extra bar|
                         |-----------------kicker-----------------|

Hope this was good enough to resolve the problem.

thanks
have fun
Felix

(Submitted via bugs.kde.org)
(Called from KBugReport dialog)
Comment 1 John Firebaugh 2002-09-23 02:43:37 UTC
I don't understand the initial configuration? Can you explain that in detail 
(i.e. screen border, alignment, and hiding mode of each panel), and also give a 
detailed sequence of actions that causes them to move into the second 
configuration? 
Comment 2 Felix Seeger 2002-09-23 08:10:07 UTC
Here is some config info:            main panel             - position down, centered           - length 75%       - x expand as required....         - size small     child panel      - position down, left     - lenght 100%    - x expand as required...    - size normal    The problem is that if the child panel is at the same level as the main panel, the child panel will be above the mainpanel after a kde restart. Also it is not hidden. The possition and the state(hidden) is not saved.  I try to make an image again:  |--- child panel hidden ---|     |--- main panel ---|  After a restart it looks like this:  |--- child panel not hidden ---| |--- main panel ---|  
Comment 3 Aaron J. Seigo 2003-09-04 00:26:26 UTC
*** Bug 63466 has been marked as a duplicate of this bug. ***
Comment 4 Tiago Freire 2003-09-04 14:09:24 UTC
Ok, my bug was marked as a duplicate of this one, so I am going to repost my bug 
report here to complement the information which is already here: 
 
 I like the kasbar better than the taskbar, so I tried to set both side-by side at the 
bottom of the screen. If I set both at the middle, kicker stays in the bottom of the 
screen, and kasbar on top of kicker. I expected this. But this is what I did not expect: 
when I set kicker horizontally to the bottom right side of the screen, taking up less 
than 100% of the screen, without autostrtech, and kasbar horizontally OR vertically to 
the bottom left, there is a useless rectangle at the bottom left which will never be 
used by kicker, but kasbar is not allowed to use it too. IF I put both of them 
horizontally, one to the bottom left, and the other to the bottom right, I would like to 
see them take up only as much space as they need, and coexist side by side. 
Creative ascii-art:  
 ***** -> free space  
 ===== -> kicker 
 """"" -> kasbar  
  
 Currently, it is like this:  
  
 ***************  
 """""**********  
 **********=====  
  
 which makes no sense, look at the free space!  
 It should be like this:  
 ***************  
 ***************  
 """""*****=====  
 Kasbar also does not show buttons to scroll when there is not enough space to show 
all images (just found it!) , I will fill another bug for this.  
  
 Proposed solution:  
  
 I think there should be priorities for taking up screen space space.  
 In the control center, we have the Desktop -> Panels -> Arrangement  
 There we could/should have a Priority/Importance setting, which means "who takes up 
screen space first". 
It could be as simple as using the left list in this screen and add up/down buttons to 
switch the order of the "panel applications" (and allow them to be draggable up/down). 
The one in the top claims it space first, but only what it needs, not the full screen width 
(depends on setting, of course). The others go one after the other. This is the 1.0 
setting to be implemented.  
 Others will certainly want one panel to "squish" the other panel if it suddenly grows (as 
the kasbar does), but this could be left for version 2.0, as it is more complicated to 
agree in a "best way" to do.  
 Anyway, this is my suggestion for version 2.0:  
 Let panels be simply "Greedy" or "Shy". Greedy panels try to squish the other panels 
before they show up scroll buttons for lack of space. Shy panels never try to take the 
other panels' space. when two greedy panels collide, a) It does not claim the others 
space (my preferred) or b) the priority solves who wins and squish the other. Shy 
panels need to have a minimum width/height, though, because they must have a 
meaningful area in which to scroll content.  
Comment 5 Tiago Freire 2003-09-04 14:10:19 UTC
Created attachment 2369 [details]
This screenshot illustrates better the problem.
Comment 6 Tiago Freire 2003-09-04 14:11:45 UTC
Created attachment 2370 [details]
This screenshot illustrates better the problem(2).
Comment 7 Aaron J. Seigo 2004-10-20 03:45:02 UTC
*** Bug 43575 has been marked as a duplicate of this bug. ***
Comment 8 Aaron J. Seigo 2004-10-21 19:49:25 UTC
*** Bug 90833 has been marked as a duplicate of this bug. ***
Comment 9 Aaron J. Seigo 2004-10-25 08:00:09 UTC
*** Bug 85511 has been marked as a duplicate of this bug. ***
Comment 10 jghobrial 2004-10-25 16:36:35 UTC
Created attachment 8028 [details]
workaround for this problem

This screenshot shows a workaround with the suggested configuration in the
upper left-hand corner and an example along the bottom of the screen.
Comment 11 Jedd 2004-11-13 10:11:51 UTC
Another reason that votes for duplicate bugs should be banged across to the 'original' -- surely there's more than 60 votes against this one.  And anyone that has the power to rename the summary of this bug should consider exercising that power .. 'strut management', 'multiple panels'?!

For the gkrellm / kicker manifestation of this bug that I put in (#90833) I'd also provided some images of the problem.

 > I've got some pics (three x 8kb jpgs) at: 
 > http://www.progsoc.org/~jedd/kicker/Index.html 
 > 
 > (Drop the Index.html if you just want to d/l them directly) 
Comment 12 Aaron J. Seigo 2004-11-25 09:01:33 UTC
*** Bug 33731 has been marked as a duplicate of this bug. ***
Comment 13 Aaron J. Seigo 2004-11-26 05:59:07 UTC
*** Bug 51423 has been marked as a duplicate of this bug. ***
Comment 14 Aaron J. Seigo 2004-12-04 05:02:13 UTC
glory, glory, it's fixed in 3.4!
Comment 15 Alex Radu 2004-12-04 07:04:40 UTC
I'm happy about this too, it was annoying!
Comment 16 jos poortvliet 2004-12-05 14:05:32 UTC
angel :D

I always found this very annoying, so I simply didnt try it :D
Comment 17 Hugo Costelha 2005-01-20 16:14:47 UTC
Created attachment 9190 [details]
Erratic panel behaviour in KDE 3.4 (beta1)

Are you sure this is corrected in 3.4? I just updated to KDE 3.3.91 (beta1) and
I got the same old strange behaviour. The panels behave as if they occupy the
all area. Check the attachment.
Comment 18 Marco Krohn 2005-05-12 11:42:58 UTC
Aaron fixed it in KDE-SVN and probably backported to the 3_4 BRANCH which just means that the bug should be fixed in KDE 3.4.1. 

Kudos to Aaron!
Comment 19 Marco Krohn 2005-05-12 11:48:20 UTC
Oops, please ignore my previous comment.
Comment 20 Hugo Costelha 2006-09-26 16:48:11 UTC
This is not solved in KDE 3.5.4, so maybe it is just fixed in SVN. Is it just fixed in the SVN (head)?