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

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

Also, I have found that the list item buttons expand to fill the hight
of the panel. Each list item button really only should be high enough
to contain the text within it. What I really want is an applet version
of the drop down window list chooser thing that appears only in the
menu panel.

Actually I am fairly sure that each task expands its vertical height
to the horizontal width of the text it contains (rather than to fill
the window list).  Expected behaviour: when contained in a vertical
panel each task should be the height of a single line of text.

It is still broken and unuseable after more than a year and a half. I
pine for the days of wonderfully customization-friendly gnome-1.4. My
hope that it will ever be fixed has been long abandoned, so I use no
window lists since they are completely useless. Too bad KDE sucks so
much or I'd switch.

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

I can confirm that the window list applet does not expand vertically on a
vertical panel but instead expands horizontally which is useless. 

This has been my single longest-running beef with Gnome 2.x (except Metacity,
but that's a digression).  I want the window list to be configurable to behave
the way I had it in 1.4:  A single column of fixed-vertical-size buttons, that
grows or shrinks as necessary, resizing the panel up or down to accomodate.  If
no windows are open, the list should effectively disappear, and the panel be
just large enough to hold the hidebuttons.  There should be no maximum bound on
how high the stack (and hence the panel) can grow, clear to the edge of the display.

Now that gtk+ can handle vertical buttons and menus, can't we just rotate the
window list applet (following what was done for the gnome menus applet) ?

Vincent: yes, we probably want to do this.

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

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

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

<dream mode>Would be great to see this bug fixed in 2.18 :)</dream mode>

Mentioned in https://launchpad.net/distros/ubuntu/+source/gnome-panel/+bug/43066 as well.

How the heck can I get off of the notification list for this bug? It's more than four years old and is obviously never going to be fixed. This was one reason, among many, that I dumped GNOME in favor of XFCE.

Tell me about it -- I raised one of the dupes in 2002, and I can't believe it's been ignored so long.

Just my 2¢, I saw the arrival of the compiz/beryl scale plugin as a LIBERATION. I don't use that applet anymore because it's just well... old. There is a bug in which the size varies depending on the window titles, the planetary alignment, and your luck. This is horrible.

Has anyone with some developer clue ever considered taking the old 1.4 window-list applet and bringing it forward, as a replacement for the obviously borked 2.x window-list applet?  Or is that just more trouble than it's worth?

Yes, can someone out there put some time in fixing this bug? It has been ignored for too long!!!

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

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

Have you considered making the titles wrap around instead if the panel is wider than some threshold?  If (say) 6 letters can fit horizontally, titles may be easier to read than the whole title vertically.

Philip: that's certainly doable, yes.

Putting this on my TODO list for 2.20. I don't know if I'll have time to do it, but it's worth a try.

Just for the record, I still favour horizontal tasks which do not expand vertically.

Why would the user put the task list on the left (or right) side of the window, rather than at the bottom?

In my case it's because I want to be able to fit lots of tasks, one below another, without each one becoming too small, which is what happens when the task list is at the bottom.

If a vertical task list were simply a rotated version of the normal horizontal one, I might as well put it at the bottom, where I can read the task names without rotating my head...

If I haven't made myself clear about what I mean, borrow a friend's Windows machine and drag the taskbar to the left-hand side, turn off grouping, and open lots of windows.  They appear as a list, one above the other, with fixed vertical heights.  This is the behaviour I would like to see in GNOME.

The plan is to let the tasklist horizontal if there's enough room for at least 6-10 characters, and rotate if it's not the case.

I use a task list on a vertical panel on a daily basis (by the way, who invented this limit of 120 pixels for a width of a panel?!), and I like it exactly for the reason described in comment #26. It possibly makes sense to rotate the list on thin panels, but I'd prefer (yes-I-have-read-GNOME-HIG) a preference for the orientation of the list, mainly because the criteria is too vague (why 6-10 characters? Will it depend on the font? If the "switch size" is in pixels, what to do with small/large fonts?..) Besides, it is perfectly ok to use a rotated task list even on wide panels, e.g. when a user doesn't run that many tasks at once, but wants to have a task list on a vertical panel.

Vincent, do you plan to prevent the tasks from becoming very tall when they are horizontal?  That's my specific bug-bear :)

