[poppler] Qt4 bindings

[Kristian Høgsberg]

Brad Hards wrote:
> On Fri, 10 Jun 2005 08:24 am, Kristian Høgsberg wrote:
> 
>>Brad Hards wrote:
>>
>>>On Thu, 9 Jun 2005 04:06 am, Kristian Høgsberg wrote:
>>>
>>>>Brad Hards wrote:
>>>>
>>>>>I've ported the Qt bindings over to Qt4, and updated the API in a couple
>>>>>of places to be closer to the Qt4 style. It lives in a parallel
>>>>>directory (ie qt4/), and the compile tests for qt3 and qt4 are run
>>>>>independently. It should be safe to install both.
>>>>
>>>>Hmm, looking at the differences between the existing bindings and your
>>>>qt4 bindings it looks like most of the code is shared, only the includes
>>>>have changed and qt4 has as float rectangle type.  Shouldn't it be
>>>>possible to use the same poppler wrapper with both qt3 and qt4?
>>>
>>>No.
>>>1. The source code is fairly common at this stage, because I haven't
>>>introduced many Qt4-dependent cleanups or features yet (eg the QPainter
>>>renderer, perhaps exporting images with a QImageIOHandler).
>>
>>Is QPainter a new backend, i.e. like the cairo backend or do you have
>>something else in mind?  For backends I'd prefer that we keep them in
>>the poppler/ directory, and it shouldn't affect the front-end wrapper
>>which backend is in use, this is selected at compile time.
> 
> It is a new backend, but it needs to be exposed to the user. So where the Qt 
> bindings currently do:
> void renderToPixmap(QPixmap **q, int x, int y, int w, int h) const;
> there will be a 
> void renderToDevice(QPaintDevice *device, QRectF *region) const;
> or something like that - I haven't done it yet! Figuring out double-buffering 
> and other Arthur features might require a rethink of the API.
> 
> 
>> > That will change,
>>
>>>and the code will become littered with #ifdefs. There are a few changes
>>>already because of API differences (diff will show you where).
>>>2. The same .so can't be used - Qt3 and Qt4 aren't binary compatible.
>>>3. The original API isn't very Qt-like, so I'm planning to evolve it
>>>quite a lot. That isn't a nice thing to do for users of Qt3 (including
>>>me!) because everytime a method name changes, current code breaks.
>>
>>So do we need the Qt3 wrapper,then?  I hope you can understand that I'm
>>a bit sceptical about having to almost identical Qt wrappers ;-)  Should
>>the two be installable in parallel?
> 
> I think we do, Qt4 isn't shipped by anyone yet - it has a long time to go 
> before it will be required by a KDE release (at least a year), and then there 
> are distros that are very slow to update (cough *Debian* cough). I already 
> have code in KDE that requires Qt3 Poppler bindings. That wasn't without some 
> concern amongst KDE developers. I really don't want to be proved wrong! In 
> fact, if it has to be one or the other (and I don't see that it does, went to 
> a lot of trouble to make sure that they are parallel installable), then I 
> want stable qt3 bindings.
> 
> If you won't take the Qt4 bindings now, I can continue to develop outside the 
> tree, but it makes it harder to get feedback and for others to contribute. 
> Also goes against the "early and often" principle.
> 
> Overall, I don't see the issue. Sure, qt4/ is pretty close to qt3/ right now, 
> but that isn't a long term issue.

Alright, let's do this then.  Do you want CVS access so you can add it 
yourself?  If you're going to work on the qt4 bindings, I think it makes 
sense to set this up right away:

	http://www.freedesktop.org/wiki/AccountRequests

> BTW: I'd be happy for this to be posted back to the Poppler ML with your 
> decision, if you wish.

Oops, of course.  I took this of the mailing list by accident when I 
pushed the wrong reply button.

cheers,
Kristian