DjView4 is a new portable DjVu viewer and browser plugin using Qt4. It has more functionality than djview3 included in app-text/djvu. Ebuild attached. Should probably go in app-text.
Created attachment 124427 [details] first ebuild
Please read the project page. The viewer is now separated from djvu. There is no djvu-4.1, but a new package djview-4.1 that depends on app-text/djvu.
I do not have qt-4 installed and I doubt I'll install it before kde-4, so if anybody have interest, take it, please.
Thanks. Now if somebody could fix the typo so that it reads "app-text/djview4" it would be great.
added as app-text/djview4: upstream 4.1-2 is 4.1.2 for us. Thanks Stefan ! I made small changes, esp. : removing the nsplugin useflag, as your approach of built_with_use won't work : imagine I build djvu without nsplugin, then djview4 with nsplugin then djvu with nsplugin, that will collide. as djvu is the main package, I suppose it's better that it remains the one that provides the plugin browser. Perphaps we could do something about that to have the choice, but the only thing I can think of is to talk with upstream and ask them to give djview4 nsplugin a different name.
I think the browser plugin is basically the same as in the 3.x version. At some point djview will be separated from the djvu package and we won't have this problem. Until then, we should compile djvu with the qt3 flag to get the plugin, even if we don't use djview3... If you have the time, could you please explain me why the use of: "emake CC=$(tc-getCC) CXX=$(tc-getCXX)" Is there a toolchain w/o CC and CXX set? Thanks.
> If you have the time, could you please explain me why the use of: > "emake CC=$(tc-getCC) CXX=$(tc-getCXX)" > Is there a toolchain w/o CC and CXX set? Thanks. that's just to call gcc/g++ with their full names. gcc/g++ are usually the native compilers and it defaults to them for CC and CXX. Without that you have pain cross compiling the package or have to do some hacks while using distcc over different arches
Then why not putting it in emake?
(In reply to comment #8) > Then why not putting it in emake? Usually there is no need for this, but I suppose the way they use autotools + qmake does not handle it. But you're right, if that annoys someone he can just add the correct options to MAKEOPTS in make.conf.
