Re: Thinking about the tasklist

[Benjamin Kahn <xkahn ximian com>]

On Wed, 2004-10-20 at 08:03 -0400, Havoc Pennington wrote:
> On Tue, 2004-10-19 at 15:16 -0400, Benjamin Kahn wrote:
> Some quick notes, but I'm following up in offline mode so can't read the
> bugzillas:
> 
> >       * The tasks are sized according to the amount of text in window
> >         titles. 
> 
> I would note that as a first order problem, the layout and sizing of
> tasklist seems to be just buggy. Sometimes it expands to use all avail
> space and sometimes it doesn't for example. At least it seems that way
> to me.
>
> Because GTK lacks width for height layout and because of the way the
> panel works, it's all a bit hard to get right. Alex struggled with it
> for a long time.

Yes.  And, sadly, I haven't been able to solve this issue.  The trouble,
for those following along at home is that there are three sizes:  the
size of all the tasks being displayed, the amount of space available for
the tasklist, and the actual space allocated by the tasklist applet.

I fought with the code for quite a while trying to get the actual space
allocated to be correct, but gave up.  You'll see some flashing of task
sizes sometimes and you'll frequently see the tasklist applet being
larger than the tiles that make it up.

> >       * The amount of padding around the icons and text in the
> >         tasklist is too small. Bug 155865 Patch 
> 
> I would guess the goal here was to get two tasklist rows onto a 48-pixel
> panel.

Actually, I didn't touch that part of the code.  I was simply talking
about the padding between the icon and the text.  (And the icon and the
left and right tasklet borders.)

> >       * The default icon showing a blank page is ugly and is the wrong
> >         size – thus it always looks blurred. Bug 155867 ([embedded
> >         Image]) 
> 
> Icon theme bug? Or failure to use icon theme correctly?

The icon is embedded in the tasklist directly.  It isn't using icon
themes at all.  That's probably the real bug here, but I'm not sure what
the right theme icon would be.

> >       * When a window title is too long to fit in the space provided,
> >         it should be shortened and ellipsizes should be shown. (…) Bug
> >         155868 Patch 
> 
> Easier now that gtk has an ellipsis feature ;-)

Yes...  That's what I get for using an older version of Pango.  This is
probably a three line patch now.  /me grumbles

> >       * When windows are grouped together, the right click menu should
> >         act on all the grouped windows. Right clicking on the group
> >         menu itself should allow you to act on a single window. Bug
> >         155875 
> 
> Agreed. (Though you may find a right-click menu on a right-click menu
> item is something gtk doesn't like much, I'm not sure)

Well, the panel does it.  And galeon does it.  (If everyone is doing it,
it must be okay!) Issues come up when backing out of menus.  (Clicking
off of the second popup menu should return you to the first menu.)  But
I believe I've seen code which does this correctly.

> >       * It would be nice to improve the title of window groups. One
> >         way might be to get the WM_COMMAND from the window properties
> >         and look that command up in .desktop files. This won’t work if
> >         no .desktop file exists for the application, and might not
> >         work well on remote applications. Still, this should improve
> >         the display quite a bit. Bug 155878
> 
> There's a g_set_application_name(), having apps call that is the right
> fix (it's why I added g_set_application_name())
> 
> I think it would also be neat to have apps load their own desktop file
> at startup and set the app name, their icon, etc. from that desktop
> file. We used to have that back in the GNOME 1.x day I think.

I'm not as worried about GNOME applications as I am about non-GNOME
applications.  OpenOffice, Firefox, and old UNIX applications seem to
set terrible WM_CLASS strings.  I'd love to never see firefox-bin and
soffice.bin in any user visible places.