After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 600286 - [Patch] Display Task Progress In Task List
[Patch] Display Task Progress In Task List
Status: RESOLVED WONTFIX
Product: libwnck
Classification: Core
Component: tasklist
unspecified
Other All
: Normal enhancement
: ---
Assigned To: libwnck maintainers
libwnck maintainers
Depends on:
Blocks:
 
 
Reported: 2009-11-01 05:56 UTC by HyperHacker
Modified: 2010-03-09 01:28 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Add progress bars to taskbar buttons that display a percentage (2.90 KB, application/octet-stream)
2009-11-01 05:56 UTC, HyperHacker
Details

Description HyperHacker 2009-11-01 05:56:54 UTC
Created attachment 146670 [details]
Add progress bars to taskbar buttons that display a percentage

This patch adds a useful feature to the task list: if the window title contains
a percentage, the button doubles as a progress bar showing that percentage. So
for example a download window that shows "50% downloaded" in its title bar will
have a progress bar at 50% in the background of its task list button.

This patch is a WIP, and a bit hackish because any time I tried to add elements
to struct _WnckTasklistPrivate, my xfce4-panel would break. So it could be
enhanced, by someone who can figure out how, to add a flag to toggle this
functionality, improve the appearance and detection (perhaps a black/whitelist
of applications or title regexes), etc.
Ultimately it would be nice to have, in addition to this method, some way for
applications to provide a hint that they are performing a task and that it's x%
done, or that they don't know how much is done so the progress bar can "bounce"
as it would in the actual application window.
I'd want to keep the titlebar detection though, as otherwise everything has to
be retrofitted to use the hint. This is a problem in Windows 7; it appears to
require the application to notify it of its progress, which means really only a
couple built-in programs take advantage of it.

The current detection method is simple: if the window title contains only one
'%', and there is a number (may contain '.' or ',') immediately before it, that
number is considered the task percentage. So "Operation 20% complete" would be
displayed with a progress bar, while nonsense like "foo%" or "%%% LOOK AT ME
42%%%" would not. The downside of course is that if you're, for example,
reading a web page whose title contains a percentage, that number is going to
be shown as well.
I chose not to ignore numbers outside the range of 0 to 100, as it's not
uncommon that a broken program displays a task going beyond 100% completion,
and I'd rather it still display as an active task until it actually finishes.
Anything below 0 is considered 0, above 100 is considered 100.
An enhancement I'd like to implement (but would require modifying structs)
would be to only display a progress bar if the percentage changes. So a web
page with "50%" in its title wouldn't have a progress bar, but when a download
window advanced from 0% to 1%, its progress bar would be enabled. Again, this
is where it'd be nice to have some way for windows to hint that they do/don't
display a task progress in the title, or publish the progress another way.

Tasks that have a percentage will display on all workspaces. I'm unable to add
a flag to disable this, but noted where that flag would be checked.

The method used is a bit of a hack as well. I played with Cairo but couldn't
find a way to draw a progress bar in the background. Instead I replaced the
labels with progress bars. This works, but there doesn't seem to be a way to
left-align the text, remove the padding completely, or have the bar fill the
entire button (i.e. extending it to under the icon). GtkFixed and GtkLayout
wouldn't do it: the bar always drew overtop of the other widgets.
I did take the liberty of naming the widgets, so they can be styled in .gtkrc.
Unfortunately progress bars don't have many style options.

Anyway despite the quirks it works nicely in my xfce4-panel, so hopefully it
won't be difficult to properly add this functionality to the next version of
libwnck. It should be quite simple to add configuration for it to the panel
plugin once it's implemented.
Comment 1 HyperHacker 2009-11-01 06:14:03 UTC
Screenshot attached to bug 600287 (https://bugzilla.gnome.org/show_bug.cgi?id=600287#c1) shows this as well.
Comment 2 Vincent Untz 2010-03-09 01:28:37 UTC
It really can't go in as is: as you point you, the way to detect this is a hack. And there are indeed issues when there's already a progress bar somewhere else since it means exposing this information multiple times on the screen, and we don't want this.

I'm going to close as WONTFIX since I don't believe this is solvable right now in a way that is reliable. If you're really interested in this, I suggest contacting either the people working on the EWMH or the xdg mailing list to come to a real way to achieve this kind of things.