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 _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
