qpdfview team mailing list archive

[Adam Reichold <adamreichold@xxxxxxxxxxx>]

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

Hello again,

I messed up thing some more: I made the plug-in loading lazy, i.e. we
only try to load a plug-in when the corresponding format is used. And
I added build-time options to make the plug-ins static. (One option
for each plug-in, e.g. for the Arch Linux package I choose to make PDF
static and PS not.)

Of course, this further complicates the matter of determining the
actual "TARGET" variable in Makefile from qmake's "TARGET", e.g.
"libqpdfview_pdf.so" or "libqpdfview_pdf.a" for "qpdfview_pdf"...

Does anyone have an idea which qmake guru one could ask about this?
(The point is that I do not really want to write a OS switch statement
somewhere concatenating $QMAKE_PREFIX_SHLIB and things like that...)

Best regards, Adam.

Am 10.01.2013 20:42, schrieb Adam Reichold:
> 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)

iQEcBAEBAgAGBQJQ79chAAoJEPSSjE3STU34mZ0H+gIOip3EPRLRm+6y17XQyB0b
9Q+9blCMJNbPPSB0FtHjWzAnBZgr4uQHtyhZtl5nNysUEYu3vHy9QY2jy76Ioztc
HAB34ViECpzgPYj11uXu8GBJ+dKmT3BXaaZ0MvCaSQinXi6CzDl22gCs8GmIz0PL
TrPylCOkGcIGaoO/gtBeEWAUyYU5O73XMR3iJjrn3iUpRNynxZKMAnwqE7xuPxRp
eQV8Hyyt9+iyCeB1/9zOFrJhmGGe07W+geQjeYdZXjW96ZbfNSBt1d/zfveGGb19
IAt+giOdsdoMDignC1+ZwnDGovgHY0HDPcoDn48gVQzSqqOltk/sL0CGoLqAQY4=
=6NrH
-----END PGP SIGNATURE-----