We have an Evince-side field struct which store :

• bounding rect
• type
• field ID (unique, used by poppler to identify the fields)

On the Poppler-side, we have almost the same :

• bounding rect
• type
• content
• ID

event handling :
1) The user clicks inside a field bounding rect
2) Find the relevant field through Evince cache
3) Create a GtkWidget corresponding to the field's type
4) Retrieve the field's content by calling Poppler and set content
5) wait until the user unfocus the field
6) Get GtkWidget content and store it, delete GtkWidget
7) quickly render the content directly on the pixbuf, evince-side
8) propagate content change to poppler
9) ask for a re-rendering of the page, poppler-side

The idea is to implement a quick and 'dirty' text-rendering func in evince and a more slow (but less 'dirty) one in poppler.
This allow us to avoid field content update delay due to the async nature of poppler.
For the poppler-side text-rendering, we could directly use the incremental update feature to modify the in-memory representation of the pdf field. This way, when we save the file, we only need to serialize what we have in memory.