(In reply to comment #28)
> I use a task list on a vertical panel on a daily basis (by the way, who
> invented this limit of 120 pixels for a width of a panel?!), and I like it
> exactly for the reason described in comment #26. It possibly makes sense to
> rotate the list on thin panels, but I'd prefer (yes-I-have-read-GNOME-HIG) a
> preference for the orientation of the list, mainly because the criteria is too
> vague (why 6-10 characters? Will it depend on the font? If the "switch size" is
> in pixels, what to do with small/large fonts?..) Besides, it is perfectly ok to
> use a rotated task list even on wide panels, e.g. when a user doesn't run that
> many tasks at once, but wants to have a task list on a vertical panel.

It would use pango to know how many pixels n characters need. Before adding a preference, let's first try to do it the automatic way.

(In reply to comment #29)
> Vincent, do you plan to prevent the tasks from becoming very tall when they are
> horizontal?  That's my specific bug-bear :)

Yes.

But again, I'm not saying this will be done. I have a huge TODO list for 2.20...

> But again, I'm not saying this will be done. I have a huge TODO list for
> 2.20...

Of course, understood.

If you have a good idea what to do but don't have enough time to do it, and could give me some hints, I might find time to try myself.  I tried to look into this some time ago, but wasn't able to understand the code enough to find where I should be experimenting.

Well, most of the work has to be done in libwnck (file: tasklist.c). We'd need to add new API to let the applet tell the tasklist object it is in a vertical panel (we already have this kind of API between workspace switcher and the pager object). And then handle the vertical case correctly when allocating the space for the task buttons (wnck_tasklist_size_allocate() and wnck_tasklist_size_request()).

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

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

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

I'll attach patches for libwnck and the window list, and also three screenshots. I'd really love to get some feedback.

Note that we start rotating the buttons when the width of the buttons is less than the grouping limit (ie, less than the size where tasklist buttons start to be grouped). By default, this is 80 pixels.

There are still issues, though:

 + if you have a large enough vertical panel, the buttons will be too big at the very beginning (after the first size allocation)

 + the orientation of the text is not updated when the panel moves from left to right. It's done after the next size allocation, though.

 + on a left vertical panel, the image is below the text. This is obviously wrong for scripts which can be read from top to bottom

 + when the text is rotated, it's not ellipsized. This is a GTK+ limitation, but I'm sure somebody can make this work in GTK+.

 + on a left vertical panel, the part of the text which is cropped is the beginning, not the end.

Created attachment 90677 [details] [review]
Rotate window list (gnome-panel patch)

Created attachment 90678 [details] [review]
Rotate window list (libwnck patch)

Created attachment 90679 [details]
Rotated window list on a left panel

Created attachment 90680 [details]
Rotated window list on a right panel

Created attachment 90681 [details]
Non-rotated window list on a large-enough vertical panel

Another issue is that the hint that is drawn for grouped tasks is not rotated.

Hi Vincent, this looks excellent!  I'm afraid I can't test it for the same reason wasn't able to do any work on developing this - I failed dismally to build using garnome on Ubuntu Dapper (my hald version was to old).

Sorry not to follow through on my suggestion I might be able to help.

My only comment is that I would like an option to force the text to be always horizontal.  Perhaps I could set the grouping limit very high?

I think it is a great improvement (I haven't compiled it). But I think the fact that it clips the beginning of the text is a problem.

I would suggest that the threshold for rotation should be separate from the one for grouping.  First, they are not conceptually connected, and it can be confusing to users.  Second, some people move panels from vertical to horizontal positions often, and so they would have to change thresholds every time.

And when a side panel is not wrapped, it would be good to have the buttons expand vertically and the text wrap inside them.

The new behavior seems to be worse, with the latest release of GNOME now the window list seems to be squashed up into about a quarter of the panel, only really enough space for one window entry.

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

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

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

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

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

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

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

Can someone explain to me how to use these patches? I'm pretty much of a noobie, but am very frustrated with the verticle panel window list buttons no longer showing any information or icons, unless it's at least 30 pixels wide. It was all fine for me in 2.18, but not 2.20. Thanks.

Did this make it in to 2.20?

Under ubuntu, get the behaviour I want, but if there's more than 7 windows listed,  clicking and holding on the applet causes it to rapidly flip between one column and two columns.

Yes, this bug is definitely in 2.20.

You have to have the panel wide enough to show window-icons (about 35 pixels). 

Yes, things worked just fine in GNOME 2.18 [Ubuntu 7.04](somewhat limited but at least functional). In 2.20 [Ubuntu 7.10] vertical window lists are just horribly broken to the point of completely unusable.

Especially the bug mentioned in #48, bug494558, makes 2.20 absolutely HORRIBLE.

How on earth current implementation made it in to a stable release is beyond me. I realize that sometimes fixing things requires first breaking them, but that should happen in alpha/beta, not stable. PLEASE back out the changes done since 2.18 and only put it back when its actually working. 

Meanwhile, if someone could direct me towards instructions for how to install/use the 2.18 windows lists with GNOME 2.20 in Ubuntu I would be most grateful. 

I agree that the situation is ridiculous. This bug started in 2002 (!!) and still hasn't been fixed? This is such a basic thing.

At least in 2.18, with a narrow vertical panel, the icons appeared, even if they were a little off center. Now they don't appear at all if the panel is less than 30 pixels, making the buttons indistinguishable from each other and therefore useless. If you're on a laptop, where screen space is at a premium, having an extra wide panel is not a solution.

And why haven't Vincent Untz patches, above, been integrated into the code? Wouldn't they at least be a temporary improvement?

I've recorded a screencast demonstrating this bug on GNOME 2.21.90 in Ubuntu Hardy Alpha4. It can be found here:

http://www.youtube.com/watch?v=dhCbnq08roA

Note that this bug makes vertical GNOME panel completely unusable. Please either merge patches mentioned above in this bug report or revert to gnome-panel 2.18 that worked just fine.

Seeing the above screen cast it strikes me that people here might not know exactly HOW broken the window list on the panel became 2.18 -> 2.20.1

http://www.youtube.com/watch?v=Pmh0lWTar5w

As you can see the windowlist keeps resizing for no apparent reason what so ever when trying to click an item or even just using another software. Makes it pretty darn hard to select the right application...

Additional info: 
* Screen is 1650x1050 (so plenty of empty horizontal space to not require switching to two columns). Same behaviour on 1024x768 screen BTW.
* Panel is 120px wide.

Can the priority of this issue be raised ? Since widescreen is now standard, a broken vertical windows list is a major defect.

The bug is exactly what is described by Stefan.

Expected behaviour :
For vertical windows list, with horizontal text :
- the height of the buttons should be fixed at one line of text, 
- new columns should be created only when all the rows are used.

(like in Windows)

I would like to underline the above by saying add that this *HAS* to increase in priority. Just the other day I figured out that this bug is the cause of a long standing issue I've had with my laptop LOCKING UP!

Description:

If you have a window list on such a NARROW HORIZONTAL panel that the (unnessecary and erratic) switching to 2 columns simply doesn't fit, it will send your CPU into a 100% usage loop that CRIPPLES your system. This renders it completely unusable until you after considerable time manage to alt-ctrl-f1 and login to killall -9 gnome-panel (and how many Ubuntu users know how to do that??)

For the Ubuntu target user group this is definitly a potential DATALOSS situation and I propose Severity: CRITICAL and Priority: HIGH

Sorry, NARROW HORIZONTAL =  NARROW *vertical* 

Additionally, with a narrow panel Im talking about 40-50px wide.

Stefan, I'd strongly suggest filing a separate bug for that issue. This bug concerns the fact that the usability of vertical-panel window lists is very poor, but even with the poor handling of the situation, it should be able to work without locking up the system.

Already realized that and made a new bugreport for that, including added this bug as blocker to the new one. At least bugs describing the erratic behaviour of the windowlist gets duped to this one so they are linked.

Created attachment 107132 [details] [review]
libwnck patch updated for GNOME 2.22

Updated the patch for libwnck for GNOME 2.22.

Created attachment 107133 [details] [review]
gnome-panel patch to accompany the one for libwnck

Merely unchanged compared with the one proposed by Vincent. Only paths prepended to facilitate applying the patch from the top directory.

What about merging it upstream? It works very well with 2.22.x

Well, as for me, it works a bit weird with my 145-pixel wide panel. After the launch, it tries to arrange all tasks in one horizontal(!) row, and, in addition, applies windows grouping, if it's on. To fix the strange arrangement it is enough to make the width of the panel little enough so that the applet switched to the vertical layout (I just delete '1' digit, so that panel is 45-pixel wide), and then change the panel width back.

The window list is not the only broken panel in vertical layout. The notification icons, the icon area and the main menu are broken too as explained in bug 428943.

Alexey, does your patch fixes the window list? I never compiled gnome, should I go ahead and try it?

Thanks!

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

This is not really my patch :) Anyway, as I said, there are some problems with it. Looks like the window list applet fails to take all available space without panel resize events, and this looks kinda weird. I'd fix this behaviour before applying the patch, but sorry, have no time for this.

Here is why I care about this issue from a usability perspective.

Placing panels on the top of the screen is problematic since it competes with application menus. You want to be able to mouse quickly to the top without too many competing items.

Placing panels on the bottom on the bottom of the screen is problematic for laptop users who detach from a large screen monitor.

Also, on a small-size display, you are more likely to need vertical space than horizontal space.

Placing a panel on the left solves all these issues. Except, of course, for the broken window list. It is very unfortunate that this bug is not getting the attention it deserves.

Amen, brother! 
+1

Anybody working on this one actively? It's been open for over 6 years now, and severely limits the usefulness of the window list on a vertical panel.

How come that this threat is still around? There are numerous different problems being discussed here (from the direction of the text to size issues - which was the original theme - to performance problems), an even greater variety of bugs were merged into this one, I seriously have no idea at all which of them the patch(es) being offered here might help me with (seem to be about rotation - what does that do here?), and I don't think (or maybe just can't believe) that the original problem is the same one as the newer ones, though the errors might look alike.
Are vertical panel users such as myself considered perverts whose problems are all thrown on one big pile you never look at again because you just don't like the guys who do that?

And, most of all, please, find someone a way to make the accurate width accessible to the window list, and make that one greedy. Can this be that hard?

Do not be so fussy Boris. This is not the way to get things done. Perhaps you can talk like that to a company, where you bought a product from.

Probably the guys who initially wrote the vertical code, are not actively working on it anymore.
I wouldn't wonder if gnome says: If there is no one to maintain this code we gonna throw it out. Thats the way open source projects handle unmaintained modules finally.

I little while ago one KDE localization guy said: "This is Linux. You need it - you do it". Looks like I've got time finally to hack on a patch. Maybe tomorrow.

Look, Sven and Alexey, open source projects ask for and actively seek out bug reports from users. This is part of how they develop. It is not a condition of filing a bug report that the user know how to fix the bug themselves. And it is important for people to continue to comment on bugs, so that developers know the problem is still out there and people know that users still care about it.

What's more, it does not at all seem to me that the Gnome project considers itself a project directed just at developers. It is used in distributions by millions of people who are not programmers. So it matters that a bug which effects some of the most basic functionality of the desktop environment, the window switcher, continues to exist. 

I really find it astonishing that this relateivley simple, but highly problematic, bug was opened six years ago and has not been addressed. I have been waiting for it to be fixed since I started using Linux two years ago. The usability of verticle panels is one of the main things I prefer about Gnome, over Windows or OS X. So it continues to be disappointing to me that I have to live with this bug that makes the window list useless. Is it the goal of the Gnome project to drive away users who are not developers?

Well, I guess Sven is right about the tone in my post. I'm sorry for that! But, you see, because of this bug I have not been able to have more than seven windows open on one desktop (which isn't that much really) for a whole year now, and that sometimes messes with my usually good spirit.
So again, sorry if it came out wrong.

However, I still opt for closing this thread. Bugzilla is a marvelous
infrastructure, it is one of the sharpest knifes the open source community
possesses, and I really do admire the possibility to give a detailed bug report
and discuss what might be the problem. But to work, it obviously needs a bit of
structure - one bug that is hunted down and solved (or declared unsolvable),
that's it. As developer, I'd hate it to have to work my way all through this
mess just to having to guess what it's about in the end.
Guess that's all I tried to say; one bug at a time, so that you can see if
either the problem might be solved one day, or if you'll wait forever in vain
and need to find other solutions like changing environment.
The latter seemed to be the case when I found this here.

By the way: Though I agree with Jeremy that this should not be generally expected, in despair, I even took a look at the source code and now plan on
learning to work with GTK+ sometimes soon to hopefully be able to help myself next time - until that day, I guess I'll have to be a crying moron who is dependent on the good will of other people.
Alexey - you'd be my personal hero if you could save me once more this time! 
And what better way could there be to close this mess but with a working patch?

I don't agree that this bug should be closed. Certainly in principle "one bug at a time" is a good idea. But some bugs aren't so simple that they can be boiled down that way. I think this bug is an example. Once the panel is made vertical, the windows list buttons do not render text and icons in an appropriate (readable) way. This has a number of effects (and possible solutions), but the bug is essentially one bug.

Again, the basic bug here is that the windows list is unusable in vertical panels. The text and icons in the window buttons ought to reorient vertically (I think), but instead it remains horizontal. Therefore there is not enough space to label the buttons and all you see is an icon and no text, or if your panel is at the minimal width all you see is an ellipsis, e.g. "..." If you read the original bug report it's fairly straightforward and easy to understand. Developers don't need to slog through all the comments. (What's more maybe there wouldn't be so many comments, if this bug hadn't been left unaddressed for six years--don't blame the length of the bug report, just because no one has done anything about it.)

Also, it's incredibly simple for any developer who wants to take this on to reproduce the problem. Just drag the panel with the windows list applet over to the side of the screen and open some windows. It will be immediately apparent that it's useless. Any attempt to address this, even without reading all the comments, would have to be an improvement.

> The text and icons in the window buttons ought to reorient 
> vertically (I think), but instead it remains horizontal. 

No, the text should remain horizontal. I blogged about this and other problems related to the vertical panel orientation here: http://versia.com/2008/06/08/vertical-panel-in-gnome/

The blog post contains screen-shots of how the vertical window list looks like in KDE and Vista. I don't think Gnome should re-invent the wheel.

