Posted on by Martin Flöser

Firefox KDE integration in Debian Testing

One of the features I dislike about Firefox is the lack of any integration with the environment it is running in. It doesn’t recognize the correct applications to open files and presents the IMHO unusable GTK file dialog. The file dialog is a real problem to me. I often have to download patches from reviewboard and my KDE file dialog has all the shortcuts to get into the source directories.

Thanks to the openSUSE people there are patches to get a working KDE integration. But those are not upstream and not all distributions includes them. So if you are not using openSUSE chances are that you don’t get those goodies. Thanks to Blue Systems there is a PPA for Kubuntu: firefox-kde.

Even better: this PPA is also working on Debian Testing. But one needs to use the “raring” repository and not “saucy” (unmet dependencies). The normal warnings about adding additional repositories to your system apply. Don’t blame me if it breaks your system. Just add the following to your sources.list:

deb http://ppa.launchpad.net/blue-shell/firefox-kde/ubuntu raring main 
deb-src http://ppa.launchpad.net/blue-shell/firefox-kde/ubuntu raring main

I highly recommend to apt-pin the “raring” release, so that it doesn’t update your packages from this repository:

Package: *
Pin: release a=raring      
Pin-Priority: -2

Now update the sources and install firefox and firefox-kde-support. On Debian the package is called iceweasel and firefox can be installed next to it: the files do not conflict. Close any running iceweasel instance and start Firefox (no longer iceweasel).

Aus 2013-12-01

Additional gimmicks: newer version as it’s based on Ubuntu’s Firefox and appmenu integration.

16 Replies to “Firefox KDE integration in Debian Testing”

  1. Chakra use only this patched Version 🙂 Rekonq, Qupzilla and QtWeb is also there. @Martin: The Comment Link in your Newsletter is still wrong.

  2. Isn’t Mozilla going to throw a fit at this? Doesn’t a release with unblessed patches but the “Firefox” branding cause them to start taking legal action?

    “Iceweasel” was created for a reason…

    1. Why don’t any devs(including all distro devs) contribute this ?

      At least for me (and probably for many others) it’s the lack of knowledge. Different programming language, unknown toolkit, unknown source base. If one considers that one always has enough things to work on, it’s no suprise that nobody contributes to it.

    1. I don’t think that’s possible. If it were possible to do it as an addon, it wouldn’t need patches for firefox.

  5. I can’t be the only one who finds something just a little bit perverse about going to such lengths to integrate Firefox into KDE. We have Konqueror. Is it so busted that it can’t be used practically? (Even with the WebKit KPart?)

    I’ve had a gnawing suspicion that there is some software in KDE that the developers themselves don’t honestly use, Konqueror/KHTML being chief among them. Seeing this post sadly adds more fuel to that suspicion.

    No disrespect intended. I really appreciate what you do for KDE.

    1. I really think we should overcome the not-invented-here usage. There is nothing wrong with using Firefox or Chromium in a KDE environment. And there is nothing wrong with promoting KDE-integration for those tools.

      We don’t need to deny that more people are working on Firefox or on Chromium than people are working on Konqueror or rekonq. They are doing a great job with the limited resources.

      1. There is nothing wrong with using alternatives, per se, but it isn’t exactly efficient. Nor does it say good things about the quality of KDE as a whole when its developers choose to use alternatives instead of software that KDE provides. Where exactly is the line that separates not-invented-here syndrome from respectable dogfooding?

        Please don’t get me wrong: I agree, integration and such with external applications is laudable, where practical and to the extent that it makes everyone’s lives better. This just triggered a concern that has been brewing in my mind for a while now. Apologies for venting.

        1. Nor does it say good things about the quality of KDE as a whole when its developers choose to use alternatives instead of software that KDE provides.

          What exactly does it say about the quality? Should we compare the number of full-time employees working on Firefox against those working on Konqueror? Or compare the number of developers working on Gecko, WebKit and Blink to the number of developers working on KHTML or QtWebKit for Qt4?

          Where exactly is the line that separates not-invented-here syndrome from respectable dogfooding?

          Just because I’m a KDE developer doesn’t mean that I have to dogfood all applications provided by the KDE community. Neither do I expect that KDE developers use KWin (I know some who use tiling WMs and that’s just fine).

        2. Counterpoint: Just because a KDE dev wants to use Firefox and have it fit in doesn’t mean he doesn’t use Konqueror/rekonq too.

          I don’t particularly like the direction Firefox has gone starting at v4. On the other hand, there are useful extensions that just don’t have equivalents on other browsers. If you do any web work, even casual, you need to test on several major browsers. If some site you just use appears broken in your browser of choice, having a fallback with different render engine can be a useful check if the site is broken in all cases or just some, and might be a temporary solution to access the site until it gets fixed or you sort out the issue with your primary browser.

          The reason to use more than one browser is a mile long. Having them all look and feel somewhat consistent is a good thing.

    2. ” Is it so busted that it can’t be used practically? (Even with the WebKit KPart?)”

      Currently, yes it is. On the other Hand, Qupzilla, Rekonq and QtWeb are 3 Alternatives, who can fit for anybody, in my Sense. How sensefull is it, in your Terms, to integrate Servo into Konqueror?

  6. “Currently, yes it is. On the other Hand, Qupzilla, Rekonq and QtWeb are 3 Alternatives, who can fit for anybody, in my Sense. How sensefull is it, in your Terms, to integrate Servo into Konqueror?”

    Actually konqueror with webkit works just fine here. It is more stable than rekonq. It could use activities support, though.

  8. Pingback: Kako da » Unix Srbija | Unix Srbija

Comments are closed.