Re: Thinking about the tasklist

[Elijah Newren <newren gmail com>]

On Wed, 20 Oct 2004 08:03:00 -0400, Havoc Pennington <hp redhat com> wrote:
> On Tue, 2004-10-19 at 15:16 -0400, Benjamin Kahn wrote:

> >       * The tasks are sized according to the amount of text in window
> >         titles. Because applications which change their window titles
> >         frequently are very common, (Terminal, Mozilla, Red Carpet,
> >         etc.) this means that task sizes will often be changing sizes.
> >         Obviously if there is a lack of space for all the tasks, the
> >         tasks should be shrunk so they all fit. But they should not
> >         grow and shrink according to window titles. Additionally, if
> >         the tasklist is rotated into a vertical panel, the tasklist
> >         height is wrong since the text isn't rotated. Bug 155870 Bug
> >         Patch
> 
> 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.

I believe that's _because_ of the issue Benjamin points out.  At
least, it appears that way -- try putting a single window on a
workspace that changes titles easily such as gnome-terminal or
mozilla.  Then change directories or webpages and note that the size
of the tasklist is determined by the title size.  Of course, with more
than one window extra work must be done to make the buttons all the
same size and make sure they don't use more space than what's
available...
 
> >       * 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.

If I understand correctly, he's talking about horizontal padding, not vertical.

> >       * Windows on the task list should be shown in the order that the
> >         windows appeared, not reorganized at will. Bug 155874
> 
> I think there's some whole story here - I feel sure I initially
> implemented the list to use order the windows were mapped, but Alex made
> it sort by window ID instead. (Which is a stable but
> unpredictable/inexplicable-to-user ordering) There was probably a
> rationale for the way it is now. Which may not be a right rationale, but
> we should know what it is before changing.

Bug 52225 seems to contain some details, though you talk about having
originally intended it to work like a stack.  I don't quite know what
that means or if that's related to sort-by-launch-time or not.  You
asked for usability input on that bug and it was pretty unanimous for
sort-by-launch.  However, sort-by-recently-used probably wasn't
feasible at the time the feedback was given (and it should be now with
_NET_WM_USER_TIME), so I think it's another option worth considering. 
See the bug for more details, but it'd be great to have usability
input on this.

> >       * 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)

Does the fact that he's talking about a right-click menu on a
left-click menu item make things any better?  ;-)

> >       * 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())

That is used by libwnck for the label of a non-grouped window.  And it
works well.  But he's talking about the title of grouped windows, for
which WM_CLASS is used instead (see #77942) and doesn't work so well.


Cheers,
Elijah