CamiTK Action API Change: before/after apply
As a | CamiTK developer |
I would like to | homogenize what is done before and after an action is called |
So that | I can add useful behaviour (e.g., reset progress bar and wait cursor, auto application refresh is needed) and quickly add new improvement to CamiTK (e.g., automatic multithreading support for Action, better actionstatemachine/history management) |
Epic | CamiTK API Cleaning |
Follow up of #11
Description / Overview
Apply mechanism
Think about this API change to see it is reasonnable to change this
- Merge
applyInPipeline()
andapplyAndRegister()
intoapplySlot()
- note : in
applySlot
change the cursor and restore it to normal independently of the return value - note : add thread?
- note : in
-
Action::apply()
should now be a protected method - No signal should be connected to
apply()
, but connected toapplyInPipeline()
orapplyAndRegister()
apply
mechanism
Other things to do when rewriting the Encapsulate GUI update
This is also a great opportunity to add:
// before apply
QApplication::setOverrideCursor ( QCursor ( Qt::WaitCursor ) );
Application::showStatusBarMessage(action->getName() + "...");
Application::resetProgressBar();
...
// after apply
Application::resetProgressBar();
Application::showStatusBarMessage ( "" );
QApplication::restoreOverrideCursor();
Hide Application refresh
Dev should not have to include the Application
headers.
The use of Application::refresh()
in very frequent actions
→ It might be a good idea to simplify action development, e.g.:
- by adding a
setAutoRefresh(bool)
method. When called in theAction
derived class constructor,Application::refresh()
is automatically called after theapply()
method... This will also simplify header inclusion (no more#include <Application.h>
in action). By default the auto refresh is on (i.e. when theapply()
method is finished, the application refreshes automatically) - and/or add a methode
triggerApplicationRefresh()
that can be called inside theapply()
method
Others
There might be other common default things/behaviour/code that could be put before and after the apply()
call to simplify the work of the action developer:
- e.g. a
setTreaded(bool)
method that automatically controls if the action is ran in a thread or not...
Acceptance test
-
there are no Application::resetProgressBar()
calls inside action code (in CamiTK CE), and the cursor is modified for all action automatically, and the progressbar is back to 0% at the end of the action. -
there are no Application::refresh()
calls inside action code -
API documentation of class Apply
explains pre and post process actions -
there is a follow up story to implement multi-threading in action