-
-
Notifications
You must be signed in to change notification settings - Fork 6.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Do not show busy dialog if progress dialog is active while calling a plugin #14225
Conversation
xbmc/dialogs/GUIDialogProgress.h
Outdated
@@ -48,6 +48,7 @@ class CGUIDialogProgress : | |||
\return true if the dialog is closed, false if the user cancels early. | |||
*/ | |||
bool Wait(int progresstime = 10); | |||
bool WaitOnEvent(CEvent& event, int progresstime = 10); |
This comment was marked as spam.
This comment was marked as spam.
Sorry, something went wrong.
This comment was marked as spam.
This comment was marked as spam.
Sorry, something went wrong.
This comment was marked as spam.
This comment was marked as spam.
Sorry, something went wrong.
cc2a8f4
to
8f22b1e
Compare
Thanks for clarifying. Fixed. |
xbmc/dialogs/GUIDialogProgress.cpp
Outdated
return WaitOnEvent(m_done, progresstime); | ||
} | ||
|
||
bool CGUIDialogProgress::WaitOnEvent(CEvent& event, int progresstime /*= 10*/) |
This comment was marked as spam.
This comment was marked as spam.
Sorry, something went wrong.
xbmc/dialogs/GUIDialogProgress.h
Outdated
@@ -48,6 +48,7 @@ class CGUIDialogProgress : | |||
\return true if the dialog is closed, false if the user cancels early. | |||
*/ | |||
bool Wait(int progresstime = 10); | |||
bool WaitOnEvent(CEvent& event, int progresstime); |
This comment was marked as spam.
This comment was marked as spam.
Sorry, something went wrong.
This comment was marked as spam.
This comment was marked as spam.
Sorry, something went wrong.
This comment was marked as spam.
This comment was marked as spam.
Sorry, something went wrong.
xbmc/filesystem/PluginDirectory.cpp
Outdated
if (!CGUIDialogBusy::WaitOnEvent(m_fetchComplete, 200)) | ||
{ | ||
CGUIWindowManager& wm = CServiceBroker::GetGUI()->GetWindowManager(); | ||
CGUIDialogProgress* progress = wm.IsModalDialogTopmost(WINDOW_DIALOG_PROGRESS) ? wm.GetWindow<CGUIDialogProgress>(WINDOW_DIALOG_PROGRESS) : nullptr; |
This comment was marked as spam.
This comment was marked as spam.
Sorry, something went wrong.
This comment was marked as spam.
This comment was marked as spam.
Sorry, something went wrong.
095a60a
to
620dffa
Compare
xbmc/dialogs/GUIDialogProgress.cpp
Outdated
|
||
bool CGUIDialogProgress::WaitOnEvent(CEvent& event, int progresstime) | ||
{ | ||
while (!event.WaitMSec(progresstime) && m_active && !m_bCanceled) |
This comment was marked as spam.
This comment was marked as spam.
Sorry, something went wrong.
xbmc/filesystem/PluginDirectory.cpp
Outdated
} | ||
else if (!CGUIDialogBusy::WaitOnEvent(m_fetchComplete, 200)) | ||
m_cancelled = true; | ||
scriptObs.Abort(); |
This comment was marked as spam.
This comment was marked as spam.
Sorry, something went wrong.
Thank you for detailed explanations. Fixed. |
Jenkins commands only work for team members. This build already shows some failures. I'll start a new build, if failures are not code related. Thank you for your contributions, btw! 👍 |
For some reason the command works for non team members too. |
Weird! It never worked for non-team members before. And of course, you're right, all is good. First run failed on some platforms but re-run shows all is well. Great work @AkariDN |
@FernetMenta according to your remarks I would like to keep old code unchanged and set 1ms blocking interval only to new function. And should I handle closing of progress dialog without canceling? This should not happen in normal mode but somehow dialog can be closed e.g. from other thread. |
new code looks good to me |
jenkins build this please |
Description
Applies only for calling plugins from the main thread. If execution of a plugin takes some time then CGUIDialogBusy automatically opens. But if we already have topmost modal CGUIDialogProgress then additional busy dialog is no longer needed - we can use progress dialog's render loop and handle "cancel" action. Especially in case of sequentially plugin calling.
Motivation and Context
There is no need to show two status dialogs simultaneously.
How Has This Been Tested?
Build and functionality tested on Windows and Android.
Types of change
Checklist: