*** Bug 58019 has been marked as a duplicate of this bug. ***

Thanks, Mike. Usability team, do you think this is the best way to
handle this? As per discussion on bug 58019, it's definitely something
we should do somehow and this sounds like a pretty good way to do it.

My only objection would be that italicised fonts can look pretty sucky
on a screen, especially if you're stuck on a platform like
<cough>Solaris</cough> with no anti-aliasing :)

I agree that [windowname] is barely-noticeable, and was about to start
thinking about some alternatives, until the question suddenly hit me:
"does it matter"?  If you click on the window list entry it's going to
pop up whether it was minimized before or not, likewise if you're
Alt-Tabbing through them.  When do you really need to know if a window
is minimized or not?

Callum: hmm, well it doesn't have to be italicized, perhaps an
underline? Alternatively I quite liked the anonymous technical writers
idea of altering the background colour - only side issue would be how
does that affect theming etc? I don't know enough (read, anything)
about GTK to be able to comment on that.

Why does it matter? Well, at the moment it doesn't. However, to be
honest I'd prefer the windowlist applet to toggle minimization when
you click a button rather than just maximize it. After years of using
Windows (and then KDE), I've got used to clicking on the active
taskbar button to quickly minimize a window - I find it's faster than
locating the smallish minimize titlebar button. On GNOME, clicking the
active taskbar button doesn't do anything. I dunno if this has been
patched yet or not (i use garnome), but it'd be quite nice.

Of course, on Windows there isn't any way of telling if a window is
minimized or not, and people seem to manage, so there's a case to be
made for simply scrapping this altogether, as the [] marks may simply
confuse new users (what do they mean?). On the other hand, what if
somebody switches to a new virtual desktop and sees two taskbuttons at
the bottom, but only one window on the screen. Might they not get
confused? Well, I have no usability knowledge at all, so feel free to
disregard this paragraph as ass-talking.

All I know is that personally, I quite like being able to distinguish
:) Whether it matters to anybody else is something I never really
investigated.

> Why does it matter? Well, at the moment it doesn't. However, to be
> honest I'd prefer the windowlist applet to toggle minimization when
> you click a button rather than just maximize it.

That's exactly what it does nowadays, its behaviour was indeed changed
recently.

Your other point is reasonable, with a small number of windows on the
screen the mismatch between the windowlist and the desktop might be
more obvious and potentially confusing to a novice user.  (Personally
I think they'd quickly learn what was going on if they clicked around
on the windowlist though, but it's not something I've thought about
very hard!)

Well, this patch is hardly priority, but it'd be nice to arrive at a
decision. Somebody in IRC mentioned the different colour idea as well,
but how would this relate to theming? I might take a look and see if
it's possible to alter the color.

In the meantime, is it really reasonable to keep things the way they
are because Solaris doesn't have XRENDER? I'd assume that's the
problem. Not sure that's such a good idea, but then I'm not the boss.

I'll see how easy a patch to alter the colour would be.

Basically, not very easy. Now I'm far from being a leet GTK coder, but
you start to run into problems trying to alter the background colour.
The biggest is of course theming, you'd basically have to alter all
the theme definitions to give an extra colour to minimized windows.
The second problem is that there aren't really many colours that
aren't used actually.

I've started to be of the opinion that there shouldn't be any visual
notification of the minimized state at all, except maybe italicised
text as it's quite subtle, as otherwise we're introducing more visual
noise for no real gain other than aesthetic. 

I have no idea how applicable my point about virtual desktops
confusing new users was earlier, I think maybe still valid.

So we need to make a decision. I'd say that the [] method is bad, as
it's a) hard to distinguish and b) added visual noise. Italics is a
little better as at least we can see quicker there. Background colour
change probably isn't worth the hassle.

It should be noted that the icon is dimmed as well when minimized, but
 that effect is so subtle I only realised it happened after looking at
the code itself :/

What do people think? Italics, bg colour change, or no visual info at all?

Well, I personally don't think there's a compelling reason to make any
distinction, but I'd be interested to hear what the other usability
folks think.  (FWIW, Windoze XP makes no distinction either).

