(*** 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)
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?
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 ---|
*** Bug 63466 has been marked as a duplicate of this bug. ***
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.
Created attachment 2369 [details] This screenshot illustrates better the problem.
Created attachment 2370 [details] This screenshot illustrates better the problem(2).
*** Bug 43575 has been marked as a duplicate of this bug. ***
*** Bug 90833 has been marked as a duplicate of this bug. ***
*** Bug 85511 has been marked as a duplicate of this bug. ***
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.
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)
*** Bug 33731 has been marked as a duplicate of this bug. ***
*** Bug 51423 has been marked as a duplicate of this bug. ***
glory, glory, it's fixed in 3.4!
I'm happy about this too, it was annoying!
angel :D I always found this very annoying, so I simply didnt try it :D
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.
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!
Oops, please ignore my previous comment.
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)?