After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 600287 - [Patch] Fixed-Height Task List Buttons in Vertical Panel
[Patch] Fixed-Height Task List Buttons in Vertical Panel
Status: RESOLVED DUPLICATE of bug 86382
Product: libwnck
Classification: Core
Component: tasklist
unspecified
Other All
: Normal enhancement
: ---
Assigned To: libwnck maintainers
libwnck maintainers
Depends on:
Blocks:
 
 
Reported: 2009-11-01 06:09 UTC by HyperHacker
Modified: 2010-03-09 01:32 UTC
See Also:
GNOME target: ---
GNOME version: ---

Attachments
Quick hack: force task list buttons to be 20px tall (553 bytes, patch)
2009-11-01 06:09 UTC, HyperHacker 		none Details | Review
Fixed-height buttons with progress bars (39.79 KB, image/png)
2009-11-01 06:12 UTC, HyperHacker 		  Details

Description HyperHacker 2009-11-01 06:09:53 UTC 
Created attachment 146671 [details] [review]
Quick hack: force task list buttons to be 20px tall

This patch is a quick hack to force the task list buttons to be 20px tall. I
have a tall vertical panel and it annoyed me to have giant buttons when there
were few of them, so I did this.

For some reason if I add fields to struct _WnckTasklistPrivate, my xfce4-panel
breaks, so I was unable to do this the proper way (adding fixed_button_width
and fixed_button_height fields and API calls to set them; <= 0 to disable).
Hopefully someone who can figure out how to make that work can take it to that
extent. (I don't doubt there are horizontal panel users who find the autosizing
behaviour bothersome as well, but this patch as it is doesn't touch width.)
Comment 1 HyperHacker 2009-11-01 06:12:22 UTC 
Created attachment 146672 [details]
Fixed-height buttons with progress bars

Example of bug 600287 and bug 600286.
Comment 2 Vincent Untz 2010-03-09 01:32:13 UTC 
That's not the right way to fix it. There's an approach in bug 86382.

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