[master] Wait for payload thread in TUI software spoke. (#1178214)

Samantha N. Bueno sbueno+anaconda at redhat.com
Mon Jan 5 20:38:12 UTC 2015


On Mon, Jan 05, 2015 at 03:20:34PM -0500, David Shea wrote:
> On 01/05/2015 03:03 PM, Samantha N. Bueno wrote:
> >We should wait for this to finish before attempting to access any
> >of the data from the dnf payload, otherwise a traceback will occur.
> >---
> >  pyanaconda/ui/tui/spokes/software.py | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >
> >diff --git a/pyanaconda/ui/tui/spokes/software.py b/pyanaconda/ui/tui/spokes/software.py
> >index ce069c9..eedc74b 100644
> >--- a/pyanaconda/ui/tui/spokes/software.py
> >+++ b/pyanaconda/ui/tui/spokes/software.py
> >@@ -57,7 +57,6 @@ class SoftwareSpoke(NormalTUISpoke):
> >      def showable(self):
> >          return isinstance(self.payload, PackagePayload)
> >-
> >      @property
> >      def status(self):
> >          """ Where we are in the process """
> >@@ -107,6 +106,8 @@ class SoftwareSpoke(NormalTUISpoke):
> >          """ Refresh screen. """
> >          NormalTUISpoke.refresh(self, args)
> >+        threadMgr.wait(THREAD_PAYLOAD)
> >+
> >          if not self.payload.baseRepo:
> >              message = TextWidget(_("Installation source needs to be set up first."))
> >              self._window.append(message)
> >@@ -128,7 +129,6 @@ class SoftwareSpoke(NormalTUISpoke):
> >              name = self.payload.environmentDescription(env)[0]
> >              displayed.append(CheckboxWidget(title="%s" % name, completed=(environments.index(env) == self._selection)))
> >-        print(_("Base environment"))
> >          def _prep(i, w):
> >              """ Do some format magic for display. """
> 
> If I understand this right, this would cause the TUI to wait on
> THREAD_PAYLOAD before displaying pretty much anything on the hub, which
> doesn't seem ideal. Could the status message be made dependent on
> threadMgr.get(THREAD_PAYLOAD) instead?

Not the hub, but the spoke; this wait is only in the spoke's refresh
method. And the wait only occurs if you specifically choose to enter
this spoke, until the thread finishes. The same behavior is observed in
the other spokes that are thread-dependent (source, storage), FWIW.

I think there was some point in the past where it was considered to just
lock the user from being able to enter the spoke at all if it was still
waiting on a thread, and that was shot down. I don't remember why
exactly--perhaps because the spoke status message is unable to
dynamically update, which would force the user to manually refresh the
summary hub until they could enter the spoke.

Samantha


More information about the anaconda-patches mailing list