Bug 165792

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

I don't see the connection between these two.

What I reported (wished for, if you prefer that description) is the ability to have more than one bottom panel without them overlapping. Nothing to do with OpenOffice, cursors, etc.

I apologize if this somehow IS a duplicate; in that case, please provide a short explanation how are these two connected.

yes, this isn't a dupe of that bug. perhaps marco got the wrong BR#?

Vedran: also, in future it's often preferred to just comment on the bug and let us triage them (including un-duplicating them). reason for this is that for every one time the reporter gets it right (like you did), 9 others don't. this saves us (the developers) a lot of time if the triaging is left to us =)

p.s. useless note: we have rather similar last names =)

aaah, sorry, i totally messed up!
(damn tabbed browsing eheh :)

> yes, this isn't a dupe of that bug. perhaps marco got the wrong BR#?

I'd be surprised if this wasn't reported/requested yet, but I just couldn't find the original.

> Vedran: also, in future it's often preferred to just comment on the bug and
> let us triage them (including un-duplicating them). reason for this is that
> for every one time the reporter gets it right (like you did), 9 others don't.
> this saves us (the developers) a lot of time if the triaging is left to us =)

Ok, thanx for the notice. I rarely play with beta software, but KDE4 shipped with Fedora is too unfinished for my liking, hence I'm running beta now.

> p.s. useless note: we have rather similar last names =)

Did notice... :) If you have relatives in central Europe, there might be a connection.

I confirm this bug. I am using KDE 4.1 rc1 in openSUSE 11.0. 

When placing more than one panel at either side of the screen, they overlap each other instead of stacking one over the other.

I've really gotten used to have an external taskbar applet (since KDE 1.1), so this bug is a small but important pain in the butt :-)

I confirm this bug also usinf KDE 4.1 (rc1) in OpenSUSE 11.o

This is a duplicate of Bug #164052.

*** This bug has been confirmed by popular vote. ***

*** Bug 190472 has been marked as a duplicate of this bug. ***

Here's a screenshot of the way I do it in KDE 3:
http://img264.imageshack.us/img264/6594/snapshot1dx3.png

*** Bug 184880 has been marked as a duplicate of this bug. ***

*** Bug 182141 has been marked as a duplicate of this bug. ***

*** Bug 164052 has been marked as a duplicate of this bug. ***

to follow up on this one ... i have the sneaking suspicion that for the vast majority of use cases, multiple panels is a _work around_ to panels only allowing a single row of items.

to those who are on this report, is that correct? if panels allowed you multiple rows of widgets, would you be all happy?

the only use case i can think of that isn't covered by that is if one wants two panels of different widths such as a 100% width panel beneath a 50% panel.

so... the problem with stacked panels:

what do you do with stacked autohide panels? (kicker had issues there, btw; they could pop up one above the other, but then it's essentially "one" panel as far as unhide triggering goes)

how does one control which goes above another? (usually this ends being a situation where the user is forced to do a "move that panel to a different screen edge, ok, now back again" dance or else just "first come, first serve" stacking which is what kicker did; i never really liked that but at least it was predictable and was easy to guarantee consistency)

what do you do with a panel that is left aligned and 45% width and another that is right aligned by 60% width? iow, the classic "only overlaps a bit" scenario. do panels only stack if they are 100% overlapping? 90%? 

etc, etc..

stacked panels really only look good in certain configurations, and cause all sorts of fun if you get creative with your configuration. which is exactly what people who use stacked panels tend to do ;)

so ... i'd really, really like to avoid stacked panels and instead offer something that addresses the bulk of the use cases without the nasty consequences.

a multi-row panel would be easy enough to implement. what do you think?

For all serious purposes, I believe that you're right: stacking panels is mostly used as a replacement for a multirow panel. Btw, I don't use autohide.

If you DO implement a multirow panel, then consider doing it as a table and not as a stack of rows. If you (not necessarily right away) implement "cell merge" to such table, the panel might become really useful.  For example:

