Open GoogleCodeExporter opened 9 years ago
That sounds like a Launchpad bug to me, really. The Unarchiver shows a badge
while unarchiving that shows how many archives are left. If Launchpad doesn't
remove that when the extraction ends, that would be a Launchpad bug.
Original comment by paracel...@gmail.com
on 23 Nov 2012 at 3:09
If the archive is small, sometimes the progress bar isn't removed
Original comment by jaimem...@gmail.com
on 23 Nov 2012 at 6:21
Attachments:
Issue 600 has been merged into this issue.
Original comment by paracel...@gmail.com
on 5 Dec 2012 at 1:09
I tested out BitTorrent.app, which also uses dock icon overlays and badges.
Using this program, I downloaded ubuntu-12.04.1-desktop-amd64.iso. After the
download was finished, BitTorrent showed a badge of "1" which also appeared in
Launchpad. I then used Activity Monitor to Quit (not "Force Quit") the app.
The badge icon was not removed in Launchpad.
So it does appear to be a Launchpad bug. However, is it possible to work
around this issue? What if, instead of using the actual badge mechanism, you
added the badge as an overlay on top of the dock icon like what you do for the
progress bar overlay, and what BitTorrent.app does for the download speed?
Original comment by dtrebbien@gmail.com
on 6 Dec 2012 at 12:55
Attachments:
I wonder if it gets stuck because the time between the removal of the badge and
the program quitting is too short. Maybe there is a way to ensure Launchpad has
the time to update.
Original comment by paracel...@gmail.com
on 6 Dec 2012 at 1:01
Using the badge, the standard OS X look is used, but using an overlay view
would need to replicate it. Also the overlay view sometimes isn't removed on
the Dock
Original comment by jaimem...@gmail.com
on 6 Dec 2012 at 1:01
True, the badge icon look would need to be duplicated. But, it sounds like
that would not work anyway.
This issue reminds me of a bug in early Windows 2000, where the tray icon for a
program was not removed when the program exited. Oh the lengths that some
Windows programmers would go to remove this icon! The usual trick was to
simulate a mouse event on the tray icon after the program removed it, which
would prompt Windows into realizing that the tray icon could be removed.
I, too, wonder if there is a way to give Launchpad time to update. Simply
waiting a bit until exiting would probably not work 100% of the time; it is a
race condition. Maybe there is some way to force a synchronous display update
in Launchpad?
In BitTorrent, the badge is removed once the user clicks on the dock icon,
bringing the app to the front again. Is there a way to simulate this?
Original comment by dtrebbien@gmail.com
on 6 Dec 2012 at 1:13
Maybe it would work if the badge count is set to 0 when TUController is dealloc.
Original comment by jaimem...@gmail.com
on 6 Dec 2012 at 1:24
I think it should always be 0 already at that point. If it isn't, that's
probably a bug.
Original comment by paracel...@gmail.com
on 6 Dec 2012 at 2:10
I modified TUDockTileView to store the last count as well as
applicationShouldTerminateAfterLastWindowClosed: to return YES only when the
count is 0. I can confirm that the count is 0 when The Unarchiver exits.
The interesting thing is, if I modify
applicationShouldTerminateAfterLastWindowClosed: to always return NO, the
progress bar on the dock icon lags behind the progress bar on the main window.
Also, the main window closes a few moments before the progress bar on the dock
icon reaches 100%.
I wonder if the problem is that the dock icon display had not finished updating
before The Unarchiver terminated.
Original comment by dtrebbien@gmail.com
on 6 Dec 2012 at 11:41
There is a bug which causes crashes on older OS X versions, which is that the
display method of the dock tile is called on a secondary thread. Could that
affect this, too?
Try just changing the call to display to
performSelectorOnMainThread(@selector(display)) and see if that helps, maybe?
Original comment by paracel...@gmail.com
on 6 Dec 2012 at 11:50
Yes. The badge label is removed properly if I change the three calls to
display to:
[[NSApp dockTile] performSelectorOnMainThread:@selector(display) withObject:nil
waitUntilDone:YES];
Original comment by dtrebbien@gmail.com
on 7 Dec 2012 at 12:16
Just tried waitUntilDone:NO and the problem reappears.
Original comment by dtrebbien@gmail.com
on 7 Dec 2012 at 12:20
Issue 604 has been merged into this issue.
Original comment by paracel...@gmail.com
on 11 Dec 2012 at 2:09
Well, I moved all updates to the main thread, and I did some feng shui
rearrangements of API calls, and also explicitly set the badge and tile view to
nil on app exit. Hopefully at least one of these things will fix it. Thanks for
all the help tracking this down. And if this still happens in 3.6, post again
or file a new issue. Closing this one for now.
Original comment by paracel...@gmail.com
on 13 Dec 2012 at 10:17
Issue 610 has been merged into this issue.
Original comment by paracel...@gmail.com
on 23 Dec 2012 at 4:39
Problem still exists in 3.6
Original comment by ocakli...@gmail.com
on 15 Jan 2013 at 5:59
Can you be more specific?
Original comment by paracel...@gmail.com
on 15 Jan 2013 at 6:01
I still see an 1 badge on the icon of the application after I used it.
Original comment by ocakli...@gmail.com
on 15 Jan 2013 at 6:03
Under which circumstances does that happen?
Original comment by paracel...@gmail.com
on 15 Jan 2013 at 6:05
Very rare (only once) since 3.6 installed (5th January) I have just noticed
today after unzipping a zip archive.
Original comment by ocakli...@gmail.com
on 15 Jan 2013 at 6:14
I'm experiencing the same problem with 3.6. I downloaded The Unarchiver to
extract a large .7z file and now a "1" notification appears over the icon in
Launchpad. I only clicked on the archive to extract and the badge stays even
with the application open (but it doesn't show in the dock, only Launchpad).
Original comment by joshua.j...@gmail.com
on 24 Jan 2013 at 10:27
According to issue 637, this apparently still happens. Reopening, although I
have no idea what to do about it. If anyone ever figures anything useful out
about this, please post.
Original comment by paracel...@gmail.com
on 11 Mar 2013 at 2:07
Issue 637 has been merged into this issue.
Original comment by paracel...@gmail.com
on 11 Mar 2013 at 2:07
Is this still happening for anyone?
Original comment by paracel...@gmail.com
on 30 Oct 2014 at 9:11
Original issue reported on code.google.com by
GhostLyr...@gmail.com
on 23 Nov 2012 at 2:08