Bug 442475

could you please specify in which cases this behaviour occurs ?
e.g. i try this on opensuse 11.1 beta 4:
i run yast software managment in search I enter "a" and i check all checkboxes (Name,Summary,Desctription ...etc) in "Search in" group  then i press search, and while yast was searching it offer me "cancel button" and this button works well

thanks

Sure - 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

OOOps

(In reply to comment #0 from Scott Couston)
> Both Abort, Cancel and Skip Refresh, all need to operate with the Highest CPU
> authority or always higher than the Yast Application itself.

Are you aware that you cannot assign priorities to individual widgets in the same program / process?

Are you aware that you are greatly simplifying and generalizing things?

You claim that "Cancel" buttons never work. That is certainly not true.
There may be operations done in the foreground that sometimes take longer than desirable. Maybe some of those operations can be split up into sub-tasks so UI feedback can be maintained. But then, you are surely aware that there is no simple and generic way to do that everywhere.

A global statement like "Cancel and Abort never work" does not make any sense, nor is there anything to pinpoint, anything to work on. It's very much like demanding "the world must become a better place".

If you can identify situations and places in YaST where you can turn that general statement into anything concrete, let's hear it. But just that general statement alone will not do anybody any good.
 

> We have taken for granted that both cancel or Abort buttons never function
> after we commit to any changes via a Yast Application Window and perhaps it 
> is long overdue for us to correct this

Who is that "we" and "us" in that context?

Yes I am greatly simplifying the issue, but basis of entry is still the same. - Funny things about user feedback - its an honest appraisal of an experience. Funny thing about the role of the Analyst - To identify Market expectation and requirements and put them into an interface between the Programmer. 
No I am not aware of the issues within the X Windows System, however the 'Skip Refresh' where applicable, appears to function quite correctly and halts the Yast Process Window that is in progress.
You are more than welcome to close as invalid if you feel there in insufficient information presented here to identify an problem/issue that is experienced.

Scott, if you come across such behavior (cancel/abort having no effect), please report that particular situation and attach yast logs so that we know what yast have been doing during at that moment. Closing this report as invalid now.

Created attachment 252479 [details]
.jpg screen shot

OH! Thats easy! For test I bocked NTP Protocol from exit of LAN.
1. I Opened YAST>NetworkServices>NTP> I already had a public server configured>Finish.

Now by selecting Finish YAST will attempt to re-start NTP, but cannot due to NTP services blocked from exit of LAN.
It will hang Dependant on your Processor Speed.
The Cancel Button will not assist you to Cancel the stalled Process - The same can be said for any other Yast Process that stalls due to ? reason

RE-Open due #7

Nice, that is something we can look at (and please report any other such problems like this + attach yast logs, but keep in mind that we may close some of them as wontfix, if the effort outweighs the benefit).

I'm afraid this particular case would not be easy to solve. I guess the yast module just waits until the ntp startup script finishes, and the code doing this does not run in parallel to the UI. Martin, can you check what can be done to improve the situation?

adjusting summary

Its the same with any Yast Service that misbehaves - All I did is to create one. As such is hard to get something in mature Yast to misbehave. I understand that this request may be technically impossible - That Why I Tell you about bugs and you fix them ;-)

(Adjusting summary to start with the RPM name.)

See Bug 481299 for other implications of the Abort Button not functioning

The adjustment to current bug name is irrelevant.

I have no idea of how we enhance the Abort Button with the exception of 'Greying It Out' whilst a process is running or hung!

Closed due to the enormity of time wasted in non constructive and non helpful banter.

Only FYI what could help regarding comment #9:
"not be easy to solve ... code ... does not run in parallel to the UI"

The solution is to run code in parallel to the UI.

When I have to do something in the system
where I don't know if it will finish,
I call a bash script from YaST.
The reason is that at least for me it is easiest
via a bash script to work with several processes
so that a background process does the actual work
while the foreground process controls the worker-process.
After a timeout the foreground watchdog kills the worker.

See for example in the YaST printer and scanner modules
the bash scripts in /usr/lib/YaST2/bin/ which contain
a "MAXIMUM_WAIT" like
----------------------------------------------------------
#! /bin/bash
export PATH="/sbin:/usr/sbin:/usr/bin:/bin"
export LC_ALL="POSIX"
export LANG="POSIX"
umask 022
MAXIMUM_WAIT="10"
/run/the/worker/command &
PID=$!
for i in $( seq $MAXIMUM_WAIT )
do ps $PID &>/dev/null || break
   sleep 1
done
if ps $PID &>/dev/null
then kill -9 $PID &>/dev/null
     exit 1
fi
exit 0
----------------------------------------------------------

This way there is no longer an unlimited waiting
which mitigates the "Cancel button ineffective" issue
but clicking [Cancel] is still ignored (compare bug #489077)
until the timeout had happened and then
https://bugzilla.novell.com/show_bug.cgi?id=442173#c4
might happen.