+---------------------------------------------------------------+
| [KDE menu]  [app. buttons]   [ Task manager ]   [system tray] |
| [more application buttons]   [ spanned in 3 ]   [ in 2 rows ] |
| [more application buttons]   [ rows!        ]   [   clock   ] |
+---------------------------------------------------------------+

So, in this example, a panel would have 3 rows and 3 columns, but the rows of the second column would be merged in one "cell", thus allowing task manager to provide more space (i.e. more of its own rows). Also, the third "column" would have its first two rows merged to allow higher (and therefore narrower) system tray, while underneath ot would be clock.

I hope I have explained the idea properly.

Don't get me wrong: merging is not something I'd expect to get any time soon, but, if you do like the idea, it would be useful to implement panels table-like right away, instead of rows-like and then changing it some time in the future.

If you don't like the idea, than the answer to your question is: yes, I believe that multirow panels would be enough for all not-funny purposes.

Thank you,

V.

ad. #15) +1 vote for multirow, 

I use this config all the time 

#        ##############     <---- top of the screen
#
#
#

those are to panels, but looking the top of the screen, they "share" the same horizontal space. So if this can be achieved without stacking panels, it is ok with me.

But is think anyway it is a bit limiting, i.e. user should be able to define the panel alignment, orientation and placement. So in the effect you would get stacked panels (indirectly though).

(In reply to comment #15)
> to follow up on this one ... i have the sneaking suspicion that for the vast
> majority of use cases, multiple panels is a _work around_ to panels only
> allowing a single row of items.
> 
> to those who are on this report, is that correct? if panels allowed you
> multiple rows of widgets, would you be all happy?

Yes, very happy! Being able to place a taskbar widget in this extra row would emulate the look-n-feel of an external taskbar, which was present until KDE3 and which I miss very much. 

That said, I agree with Vedran Sego; a "table-like" panel would be a very interesting idea, one that would allow all sorts of nice and imaginative customizations on the desktop.

I would be happy with a multi-row panel.

The Sego's idea about cell-merging would be great,

I imagine it so:
1) Pick a special widget "Multi-row cell"
2) Click on the panel (defining a corner) and drag to another point (defining the other corner).
3) Add any wigdet(s) (maybe this can restricted to one) to that space

@Marco Poletti:

I'd prefer this to be a feature of the panel and not a special widget. Two reasons:

First, having "multirow widget" would require to make it possible for a widget to span over several rows. If that is made possible, then no special ("multirow cell") widget is needed at all, but you could just span your usual widgets (in my example: task manager and system tray).

Second, rearranging existing widgets would probably be too hard: you'd have to add this special widget together with all others, and then move them from panel to this widget. I'd be very, VERY happy to avoid this. I'm also assuming that Aaron would be happy to avoid it as well. :-)

So, either my original "table-like panel" solution or add property to panel widgets to be row-spanned. I must admit that this second idea seems even nicer to me than my original idea, if it can be done so that it doesn't collide with the idea of arbitrary widgets placement (i.e. widgets can be placed on a desktop as well, not only panels). I suppose that desktop chould be seen as a single-row panel or should be added "number of rows" property as well.

I think the possibility to stack multiple widgets is important. Implementing in a multirow panel sounds interesting but is useful in _other_ cases.

In this case its bad, that panels can overlay each other. There should be an detection if an panel is alright there. I that case calculate the offset and pint the panel at the calculated offset. This could not so hard.

*** Bug 203122 has been marked as a duplicate of this bug. ***

