The gnome-panel window-list applet defines a particular width for each item depending on how much room it has. However, sometimes when _removing_ an item (ie. close a window) all the other items in the window-list shrink from 3/4 cm to 1 cm. This doesn't make sense, as the free space just got larger. This also happens sometims when adding windows, or changing virtual desktops. Also, I currently have three virtual desktops with the same number of windows on each, and the size of items in the the window-list applet is different for each desktop! A no-brainer approach would be width=n if n x number-of-items > total-space width = total-space / number-of-items endif no other fancy width stuff needs to be done, however the applet still behaves erratically! Reproducible: Always Steps to Reproduce: play around with the window-list applet. Actual Results: width of each item changes eratically. Expected Results: width of items stays the same, until there is no more space. $ emerge info Portage 2.0.51.21-r1 (default-linux/x86/2005.0, gcc-3.4.3-20050110, glibc-2.3.5-r0, 2.6.11-gentoo-r8 i686) ================================================================= System uname: 2.6.11-gentoo-r8 i686 Intel(R) Pentium(R) 4 CPU 3.00GHz Gentoo Base System version 1.6.11 distcc 2.18.3 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled] dev-lang/python: 2.3.5 sys-apps/sandbox: 1.2.8 sys-devel/autoconf: 2.13, 2.59-r6 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.5 sys-devel/binutils: 2.15.92.0.2-r8 sys-devel/libtool: 1.5.16 virtual/os-headers: 2.6.11 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-march=pentium4 -O3 -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.3/env /usr/kde/3.3/share/config /usr/kde/3.3/shutdown /usr/kde/3.4/env /usr/kde/3.4/share/config /usr/kde/3.4/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/lib/mozilla/defaults/pref /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/texmf/web2c /etc/env.d" CXXFLAGS="-march=pentium4 -O3 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks nostrip sandbox sfperms strict" GENTOO_MIRRORS="ftp://mirror.pacific.net.au/linux/Gentoo http://mirror.gentoo.gr.jp ftp://mirrors.tds.net/gentoo http://mirrors.tds.net/gentoo" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="x86 X acpi alsa apache2 arts avi bash-completion berkdb bitmap-fonts cdr crypt cups curl dvd dvdr eds emboss encode esd fam flac font-server foomaticdb fortran gd gdbm gif gnome gpm gs gstreamer gtk gtk2 guile imagemagick imlib ipv6 irda java jpeg junit libg++ libwww mad mikmod mmx motif mozsvg mp3 mpeg mysql ncurses nfs nls ogg oggvorbis opengl pam pdflib perl png postgres ppds python quicktime readline samba sdl spell sse ssl svg svga tcltk tcpd tetex tiff truetype truetype-fonts type1-fonts vorbis wifi win32codecs xml xml2 xmms xv zlib userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CTARGET, LANG, LC_ALL, LDFLAGS, LINGUAS
btw, (gnome 2.10) and gnome-applets 2.10
Width is at least somewhat determined by contents of window name. For example, right now I have one window on this desktop (firefox with this bugzilla entry), and the single window-list item is almost half as long as the bar, because it has the intire window title ("Bug 93633 - gnome-panel window-list changes item widths erratically - Mozilla Firefox") in it. When I switch pages or tabs, the width of this item changes as well. In addition, the panel can do dynamic collapsing. If I have 6 windows with identical titles (say Xterms), it can put one window-list item with "Xterm (6)". If I change the title of a single xterm, say run emerge, it will split that xterm out into it's own item. The algorithm is much more complicated than might appear on the surface.
1. Width dynamically determined by window name: This sounds like a nice idea, however, I'm currently looking at two windows in the applet, one with "gkrel..." and one with "Grip", both about 2cm each, with about 20cm of free space after the applet. However, when I switch desktops, I see "gkrellm" (it's on all my virtual desktops), "[Mozilla Firefox]" and "Bug 93633 - gnome-panel window-list changes item w..."; combined taking up all the available space. I then close "[Mozilla Firefox]", --- and the size of the remaining window list items for the two remaining windows gets _smaller_! This reinforces my "erratic" (inconsistant) behaviour claim in two ways! -- 1. item-size determined by window title is different for each virtual desktop, and 2. item-size gets _smaller_ when available space gets larger. 2. grouping Personally, I have grouping turned off because I prefer not to use it, but grouping in and of itself shouldn't affect the width of items. The only things I see that should affect the width are as follows: - the number of entries in the window list - the total available space, _only_ if the number of entries gets too large - (possibly, as you suggested) window title. At least I would expect consistent behaviour. I agree, in theory, my algorithm may sound nice, but it may be more complicated than that. Still, I'm sure there is simple function for determining width... Don't get me wrong though - I love the window list! (Who doesn't?) Until we get mega improvements in cpu and graphics power, and the window list is superceded by some magical 3D thing, I'll continue to use it! Thanks for your prompt reply.
Just another odd piece of behaviour - three windows, the front one not "active", window list takes up all available space. When I click on the front window, which simply makes it active (no moving, closing, opening windows), the space of each item in the window list gets smaller.
This probably belongs upstream. There's a number of bugs concerning tasklist button sizes in the gnome bugzilla. Check here, http://bugzilla.gnome.org/show_bug.cgi?id=155905 for a tracker bug.
Created attachment 64595 [details] Empty space in notification area. Is this a bug you are talking about? Empty space in notification area.
We'll follow the bug upstream, although with the number of patches it encompasses I think we won't patch, but just wait for upstream releases as they come.