Cleaning up "Preferred Applications" & Desktop Consistency
Warren Togami
warren at togami.com
Wed Dec 24 12:21:04 UTC 2003
A while ago I became annoyed enough by the brokenness of this situation
to investigate it seriously. I am now attempting to improve the overall
"Preferred Applications" situation, make cleanups and patch individual
applications to honor the preferred settings. I hope to stir discussion
about further standardization of these aspects of desktop consistency.
Your suggestions would be greatly appreciated. If any new or existing
Bugzilla reports are related to anything below, please reply to let us
know of their locations.
1) https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=109738
Preferred Applications chooser in the Preferences a.k.a.
control-center's gnome-default-applications-properties sets only the
http gconf key, while there is also a https and unknown key that should
be set. htmlview uses the unknown key while Evolution honors the https key.
/desktop/gnome/url-handlers/http/command
This key is set
/desktop/gnome/url-handlers/https/command
/desktop/gnome/url-handlers/unknown/command
But these two are not set
control-center-2.4.0/capplets/default-applications
The relevant code is within this directory. Ray Strode attached a
patch that sets https, because he disagrees that "unknown" should also
be set. I believe because of the way htmlview currently acts as a
catch-all for anything that needs a web browser, that unknown should
also be set. (htmlview itself is largely broken, this is discussed
later in this message.)
2) need-terminal is the key defined in the gconf schema, but
gnome-default-applications-properties sets needs_terminal. Both Ray
Strode and I agree that this is a typo. His patch corrects this, and it
should be applied to both this package and Gnome CVS.
This means that choosing Links in the chooser as a default browser is
currently broken due to setting the wrong key name. However I have yet
to find a program that actually honors the need-terminal key...
3) On the topic of this gnome-default-applications-properties program,
the way the User Interface currently behaves is somewhat confusing to
end users. When you first launch it, all options are grayed out and
there is no indication if you are using the "Select a Web Browser" or
"Custom Web Browser" chooser. This is especially confusing when you
have set a custom web browser, close, then open it again, and the two
browsers don't match. The user interface needs to be redone in order to
reduce end-user confusion. Any takers?
4) Currently gnome-default-applications-properties's choosers have hard
coded values for options like Mozilla, Konqueror, Epiphany and other
programs. We could do a lot better than this.
I propose that we use desktop-agnostic-easy-install definitions for
Preferred Applications. We should standardize on a directory named
something like /etc/sysconfig/preferred/browser.d within which each
package can easily drop definition files. Each definition file can
contain values like Label, command, need-terminal, etc.
/etc/sysconfig/preferred/mail.d, /etc/sysconfig/preferred/editor.d,
/etc/sysconfig/preferred/terminal.d could be the same for mail clients,
text editors and terminals respectively. Then applications like
"Preferred Applications" can read all definitions from these
standardized directories and populate the chooser with all proper flag
values.
Sane?
5) This brings up the larger question of the need for desktop agnostic
configuration for Preferred Applications as KDE does not use gconf. As
individual applications are improved to honor the Preferred Applications
choice, this completely leaves out the KDE environment especially for
users of other distributions that do not unify the user experience
between Gnome and KDE like Red Hat/Fedora does. In such cases the user
may have only KDE installed, and they may not even have gconf at all,
thus the above gconf-based Preferred Applications breaks down.
This creates a disconnect where KDE development totally ignores this
standard and furthers the divide between the two camps. Otherwise
individual applications need to implement two competing standards (this
standard, plus one lack-of-standard as KDE does not currently have a
notion of Preferred browser). This is a poor situation of greater code
& effort duplication, needless added complication and more bugs.
Is it too late to go back to the drawing board and agree upon a
desktop-agnostic place to configure these things so ANY Linux desktop
software can implement it without requiring gconf? During a transition
period the Preferred Applications chooser can set BOTH the gconf like
previously, and the new standard. Eventually we will phase out all
applications that read gconf (which are currently few) and everyone will
be happy?
6) gconf /desktop/gnome/applications/browser/exec contains the value
"mozilla" by default along with needs_term, and nremote which was
probably meant to mean xremote compatible. This key is untouched by
gnome-default-applications-properties and does not seem to be used by
anything I can find. Am I correct that this is redundant?
Furthermore this lacks consistency, because
gnome-default-applications-properties's Terminal chooser sets
/desktop/gnome/applications/terminal/exec.
7) gaim Preferred Applications integration implementation
I am currently implementing a new default URL handler for gaim called
"Preferred Browser". If gaim upstream does not does not accept it as
default, Fedora's gaim package can choose this new URL handler as default.
Implementation Details:
* Due to the brokenness of xremote in all currently released
Mozilla-compatible browsers and complication with MozillaThunderbird,
some extra care and logic is necessary for proper usage of xremote.
xremote's ping() is completely broken while Thunderbird is running, thus
a workaround like this is needed from a bash script:
exec xremote args && exit 0
Rather than checking if xremote is available, it just goes ahead and to
use it. If it fails then it does not "exit 0" then goes to the next
line of the script which can launch the browser from scratch. Due to
this broken ping() problem, /usr/bin/mozilla script needs fixing. See
this Bugzilla report below comment #35.
* https://bugzilla.fedora.us/show_bug.cgi?id=1113
The script launched from gaim would be very similar to the logic used by
fedora.us MozillaThunderbird open-browser.sh in this Bugzilla report.
8) htmlview is currently flawed, and furthermore its unknown gconf key
behavior is broken due to the above problems with the Preferred
Applications chooser.
I propose that it be rewritten to use gconf's http key by default, and
launch logic similar to the above open-browser.sh. I personally really
dislike its current attempt-to-find-any-installed-browser behavior, and
IMHO it should behave only in a defined and predictable manner by
launching only the Preferred Application.
This includes honoring the need-terminal key to launch the preferred
terminal if in X. I fully support making text-mode browsers the
definable preferred browser in X, as some users like links since it
works great with the mouse and it is very fast & lightweight.
Should we have a separately definable preferred text-mode browser too?
I really question the value of needing to launch a text-mode browser
using htmlview in a non-X terminal. I mean really... does anything
currently depend on that behavior, and would anyone miss it? Let us
please kill that off...
9) After all of the above Preferred Applications mess is cleaned up, I
propose that we make the default panel launchers Web Browser and Mail
Client to launch the chosen Preferred Applications rather than
specifically Mozilla and Evolution. It works great and more importantly
100% predictably.
10) Any other common applications that need patching to honor the
Preferred Applications? Let me know and I will attempt to do so.
11) Evolution's clipboard behavior is currently and always has been
fatally broken. Reproduce: Copy any block of text with newline
formatting from any Evolution window, then paste that into any other window.
Big frown! This alone (and the fact that it takes 3-4 minutes for
Evolution to start with my 50+ IMAP folders) are why I switched to
Thunderbird. We really need to get the clipboard behavior fixed at
least. Please find existing Bugzilla reports related to this... they
have to exist somewhere...
12) Mozilla, MozillaFirebird and MozillaThunderbird use ALT-A for
Select-All within TextAreas and TextBoxes. This is inconsistent with
the default keybindings of all other end-user GUI applications in
Windows, MacOS and even Linux where CTRL-A acts as Select-All. Even
CTRL-A works in non-Text input areas of Mozilla. This is totally
inconsistent and needs to be fixed.
Anecdotally, I do a lot of LTSP and Linux work with schools
indoctrinated by Windows and MacOS. This CTRL-A-fails-to-Select-All
behavior is hit VERY OFTEN during while classes use Mozilla. These
little annoyances everywhere in our desktop software & integration
between applications really add up to a negative feeling toward our
software. We need to strive for greater consistency with all end-user
applications in areas like keybindings, thus ALT-A for Select-All needs
to be changed.
Before the kneejerk reaction, let explain how this came to be. CTRL-A
is historically the "jump to beginning of line" keybinding in Emacs and
command line shells. Thus the Unix hackers much preferred CTRL-A in
text input in Netscape to jump to the beginning of the line.
Unfortunately this conflicts with the well understood "standard" of
CTRL-A being Select-All known by all non-Unix-hackers, and is the
standard keybinding of the vast majority of applications in Linux.
Earlier versions of Mozilla even said "CTRL-A" in the Edit menu as the
keybinding for Select-All, which did not match the behavior. When this
was pointed out by many users, somebody upstream simply changed the
string to read "ALT-A".
I complained about this several times before but was shot down as
NOTABUG by Unix hackers. I wont go as far as to claim that they were
biased. =) Fortunately, recently Christopher Blizzard confirmed that
this is indeed a bug, because Mozilla should be using gtk2's defaults
rather than its own hard coded defaults.
If you look at gtk2 applications like gedit, CTRL-A acts as Select-All.
This is true of most other gtk2 applications and all KDE applications.
Blizzard said that gtk2 has options that allow you to set this
Windows-like behavior, and there is the option to change all keybindings
to be Unix-like globally (where is this setting?). Thus Mozilla needs
to adhere to this configuration option and properly use CTRL-A for
Select-All by default. Knee-jerk reaction Unix people who liked the old
behavior can toggle the gtk2 option and get back the old behavior.
More generally we should make it a standard that all end-user
applications adhere to these common keybindings. Web browsers like
Mozilla *definitely* are end-user applications. This standard of course
does not mandate that developer applications with a tradition of a
different keybinding be changed, so of course Emacs and bash continue to
work as they do today.
Is this sane?
13) In the name of end-user application consistency, Konqueror could use
some extra key-bindings by default to make it behave like Mozilla. The
following do not conflict with current Konqueror defaults.
CTRL-W Close current tab.
CTRL-+ Larger font.
CTRL-- Smaller font.
Other common Mozilla keybindings conflict with already defined Konqueror
bindings, and I really don't feel it is worth the emotional & political
fight to ask that they change.
Any active KDE developers here? Could you please get these checked-in
so it can be in KDE 3.2? RH/Fedora will not apply this change, and we
will only have it if upstream applies it. Please confirm in a reply
when it has been submitted.
Can anyone think of other common Mozilla keybindings that could be easy
to integrate?
Thanks,
Warren Togami
warren at togami.com
More information about the fedora-devel-list
mailing list