Most of what PRICE does is implemented by actions, which are typically filters. Some of then require user input, some not. An action may also give user feedback, for example through a progress bar. This pages sketches out the classes involved with one action, this may be useful both for people trying to implement a new filter in PRICE and also for those who want to extract a filter to reuse it and so to understand the environment a single filter uses and needs.
Like in a tyipcal Document-based application, the user events are managed by the Document Controller.
A basic action is so invoked directly by the document controller.
A more evolved action which needs user input has a controller, to follow the MVC idea (Model, View, Controller). So we have a controller class which manages, for instance, the user panel with text fields and sliders, which whill invoce the actual code with the parameters. To invoke the filter it passes thorugh the document controller, this way it can easily work on the frontmost document.
The hiearchy is briefly sketched this way:
The most complete filter has also a progress display and this is
explained in the diagram above too.
Only the core of a filter knows the real progress of a calculation, so
the core needs to send messages to its controller communicating the
status. But this would be cumbersome.
PRICE offers a subclassable object called PRProgressAction which every filter can sublcass. This offers the method to communicate directly with the progress panel, both to move the progress bar and to display descriptive text. The other interactions of the filter with the rest od the application remain unchanged, so adding progresd display to an existing filter is quite easy.