Wow. Those panels take up ALOT of screen space. I'd really rather have the panel contents fit the orientation of the panel rather than expanding the panel to that size.

Hooray, things seem to happen around here finally. Two new posts while I was replying to Jeremy.

It's funny,and actually, it's what I was talking about. I see that now. If I
understand you correctly, Jeremy, your concern is about the direction of the
text and the icon size and it seems to have been the problem back in the days of 2002. But that is not my problem at all. Though I agree that
yours sucks, too.

All I want is that the window list uses all vertical space possible, and never
splits into two columns. Right now, there is a rapid changing between one and
two column view if you have more than seven windows open, making it impossible
to click on one specific window, especially because the click seems to trigger
a different kind of movement, this time (mostly) changing back and forth from
height-compressed two column view to one column view with maximum height.
If that isn't clear already: this change happens at least about three times per
second, causing a disturbing flicker. The click usually doesn't do anything
beside the described change in flickering; occasionally you get the wrong
window, but most of the time you just press the button like an idiot watching
the list twist and turn under your hits. About the fifth click might get you
the right window.
It is horrible, and I seriously hate it!

This problem was often addressed, but all reports I found were merged here (for
example 494558 or 487080 or 482621 or 478713), and if I got it right, some
people here suffer from the same thing; there is even a video linked in comment
#59 from Stefan Huszics displaying this problem, but Stefan continues to write
about hang ups and performance issues, which would be problems I never
experienced.

In fact, I don't even want the text of the buttons to behave differently than
in horizontal mode. My panel is 130 pixels in width and I want my list, well,
like a list. That's all. Compare it to a shopping list:

- one
- item
- below
- the
- other.

Just like that. No columns, no space compression until necessary, and text left
to right. Bang.
All of this was possible until 2.20, which came out last year (I think), when
this thread here was already five years old.