Looks like the patch is irrelevant from a look at the current sources.
Remove the keyword?

*** Bug 155876 has been marked as a duplicate of this bug. ***

Comments from bug 155876:
Putting brackets [] around minimized windows looks ugly and may not be needed. 
Other ideas:  Italics?  Only dim the icon?  Shrink the text size?

I vote for only dimming the icon.

MS Windows (as a data point only) actually does ...  nothing.  There is no
difference in appearance between minimized and non-minimized windows.

Larry suggested making the text appear greyed out.  (I think that might be
difficult to see on some themes and might make users feel like they can't
restore applications.)

Our choice of behavior will affect bug 136666.

Not that I have any better ideas off the top of my head, but dimming the icon or
the text won't really work in high or low contrast themes, and shrinking the
text size could be a bit iffy for Large Print users.

I tried working on this a while back and couldn't come up with anything except
redesigning the entire idea of the task bar into something different.  Basically
I couldn't come up with a way to micro-optimize the current task bar and come
out with great new strides in usability.  Everything only helped a very small
amount, if at all.  Instead a total redesign of how we represent
tasks/applications seemed to provide the most gain, which is what i'd recommend
we try.

Bryan,
  You're welcome to come up with designs to make the tasklist be wonderful and
different and all powerful.  But I think saying that the existing stuff is too
broken to even consider fixing is self-defeating.  If you don't have the new
tasklist for the next GNOME version, it seems like useful energy could be spent
on  improving the existing system.

Calum,
   Right now, the icon is dimmed.  Is this causing problems for people?  I
believe the dimmed text would appear in the same style as a disabled control. 
Probably not a good suggestion since it would look unclickable, and minimized
windows are a great reason to be using the tasklist in the first place.

I'm leaning towards dimming the icon and leaving the text alone.  We could make
the tooltip for the application say: minimized: <application title>

Sorry, I think you've interpreted what I thought was 'I'm out of ideas to help
this idea along, maybe we should focus elsewhere' into something else so I'll
clarify.  I don't think I came off saying "that existing stuff is too broken to
even consider fixing".  What I am saying is that we can spend a lot of time
worrying about using italics versus grey fonts to convey to people that the
application is minimized.  When you step back and think about it neither of
these options are going to really mean much to people other than 'something has
changed'.

Tweaking the little parts, like the subtle changing fonts or lighting doesn't
seem as valuable as moving in a new direction where we can make greater strides.
 There's nothing wrong with saying the old system works well enough, but lets
leave it behind and move on to something a lot better.  This is just my opinion
and is really something for a mailing list or irc.  

My comment wasn't made to make you in particular from spending your time on
this, but to try to say I think as a whole I think we're good enough to leave it
and move on to new stuff.

A very small, but noticable (and could be made more so with the accessibility
themes) gesture could be:
Focused window: Sunken border
Restored/not minimized window: No border
Minimized window: Raised border

Or any other circulation of those states. I'm also for the current "dim the
icon"-thing, although it's mostly useless.

Benjamin: I don't think dimming the icon is causing problems for anyone right
now, because I doubt that most people notice.  Certainly in a high or low
contrast theme, the effect is as good as negligible.

Vidar: Ingenious idea, but I'd be worried that it would interfere with the
'affordances' offered to the user.  Right now, the buttons look and behave like
radio toggle buttons... when a window is focused, the button pushes in, when
it's unfocued, the button pops out; and only one button can be pushed in at
once.  It's a model that's easy to learn and take in at a glance.

If there were three possible states, I don't think it would be clear what would
happen next when you clicked a button-- if I clicked a button with no border
(assuming I recognised such a thing as a button at all), would it push in or pop
out?  If I clicked a popped-out button, would it push all the way in or only go
half-way? :)

Calum: I see your concerns, and agree it could be a little confusing :)

Another thing that might be possible:
Focused window: Bold text and raised button.
Restored/not minimized window: Raised button.
Minimized window: Sunken border.

