Re: Thinking about the tasklist

On Wed, 2004-10-20 at 08:03 -0400, Havoc Pennington wrote:

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

Ben put in an "application window" in the bug; this should simply
replace libwnck/libwnck/default_icon.png.  I think that's the master
fallback, and the code does not try to fetch images from the stock
system or anything, but I could be wrong.

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

The current code in wnck_task_compare() does this:

1. Groups get put first; groups are sorted by name.  Within a group,
windows have no order [this could be easily fixed; grep for

2. Stray windows get put next, sorted based on two keys:  the primary
one is the xid of the window's group leader, and the secondary key is
the xid of the window.

3. Startup notification windows get put last, in arbitrary order.

So you'll get this:

[A Group] [B Group] [App1 Window1] [App1 Window2] [App2 Window1] [App3 Window1] [startup-something]

As far as I know xids are strictly incrasing, so it's more or less
equivalent to sorting by time, except when you get xid wrap-around.

A well-known Windows developer says they considered an MRU order for the
Windows task bar, but people found it confusing that the order changed:


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]