[rkward-tracker] [ rkward-Feature Requests-1184757 ] interupting commands

[SourceForge.net]

Feature Requests item #1184757, was opened at 2005-04-17 19:59
Message generated for change (Comment added) made by tfry
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=459010&aid=1184757&group_id=50231

Category: None
Group: None
Status: Open
Priority: 5
Submitted By: Thomas Friedrichsmeier (tfry)
Assigned to: Nobody/Anonymous (nobody)
Summary: interupting commands

Initial Comment:
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 By: Thomas Friedrichsmeier (tfry)
Date: 2005-04-24 15:25

Message:
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 By: Thomas Friedrichsmeier (tfry)
Date: 2005-04-18 13:25

Message:
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 By: Thomas Friedrichsmeier (tfry)
Date: 2005-04-17 22:11

Message:
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. 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=459010&aid=1184757&group_id=50231