qpdfview team mailing list archive

[Adam Reichold <adamreichold@xxxxxxxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello again,

Ok, so I switched the whole thing to a plug-in based architecture and
changed the build system accordingly. Since this is the first time I
used Qt's plug-in system, comments and remarks are very much appreciated.

For now, I chose to make plug-in loading explicit, i.e. the program
will only load the plug-ins it expects since build time and fail if
they are not present. (We probably want to relax this to failing only
if none are present.)

One thing I still have not figured out yet, is an automated way for
qmake to tell me what the plug-in files will actually be named
depending on the platform for which the program is built. (I.e.
TARGET=qpdfview-pdf and TEMPLATE=lib will yield libqpdfview-pdf.so on
Linux.) Currently, I explicitly set this (PDF_PLUGIN_NAME) in the
project include qpdfview.pri. Any hints/proposal are welcome.

Best regards, Adam.

Am 10.01.2013 16:52, schrieb Adam Reichold:
> Hello Alexander,
> 
> Am 10.01.2013 13:10, schrieb ????????? ??????:
>> Hello Adam,
> 
>> It looks great. I'm going to start the work on PS backend. But 
>> there is one issue with poppler and libspectre on Debian Wheezy.
>>  It's impossible to link application with theese libs together 
>> because of their dependence on different versions of liblcms. So
>> it will be good to put all backends to plugins later.
> 
> Well, I sorted of looked forward to not having to do this... :-) 
> Thanks for the hint! I'll adapt Qt's echo plug-in example to our
> needs.
> 
> Best regards, Adam.
> 
> P.S.: Since you'll put considerable functionality into qpdfview,
> how about I add you to the "qpdfview-bugs" Launchpad group giving
> you the powers and responsibilities of a bug supervisor?
> 
>> Best regards, Alexander.
> 
>>> Well, been a busy day: I finished the first round of
>>> integrating the abstract model. Comments and especially testing
>>> is very much appreciated. There are probably some issues with
>>> integrating format differences into the UI which have to be
>>> solved by further plumbing...
>>> 
>>> I am looking forward to integrating the PostScript backend! Is 
>>> there anyone interested in maintaining the DjVu backend?
>>> 
>>> Best regards, Adam.
>>> 
>>> Am 08.01.2013 19:25, schrieb Adam Reichold:
>>>> Ok, so I prepared the build system and the integration
>>>> builds on Launchpad and the OpenSUSE build service for
>>>> multiple format support (basically adding libspectre to the 
>>>> dependencies). Besides the general review, the (currently 
>>>> empty) files "psmodel.{h,cpp}" await your PostScript
>>>> backend. :-)
>>>> 
>>>> Best regards, Adam.
>>>> 
>>>> P.S.: I have not yet begun the actual integration work 
>>>> itself...
>>>> 
>>>> Am 08.01.2013 16:33, schrieb Adam Reichold:
>>>>> Actually, I think we could make it (almost) as easy as the
>>>>>  attached model interface... Am 08.01.2013 15:35, schrieb
>>>>> Adam Reichold:
>>>>>> Hello Alexander,
>>>>>> 
>>>>>> After thinking about it for some time, I'd say that I
>>>>>> would be interested in supporting multiple formats in
>>>>>> qpdfview if: * We agree to use an abstract document model
>>>>>> separating data and presentation completely. * We agree
>>>>>> that the interfaces are modelled on Poppler's interfaces
>>>>>> in the beginning, generalizing them later on. * We
>>>>>> support at least PDF, PS, and DjVu. * We take our time
>>>>>> for the next version which will be 0.4 and no rush w.r.t.
>>>>>> a new name... :-)
>>>>>> 
>>>>>> Modelling Poppler's interfaces will make it possible to 
>>>>>> keep the settings as they are even though some might not 
>>>>>> make sense for other backends. I attach some sample code
>>>>>> on how I would like to proceed with the abstract model.
>>>>>> Your thoughts?
>>>>>> 
>>>>>> Of course, the "fun" part will be adding (probably 
>>>>>> polymorphic) interfaces for annotations and form fields 
>>>>>> which is current missing. But maybe we just make them 
>>>>>> struct's containing their boundary on the page and a 
>>>>>> "handler object" derived from QDialog which should make
>>>>>> it possible to use the current implementation with
>>>>>> minimal changes.
>>>>>> 
>>>>>> Best regards, Adam.
>>>>>> 
> 
> 
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iQEcBAEBAgAGBQJQ7xmdAAoJEPSSjE3STU34A6UH/jxKXFMrUxtSJDVX0VPixw0C
tWxhgItFpzwXfKFqOADjlVZYFUswZ/hurFP8u88JZZbDvrIX8WppuT7rrS1YGciU
D7n22mAUgf/wb+Z9YqX8cfRtNwZdGEVBrkmSkmJTVXUFqjnrq9uwpkQbHZqpTdQA
ZEZBpJst9I0JaWkGMpKcQ97VlgBJR0fC7Tcse1U5wn5w6PFyDjrLLZ2xakOtNhHi
lYINLqjGpCFKC1nfoPmLePk09xVvAH5sXuTJLskfsIE3PCvomZ82M4TIJVbpI3TK
B+B8jrKZseIixIa4RgzBtvH5kXbSU0QV0llaUpmYX7mcX66v1fzoqvHabHPx1tE=
=DAzQ
-----END PGP SIGNATURE-----