And that is what I'm talking about! I think this thread here started out with
precisely your problem, Jeremy, but numerous other problems were merged into
it, so that it seems to be about vertical panels in general; some questions
raised even seem to be rather concerning design, not bugs.
And though I like these questions being discussed, I'd seriously love to see my
error handled (once again: seven windows max; for one year. I'm so sore.).
And I guess so does everybody else with their bug, but: They're not the same!

For that reason, I opened up a new report, and I really hope it will not be
merged with this one again (They're not the same!). And from my understanding
of the other big problem here, I'd suggest someone does the same thing to have
a place where maybe new constraints might be worked on like when and how text
should be toggled vertically, shown at all, what about the icons and their
size, and whatnot. But again, that is not the problem I have.
And I'm happy about that in the regard that that problem is quite difficult and
it might take some time to figure out a good logical approach to it, while mine
seems fairly simple, what gives me hope.

Gentlemen, excuse the long post. I hope I made myself clear at least. Taking
the risk of exposing myself and finding me linked here again instantly (please
no), you can find the new threat concerning the flickering here:
http://bugzilla.gnome.org/show_bug.cgi?id=563407
Please help me on that issue and please don't link me here again.

I strongly disagree that text should remain horizontal in the windows list buttons on a vertical panel. That's fine if you have an incredibly wide panel. But I keep my panels at the minimum width, 23 pixels, which by the way is the default width for Gnome. I am using Gnome on a laptop and am trying to maximize screen space. A huge wide panel would completely defeat the value of a vertical panel for me (maximizing vertical screen space for open windows, while not wasting the precious remaining space on the sides).

At 23 pixels, my windows list buttons show nothing but an ellipsis, just two dots, like this: ".." That makes the buttons completely useless, since they all look the same. I consider this a bug and not just a design problem.

Given that Gnome defaults at installation to thin panels, it seems to me that the windows list (one of the most basic elements of the user interface) out to work, when dragging the list to the vertical position. What's more, even if one likes a wider panel, the windows list should still remain functional regardless of the width of the panel. The windows list be able to work with all available width settings for the panel.

What's more, most other applets that use text reorient to display the text vertically when the panel is made vertical. I know this is the case with at least the following applets: clock, battery charge monitor, menu bar, and keyboard indicator. So it seems to me the designers of Gnome have already acknowledge that text should reoriented vertically in vertical panels.

Ideally, of course, the text would reorient to horizontal if the panel is wide enough. The clock applet performs this way (though not the menu bar, battery charge monitor, or keyboard indicator, which all keep the text vertical regardless of the width of the panel). But I regard this as an added feature in the clock applet. The default behavior, if there is only one, should be vertical text. Otherwise under some conditions, namely a thin vertical panel, the applets become useless. The windows list should not be deliberately designed so that it is useless on some available panel conditions. Vertical text is the only solution that keeps the applets basically functional at all widths in a vertical panel.

***

That aside, Boris, I have seen the flickering button problem you describe and did not realize that was due to the vertical panel. I agree that this is in a sense a separate bug, although it might be resolved by fixing the text orientation problem. Verticle text in the windows list buttons would obviate the need for multiple columns of buttons--since the window list then simply behaves the same way it does in a horizontal panel, except that the buttons are reoriented vertically.

I would also like to note, that it was mentioned that the horizontal text solution in the windows list, in vertical panels, is the solution employed in Windows and KDE. This is precisely one of the reasons that I do not like Windows and KDE. There is no good solution for having *thin* vertical panels. So it is not a question of Windows and KDE getting it right and Gnome just needing to follow their lead. In my opinion, Windows and KDE have an inferior solution for vertical panels and there is no point in reproducing this.

Horizontal text when the panel is set to a large width is critical for my use of vertical panels.  Absolutely critical.  The only reason I put the taskbar on the side is so that I can see the full text of all 18 or so windows I have open, without needed further interaction to see the full list.  Very useful on both wide monitors and dual-screen setups.

Calling an approach inferior because it solves a problem for people, but not your problem, is asinine.  (Yes, really.)

I can see this working either way for different people. For me, vertical text is totally usable, (my "Menu" applet is on a vertical panel and I love it), but horizontal takes way more space than I want. Sounds like a great spot for a configurable option.

(In reply to comment #85)
> In my opinion, Windows and KDE have an inferior
> solution for vertical panels and there is no point in reproducing this.
> 
Unlike Gnome, Windows and KDE *do* have a working solution. Current Gnome implementation is not suitable neither for people who want the vertical text, nor for those who like their text horizontal.

(In reply to comment #86)
> Horizontal text when the panel is set to a large width is critical for my use
> of vertical panels.  Absolutely critical.  The only reason I put the taskbar on
> the side is so that I can see the full text of all 18 or so windows I have
> open, without needed further interaction to see the full list.  Very useful on
> both wide monitors and dual-screen setups.
> 
I second that. This bug is the only reason Vista is still my primary OS.

(In reply to comment #87)
> I can see this working either way for different people. For me, vertical text
> is totally usable, (my "Menu" applet is on a vertical panel and I love it), but
> horizontal takes way more space than I want. Sounds like a great spot for a
> configurable option.
> 
Or, the window list can switch to horizontal text automatically if the panel is wide enough. It makes very little sense to draw text vertically in this case.

(In reply to comment #88)
> Or, the window list can switch to horizontal text automatically if the panel is
> wide enough. It makes very little sense to draw text vertically in this case.

I was thinking about that. Unfortunately there's no good way I can think of to tell if it should display multiple columns with vertical text, or single columns with horizontal text.

The XFCE panel also works fine in vertical orientation. I have since switched. I forgot to unsubscribe here. Will do so forthwith.

And now, guys, could you please re-read the bug (comments 50 to 65, approximately) and look at the screenshots attached to it. Things that you discuss here are already addressed with the patch, that is attached here, too.
However, I don't think that more complaints kinda "why this patch hasn't been merged" should go to this bug, as they proved to be useless - nothing happens :) As for distribution I use, ALT Linux, the patch is already in and working for nearly a year. Maybe you should ask your distribution developers to create more positive feedback and the patch.
The only problem with the patch (the one that upsets Boris) is that the window list fails to take all available vertical space on the panel. I'm working on it.

I can only confirm what Alexey says. I'm using those patches without any problem since my last complaints about including it upstream ;)

And yes, "horizontal text on a vertical panel" idea is just horrible. Vertical panel is about to save space and not wasting it!

Fryderyk, I'm not going to step into discussing this point. I'm just employing this idea for years and I think it's convenient and effective.

Created attachment 124112 [details] [review]
libwnck 2.22 patch (final version)

So here is the final libwnck patch that works for me. This is for 2.22, but it should apply to 2.24 branch as well, AFAIK; don't know about trunk.

Well perhaps the word "inferior" was overly strong. I can see why people like the horizontal text solution. I was just trying to make the point that, whereas in its current state the horizontal text solution is far from ideal, it is only for those of us who want thin panels and vertical text that the windows list is completely useless. Perhaps with horizontal text right now, people can't see all of the full text of windows, but at least you can see some text and the icons and have an idea of to which windows the buttons actually correlate. Whereas in the thin panel situation, without vertical text, as I've said, all the buttons display nothing but an identical two dot ellipsis (".."). With all due respect, having the windows list be completely useless to me seems like a bigger problem than just not having it work the way one would prefer. And, for better or worse, as I pointed out, if there is only one solution (as is the case currently), only vertical text would be minimally useable at all panel widths. But of course it would be nice to have a solution that solves both these problems (and since it exists with the clock applet already, it seems like it ought to be possible).

That said, can someone please point me to a howto on how to apply the patch provided by Alexey. I tried doing this once before to no avail, to solve the windows list problem. I've used linux a lot, but I'm not a super sophisticated user and I could not figure out the patch solution in the past. (The patch solution also essentially lives the vast majority--e.g. millions--of Gnome users out in the cold, but that's another story."

Wow, that was fast, Alexey! I'm impressed!

Unfortunately, I couldn't get it to compile; patching worked fine (using
libwnck-2.22.3), but make gave me the good ol' undefined reference error:

...
/bin/bash ../libtool --tag=CC   --mode=link gcc  -g -O2 -Wall   -o wnckprop
wnckprop.o -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lpangoft2-1.0
-lgdk_pixbuf-2.0 -lm -lpangocairo-1.0 -lgio-2.0 -lcairo -lpango-1.0 -lfreetype
-lz -lfontconfig -lgmodule-2.0 -lgobject-2.0 -lglib-2.0   ./libwnck-1.la 
gcc -g -O2 -Wall -o .libs/wnckprop wnckprop.o  ./.libs/libwnck-1.so
/usr/lib/libgtk-x11-2.0.so /usr/lib/libgdk-x11-2.0.so /usr/lib/libatk-1.0.so
/usr/lib/libpangoft2-1.0.so /usr/lib/libgdk_pixbuf-2.0.so
/usr/lib/libpangocairo-1.0.so /usr/lib/libgio-2.0.so /usr/lib/libcairo.so
-lpixman-1 -lpng12 -lxcb-render-util -lxcb-render -lxcb -lXrender -lm
/usr/lib/libpango-1.0.so /usr/lib/libfreetype.so -lz -lfontconfig
/usr/lib/libgmodule-2.0.so /usr/lib/libgobject-2.0.so /usr/lib/libglib-2.0.so
-lX11
./.libs/libwnck-1.so: undefined reference to `wnck_obox_get_type'
./.libs/libwnck-1.so: undefined reference to `wnck_obox_new'
./.libs/libwnck-1.so: undefined reference to `wnck_obox_set_reverse_order'
./.libs/libwnck-1.so: undefined reference to `wnck_obox_set_orientation'
collect2: ld returned 1 exit status
...

I understand the voodoo of make only to a certain extend, and although I tried,
I couldn't find the missing reference; I don't even know if the output above is
helpful, but I didn't want to spam, so I didn't include more output. If that is
needed, let me know.
A copy of libwnck-2.22.3 without the patch compiled without errors, so I guess
there is something missing within the patch, but it might as well be me doing
something wrong.
But it feels like you're very close to solving the most annoying problem I've
had with GNOME, Alexey. Thank you in advance!
I'm exited already!

Greetings

Boris, you should invoke automake before running usual configure/make sequence. The patch adds new files (obox.[ch]) to Makefile.am, and they won't be compiled unless you call automake.

Fantastic, it worked! Thanks Alexey, autoconfig did the trick.

However, it didn't seem to solve my problem. The only thing that changed was that I can open up to nine windows before the flicker starts (which is at least an improvement +1).
Maybe I'm missing something; here is what I did:

patched the source, then autoconfig, config, make, make install. Finally I had to locate the file libwnck-1.so.22, which was in /usr/lib/ and had it point at the newly compiled /usr/local/lib/libwnck-1.so.22.3.8.

After restarting X, the new file is used I guess because of the +1, but window list is still only using half of the available vertical space, and it still wants to split in columns (and back, rapidly).

What now?

Boris, did you also apply the patch to gnome-panel? They work together.

>I strongly disagree that text should remain horizontal in the windows list buttons on a vertical panel. That's fine if you have an incredibly wide panel.

Well, 4:3 screens are becoming fewer and fewer every day (even on laptops), and on a WS screen it makes perfect sense to have a vertical lists with horizontal text. This is something that WAS working 100% but was BROKEN. That is called a regression. 

> What's more, most other applets that use text reorient to display the text
vertically when the panel is made vertical. I know this is the case with at
least the following applets: clock, battery charge monitor, menu bar, and
keyboard indicator.

Those apps behaviour is irrelevant. They dont diplay eg 30 different lines of text that you need to be able to read. In Firefox I'm using the "Tree Style Tabs" addon (0https://addons.mozilla.org/en-US/firefox/addon/5890 ) to get exactly this behaviour, which is the only workable way when you have 100-200 tabs open at times.
I used to be able to do the same for in Gnome, but this is no longer possible. When I could, I had this behaviour both in browser and Gnome on both desktop and laptop.

> Vertical text is the only solution that keeps the applets basically functional at all widths in a vertical panel.

That is outright wrong. It assumes you only have like 3-4 apps/instances open, which definitly doesnt hold true in my usage case (15-20 is more common for me, under which vertical text is utterly useless, since it doesnt fit).


My current solution to this bug? I've reverted the laptop to use a really old version of Ubuntu (from before this was broken). On Desktop I have one long horizontal windowlist which in combination with "show only current desktop" is an acceptable alternative. Vertical lists currently is utterly useless. 
If I wouldnt have dropped windows already 5 years back, this usage impairment would literally have made me switch back.


As for a solution that would fit everybody, why not a checkbox "display text horisontal/vertical". I dont care about how it works in default, I only care about that I can at least change it to what I want (ie the way it used to work).

So I recompiled gnome-panel with the patch applied, and the old /usr/bin/gnome-panel now links to the new /usr/local/bin/gnome-panel.
But I suppose that's not all there is to do, because nothing changed. What am I missing this time? (By the way: thank you for your patience!)

I'm afraid you're going to mess up your system with symlinks... I'd suggest you you use ALT Linux, but I understand that's too much of a change :)
So, instead of symlinks:
1) add /usr/local/bin to your PATH variable (before /usr/bin)
2) add /usr/local/lib to your /etc/ld.so.conf (or /etc/ld.so.conf.d, depends on a distribution)
3) invoke ldconfig command.
This messes up the system too, but sucks less than symlinks.
If you are interested what you are missing - besides gnome-panel binary there is libpanel-applet.so library, for example, as well as /usr/lib/wnck-applet binary that is the actual window list applet. To be short - you'll die trying to catch up on everything with symlinks, don't go this way :)
And, one more thing. The bug is not a good place for such discussions. You can write to me personally (ktirf at altlinux dot org), or ask for help in an appropriate mailing list...

>> Vertical text is the only solution that keeps the applets basically functional >> at all widths in a vertical panel.
>
>That is outright wrong. It assumes you only have like 3-4 apps/instances open,
>which definitly doesnt hold true in my usage case (15-20 is more common for me,
>under which vertical text is utterly useless, since it doesnt fit).

No, it's correct. Only vertical text, even if you hate it, allows some minimal functionality at all panel widths, whereas horizontal text does not.

Even if the horizontal text solution worked the way people want it to here, no columns, no compression until necessary, the window list buttons would still display no usable information on a thin panel. As I've said, just a two dot ellipsis ("..") displays. So the horizontal text solution guarantees that for thin panels (which is the defualt width in Gnome, for better or worse) the window list is useless when the panel is vertical. But if the text is vertical, then even with fifteen or twenty apps open, you can at least see an icon and have some idea what the window list button correlates to regardless of the panel width. That may be far from ideal for those who prefer horizontal text, but it does allow some information to appear in all buttons regardless of the panel width, which is not true of the horizontal text solution.

So I maintain that only the vertical text solution provides some information in window list buttons at all panel widths, and therefore minimal functionality, whereas in some conditions the horizontal text solutions renders the window list buttons completely useless with no information dispalyed whatsovever.

> So the horizontal text solution guarantees that for
thin panels (which is the defualt width in Gnome, for better or worse)

Only in the range between 23-29px does icons turn into (...) (and even then, hovering with the mouse over the (...) still shows you the full text). 

So, if you want to SEE icons, all you have to do is up your width to min 30px.

Instead of this simple solution you advocate continued BREAKAGE of usability for everybody with windowlist in vertical panels of about 60px or more in width.

The entire reasoning that breaking it for >60px width, by optimizing for 23-29px width, is just flawed to the point of bordering pointless. After all, even on 4:3 vertical space is more scarce than horizontal, so you are SOL in any case, as the 23-29px relative 30px difference wont exactly rock your world. 

And with such an infinitesimal small screen that a 30px panel is too wide, chances are you wont be having very many apps open in any case, so you should be able to have a fair clue of which one of your current 3-4 you opened first.



Additionally, that "the designers of Gnome have already acknowledge that text should reoriented vertically in vertical panels" doesnt hold water either. 

Eg the Sensor applet also has the "shoplist" behaviour. When refering to other panel applets, this applet is the most relevant, since it's the one that by far has the most common with the windowlists applet (multiple lines of info, suitable for "shoplist" behaviour). In my case I have 19 values tracked by it, and rotating that text would make that app just as broken and unusable in a vertical panel as the windowlists applet having vertical text.

As for other obvious "shoplist" behaviours we have the entire Gnome Menu. Changing the text to vertical for the entire menu just because it is placed in a vertical panel would just be insane. In short, "shoplist" behaviour makes sense for many things.


Finally, if you would really be interested in SOLVING this issue, you would be supporting the "lets at least have an option for old behaviour/horizontal text direction" as it would allow you to get what you want without everybody else suffering.


So coders, can we users please get an implementation that isn't entirely focused on optimizing things for people with miniscule screens and ultra thin panels while leaving the rest of us tearing our hair out in frustration. And save us from the "blinking/resizing" windowlist!

I'm not advocating that the solution should be only vertical text. If you read my comments, I already said that the best solution would be to accomodate both vertical and horizontal text options.

My only point is that if there is only one solution (which is currently the case, the only opiton is horizontal text), then vertical text offers minimal functionality is a broader array of situations, even though it's far from perfect for all the reasons people have pointed out here.

You may also dismiss the idea that a panel less than 30 pixels wide is useful (regardless of the size of the screen), but given that the default setting for panels with Gnome is less than 30 pixels and that this is probably the width at which the vast majority of users leave the panel, it seems like the windows list ought to have a solution that works when the panel is vertical, and that solution for better or worse is vertical text.

But again, I'm not advocating against horizontal text as an option. I think there should be both options. But having only horizontal text (which is currently the case), I think is a flaw, because it renders the windows list useless, when the panel is put in a vertical position at its default settings.

Ok, then we are on the same page. :)

