[poppler] poppler-glib

[Kristian Høgsberg]

Jeff Muizelaar wrote:
> I haven't gone over your stuff to thoroughly yet. I'll do that as I
> continue work on the qt wrapper later tonight. However, there are a few
> quick things right now.
> 
> On Fri, Mar 18, 2005 at 02:01:54AM -0500, Kristian H??gsberg wrote:
> 
>>If people are happy with this direction, my plan is to commit these 
>>files to CVS (with required auto* magic) and then gradually add the 
>>remaining features to allow evince to switch to this interface.  The 
>>glib wrapper would live in poppler-glib/.  
> 
> 
> I think just glib/ might be better. That's what dbus uses...

That's probably better, yeah.

>>PopplerDocument *poppler_document_new_from_file (const char      *uri,
>>						 const char      *password,
>>						 GError         **error);
> 
> like we discussed on irc, instead of using **error this should just
> return a locked document if it is encrypted and no document if it fails.

It can still fail for various other reasons; file not found or invalid 
document...

> One other thing, out of curiosity, do we actually gain much other than
> reference counting from using glib over a plain c wrapper?

Well, it's more than just using GObjects for the document and page 
objects, it's being able to render to a GdkPixbuf, using GObject 
properties for meta data.  It's the availability of a set of tested and 
optimized data structures, and a large set of convenience functions that 
just work across a wide range of platforms.  I think the benefits will 
become clearer as the binding is fleshed out a bit more.

I'm not too attached to the glib dependency, though I have a threshold 
as to how much of glib I want to reinvent.  If we find out down the road 
that glib is not worth it, I think we should consider providing only one 
wrapper using neither glib or qt.  There is no point in providing both C 
and C++ bindings if they don't integrate nicely with GNOME and KDE, 
respectively.

cheers,
Kristian