https://bugzilla.novell.com/show_bug.cgi?id=489077 User jsmeix@novell.com added comment https://bugzilla.novell.com/show_bug.cgi?id=489077#c442475 Summary: YaST buttons clickable but may have no immediate effect Classification: openSUSE Product: openSUSE 11.2 Version: Factory Platform: All OS/Version: SuSE Other Status: NEW Severity: Enhancement Priority: P5 - None Component: Usability AssignedTo: mschmidkunz@novell.com ReportedBy: jsmeix@novell.com QAContact: qa@suse.de CC: kmachalkova@novell.com, alpha096@virginbroadband.com.au Found By: Development When a YaST module runs, then in the YaST user interface the buttons in the dialogs are usually always clickable (i.e. at any time the user can click a button) even when at the same time YaST is busy with something else so that YaST cannot immediately do what the click requests and in the end the user's click action has no immediate effect. After YaST had finished why it was busy while the user clicked, the click event will be actually processed so that the actual effect of the button click happens delayed. As far as I know this is just the normal behaviour of any usual application. For example when my web-browser (e.g. Firefox) is busy with downloading a huge amount of data or when it is busy with starting a helper application like the Adobe Reade to view a downloaded PDF there is no immediate effect whe I click a button in the web-browser's menue. Therefore the issue in YaST is no bug but nevertheless the usability feeling is bad so that I filed this enhancement request for the next openSUSE version so that we can find out how we could improve the situation. Here some bug reports where the issue becomes really annoying for the user: https://bugzilla.novell.com/show_bug.cgi?id=442173#c4 ------------------------------------------------------------------- clicking the [Abort] button has not the expected effect. One can click [Abort] but then one must wait all the time until the GUI has completed its job (i.e. until the list finally shows up) and afterwards the module is aborted just when the reason for the abort request is no longer valid. ------------------------------------------------------------------- bug #442475 ------------------------------------------------------------------- Cancel button ineffective while starting the module .. If a Yast Application stalls at any point, using the Cancel Button has NO effect on the Yast Application. .. IG ANY YAST Module hangs for any reason on completion of settings you have to wat for it to time out- Abort or Canceled are ignore ------------------------------------------------------------------- https://bugzilla.novell.com/show_bug.cgi?id=481299#c5 ------------------------------------------------------------------- no matter the cause - the user cannot terminate the process .. As a conventional user the only option now is to shut down/restart the PC ------------------------------------------------------------------- My current personal thoughts: Usually there is only one single process which is running. When this single process is busy with something else it cannot process what a button click requests. This is a limitation of the core operating system and we cannot do anything here on the YaST module level with reasoable effort - this means that it is impossible regarding the effort when each YaST module author would have to implement his module as a multi-process or multi-threaded thingy. The core operating system can immediately kill any process at any time by sending appropriate signals to the process. When a signal was sent to a process, the normal operation of the process is interrupted by the core operating system and the process is forced to act on the signal's request. To kill a process usually first SIGTERM is sent to it and if this doesn't have an effect SIGKILL is sent. Those signals can be usually sent by using the window controls of the window wherein the YaST module runs. For example I run fvwm2 as window manager and here I have for each window a dropdown menue with the entries "Delete" which sends SIGTERM so that where the YaST module can respond with a "Really Abort ?" popup dialog so that the YaST module can do some cleanup and terminate with a clean state "Destroy" which sends SIGKILL where the YaST module cannot respond at all because the core operating system will immediately kill the process regardless what the state is afterwards On the other hand the "Cancel/Abort" button in a YaST module does not send a signal to the YaST module process so that its normal operation is not interrupted - instead the "Cancel/Abort" buttons are just normal buttons where a button click is processed when normal operation allows to react on button clicks. This behaviour is intentional because the meaning of the "Cancel/Abort" button in a YaST module is not to kill it but to request for normal termination exactly like the "Quit/Exit" buttons in any other application. We might discuss if it makes sense to have an additional "Kill" button in the dialogs of YaST modules which does send a SIGTERM but do other applications have it? Or should we also in YaST simply rely on the window manager (or on [Ctrl]+[C] via keyboard) to send kill signals? Back to the initial issue in this bug: As far as I see the root cause of user annoyance is that for the user it is not clear when a button click has no immediate effect (because the process is buys otherwise). I think this can be improved by providing better feedback to the user what is going on behind the surface. Some suggestions: a) Gay out the buttons when the process cannot respond to them immendiately? I think this cannot be implemented correctly because then also for any stort-time action of the process the buttons would be grayed off and on all the time (i.e. results some kind of button flickering). b) Change the graphical representation of the button after it was clicked so that the user can see that his click request was noticed. Usually when the process is busy otherwise the cursor is changed to a busy-cursor so that both the busy-cursor together with the clicked-button shows the user what is actually going on. As far as I see the graphical representation of the button already changes after it was clicked but the effect is so minimal that I didn't noticed it up to now. c) When when the process is busy with something where the autor of the YaST module knows that it can be time-consuming, he would like to show a busy popup notification. But here the problem is the word "can" - i.e. the autor of the YaST module only knows that it may be time-consuming under whatever circumstances which are beyond his control (e.g. when re-starting a service). Therefore he does not want to show a busy popup notification in any case because when it is not time-consuming there would be a flickering popup (appear and disappear almost at the same time). Currently my personal workaround to avoid the flickering is that when I show a busy popup where I don't know for sure it is time-consuming I do an additional "sleep 1 second" so that the busy popup stays at least for one second. d) When when the process is busy with something where the author of the YaST module does not know that it can be time-consuming (e.g. in bug #442173), the underlying YaST system (e.g. the YaST UI) might be able to provide better feedback than just the busy-cursor? -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.