The three-state problem is still there, however, but you only need to "button
states". Of course, making the text bold further limits the number of characters
that can be shown in the "button" for the selected window - but that shouldn't
be a big problem, as it is always available in the window title.

This mimicks for example Firefox' behavior with tabs: the selected one is bold.
It also makes it easier to distinguish which window is open or not: the ones
that are mimimized are "hidden" (sunk), whilst the ones that are visible are
popped out (raised) - also like tabs in FF/Moz and Epiphany.

*** Bug 163135 has been marked as a duplicate of this bug. ***

Bug 163135 had a more extreme request of not showing the title at all for
minimized windows (apparently came from a usage case where the window list was
used predominantly for active windows only).

Bug 81222 may also be related...

Let me elobarate on my Bug #16135 and explain a few things: No, I don't use the
window list predominantly for active windows only. I use it for both active and
minimized windows. But the window list is actually nearly unusable for *both* cases.

First, active and minimized windows are hard to distinguish. Dimming the icon,
putting brackets around the title, italics, bold text or different background
colors doesn't help much here, even worse, it *adds* clutter instead of clearing
this thing up. Displaying just the icon for minimized windows would do that
trick in a much more elegant way: It's clearly to distinguish and it *removes*
clutter. This is a quite basic rule of UI-design: If you can distinguish things
by removing information or by adding information do the former, not the latter.

You may argue that this makes minimized windows harder to identify and harder to
click on. Harder to identify: No. You can clearly see the minimized windows and
have to look for the right one only among the icons, not among a whole row of
nearly indistinguishable buttons. Harder to click: yes, but getting rid of them
as far as possible was the sole reason to minimize them. You minimize windows
only when you don't plan to use them for a while and making them harder to click
on just fits in here. Minimizing a Mozilla or OpenOffice window and then
clicking accidently on it (and having it swapped in again) is absolutely
annoying. Making it harder to click on once it is minimized is good, not bad.
And it's not that much harder anyway, since with all windows being displayed
with icon and text the individual buttons become easily that small that all
titles are unreadable and you have to resort to the icon or the tooltip anyway.

To put that in other words: Having only icons for minimized windows makes them
easier to find (because they're easier to distinguish from active windows), but
harder to click on. At the bottom line the effort to unminimize a window would
stay the same but the probability of accidently hitting the wrong window would
be lower. (Might be a good idea to gather those icons on the left-hand side of
the window list instead of mixing them with the other buttons in the list.)

By the way, I'm sick of otherwise perfectly normal small applications (like the
Blog posting applet) being rolled into an applet just for the reason that users
like to keep such an app running all the time but not want it to permanently
block a slot in the window list. This points exactly at the problem the window
list has.

And don't get me started at the default Gnome setup with two panels, one almost
empty and another with nothing but the window list... If the window list would
display just icons for minimized windows, we could probably do with only one
panel, because then the list could be useful with quite a bit less room for it.
People tend to start minimizing windows when the workspace is cluttered and they
don't need all applications right now. When this at the same time cleans up the
window list you don't need a window list running over the full screen width in a
panel of its own.

Both joh and Bryan's comments lead me to believe that bug 81222 should be
handled first...

joh: Your proposal sounds totally backwards to me (though this may be due to
different usage scenarios that we have)--clicking on active windows is much more
likely to be accidental than clicking on minimized windows.  Why not remove
everything but the icon for active windows (if not remove the active windows
from the window list entirely)?  See also bug 84411...

> Having only icons for minimized windows makes them easier to find

I agree that it makes it easier to distinguish between minimized and unminimized
(which may not even be useful as pointed out by both Calum and Benjamin), but it
only makes it easier to find if you assume that you have no more than one window
with any given icon minimized.  That most definitely isn't valid for me,
although, I have to admit that this assumption may be valid for most people...

> You minimize windows only when you don't plan to use them for a while and
> making them harder to click on just fits in here.
...
> the probability of accidently hitting the wrong window would be lower.

This is just backwards.  I may not plan to use them for a while, but I also
don't plan to use the window list for a while either.  And when I do use the
window list again, it will almost certainly be to recover one of the minimized
windows.