(In reply to comment #21)
> I think the possibility to stack multiple widgets is important. Implementing in
> a multirow panel sounds interesting but is useful in _other_ cases.

I agree that both ideas sound worth implementing to me.

> In this case its bad, that panels can overlay each other. There should be an
> detection if an panel is alright there. I that case calculate the offset and
> pint the panel at the calculated offset. This could not so hard.

I don't think implementing an algorithim is the problem here - deciding on which one to implement is. That said, I think the position could be determined using drag'n'drop. And perhaps docking one panel to another might be useful for saving the relative positions.

I would be happy with a multi-row panel. It would be nice if I could hide the upper row and keep the lower one. Perhaps even be able to have the show/hide button for the upper row on the lower row - that would surpass what KDE3 had.

renaming this wish after the discussion here.

*** Bug 185142 has been marked as a duplicate of this bug. ***

I'd like to add that it should still be made impossible to put two panels on the same screen edge because of the whole one panel hiding another thing. (IOW this isn't only about multirow panels, see comments #1 - #6.)

"it should still be made impossible to put two panels on the same screen edge"

you already can, but they will overlap instead of stack. 

we currently have no intention to support stacking random panels because there's no way of supporting all configurations well. kicker proved that rather well.

> "it should still be made impossible to put two panels on the same screen edge"
>
> you already can, but they will overlap instead of stack.

How? In KDE 4.3.1 I can't seem to prevent two panels from occupying the same screen edge.

*** Bug 202776 has been marked as a duplicate of this bug. ***

The issue seems to be a solution for bug #168579 as well, which is a similar issue for vertical panels.

One concern mentioned on that bug would be the case of widgets that should be shown the full width of the panel, such as the analogue clock. Therefore, if a panel will have a multi-row options (multi-column in the case of a vertical panel) then an area of single row/column should be available for widgets such as the analogue clock and others for which the full height/width of the panel is necessary. I know that may complicate things, what do the devs (Aaron) think of this concern?

*** Bug 251878 has been marked as a duplicate of this bug. ***

in kdeplasma-addons/containments/groupingdesktop/panel there's a multirow panel.
It is rather simple still but it provides the basic needs asked here, so i think is ok to close this bug.

i test it on last beta of 4.6 and it was not really surprising. widgets are not locked (in normal panel they are only unlocked if the config is open (length, width, height settings, ...), arranging applets was hard (exact position of a applet is hard), and so on.
All subscribers of this bug should test that function and report their feedback. I'm sure there is place for improvment before 4.6 release.

Nope, the multirow panel idea is not good. It should not have a separate panel for that. The default panel should support the “rowing” feature. At least have rows (or columns when places vertically). If that spacer widget would just work as expected (which it never did!) there would be no need for columns in my eyes. I don‘t think that panels need to be split into cells anyway. The idea is fine for the desktop but on panels, I don‘t know…
The fact is that the current implementation is just… bad. Widgets are way too small and it is complicated to place them where you want them since they don‘t snap as they were used to in the default panel. It is so uncontrollable and random how your widgets are sized and positioned.
Just let the user stack widgets on top of each other and everything would be fine. In 4.6 the window corner dragger is way more intuitive, you can optically drag the panel where you like it, so you end up dragging your panel above the other panel, release the mouse button and it snaps to the screen corner. Am I the only one who would like to have his taskbar at the top and below this the global menu bar? It seems so.
One of the most missing features in my eyes is the ability to place a panel on top of another. Please first implement this before playing around with a buggy grouping panel.

I concur. I have had a panel with my menu, shortcuts, and notification
bar above a panel dedicated to  task manager on pretty much every
computer I have ever used -- other than those running KDE4. This allows
a *full* panel for task manager, and does not limit the user -- but for
some reason people decided to cut this common feature out of kde 4.

KaiUweBroulik2@hotmail.com wrote:
> https://bugs.kde.org/show_bug.cgi?id=165792
>
>
> KaiUweBroulik2@hotmail.com changed:
>
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>                  CC|                            |KaiUweBroulik2@hotmail.com
>
>
>
>
> --- Comment #35 from  <KaiUweBroulik2 hotmail com>  2010-12-16 16:35:29 ---
> Nope, the multirow panel idea is not good. It should not have a separate panel
> for that. The default panel should support the “rowing” feature. At least have
> rows (or columns when places vertically). If that spacer widget would just work
> as expected (which it never did!) there would be no need for columns in my
> eyes. I don‘t think that panels need to be split into cells anyway. The idea is
> fine for the desktop but on panels, I don‘t know…
> The fact is that the current implementation is just… bad. Widgets are way too
> small and it is complicated to place them where you want them since they don‘t
> snap as they were used to in the default panel. It is so uncontrollable and
> random how your widgets are sized and positioned.
> Just let the user stack widgets on top of each other and everything would be
> fine. In 4.6 the window corner dragger is way more intuitive, you can optically
> drag the panel where you like it, so you end up dragging your panel above the
> other panel, release the mouse button and it snaps to the screen corner. Am I
> the only one who would like to have his taskbar at the top and below this the
> global menu bar? It seems so.
> One of the most missing features in my eyes is the ability to place a panel on
> top of another. Please first implement this before playing around with a buggy
> grouping panel.
>
>

"Am I the only one who would like to have his taskbar at the top and below this the global menu bar? It seems so."

Well I put them at the bottom of the screen, but otherwise no, I want the same thing. :-)  One big line of buttons (and system tray, etc.), and above it one big line of taskbar.

I do not know the innards of KDE well enough to say what the "right" approach is to make this possible, but at this point it is a functionality regression from KDE 3/Kicker in Plasma.  It is not fixed.

I do think it would be nice if the features of the grouping panel and grouping desktop were integrated with the default panel and desktop for 4.7, but whether the plasma developers would be willing to do that or not is a different matter entirely.

i'm not saying the grouping panel is finished and perfect as it is now. In fact, it is the only way to have multirow panel. It sure needs many improvements, but i will not implement the support for stacked panels and i don't think i'll implement multirow in the default panel.

Then, if it doesn't answer what this bug report is asking for, it can be always reopened.

Why close it, when you have already received feedback that it does not
answer what this bug report is reporting? While it sounds like an
interesting project, and may meet the needs of some people, this is
still an open regression bug from KDE 3.5

Giulio Camuffo wrote:
> https://bugs.kde.org/show_bug.cgi?id=165792
>
>
>
>
>
> --- Comment #39 from Giulio Camuffo <giuliocamuffo gmail com>  2010-12-16 21:40:08 ---
> i'm not saying the grouping panel is finished and perfect as it is now. In
> fact, it is the only way to have multirow panel. It sure needs many
> improvements, but i will not implement the support for stacked panels and i
> don't think i'll implement multirow in the default panel.
>
> Then, if it doesn't answer what this bug report is asking for, it can be always
> reopened.
>
>

But why not leave the grouping panel be a grouping panel and still allow stacking panels? This would be the most intuitive and discoverable way of having those two rows. I don‘t think the average user would add a grouping panel (which the default panel is not by default) then re-add his widgets and fuzz around with the weird placement, add a row and add his widgets there.
So - speaking for me - I would move the default panel to the top of the screen, add another panel with the Global Menu Bar and put it below -> Done!
Also, it is not intuitive that the panels cannot be stacked. You move your panel around with the new dragger (in 4.6 the panel follows your mouse pointer instead of jumping around screen edges) and then you position it right over the panel and after releasing the mouse button you find the panel sliding below the already existing one (or over it covering it). And this is not good!

it is not that i don't think panel stacking of a default multirow panel is a
good idea. the thing is that coding requires time and effort. nobody pays me to
code and i prefer to work on what i need and i like. i don't need a multirow
panel, and i developed the grouping panel only because it allowed me to test a
concept and it required very little effort: if you look at the size of its code
it is really tiny compared to the default panel.

Right -- and I support that. You code what you want -- but don;t mark a
bug as closed when it is not, just because you don't want to write the
solution. Leave it open so someone else can find it and try and write a
solution if it bothers them, and they have the ability.

Giulio Camuffo wrote:
> https://bugs.kde.org/show_bug.cgi?id=165792
>
>
> Giulio Camuffo <giuliocamuffo@gmail.com> changed:
>
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>              Status|RESOLVED                    |REOPENED
>          Resolution|FIXED                       |
>
>
>
>
> --- Comment #42 from Giulio Camuffo <giuliocamuffo gmail com>  2010-12-16 22:34:02 ---
> it is not that i don't think panel stacking of a default multirow panel is a
> good idea. the thing is that coding requires time and effort. nobody pays me to
> code and i prefer to work on what i need and i like. i don't need a multirow
> panel, and i developed the grouping panel only because it allowed me to test a
> concept and it required very little effort: if you look at the size of its code
> it is really tiny compared to the default panel.
>
>

(In reply to comment #42)
> nobody pays me to
> code and i prefer to work on what i need and i like.
As iI repeated some times in irc:

> [10:18:07] <crissi> next, configuring the length and position of the panel is _not_ intuitive. in kde3 it was: http://crissi.linux-administrator.com/tmp/panel_settings_kde3.png
> [10:18:07] <notmart> but now neeeeh, sorry  :)
> [10:18:30] <crissi> that was easier for users
> [10:20:05] <crissi> if you can improve the panel and implement stacking i'm happy (and a lot ppl too). I promise you a donation if you get that one ready.
> [10:23:32] <crissi> that promise is valid until end of march.

I offer again:
I will made a donation (> 20EUR) if this feature (panel stacking) will be implemented. For made the multiurow panel _really_ intuitive and good working i'll made a small donation (10EUR). 
Its nessary to implement it _before_ 4.6 release to get the _full_ donation value.

I think thats fair and some ppl will think same.

Not to be a wet towel, but 30 Euro is not even close to the value of one hour's work, so it's not going to be a huge motivator, I'm afraid. Furthermore, 4.6 is already feature frozen, and no amount of money can change that.

Finally, as I've noted multiple times on irc, stacking panels on the same side of the screen is exceptionally (perhaps deceptively so) difficult and has quite large obstacles to implementing it properly when you take things like auto-hide into consideration.

I know because I worked on the stacking support of kicker for years and the number of "gotchas" were pretty impressive and it never did work 100% right in all situations. ("Marching panels" was an occasional and humorous regression that would creep in from time to time as well ..)

In any case the wishlist item has been lodged. Someone can write the code (it won't be me), but until then I don't think further discussion or promises of small amounts of money are useful for anything.

Cheers ..

(In reply to comment #45)
> Not to be a wet towel, but 30 Euro is not even close to the value of one hour's
> work, so it's not going to be a huge motivator, I'm afraid.
Right but if more than only one donate money, it should be a greater sum.

 Furthermore, 4.6 is
> already feature frozen, and no amount of money can change that.
Right, for stacking its short time. But for fix the multirow panel it should be not to late.
 
> Finally, as I've noted multiple times on irc, stacking panels on the same side
> of the screen is exceptionally (perhaps deceptively so) difficult and has quite
> large obstacles to implementing it properly when you take things like auto-hide
> into consideration.
Maybe. It works fine here (kde 3.5.10). Autohide should not so problematic (case1: no autohide, case2: autohide base panel only, case3: autohide base panel and stack panels). I think with that most of the users which used stacking before this is ok. 
 
> I know because I worked on the stacking support of kicker for years and the
> number of "gotchas" were pretty impressive and it never did work 100% right in
> all situations. ("Marching panels" was an occasional and humorous regression
> that would creep in from time to time as well ..)
Ask the ppl outside if they have many problems with stacking panels on kicker. I guess most ppl are happy.
 
>I don't think further discussion or promises of
> small amounts of money are useful for anything.
I dont think so. Let us hear what user users have to say.

Stacking is still not possible in 4.6.2 or dev, thats a pity. Please reimplement that  feature.
Otherwise, kicker with the possibility to load plasma applets (and kicker containments) would be great.

We wouldn‘t need that feature if that Stacking Panel would just WORK as expected. But it doesn‘t and I‘d rather be able stacking panels to my liking.

Now, we have summer 2011, kde 4.7 is out and the problem is stil not fixed.

There is another idea how the problem could be fixed:

Make plasma containers dockable.

This will fix the problem and would allow to dock various plasma containments to each other like toolbars.

Heck, they are talking about KDE 5 already -- and we still don't have the features they broke when they left KDE 3.5 working. It's a shame that regression bugs are not addressed at all.

> It's a shame that regression bugs are not addressed at all.
>

Regression bugs are addressed in the same fashion as any other feature request.

(In reply to comment #50)
> Heck, they are talking about KDE 5 already -- and we still don't have the
> features they broke when they left KDE 3.5 working. It's a shame that
> regression bugs are not addressed at all.
Yes, this bug was openend 2008-07-05 and still not fixed :(

Dotan,

And that's the problem. A regression bug is *NOT* a feature request, and should not be treated like one. A regression bug is a bug that crops up, or a feature that *used to work* that no longer works due to a recent code change. This is a once-working feature that *broke* when they released KDE 4.0. In 3.5 this feature works consistently, but was broken when they changed the code base.

A feature request, on the other hand, is asking for new or expanded functionality that has never existed in the past.

If anything, regression bugs, being a bug, should be treated as such -- and bugs should never be labeled 'wishlist'.

> Yes, this bug was openend 2008-07-05 and still not fixed :(
>

https://bugs.kde.org/show_bug.cgi?id=78758
https://bugs.kde.org/show_bug.cgi?id=64494
https://bugs.kde.org/show_bug.cgi?id=65692

> A feature request, on the other hand, is asking for new or expanded 
> functionality that has never existed in the past.

please stop wasting all of our time with meta-arguments on bug reports. if you want this feature, go back to using kicker. otherwise, it's a feature request for plasma-desktop which has never supported this feature. i don't care to argue semantics nor do i care to receive lectures in my inbox from random passerby.

this bug has been triaged to the appropriate location and until someone submits a patch, it remains open. it's been described numerous times what sort of patches would be satisfactory.

until then, metadiscussions are unwelcome. if they persist, i will close this particular report as having been driven into useleness, something i've had to do twice in the last 4 years due to people who feel it is more important to argue.

cheers...

(In reply to comment #55)

> please stop wasting all of our time with meta-arguments on bug reports. if you
> want this feature, go back to using kicker.
Where its for kde4? If there is an updated version for current kde4 I'll use it.

Aaron,

I was under the impression that KDE4 did not support kicker, which is why it would be a regression bug. If you would kindly show us how to get kicker working in KDE4, I will agree that this is an issue of semantics, and move on. I don't mean to give the impression that I feel it is more important to argue, but when I last looked into this, there was no work around for this bug.

I'm sorry we are arguing semantics, but it's clear that many of us do not feel that this has been triaged to the the appropriate place, and are simply hoping for a resolution to this bug, and the ability to once again use features that have long been working in KDE.

a patch for this is available at: https://bugs.kde.org/attachment.cgi?id=72401

(In reply to comment #58)
> a patch for this is available at:
> https://bugs.kde.org/attachment.cgi?id=72401

Thank you for the patch. Could you please submit this to http://reviewboard.kde.org ?

Its submitted but it seems that its still not available in current git. I think it should be available in next release (4.9.3) but latest in 4.10 (release date is at 13.th Jan 2013).

Its really bad that a bug reported at 2008-07-05 is still not fixed.

Whats about to add an option for manual positioning a panel (e.g. offset from edge)?

That would be a workaround.

Hello!

This feature request was filed for KDE Plasma 4, which reached end-of-support status in August 2015. KDE Plasma 5's desktop shell has been almost completely rewritten for better performance and usability, so it is likely that this feature request is already implemented in Plasma 5, or is no longer applicable.

Accordingly, we hope you understand why we must close this feature request. If the requested feature is still desired but not implemented in KDE Plasma 5.12 or later, please feel free to open a new ticket in the "plasmashell" product after reading https://community.kde.org/Get_Involved/Bug_Reporting

If you would like to get involved in KDE's bug triaging effort so that future mass bug closes like this are less likely, please read https://community.kde.org/Get_Involved#Bug_Triaging

Thanks for your understanding!

Nate Graham

This is still valid in plasmashell.