krh at bitplanet.net
Fri Mar 18 08:16:49 PST 2005
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
> 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,
More information about the poppler