> I'm sick of otherwise perfectly normal small applications being rolled into
> an applet

That's really not relevant here.  File a bug to the author and tell them to use
the SKIP_TASKBAR hint.

(Regarding this question and that of Bug 163135)

I usually have lots of windows open on my desktop, including some
inactive windows which I generally keep minimized and many active
windows, some of which are minimized and some of which are not at any
one given time.

When I'm changing windows, I find the display of titles absolutely
critical to finding the one I need next.  I have to distinguish
between web browsers visiting different pages, Emacs windows visiting
different buffers on different machines, and xterms visiting different
directories on different machines, among all the other applications
that might be open at the moment.  Having to rely on tooltips to do
this would be pretty terrible.

I do find that with the default setting of no grouping, the window
list quickly gets too crowded to be useful.  The setting "Group
windows when space is limited" has a bad idea of what "limited space"
means.  It kicks in when only about the first 6 characters of each
title can be displayed.  This is far from enough to let me distinguish
individual windows from other members of the same class (emacs, xterm,
galeon, etc.)

"Limited space" should probably mean something more like "when
complete titles can no longer be displayed" (within reason - titles
that are, say, on the order of 1000 characters long should probably
just be truncated).

I have recently turned on "Always group windows", and I think this is
probably my favorite configuration so far.  If I'm looking for a
window that's only one instance of a class (for instance, one Emacs
window of many, that's visiting a particular buffer I want to see), I
do have to make two selections, one for the class, and another for the
instance.  But some about of hide-and-seek is pretty much inevitable
when you combine the need for seeing complete titles and not having
too much clutter.

An alternative solution would be to have a very large list showing
complete titles, but which only appears when needed.  You can do this
if you make the bottom panel very large and use hiding or auto-hiding,
or if you use the Window Selector applet (which displays a vertical
list when you click on its icon).

Currently, I don't like the "hidden list" alternatives because they
are not sorted by class; all windows are just jumbled into the list.
(Actually, I think they appear in the order you opened them, but this
quickly starts to look pretty random.)  This means that it takes me a
very long time to find the window I need.  With this modality, I have
noticed that I sometimes I accidentally open a second copy of a file
that's already open, simply because I didn't see it in the long and
relatively unsorted list of open windows.

If the sorting problem were fixed, I think the "hidden list"
alternatives would be quite attractive for smaller screens, where the
window list seems to take up too much valuable real estate.

I'm sure that "hidden list" solutions are much harder for novice users
- for their sake, the default configuration should almost certainly
put minimized windows someplace in plain view, in some sort of
recognizable form.   I'm skeptical that an icon-only representation is
a good idea for novice users, because it takes a while before one gets
to associating the bewildering array of icons with particular
applications.

For some reason, when I click on a grouped window, it always
maximizes, but when I click on an ungrouped window, it cycles between
minimizing and restoring.  I have never been bothered by this, and in
fact, it's probably the right thing to do.  With an ungrouped window,
if the wrong thing happens, correcting it is an easy click.  With a
grouped window, if a window gets minimized when it should have been
raised, you have to re-select the class and then re-select the
instance, which involves a sequence of mouse moves and clicks.  Users
are unlikely to use the window list to minimize windows, because the
intuitive thing to do is to click on the minimize button on the window
itself, because the *window* is what's in your way, not the taskbar.
But if you can't see the window (and you want to raise or restore),
then you should intuitively turn to your window-finder (the window
list).

I can also only use the right-click menu on ungrouped windows, and
this is *not* OK.

Personally, I identify minimized windows by the brackets.  I don't
find this cluttering, and I do find it useful.  (It tends to help keep
me on task.  Though I should note that I minimize windows both because
I'm not going to use them for a while and because I simply have too
many open windows on the desktop, and I need to resort to the window
list to switch between them.)  For novice users, it's not terribly
important that they understand the meaning of the brackets, and their
presence seems unlikely to cause them to do something different than
if they weren't there.

I agree that color change is very problematic w.r.t. themes, and it's
probably too pronounced of a change anyway.

