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

Re: text UI and threading issues

On Mon, May 06, 2013 at 01:41:39PM +0200, Vratislav Podzimek wrote:
> 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.

Hm, not sure how I feel about that since it seems a little clunky, but I
don't know there is a better solution right now. It's too bad the text
UI is so limited in situations like this.
> 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).

I do like that, and I don't think it would be very much work to check if
there is a background thread running and setting the spoke status to
"Processing..." (or similar).
I think more needs to be done than just showing the changed status
though. In the GUI there's a hard lock (graying out the icons and making
them unclickable). I think the way to enforce a sort of hard lock in
the TUI would be to just not allow a user to enter a spoke if a relevant
background thread is running. What do you think?
> 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.

No, definitely not impossible. I think setting some sort of "processing"
status message is doable for F19, though implementing any sort of lock
as I described above would have to wait for F20.


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