GNOME Bugzilla – Bug 567751
move reusable code into a shared library so other apps can display documents using evince code
Last modified: 2009-01-18 12:01:03 UTC
Most of evince code would be useful in other applications if those were able to embed EvView as any other widget. Evince's architecture is very well suited for this, but in order to not duplicate code, those other apps would need to link to a shared library. This is very similar to libabiword and abiwidget. The patch attached does just that: puts most code in libevince and links the evince executable to it, though there are some hacks that need cleaning up. Comments and help welcome. Will submit python bindings and a few API additions in a separate ticket.
Created attachment 126421 [details] [review] move most code to a shared lib
Created attachment 126433 [details] [review] removes some hacks
Dou you really need the whole evince shell in the library? I tought EvView and libevbackend were the only things interesting for embedders. Right now there are minor issues, though, since EvView depends on ev-pixbuf-cache. Well, EvJobs might be useful to reuse too, but probably optioanlly for clients.
(In reply to comment #3) > Dou you really need the whole evince shell in the library? I tought EvView and > libevbackend were the only things interesting for embedders. I would say that almost everything except the UI around the view widget is of use to embedders. What API we are using in Sugar right now: - View - DocumentFactory - Document - DocumentLinks - PageCache - Job* (used for searching) Any suggestion about what I can move from libevince to the evince executable?
(In reply to comment #4) > (In reply to comment #3) > I would say that almost everything except the UI around the view widget is of > use to embedders. exactly > What API we are using in Sugar right now: > > - View we should refactor the pixbuf-cache stuff I think. > - DocumentFactory > - Document > - DocumentLinks These are already in a library (libevbackend) > - PageCache > - Job* (used for searching) I think jobs stuff should be at least optional, since you might want to write a non-thread application which embed the evince view. A simple pdf previewer doesn't probably need threads at all. > Any suggestion about what I can move from libevince to the evince executable? > I think two libraries are needed: * libevbackend: already exists * libevview: containing the EvView widget, EvPageCache stuff and EvJobs as a convenient API for using libevbackend.
(In reply to comment #5) > (In reply to comment #4) > > (In reply to comment #3) > > > What API we are using in Sugar right now: > > > > - View > > we should refactor the pixbuf-cache stuff I think. In which way? Should that refactoring happen before we can land libevview? > > - PageCache > > - Job* (used for searching) > > I think jobs stuff should be at least optional, since you might want to write a > non-thread application which embed the evince view. A simple pdf previewer > doesn't probably need threads at all. By optional, you mean that it can be there but people don't need to use it? > > Any suggestion about what I can move from libevince to the evince executable? > > > > I think two libraries are needed: > > * libevbackend: already exists > * libevview: containing the EvView widget, EvPageCache stuff and EvJobs as a > convenient API for using libevbackend. Sounds good. What about code organization? Should such libevview be built like is libevince in the patch above or should a new directory be created? Thanks a lot for your input.
Also wonder if would make sense having a --enable-libevview switch or if this should be done unconditionally.
Created attachment 126588 [details] [review] minimal patch As I'm in a bit of a hurry, have made a very simple patch that moves EvView to a smaller lib. Comments will be very welcome.
Created attachment 126639 [details] [review] tidy up a bit previous patch
Fixed in svn trunk (r3348). I've finally moved the view specific code to a libview directory.