If you like using one panel instead of two, a sorting Window Selector
might be a good solution.  The Ximian default desktop (at least for a
while) was configured with only an upper panel, using Window Selector.
Though I can see a certain efficiency to the "show icon only for
certain windows" solution.

With regard to Fitt's Law, I think it' probably not appropriate to
assume that people aiming for the Window List are going to prefer
displayed windows to minimized ones.  Perhaps if you are a
many-windows-at-once user, this is true.  But if you have a smaller
number of windows, it's likely that you will change windows directly,
and use the Window List primarily for unminimizing.  In which case,
you want to provide a large clickable area for minimized windows.  Or
maybe not; perhaps actual usability testing with a representative
sample of users would be necessary to find out.  Personally, I use it
for both.

(And for the record, right now, I'm using Fedora Core 3 with
gnome-applets-2.8.0-5 and gnome-panel-2.8.1.-3.)

Ok. As with many things regarding user interfaces one should first do some
empiric analysis. I do not know if users use the window list primarily for
switching active windows or for unminimizing windows. I personally tend to not
use it at all as soon I have more than a handful of windows open, since the
individual buttoms get too small to identify a window without looking at the
tooltip anyway. 

Short of real data from the user base the sensible approach would be to add two
options to the window list preferences, like these:

[x] Show titles for active windows
[x] Show titles for minimized windows

This way the user could easily decide to have both or one or none of these
window states shown with both title and icon, with the default being the same as
it is now. Yeah, I know that adding options is considered evil. But as it is now
the window list starts getting useless exactly when you start to need it (when
you have more than just 5 or 6 windows open).

Ok, I admit that this has no easy solution other than what we have now (and what
we have now works somehow, granted).

Removing PATCH keyword since discussion suggests that there's no patch with
consensus in here.

*** Bug 310084 has been marked as a duplicate of this bug. ***

Bug 310084 was of the same opinion as Benjamin and provided a patch in
attachment 48998 [details] [review].  Considering that the trailing ] or = is often cut off by
ellipsizing (haven't we fixed that once before already?), I think it makes sense
to at least remove the ASCII decorations.  Do any of the usability people see
any potential problems with doing that?

Continuing the discussion from bug 310084:

> I think I'm in favor of this proposal (especially since the trailing bracket is
> often cut off by the ellipsizing), but if we change behavior in libwnck then we
> also need to change Metacity at the same time (the alt-tab popup uses the same
> methods as libwnck for displaying windows).  If you can convince Havoc to take
> the change in Metacity, and the usability people don't object, I think this
> patch would be fine.

Metacity is already different from libwnck, so I don't see how that should hold
up the libwnck changes. (Metacity will add [] around minimized windows, but it
won't add == around shaded windows.)

nmiell: Well, perhaps there's yet-another-bug in metacity-libwnck syncing, but
we really have tried to keep Metacity and libwnck in sync in the relevant
places.  Yes, we've kind of sucked at it but I'd still rather prevent further
divergence in order to make it easier to continue trying to get them unified.

Well, then convincing Havoc to remove the window title mangling shouldn't be too
difficult (famous last words....)

Metacity is already wrong, and a fix that removes the mangling entirely would
actually be less intrusive than one that would add shaded window title mangling.

*** Bug 325665 has been marked as a duplicate of this bug. ***

*** Bug 403087 has been marked as a duplicate of this bug. ***

*** Bug 546577 has been marked as a duplicate of this bug. ***

Not a very constructive comment, but if Gnome doesn't change the taskbar completely, IMHO it would be the best to simply remove the square brackets. They look ugly and remind of the console era, when windows had borders made of the - and | chars.

It would be a small and *easy* step towards competition (Windows 7, Mac OS X) in tearms of the desktop beauty :)

Any update on this? Should this be changed or not? 
I agree with Mateusz that brackets is ugly and should be removed. 

If you'd like I could create a few screenshots showing minimized windows with <i>title</i>

Take into consideration that as italics look good when used in printed text, they become harder to read when displayed on screen. That's why <i> is practically unused on web pages.