I do have 1 more question though. Lets say someone implements images and vertical text fully working 23px panel width. 

What will/should happen once the vertical space is not enough to fit the image (and thus neither the text)? 

Dont we then again fall back into the (...) solution out of necessity since we have no other option? In short, isnt the proper solution:

1) Ensure images show up in down to 23px width, but otherwise keep current (...) implementation.

2) Have the option to choose between hor and vert text

I suppose if you had enough windows open that you could fit neither image nor text on the button, even with the vertical option, then you would be stuck with the ".." solution. That would be a lot of windows though, thirty or forty on my 14" laptop. Also, the problem you imagine would be the case whether the text was vertical or horizontal, since the icons really have the same size regardless of their orientation. So the problem you outline to me doesn't seem specific to the vertical text option. Although, I suppose with a wider panel, the problem could be avoided by splitting to two columns of buttons (but everyone here seems to hate that). And that solution is in principle available whether the text is vertical or horizontal. So I guess I don't see how the situation you're imagining relates to the question of horizontal or vertical text.

Another solution that could be applied, which would work with horizontal or vertical text, is: Once there are enough buttons that only icons fit, the buttons could scroll off screen or break out into columns off screen, which would be accessed with arrow buttons that appear and are used to scroll between visible buttons or select between the columns of buttons. Both these behaviors exist as an option with tabs, if you use the Tab Mix Plus plugin with Firefox.

That said, yes I think that icons should be shown down to the 23 pixel width and there should be an option for horizontal or vertical text.

> That would be a lot of windows though, thirty or forty on my 14" laptop.

That is assuming the user has 1 vertical panel purely for the window list. I dont and I can easily see more people wanting other stuff on it as well, like the menu, notifications, desktop switcher etc. So in the end, some usage cases could easily run out of space already at 5-10 apps. A "FIX" needs to work also in these cases.

> Also, the problem you imagine would be the case whether the text was vertical or horizontal

Indeed, that is why I separated the 2 issues from each other above. 

>  I suppose with a wider panel, the problem could be avoided by splitting to two columns of buttons (but everyone here seems to hate that)

I presume we all dont hate that it would split into multiple columns, if that is the only way to fit things. At least for me that is fine. What I/we(?) do hate is (in >2.18) when it splits into more columns when it does NOT need to and then continue to jump back and forward, sometimes several times per second (as in my screencast in #59 ).

Lets call that issue 3, to lower the confusion in this bug.

BTW, I like your suggested solution for issue 2. So let me revise my list of issues:


1) Ensure app images show up in down to 23px width vertical panels. (It does for 23px heigh horizontal panels, so this is probably related to some margin/padding, likely added due to the horizontal text)

2) Have the option to choose between horizontal and vertical text.

3) Fix vertical windowlists behaviour so 2+ columns doesnt show up even when plenty of free space is available to keep things in 1 column. (This implies also fixing the erratic jumping back and forward between X and X+1 columns at mouse over or keyboard input.)

4) Replace current (...) implementation when a new row or column would make not even the app image fit. Instead show a scrol list with <-/-> arrows in horizontal panels and up/down arrows in vertical panels. (the panel show/hide button graphics could be reused for this).


Now next question, should we split out these 4 clearly defined issues into separate bugsreports and keep this bug more as a tracker bug of "all things related to vertical windowlists"? Because as Boris pointed out, it's really hard to know which proposed patch solves which issue(s) currently. (I for one am partially lost).

As for priority, I think issue 1 & 3 are most urgent to fix.

