Bug 380548

Summary: interupting commands
Product: [Applications] rkward Reporter: Thomas Friedrichsmeier <thomas.friedrichsmeier>
Component: generalAssignee: RKWard Team <rkward-devel>
Status: RESOLVED FIXED    
Severity: wishlist    
Priority: NOR    
Version: unspecified   
Target Milestone: ---   
Platform: unspecified   
OS: All   
Latest Commit: Version Fixed In:
Sentry Crash Report:

Description Thomas Friedrichsmeier 2005-04-17 16:59:50 UTC 
-- This ticket was imported from http://sourceforge.net/p/rkward/feature-requests/14 on 2017-05-31 14:48:55 +0100 --
Interupting commands is broken. But also it  
never was quite good, you could only ever  
interupt the one command last submitted in the 
console \(as far as I remember that is\). 
Hence instead of "fixing" this, it will probably 
make sense to come up with a better solution. 
After all, it should also be possible, to interupt a 
command from a plugin, from a command file, 
etc. \(while generally internal commands might 
not be safely interruptable\). 
What I think would be cool is to have a widget 
display a list of commands currently in the 
execution stack, i.e. pretty much visualize the 
RCommandStacks. Then commands / 
command chains can be selected to be 
interupted, and also we can make a cool 
screenshot ;-\). 
What may make this somewhat non-trivial is the 
threading stuff involved. Not sure right now, 
whether we can safely get at the data in the 
RCommandStacks from the GUI-thread without 
duplicating that data. I'll look into that later and 
add a further comment then.
Comment 1 Thomas Friedrichsmeier 2005-04-17 19:11:56 UTC 
Logged In: YES 
user\_id=300591

When done, remember to clean up 
"user\_command", etc. variables/functions in rkwatch 
and rkconsole \(also in rkwardapp?\). Those are 
leftovers from the old interupt functionality.
Comment 2 Thomas Friedrichsmeier 2005-04-18 10:25:08 UTC 
Logged In: YES 
user\_id=300591

Threading should not be a big issue. All we need to 
do is lock/unlock the mutex before/after accessing 
the data in RCommandStack::regular\_stack. 
Probably it does not make sense for a GUI-widget to 
be kept actively in sync with the command stack \(via 
signals and slots or the like\), but rather to update the 
command list in the widget every few seconds \(if 
visible\) or on user request. 
This is because \_lots\_ or small command get 
generated and delelted all the time.
Comment 3 Thomas Friedrichsmeier 2005-04-24 12:25:25 UTC 
Logged In: YES 
user\_id=300591

On second though, maybe it would in fact still be 
easiest to keep the list of commands directly in sync 
with the RCommandStack. In fact, it might be smart 
to implement that functionality using direct calls from 
RCommandStack or RInterface \(whenever a new 
command/chain is issued and whenever a 
command/chain is closed\). 
Remember that using QT-GUI functions is only legal 
from the main GUI-thread. But it should be quite 
possible to do this right.
Comment 4 Thomas Friedrichsmeier 2005-10-13 21:33:05 UTC 
- **assigned_to**: nobody --> tfry
Comment 5 Thomas Friedrichsmeier 2005-10-16 20:01:11 UTC 
Logged In: YES 
user\_id=300591

done. see class RControlWindow
Comment 6 Thomas Friedrichsmeier 2005-10-16 20:01:11 UTC 
- **status**: open --> closed