The exact responsibilities in the many patterns that are referred to as Model-View-Presenter vary. Mainly they vary about how much control is exerted over the view by the presenter. Martin Fowler has an in depth discussion of a number of different variants in his chapter on GUI Architectures, it's well worth a read.
Have a look at Presenter First as it deals with adapters and the responsibilities in some depth.
Both Passive View and Supervising Controller are worth looking at.
model (or domain model) == logical representation of the entities involved in the system including their state and behaviour
presenter == listen for events from view (and maybe model) and service those requests, convert model types into view types (passive view), this is really plumbing to hide the view and the model from each other. Reacts to stimulus from the user.
view == presentation: the visual representation of the model that the user can interact with, collecting user input
Your specific questions around the callbacks and getting the grid cell style are both going to involve the view handling events from grid and raising events back to the presenter to request actions or retrieve data from the model. This is perfect for the callback when the cell content is updated (this needs to be published to the presenter so that the presenter can validate the change in the model and make the change in the model).
For the grid cell style I am thinking that some sort of adapter in the view may need to translate the state from the model (retrieved via an event from the view to the presenter) into the grid cell style information. This could happen in the presenter but I would personally prefer the presenter not to have knowledge of the widget in the view.