wxOSX: wxProgressDialog is showing a dock progress bar that doesn't seem to update (Issue #25907)
Will Cosgrove
willco007 created an issue (wxWidgets/wxWidgets#25907)Description
When using wxProgressDialog on macOS, it will automatically insert a progress bar into the dock icon. First, I would prefer if that was opt in with a style flag on wxProgressDialog and wxGauge. Second, and more importantly, it doesn't appear to update correctly.
Bug description:
When updating progress using wxProgressDialog using the pulse or update API the dock progress bar doesn't update as expected. It is always stuck at 0. Using pulse also doesn't set it to indeterminate.
Patch or snippet allowing to reproduce the problem:
wxProgressDialog dialog = wxProgressDialog(wxString::Format(_("Installing \"%s\""), gameName), wxString(' ', 130), 100, this, wxPD_AUTO_HIDE | wxPD_SMOOTH | wxPD_APP_MODAL); dialog.SetRange(3); dialog.Update(1);
Platform and version information
- wxWidgets version you use: 3.3.1
- wxWidgets port you use: wxOSX
- OS and its version: macOS 26 (also reproduces on older OSs)
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
vadz left a comment (wxWidgets/wxWidgets#25907)We already have wxGA_PROGRESS but it is indeed used by wxProgressDialog unconditionally. At this point we probably should leave it enabled by default, but we could provide some way of disabling it, e.g. DisableAppIndicator() function.
As to why it doesn't work, I think it could be due to not calling m_appProgressIndicator->SetValue() in wxGauge::SetValue() in src/osx/gauge_osx.cpp (and SetRange() too). Could you please check if adding this call there fixes it?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Will Cosgrove
willco007 left a comment (wxWidgets/wxWidgets#25907)The API seems to be called correctly, it seems like the dock tile just isn't redrawing.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Will Cosgrove
willco007 left a comment (wxWidgets/wxWidgets#25907)Regarding keeping wxGA_PROGRESS set by default on wxProgressDialog, IMHO it doesn't seem necessary. I would make a new flag on wxProgressDialog and enable it in the prototype by default - retaining some of the default behavior. Users using custom flags would have to add it to their style flags, but I would guess that would be a relatively small group (?). Of course this change would be noted in the API docs and release notes.
As for the dock tile not drawing, my co-worker was mentioning he was seeing issues with OS controls not redrawing correctly in the dock tile last time he tried using it. That may have something to do with it. If I have time I will investigate further.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
vadz left a comment (wxWidgets/wxWidgets#25907)I think using wxGA_PROGRESS by default is not unreasonable, it makes a lot of existing code look better without any changes done to it, just by recompiling it with newer wx version. And it doesn't do any real harm even when it's unwanted, does it?
Of course, I'm speaking about wxMSW, where it works. In wxOSX we need to either fix it or stop using it by default.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Will Cosgrove
willco007 left a comment (wxWidgets/wxWidgets#25907)This may be a very dumb question, but where does it show up on Windows? I've never noticed it. As for enabled by default, I'm not a big fan of doing things 'automagically' so I'd prefer a switch to enable the behavior; but it's not that big of a deal either way.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
vadz left a comment (wxWidgets/wxWidgets#25907)This may be a very dumb question, but where does it show up on Windows?
When using the generic progress dialog, it's supposed to show in the taskbar button, but I've just tested and it doesn't any more :-( And I also forgot that this doesn't work with the native progress dialog anyhow.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Ryan Ogurek
ryancog left a comment (wxWidgets/wxWidgets#25907)I'll preface my message: I don't have much substance or useful information to provide here, unfortunately, so I apologize for that.
I've been reading through issues for something else and came across this, which I've seen myself in my program:
CleanShot.2026-0...@2x.png (view on web)I have a dialog that moves the progress bar quite a bit, which is why it shows as just a little dot on the left here (Red is my system accent color). I guess the last time the icon is refreshed, it's with the progress bar at a low value. It sometimes ends midway or closer to the end though. The last value set programmatically is always 100, however.
I played with this some time ago and found that, intermittently, trying to set the values different ways would make the bar more reliably disappear (but never 100% consistently), and sometimes it does on its own, so it seems timing-related.
I just figured I'd make a comment since I managed to spot this issue.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.