Firefox3KDEIntegrationIntrepid

Firefox3KDEIntegration

Motivation

Firefox 3 comes with improved OS integration on gnome; unfortunately, the KDE user-experience still needs to catch up in order to provide a complete and integrated firefox experience on the KDE/Kubuntu Desktops.

This specs identified the main issues and proposes solutions on how those can be resolved in the mid-term.

Another motivation is that KDE integration is a feature wanted upstream; however, this implies that implementations should take extra care that they are still on track for upstream inclusion code and design wise.

Summary of Cross-Desktop techniques available in mozilla

Adapting to desktop dependent APIs always introduces the problem of package desktop specific dependencies getting pulled in by default. The general approach used for mozilla packages in the past was:

  • provide a dynamic component that can be shipped in a desktop specific package. The current example is the xulrunner-1.9-gnome-support package which is ment to ship features that require gnome specific libraries.

In addition you can use dlopen:

  • In some cases it might be feasible to use dlopen to get access to desktop specific features/symbols. This usually works well when the involved functions only have basic datatypes as parameters (e.g. char*, int, etc.). Otherwise, stick to the component approach outlined above.

Identified Problems

General

Firefox 3 doesn't have official infrastructure components that allow to get details on the currently used desktop environment. Getting such a component would allow desktop specific handling to be done in a clean fashion.

Mime-Type Handling

The mime-type has become worse in firefox 3 for pure KDE desktops as mailcap support was completely dropped, which basically leaves KDE users without any defaults for non-browser content types.

Protocol Scheme Handling

Firefox 3 supports two mechanisms to setup protocol handlers for URI schemes. The first one is a preference the user can place in a system- or profile- configuration file; the second approach leverages gconf to gather the scheme-to-application mapping.

KDE/Kubuntu users don't have a sane default behavior as the firefox package cannot ship the preference

Set Image as Desktop Background

Setting the background image using the right click context menu isnt possible on KDE. This is not a regression, but a long standing issue that finally should be resolved.

Mime-Type icon integration

Firefox3 introduced the gnomestripe theme, which allows to map skin icons to gtk/gnome stock icons - when available. In general, this works well and on KDE firefox 3 falls back to the old theme known from firefox 2. Only big feature missing is the ability to display icons for content types when using firefox to browse files. The current behaviour displays no image at all if no stock icon for the mime-type can be found.

Proposed Solutions

General

(Targetted Quickfix 3.0) Provide javascript templates/snippets that implement the desktop environment detection logic. If required duplicate the code and replace that with the real solution in 3.1

(Targetted Upstream 3.1) Provide a nsIDesktopEnvironmentInfo interface that gets shipped as a toolkit component. The contract id would be '@mozilla.org/desktop-environment-info;1'.

The nsIDesktopEnvironmentInfo would expose information about the desktop name, the facilities that ship with that desktop (e.g. xfce might use gconf, while kde doesn't, but both are not gnome)

Mime-Type Handling

(Targeted Upstream 3.0) No short term solution available; go for 3.1

(Targeted Upstream 3.1) The long term goal is to make firefox code as much desktop environment independent as possible. Thus, the right approach for this is to use xdg as a cross-desktop way to access the freedesktop mime-type database.

Unfortunately, not all features required are provided by the xdg wrappers. Until then we have to use desktop dependent APIs to supplement the missing features.

XDG Features identified to be missing in order to switch firefox to use xdg only are:

  • ability to retrieve a list of all known MimeTypes

  • ability to retrieve icons for a certain mime-type
  • ability to retrieve icons for a certain application

In summary, the changes required to the firefox code base are:

  • use xdg for getting mime type defaults for the current desktop environment
  • the complete list of mime-types required to present the configuration dialog needs to be gathered from desktop specific code.
    • Introduce new XPCOM Interface nsIMimeTypeLister

    • implement gnome, kde and xfce dependent MimeTypeLister and deploy them using a contract id which allows to specifically load/use any given implementation.

Set Image as Desktop Background

Setting the Background for the Desktop cannot be done using xdg; thus we need to support desktop environment specific backends for this feature in firefox and provide a KDE as well as a gnome (and maybe xfce) implementation for it.

The gnome way of doing this is to download the Picture to the default download directory and updating a gconf setting to point to the new file.

The KDE way is to send a dbus command to update background path. Basic Dbus support is available in firefox and thus implementing this is just a matter of special casing dependent on the desktop environment the firefox session runs in.

Mime-Type icon integration

Current firefox implementation uses dlopen and explicitly binding function pointers to in-source defined API declarations to prevent the requirement to link against libgnomeui. Something similar is not doable in a simple fashion for KDE as the kde lib functions use Qt types whose declarations can hardly be duplicated in firefox code.

Thus, the nsIDesktopEnvironmentInfo implementation should provide a simple API that allows firefox to gather real icon paths per mime-type.

The gnome API elements to use in the Gnome implemenation can be directly taken from the current firefox code.

On KDE to gather the abstract name for the mime-type icon, use:

To get the real path for a abstract icon name (which can then be used to load the icon in gtk use):

Implementation Details

  • (Add any details that become available while implementing this here ...)

Outstanding Issues / TODO

  • The most critical issue regarding Firefox and KDE integration is probably the File Picker dialog leftover from GTK. Setting ui.allow_platform_file_picker to FALSE gives a nicer File Picker which is more similar to the KDE File Picker, but is still not a solution.

Comments

  • The biggest problem in Firefox for me (as a KDE user) is the terrible GNOME file dialog. If the only KDE integration change is a switch to use native file dialogs, I'll be very happy.
  • What I would like to see is: Kprinter-Integration and saving of Passwords in KWallet

  • also: "Open containing folder" is only working if nautilus is present (LP: #133133 - http://bugs.launchpad.net/bugs/133133)

  • And don't forget about things like compose key sequences. As well as the fact that the Gnome ones sometimes differ from the ones KDE uses, I have found that on certain keyboard layouts (e.g. Canadian multilingual), the compose key doesn't work at all under Gnome, but does under KDE.

Firefox3KDEIntegrationIntrepid (last edited 2009-05-12 12:25:15 by cable-85)