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

David Shea dshea at redhat.com
Mon Jan 5 20:40:42 UTC 2015


On 01/05/2015 03:38 PM, Samantha N. Bueno wrote:
> 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.

Oh, right. Apparently I forgot how to read patches over the break and 
thought I was looking at status. Ack.



More information about the anaconda-patches mailing list