The primary task of the window list is to present running applications in a way that allows user to quickly find the program she wants to switch to. IMHO any additional elements like [] (and changes of style between buttons) may make the task harder to achieve. Sometimes simplicity is the key, but I guess many users are used to [] so as any change happens, they will file bugs stating it's a regression.

How about also dim the text (aka gray) as we do with the icon?

Well, after scanning through comments, I believe that visual differentiation of minimized windows is the primary discussion here. In any case, I cannot think of a reason why not use a similar differentiation as the - [] x buttons.

In addition to this would be the harder question. Yes, I would think that a broader (in terms of physical area on the screen) visual impression would be a benefit in terms of usability.

I would propose including the +/-,[],x in the taskbar for marking window status. As for actually noticing the window is minimized, I would suggest a different shading or color scheme for minimized windows on the task bar (which is certainly difficult to define, but let's try).

Idea, in addition to what I said above about +/-,[],x..., let's use the window state colors from the theme on the task bar.

deadowlsurvivor@gmail.com, maybe I'm lost here but what would state would "x" show?

(In reply to comment #42)
> deadowlsurvivor@gmail.com, maybe I'm lost here but what would state would "x"
> show?
> 

The application has received the signal to terminate, or at least that the signal has been sent. Some applications do some clean-up things at the end (like Eclipse saving your workspace) and it would help to have a visual clue that yes, you have told the application to exit, and it hasn't said about doing otherwise. If it needs some user input, or if there is still the possibility of user input before it exits (you have unsaved documents, are you sure you want to exit? [exiting in N seconds...]), you could also have a variations of the "x" state.

You could also set a timer to throw a force quit button or something if this is the state (would come in handy).

I'm running Gnome on Fedora 11, and I already get pop-up windows when applications take too long to close.

That wasn't really my primary argument. What I'm trying to say is that it would make sense to reuse min/max/unmax/terminate symbols to represent application and window state as they'd be familiar, introduce a stronger level of consistency within the user interface, and wouldn't require very much screen real estate. In other words, it would meet the criteria for representing a minimized window.

Any suggestion on how to do it? 

Such as when holding the mouse over the window in the list; rotate the icon in 3D and on the back show the window state? :-)

(In reply to comment #46)
> Any suggestion on how to do it? 
> 
> Such as when holding the mouse over the window in the list; rotate the icon in
> 3D and on the back show the window state? :-)
> 

In order to be useful, I'd think it'd have to be visible.

In that case, why not style it the same way as the title bar? 

Perhaps base it off the location of the specific button on the title bar as it is in the user's theme, have a default if it isn't specified, and decide what what options the user should have in terms of preferences otherwise.

(In reply to comment #39)
> How about also dim the text (aka gray) as we do with the icon?

Might make sense; someone needs to try to be sure, though ;-)

Vincent, I'll see what I can do :)

Created attachment 139498 [details]
Screenshot of how grey minimized windows could look like

Wrote a quick hack (not working if number of windows changes, hardcoded color #555555, not tested etc - tell me if you still want it) to do the screenshot - what do you think? What more screenshots of different themes? What about rolled up windows? Window selector?

My comment; I think this blends in pretty nice with the icon.

Just to make sure we don't miss anything when/if we redesign this, but it seems some people don't like the greyed out icon, see http://bugzilla.gnome.org/show_bug.cgi?id=552416

Almost eight years passed. Brackets still here alongside with dimmed icon. Maybe two indicators of same thing is finally too much, heh? Will these brackets (one bracket actually(!), because titles are long) ever be banished or changed to <i></i>?

<rant> Well, it seems to be the problem of Gnome platform as a whole - lack of QA people for finishing it properly, leaving bugs that bother users without final action for years; instead focusing on "the next big thing" (Gnome 3), which won't address those problems </rant>

Evgeny, I personally recommend workaround in form of a dock - Docky or AWN. They have some rough edges, but in terms of presentation they leave standard Gnome panels (Gnome 2 and 3 included) light years behind. They are also actively developed.

-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/libwnck/issues/14.