(In reply to comment #108)
> Now next question, should we split out these 4 clearly defined issues into
> separate bugsreports and keep this bug more as a tracker bug of "all things
> related to vertical windowlists"?

Please don't do this unless you want to make my life harder :-) It might be needed at some point, but right now I'm tracking all this here. And we have to fix the basic stuff first before starting the next steps.

Unsurprisingly, I think 2 ought to be a priority as well. It's not quite as big of a problem as 1 and 3. But to me it seems ridiculous that in a thin panel you can end up with a huge button and only see an icon and no text. As I've said, this leaves the button minimally useful, but falls pretty short. And this essentially breaks the behavior that you see in a horizontal panel. And I still think having vertical text (with the horizontal text option also, but perhaps vertical as the default behavior) would keep the window list behavior consistent with how other basic applets operate in a vertical panel (menu bar, clock, battery monitor).

comment #109
> And we have to fix the basic stuff first before starting the next steps.

Are there other more basal things broken in the window list?
Or are you talking about basic panel things?

comment #110
> keep the window list behavior consistent with how other basic
> applets operate in a vertical panel (menu bar,clock, battery monitor).

Only when you carefully select which apps, and under specific conditions. Clock for me eg is horizontal in a vertical panel, as is the calendar you get when you click on it. Same with menu bar, once you click on it it's all horizontal. And eg the dictionary, weather and sensors are all strictly horizontal.

I only mean how the applets (menu bar, clock, battery monitor) appear *in the panel*, not when you click on them. This whole discussion, I thought, is about how things appear in the panel.

I selected the applets as examples not to suit my purpose, but because they are some of the most basic applets. The menu bar and clock both come installed in the default Gnome configuration, as well as the windows list. Also they are the only applets that I've used that also have long text strings like the windows list buttons, so the way they configure text in a thin vertical panel seems worthy of comparison. (In contrast the sensors and weather applet have short text strings that appear fine horizontally even in a 23 pixel vertical panel, so there's no issue there. The Dictionary, I suppose doesn't really have a good solution in a thin vertical panel, it's awkard either way the text might be oriented.

It would obviously be silly to have vertical text in the actual pop out menus from the menu bar or in the pop out calender from the clock, since at that point there are no space constraints. It is the space within the panel and how things appear *in* the panel that pose the constraints which spawn this whole discussion.

Also the clock is only horizontal in a wide panel (wider than 60 pixels). At the default panel width in a vertical panel the clock text is vertical.

> In contrast the sensors and weather applet have short
> text strings that appear fine horizontally even in a 23 pixel vertical panel,
> so there's no issue there

Surely you are joking. You will never get me to believe that your small monitor where even 7px width difference matters will actually fit eg 19 sensor value outputs on a 23px vertical panel.

Also, you claim sensors and weather doesnt have long textstrings so they are a non issue, yet you list batt mon as an example to underline how important vertical text is, yet if anything, bat mon has even shorter textstrings that the 2 you dont consider matter for comparison. 

Additionally I dont think eg "Core0 Temp 19 C" or "Graphics processor 46 C" are especially short strings.

> It would obviously be silly to have vertical text in the actual pop out menus
> from the menu bar or in the pop out calender from the clock, since at that
> point there are no space constraints.

How do you know there is no space constraint? Because in exactly your usage case there isnt? Maybe somebody on a small screen eg wants to keep the calendar open while still being able to discuss dates with someone in eg ICQ. To not have the panel applet cover the message window would be highly relevant.

> Also the clock is only horizontal in a wide panel (wider than 60 pixels). At
> the default panel width in a vertical panel the clock text is vertical.

If ONLY default settings are relevant, then all your argumentations fall due to the simple fact that there are NO vertical panels by default. And with that logic we might as well just close this bug as "wontfix"... 

comment #113:
> Maybe somebody on a small screen eg wants to keep the calendar open 
> while still being able to discuss dates with someone in eg ICQ.

That has nothing to do with orientation of the text inside the panel. Both the calendar and the ICQ window should be horizontal (obviously), because they are outside the panel.

> If ONLY default settings are relevant, then all your 
> argumentations fall [because] there are NO vertical panels by default

He wasn't saying that - he was arguing for consistency. Because the clock and weather app go vertical if the vertical panel is too narrow, so should the window list applet.

How the battery monitor is oriented also does not matter, exactly because it takes up about the same space vertically as horizontally. The question is how to orient an applet that takes more space in one direction than the other. The weather and clock applets are two of those, and they work just as they should in a vertical panel. When the panel is wide enough, they are horizontal, otherwise they orient vertically or wrap around.

I do not have a sensor applet, so I do not know how it works. But it does not matter how it works, because the sane behavior is to go horizontal if the panel is wide enough is available, otherwise go vertical. That solves both Stefan's use case and Jeremy's. 

There is no need for an option for this; instead of cluttering the user interface with another option, let's use a parameter that works for the vast majority of users. If you insist on having an option, please hide it in the gconf database. And an "always horizontal" boolean option would probably be less useful than an option for the minimum panel width when the window list goes horizontal.

> ...text inside... ...window should be horizontal (obviously)

Since it's obvious, I assume we both agree on that V text is clearly an inferior alternative if H text is an option. Yet we have suggestions of V text missing being of high importance and that it should even be the default in a V-panel. IMO a last resort alternative should NOT be the default behaviour...


FYI "weather app go vertical if the vertical panel is too narrow" is not the case for me. In a 23px panel it line breaks and stays H for me.

> He wasn't saying that - he was arguing for consistency.

Well, I would consistently want all text to be horizontal. Eg I hate the fact that keyboard selector changes to V in a V-panel (forces me to put it in a H panel) and I consider Menu bar to be completely useless for V-panels. 

And Im sure, if there are people that prefers V-text in a V-panel, there are users that would like to have V-text in a H-panel as well.

Only solution to all potential usage cases are user settings (per app or per panel). 

> the sane behavior is to go horizontal if the panel
> is wide enough... ..., otherwise go vertical

Well, if we call that "auto" and have the user setting:
 Textdirection
[ ] Auto
[ ] Horizontal
[ ] Vertical
then I agree. 

>  instead of cluttering the user interface with another option

That seems to be the cool thing right now, guess what fits most users and force it down everyones throat.

It's the direct opposed to what used to be the Linux motto, come completely unconfigured and require spending 1h reading manpages seting it up to work.

I believe they are both equally wrong approaches. The middle way I think is where nirvana lies, sensible defaults, but simple and accessible ways for a user to override default behaviour.



Meanwhile, we have a REAL bug in this thread (comment #108 issue 3), that is now into it's 2nd year of not being fixed. Hope some coder will give that some attention one day so next gnome windowpanel release works.

I opened #90777 back in August 2002 which got marked a a dupe in the second comment of this bug. I can't help but think the bug has veered off a little... but that's what six years will do.

It's great to see all of the activity and I'm glad you're working through it. When I opened the bug in the first case I had posted a composite screenshot which contrasted GNOME 2 & GNOME 1. (I've since deleted the image.)

Perhaps my memory is rose-tinted, but as I recall GNOME 1 handled vertical panels in an intuitive, highly functional way, for both small and large widths. My opinion at the time was that all GNOME 2 needed to do was follow the same behaviour.

Might it be worth sticking V1 on a virtual image and having a play with the panels? Even if it's not HIG-compliant or what we want now, it might provide some insight.

The patches work for me!  Thank you very much Vincent and Alexey.

I have posted how I managed to apply them as custom .debs on my Ubuntu Hardy machine here: http://www.artificialworlds.net/blog/2008/12/10/fixing-the-vertical-panel-window-list-on-ubuntu-hardy/

Just in case it's useful to anyone.

Created attachment 124396 [details] [review]
libwnck patch with taller buttons

I found the buttons too short for my taste with Alexey's patch so I made them taller.  I'm pretty sure the way I did it is Very Wrong, but it works for me.

What I did was multiply the "thickness" variable by 10.

I assume the correct thing to do would be to change the xthickness or ythickness property of the taskbar button in your theme.  I'm not sure how to do that...

Created attachment 125280 [details] [review]
fix up some vertical layout and grouping code

I hope the .tar is alright...

ignore the simple part... this is still a large patch... just not as large as my first try at a patch.

I broke the api... removed the screen part in the wnck_tasklist_new(void); and added some new functions.. 

bugs "fixed"
- when panel is vertical, row hight on tasks buttons are maintained
- autogrouping works smarter when panel is vertical
   |- one small bug tho.. grouping can in some cases prevent the user from 
      grabbing the parent panel... this will be a difficult bug to fix.. 
      I think the user should have to grab the panel from somewhere
      else... kinda like how KDE is going about it...
- added options to remove icons and lables.  also added the 
  option to change the task button size
   |- not added to the GUI yet... but the back-end has the options.
      I did code one tho if you want the code..?

if you ask me i think the applet panel thing needs to be updated..
perhaps do this when/if GTK adds in docking?... or does it already.. im noob
- you should be able to undock/dock applets
- add applet panels into applet panels 
- the size hint stuff seems like a hack when you have size_request
  perhaps use the GtkRequisition *requisition as an in/out parma...

and for the task list stuff i think the Notification Area shares alot of the same things we want for both.. perhaps combine alot of that code.

A icon view would be nice for the task list since it has alot of the code we want.. then you can select a few of the open tasks and perhaps group them, tile on workspace, ... kinda how in windows you can hold control and select a few tasks and then get them to tile or stack... 

the current tasklist.c is 4000+ lines of code... (not cool)
patching this crap seems silly.

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

What's the status here? It's hard to tell from the MANY patches posted here what's happening. Is there a patch that implements vertical text with rotation for the window list?

I just switched to a netbook with a little 16x9 screen. Having a vertical-text window list on a vertical panel would make this thing ALOT more usable.

I think this would never be fixed due to the complexity of it and due to the fact gnome-shell will replace gnome-panel very soon. 

That would be VERY disappointing, given as the darned thing USED TO WORK.  I always regarded it as one of the slickest and most useful aspects of the entire user interface, and it has been a years-long festering sore, the unscratchable itch, that it no longer functions.

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

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

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

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

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

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

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

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

Created attachment 140334 [details] [review]
Simpler patch to address the brokenness of the current behavior, without addressing any other potential concerns.

Simpler patch to address the brokenness of the current behavior, without addressing any other potential concerns.  This patch simply fixes the existing behavior, and only requires patching libwnck's tasklist.c.

Specifically, I'm interested in unbreaking the current behavior as much as possible, without addressing any desired changes of that behavior.  Although I have sympathy for the netbook people (having two myself), the behavior needed to take advantage of large-and-wide desktops is very different from that required for small-but-wide desktops.  

As such, I think that although it is important to have a sensible plan for the future, making the current behavior work right now is preferable to leaving it a broken state indeterminately.

Carey, I'm not very experienced in GNU/Linux, but I'd really like to try to help testing here -- this bug bothers me a lot; just fixing the brokenness of the current behavior would already be great for me.

I tried applying your patch, and I don't see any difference; but I'm not sure I did it correctly. What I did was:

. download the source for libwnck-2.27.5 (I'm running Ubuntu Jaunty, the libwnck I had installed was 2.26);
. unzip, and apply patch for "tasklist.c" (used patch command, and apparently the file was patched: its date-time changed accordingly);
. configure (a couple of tries until successful, installing the packages asked for); make; sudo make install.
. reboot -- tested opening some windows, and at some point the weird behaviour with the flickering between one and two columns shows up.

Would anyone be so kind as to tell me if I missed something, or how to confirm I'm actually running the patched version (and not the previous one in my system)? And if you need any log files etc., please let me know.

Miguel:  run "sudo ldconfig" after running "sudo make install" the first time, and
then restart gnome-panel ("gnome-panel --replace", or "killall gnome-panel; gnome-panel", or reboot).

Thanks a lot, Carey -- that did the trick.

With the patch applied, the broken behaviour is gone in my system. Congratulations for your great work!

The task buttons start with a fixed height, and the task list only changes to two columns when all the space available is filled; even then it works fine, with no "flickering" as there was before. Grouping also works fine.

The only small glitch I noticed is that there is some weird behaviour if you turn off the "expand" option (panel-->properties-->expand, or gconf-editor-->"/apps/panel/toplevels/panel_<your_panel_number_here>/expand"). It behaves as if the option was still on -- that is, the task list is always "expanded", so the panel takes up the whole height of the screen as well (if there's no other applet . Also, if I turn off "expand", move the task list inside the panel (this only seems to be necessary if there are more applets inside that panel), and then turn on "expand" again, the task list automatically compresses itself and moves to the very bottom of the panel, and to see it again I have to move it. (But that only happens if the task list is "unlocked".)

But then again, this is a very small trade-off; personally, I never turn off the "expand" option, just did it for the sake of testing. Once again, thanks for your work.

Well the current behaviour *really* needs to be fixed. For me, once the single 'short column' fills up (and it only takes about 6 or 7 windows), the entire panel freezes up, eats large amounts of CPU, and refuses to respond.

When this happens I have to close some windows, and 'killall gnome-panel'.

Thank you Carey, the window list looks much better with your patch. The height of task buttons have fixed height and the second column is not added after opening 6 windows.

However, the column IS added after 16 windows. Still, it makes the vertical window list at least usable. Thanks!

@Porges, why don't you try applying Carey's patch? That's exactly the behavior that was fixed with it. See steps above.

@Alexander, it took me 32 windows for the second column to be added -- it happened only when there was no more space available. What could be happening in your case?

(In reply to comment #139)
> @Alexander, it took me 32 windows for the second column to be added -- it
> happened only when there was no more space available. What could be happening
> in your case?

Something is definitely strange here. I just tried opening a bunch of windows, and the second column appeared after just 7 windows. I then closed all of them, moved the window list a bit, and then I could open 30+ windows without seeing the second column.

There's some weirdness that I didn't address relating the size hint used to determine how big the window list is allowed to grow. You can see another effect of this by right clicking in the empty section of the panel where the list grows into: it should show the panel menu, but in vertical orientation it shows the window list menu.

There needs to be some additional information passed between gnome-panel and the window list in order to handle these cases properly.  

That said, this patch works well enough (and the previous behaviour was broken enough) that I think it's worth committing.

What the heck? This is me trying to use the vertical window list...

http://imgur.com/9fXQa.gif

this is bad, very bad. Usability nightmare.

JP St. Pierre: that's the old (broken, obviously) behaviour.  Have you applied the patch I attached?  (http://bugzilla.gnome.org/attachment.cgi?id=140334)

Carey (or anyone else who might help),

The patch is working perfectly, but I can't seem to make it "permanent": everytime I reboot the computer I get the previous behavior, and I have to "sudo config" and "gnome-panel --replace" to get the patched behavior again.

Would you know how to make that stick? In his blog, Alexander suggested me using the switch "--prefix=/usr" when running "./configure", but that didn't help. I'm running Ubuntu -- many thanks in advance.

> The patch is working perfectly, but I can't seem to make it "permanent":
> everytime I reboot the computer I get the previous behavior, and I have to
> "sudo config" <TYPO: SHOULD BE "sudo ldconfig"> and "gnome-panel --replace"
> to get the patched behavior again.

Alexander pointed out that the solution to my problem was simply dragging another applet up and down inside the panel. This was enough to bring back the expected patched behavior, without "sudo ldconfig" and "gnome-panel --replace". Sorry for polluting the bug report with the post above.

However, that tells us that there's probably a bug in the code, such that it only displays the correct behavior after the applets are somehow refreshed (through "gnome-panel --replace" or through moving them inside the panel). But I still think the patch is already a big improvement.

@Carey
Thank you, the patch works well!

Only I had to manually add a link 
/usr/lib/libwnck-1.so.22 -> /usr/local/lib/libwnck-1.so.22

Because the "sudo make install" did not update the link to the library on my Ubuntu Januty

I hope the will use your patch for the nexe version of the window list.

Best Regards

(In reply to comment #140)
> (In reply to comment #139)
> > @Alexander, it took me 32 windows for the second column to be added -- it
> > happened only when there was no more space available. What could be happening
> > in your case?
> 
> Something is definitely strange here. I just tried opening a bunch of windows,
> and the second column appeared after just 7 windows. I then closed all of them,
> moved the window list a bit, and then I could open 30+ windows without seeing
> the second column.

I can confirm this behavior somewhat. Opened 7 windows, 8th one caused failure on the list (two useless columns of identical icons).

Doing as described above, I was able to get 9 windows before fail on 10th. The GNOME Panel 2.24.3 and libwnck-2.26.2.

I'm on Gentoo, so if there's any guidance/suggestions to getting a different list of packages that should work, let me know. I'd love to help make this bug go away.

Been using this patch for a few weeks now. I can confirm that the behavior is random, failing with as few as three items, sometimes as many as ten.

Running gnome-panel --replace & from a terminal makes the icons appear properly. 

Anyway, at the least it doesn't crash gnome-panel so it needs killing. Even if the patch isn't perfect, it's an improvement. And I feel like I'm wasting time here replying to myself, but whatever...

I do not think there will be a complete patch on this issue since GNOME 3.0 will drop gnome-panel in favor of the new gnome-shell.

I also suffer from this annoying behaviour, could you please fix it for 2.30?

This whole report / development is just pathetic. I mean... take a look how many years old is the report. Why can't someone just apply the patch AND release it in stable? I just can't understand the devs.

Anyway, thanks Vincent for the patches, I'll just create new packages from the patched source and I'll use that pack. (Thanks IF you was not in charge of implementing these patches.)

Sorry for ranting but ...yeah.

IDK if I should comment now, or not. Looking at comment 149, I decided to just go for it. Gnome-shell, no panel. (Seems not totally stable, but...)

I guess there are at least three patch sets available for the vertical panel problem. http://launchpadlibrarian.net/15679096/paskma-patch.tar is another set that *just worked* for me through a few libwnck and gnome-panel releases...

The patch from C. Underwood seemed to vary in its behavior. Sometimes I'd get a lot of usable icons in a vertical list, sometimes only four. Not really OK.

I hadn't tried the patches from Vincent. Maybe that's the ticket, but it wasn't clear to me there was an even close to official fix for this. Now, I'm beyond it. Gnome-shell is cool (as long as it works for me).

Mostly, I'm amazed that this kind of system-locking bug could persist for so *long*...

I had a bit of grief with the C. Underwood patches too. I am one of those people with a skinny vertical panel that shows just buttons, not labels. So, I simply added this to the end of wnck_tasklist_layout:

  if (allocation->width <= 40)
  {
     n_rows = n_buttons;
     n_cols = 1;
  }

A patch along these lines will make the "skinny vertical panel" camp happy. It does nothing for the "wide vertical panel" folks, but it doesn't hurt them either. (I'd be happy to submit such a patch, but I thought I'd first put the idea out there so that one of the more experienced patch authors could consider rolling it into theirs.)

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

voting for this to be fixed

Only Carey's patch applyes to 2.28 . Other refer functions that no longer exist. 
It no longer flashes/locks, but the height of this applet is too small. Only 4 buttons fit in 1 column.

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

Created attachment 155990 [details] [review]
addition to Carey's patch: ask parent for space to store buttons in 1 column

Before: 
the vertical size of applet is determined when it's loaded, and not changes. When the widget starts, it always thinks it's horizontal and thus requests the "size" for itself = button-width * nbuttons. 
But the applet knows it's vertical, so "size" becomes "height".
When number of buttons changes, and the widget thinks it's vertical, it tries to align the buttons so they fit into current rectangle, splitting to 2 or more columns when needed.
That's why if vertical, it'll never ask for more space, which is bad.

After: 
If widget thinks it's vertical, it'll ask for space to store all buttons in 1 column, not using the alignment. As the result, it decides to split into 2 columns only when the applet has reached it's max height on the panel.

Sounds right, I remember thinking something was weird there.  I'll rebuild and try this out over the weekend.

The old behaviour that I saw was that it would only use the available space if I dragged another applet over the space first;  obviously still broken, but it's worked good enough for me over the last year that I've largely forgotten about it.  It'll be good to get that fixed :)

(It's been a long weekend :p)

leniviy:  just tried it, your addition works good.

This patch triggers another bug here: the first window to be displayed doesn’t
get its title printed in the window list; just “…”. Only when a second window
appears, the two of them are displayed correctly.

This gets worse when fonts are configured to look bigger. In this case, the
panel process enters an infinite loop of computation of the size of the applet.

Also note that bug#513347 (which should be a dupe) has another patch proposal.

Created attachment 172516 [details]
Screenshot of a vertical task list with many windows showing sensible behaviour after patching.

I am also affected by this bug since I like to use a vertical task bar to save vertical pixels on a wide laptop screen.

Carey Underwood's + Leniviy's  patches work great for me. Now my task list has a single column of buttons of a fixed height (they used to expand to ridiculous heights) and they don't flicker in and out of unclickable columns when I have more than seven windows open, which is regularly.

I don't see the "..." only effect reported by Josselin Mouette - the first button has the beginning of the window name in it. I also changed the font size in the system "Appearances" settings, and I didn't see any adverse effects, even when I made the font size extremely large. Is there another font size you are referring to?

Hopefully, we can soon put this horrible 8-year old bug to bed!

Hint for anyone trying to build with these patches: you may need to copy the files created by building libwnck (should be a few, all beginning libwnck*) from /usr/local/lib to /usr/lib. Only after that should you build your panel manager, in my case xfce4-panel.

See also the screenshot above to see how my task list looks after patching.

I have a stupid question: this bug is now more than 8 years old.  There are patches available to ameliorate this behavior, and yet it is still present in 2.32, which is now just over 3 months old.  I just submitted another bug (484663) about this, not having seen this one until cross-referencing it to the ubuntu bugs list, and the misbehavior still occurs.

So will it take to get any patches for this bug released?

Sorry if I sound disgruntled, but 8 years with known workable patches?

Have you tried to join #gnome IRC channel for trying to get attention on this?
http://live.gnome.org/GnomeIrcChannels

Good luck! :-)

As far as I can tell, the patches posted here aren't working with Ubuntu 11.04 which has gnome-panel rev 2.30.2   I'm not a guru but I've been hacking on it for a while.  I've tried both the Carey Underwood patch and the Rusakov patch to no avail.  

I've also tried various tweaks and changes of my own.  No matter what changes I make to wnck_tasklist_size_request() in tasklist.c, the panel ignores them and allocates a way-too-short size for the tasklist widget.  (On my machine it's 220 pixels.)  I've also done some snooping about in the gnome-panel code trying to find a way to fix it at that end, but I just don't have the time to come up to speed on that code base.

A less-than-acceptable-but-better-than-nothing fix is to just add this code at the bottom of wnck_tasklist_layout() just after the big if-else statement:
      n_cols = 1;
      n_rows = n_buttons;
That'll display all the buttons, but smashes them into the allocated space.

I want to reiterate Mark's comment about how absurd it is that this has not been fixed after all this time.  A lack of robust configurability, as illustrated by this bug, is #1 on my list of hates for GNOME.  Also, if I had written the tasklist.c code, I'd be embarrassed.

(In reply to comment #166)
> I've tried both the Carey Underwood patch and the Rusakov patch
> to no avail.  
> 
Try to apply both Carey Underwood's and Leniviy's patches. They work with libwnck gnome-panel 2.30 - 2.32.1

I've tried the Underwood patch both with and without your (lenivy's) addition.  I fully admit that this could be a PEBCAK but from where I'm sitting I really don't think it's working any more.

When I look at the original tasklist.c code and compare it to the patch, it looks like an attempt was made to integrate the patch in the official version.  Identical or very similar code is in the right places.  So, when you patch it, it fails since the patch is essentially already there:

File to patch: libwnck/tasklist.c
patching file libwnck/tasklist.c
Hunk #1 FAILED at 1148.
Hunk #2 FAILED at 1364.
Hunk #3 FAILED at 1395.
Hunk #4 FAILED at 1410.
Hunk #5 FAILED at 1434.
Hunk #6 succeeded at 1712 (offset 84 lines).
Hunk #7 succeeded at 1721 (offset 84 lines).
5 out of 7 hunks FAILED -- saving rejects to file libwnck/tasklist.c.rej

This might be cause to celebrate except that it doesn't work.  As I described above, it appears that the panel is now rejecting the applet's request for sufficient space to display the buttons even when space is available.  I even tried hardcoding values into the requisition struct just to see that I was sane.  No matter what numbers you put in there, I always get back an allocation that has a height of 220 pixels (on my computer anyway).

IMO, the underlying problem is that you should be able to specify the size of the window list panel (width AND height) in your gconf file and you can't.

After reading this last comment from Andrew (and not being at all familiar with the source) I'm wondering if this might possibly be related to a maximum limit on the vertical size of the panel, possibly based on presumed/default horizontal orientation (as in, since the panel is horizontal most of the time and by default, it can't be more than x (220?) pixels high) but that this constraint is not alleviated or altered when the panel orientation is changed to vertical.

Side note: Ubuntu Natty (11.04) is using Gnome 2.30?  Sounds fishy to me since they're talking about going with Unity, and 10.10 runs with Gnome 2.32....

Interesting discovery:

I am running CentOS 5 in a VMWare Workstation virtual machine and I noticed that this problem does not occur there - I have the "bottom" panel on the right side of the screen and the window list occupies the entire panel without any problems.  The Gnome there is 2.16.  I also noticed that it has grouping set, so I turned that off and the list icons all shrank but the list still occupies the whole panel.  I currently have 14 windows open and they're all visible with no flashing repaint problem.

However, when I try this on my Ubuntu host (moving the panel to the right side) it makes no difference.  This is Gnome 2.30.

So it looks like this was working properly in 2.16 and has since been broken.

Hope that helps....

I can confirm that the Underwood/Leniviy patches work under Lucid with libwnck 2.30.0 (which is the latest version in the repositories).  It took me a while to get it to work just because I'm not a Linux expert. So for the other relative novices, here is exactly what I did...

Download Carey Underwood's and Leniviy's patches (bottom of this page).  Open a terminal, and perform these commands:

sudo apt-get install libwnck-dev
apt-get source libwnck
patch ./libwnck-2.30.0/libwnck/tasklist.c nbuttons.patch
patch ./libwnck-2.30.0/libwnck/tasklist.c vertical.patch
cd libwnck-2.30.0
./configure --prefix=/usr &&
make
sudo make install
sudo ldconfig
killall gnome-panel

How close is this to working for Ubuntu Maverick (Gnome 2.32), or does the same patch also work?

It looks like this bug might become moot, since in Ubuntu Natty (11.04), the panel appears to be vertical and icons only (i.e. more Mac-like) by default.
http://www.ubuntu.com/ubuntu/whats-new#the-launcher

I have put updated patches for 3.0 in bug#513347 (no rotation, but fix crashes).

Same bug appears in the fallback mode in Gnome 3 :-/

adding the window list to a vertical panel now causes X to crash when it tries to draw a window button. my system is GNOME 3 on debian wheezy/sid

$ aptitude show gnome-panel
Package: gnome-panel                     
State: installed
Automatically installed: yes
Version: 3.2.1-2+b1
[...]

So, nine and a half years on the reported list and this is not only NOT fixed, it's worse in Gnome 3?

I realize that Gnome is free and the people who work on it largely do so voluntarily, but really?  This is shameful.

I have already had a fair amount of feedback giving reasons NOT to upgrade to Gnome 3, primarily that it remains to be even half as configurable as Gnome 2 was.

I've been a software developer for my entire professional career, 32 years so far, and I've never heard of a bug being left behind for this long when, with 176 comments before this one, it is quite clear that there is concern in the public about it.

Is this really so hard to nail down that you'd rather suffer this kind of embarrassment than fix it?  Seems like a ripe challenge to tackle and fix, once and for all.

I'm sure y'all can do it.

SUMMARY:
This bug makes vertical button panels almost totally useless, if not wholly useless. The disadvantage of the workaround is that precious screen space is wasted.

DETAILS:
Depending on the screen resolution & width of the vertical panel, you generally get about 7 or so running programs before WHAM! The buttons dance about 3 or 4 times a second such that you can't possibly open up another window without clicking again and again and again, like an idiot - which for the most part, does nothing. 

The dancing buttons apparently happens, as explained in this bug, whenever a new column is started, which depends on the width setting of the panel and the number and name of the running programs. 

This youtube video set shows how easily the bug is reproduced:
http://youtu.be/NczFOlvaR9A
http://youtu.be/wdwaVfu2HHk

You might say "just put your panels on the top or bottom"; but that's a lousy workaround. 

The REASON it matters greatly to have panels on the sides of your monitor is because the most precious real estate is the top:down direction (especially on HD monitors such as that on the Lenovo W510 laptop, 1920x1080). 

So, from a logical standpoint, it wastes precious top:bottom real estate to put the panel on the top or bottom (which is the only practical location given this bug which makes the sides useless). Then you're forced to autohide, which in and of itself is an obnoxious setting due to the time-wasting lag - but at least with this sub optimal workaround, the panel can be utilized.

I have switched to LXDE which actually has a usable vertical panel (lxpanel).  One thing that probably makes it easier to deal with the semantics is that the size of the minimized windows on the panel are fixed and configurable.  So no matter whether you have 100 vertical panel items or 1, each minimized window takes up the same space.  It is probably not aesthetically as "geeky" as having dynamic sizes depending on how many applications are open, but I find it to be far more functional than the GNOME vertical panel which just became more and more unusable over time.  Perhaps the GNOME panel can take a page from this book.

Is anybody considering having a tenth anniversary party for this bug, when it comes up on ten years of being open and not resolved on June 24th of this year? It's a big important birthday.

I was also thinking there should be awards for longest running, most ridiculously unresolved bugs.

Maybe this bug's unresolved-time beats Duke Nukem Forever development-time. Related to the current unresolved-time 5 years longer isn't that long!

Happy belated 10 year anniversary! I just installed Mint Mate 13 on my widescreen laptop. Having a widescreen, it makes much more sense to arrange the panel vertically. Unfortunately, the window list in the task bar is totally screwed up and unusable in this configuration.

It makes me sad to say this, but major usability issues like this are why GNOME Linux will never be relevant in the Desktop market.

Luke, I think that's quite exaggerated. MATE is a GNOME 2 fork which is no longer developed by the original GNOME developers, so if you have problems with MATE, wouldn't it be a better idea to report this bug to them? I think it's more likely that they will fix it than the GNOME developers.

This bug has apparently been forgotten by the GNOME developers because they have moved on to GNOME 3. I don't think this is a problem since I've been using GNOME 3 for many months with great satisfaction. I don't really feel a need for a vertical menu panel in GNOME 3 now, the current panel doesn't occupy much space. I'd say that GNOME 3 has good usability and makes Linux totally relevant in the desktop market.

When I still used GNOME 2 I hoped to see this bug fixed too, but now I think the GNOME developers should just mark this as WONTFIX to be clear that they won't fix it. Then it's up to the MATE developers to fix it which is ultimately more productive for all of us than voicing our disappointment here.

This bug is still relevant for gnome-panel 3.x - although it is also here in MATE which is a fork (if you can call running sed on the sources a fork) from an earlier version.

I reported this bug against GNOME under Ubuntu 10.10 last year or the year before, and found out then that it was going on 10 years old.

That's pathetic, to be blunt.

Partially as a result of this bug, and also the new, grossly inflexible lack of configurability of both Unity and GNOME, I have gone to Xubuntu 12.04 with lightdm and xfce4, which does not have this problem.  (The Windows display applet works perfectly whether horizontal or vertical, no matter how many windows are open.)

Don't you think if they can write their vertical panel support without this bug that GNOME can handle it?

It would also be nice if the versatility of GNOME 2 were carried forward into GNOME 3, rather than the lack of both flexibility and backwards compatibility, don't you think?

bugzilla.gnome.org is being replaced by gitlab.gnome.org. We are closing all old bug reports in Bugzilla which have not seen updates for many years.

If you can still reproduce this issue in a currently supported version of GNOME (currently that would be 3.38), then please feel free to report it at https://gitlab.gnome.org/GNOME/gnome-panel/-/issues/

Thank you for reporting this issue and we are sorry it could not be fixed.