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