On Tue, 2013-05-07 at 13:06 -0400, Samantha N. Bueno wrote: > 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? I'm completely okay with that. > > > 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. That would be great! Thanks, -- 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
