Bugzilla – Bug 105468
embed kpdf into firefox (using dragonegg) by default
Last modified: 2005-08-30 21:12:40 UTC
to get rid of acrobat reader in the default selection we need to be able to reliably view PDFs in Firefox. Dirk, can you integrate kpdf (?) into firefox so that it started by default? We will need to do the same with gnome and gpdf or evince there.
Created attachment 46798 [details] patch this diff should do it, but I'm hesistant to submit as the package is broken right now and I cannot test it..
without having any clue about dragonegg I understand that it will then *always* use kpdf for PDFs? How about all other types which are supported through dragonegg? I have tested it with both plugins installed now (acroread/dragonegg) and Firefox just displays nothing now!
you probably don't have kpdf installed ?
Wolfgang? anyway, I fixed this issue. it will only advertise pdf portability if kpdf is installed in the system. also fixed some crashes and braindamage (netscape plugins were loaded via the nsplugin kpart which was embedded in dragonegg) as well. there is still a problem about priotizing acrobat if installed. according to mozilla documentation mimetype handlers are registered on first-come-first-serve base, so the order of initialisation matters which one is registered first. to make matters worse, mozilla caches the mtimes of the plugins and only re-requests mime type information if mtime changed. therefore, libdragonegg.so has to be touched after kpdf or acrobat is installed. either that, or let the user sort that out (user can disable plugins on a mimetype base). opinions?
ok, can I check in the dragonegg plugin linking patch? yes or no? any reaction would be nice.. Thanks!
(In reply to comment #4) Yes, most probably kpdf wasn't installed at that time. > anyway, I fixed this issue. it will only advertise pdf portability if kpdf is > installed in the system. also fixed some crashes and braindamage (netscape > plugins were loaded via the nsplugin kpart which was embedded in dragonegg) > as well. > > there is still a problem about priotizing acrobat if installed. according to > mozilla documentation mimetype handlers are registered on > first-come-first-serve base, so the order of initialisation matters which one > is registered first. > > to make matters worse, mozilla caches the mtimes of the plugins and only > re-requests mime type information if mtime changed. therefore, libdragonegg.so > has to be touched after kpdf or acrobat is installed. > > either that, or let the user sort that out (user can disable plugins on a > mimetype base). > > opinions? That's not easy :-( You are right about the mozilla plugin behaviour. But the plugins are registered at least at every startup? I don't have a big problem if the user installs kpdf and firefox doesn't recognize it immediately but after the next restart. (In reply to comment #5) > ok, can I check in the dragonegg plugin linking patch? yes or no? > > any reaction would be nice.. Firefox on beta3 should already add dragonegg to its plugin list. The patch within this bug (and some missing change) is already there.
ok, great, then reassigning to stefan for fixing the selection.
So what should be fixed exactly in selection?
add dragonegg package to default selection in KDE.
fixed for RC1.