[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: text UI and threading issues



On Wed, 2013-05-01 at 11:09 -0400, Samantha N. Bueno wrote:
> Hi,
> 
> I'd like to solicit opinions/have a discussion on an issue Chris and I
> noticed with text UI for F19. Some of the new functionality will include
> being able to set the source repo and choosing software groups to
> install. However, text UI does not lend itself to handling
> multithreading as in the GUI.
> 
> While yum payload transactions or depsolving is happening in the GUI,
> the software and source repo spokes are grayed out, forbidding users to
> click on them again until the threads have finished running.
> Unfortunately, there is no mechanism in the TUI to prevent users from
> re-visiting a spoke with threads active, which is quite dangerous.
> 
> I think the safest way of handling this is to accept the limitations of
> text UI and lock the user in the current spoke until running threads are
> finished, then return them back to the main hub to proceed with
> installation. Not terribly convenient, but again, I think it's safest.
> 
> Before doing this however, I want to make sure there is general
> agreement or that nobody has a better suggestion.
Well, I might have a suggestion, but maybe it is a complete nonsense:

What we do now is that we prompt the user to enter a number or 'c'/'q'
on the main hub. And we have a mechanism for handling asynchronous
events in the text mode (used for exception handling). So maybe we could
use it in a way that if an event that changes what is displayed on the
main hub appears, it could reprompt the user with an 'r' option added
that would refresh the screen. That would allow background changes to be
reflected on the main hub even with the "monochromatic line printer
mode" we have to implement.

To prevent users from entering the spoke that has its background thread
still running, I would not block the user in the spoke when the values
are entered, by when the spoke is entered with a background thread
running. That way, the other spokes could be entered while some of the
spokes need to be blocked. It would just need to show that the spoke is
blocked e.g. by changing it's status to something like
"Processing..." (but better).

What do you think about that solution? I understand it is much more
complicated than blocking user in the spoke she is trying to leave after
entering values that trigger background threads, but I think it is not
that complicated it would be impossible. The questions are if we have
enough time to implement something like that and if the underlying code
really supports it that much I think it does.

-- 
Vratislav Podzimek

Anaconda Rider | Red Hat, Inc. | Brno - Czech Republic


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]