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@togami.com
Warren Togami wrote: 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.
Well, since you are at this, as far as I know every single browser on the market (be it IE, Opera, Mozilla, Galeon, Konqueror) is configured by default or can be configured to zoom the text with ctrl+mouse-wheel. Which might seem useless for laptop users but is crucial for normal desktops, since about every single mouse sold nowadays has a wheel (or more).
Of course, there had to be an exception and in this case the exception is Epiphany (single reason why I could never stand it btw) - which is kind of strange since this is one control that would not clutter the GUI and infringe on the HIG. Therefore I propose : - that Epy be fixed to conform to the de-facto zooming standard - that ctrl+wheel be used as alternate zooming control in all apps that need one (preferably keeping the same direction as + :)
Another good thing would be to standardise the actions of the fourth and fifth buttons one can find on some mice (not counting the wheel), but right now they are still in the minority and no common usage has emerged yet I think
Cheers,
On December 24, 2003 07:21, Warren Togami wrote:
- 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.
Konqueror key bindings have been modified recently (ie. in the last week or so) for reasons similar to your own. Discussion has taken place on the kde-usability mailing list, so you should search the archives (http://lists.kde.org/?l=kde-usability&r=1&w=2).
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.
Some "unification" keybindings were decided against, because they were in fact disrupting the unification of KDE as a whole. For eaxmple, CTRL-wheel was proposed as a zoom control, like many other browsers do. But this was rejected because in every Qt app, CTRL-wheel works like page up/page down.
The point is: you might be tempted to unify Konqueror with other browsers, but don't forget that you will probably be breaking unification within KDE. So your best bet is to CC: every change to kde-usability@mail.kde.org, especially if the KDE community has any worth to you.
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.
This is a good policy. Check the current 3.2 configuration, I think has what you want. If not, tell me what you need and I'll get kde-usability to discuss it.
Simon Perreault wrote:
Some "unification" keybindings were decided against, because they were in fact disrupting the unification of KDE as a whole. For eaxmple, CTRL-wheel was proposed as a zoom control, like many other browsers do. But this was rejected because in every Qt app, CTRL-wheel works like page up/page down.
This seems like broken logic to me, IMHO because by definition browsers are different from all other applications, and users expect a browser to behave in a similar way from what they are used to. The argument of "unification within KDE" seems to me like a continuance of the divide between the two camps, which only hurts us.
Not nearly as bad as the arts vs. esd problem though.
Anyhow, I didn't expect that KDE would accept all of our unification ideas, but only the less controversial ones that don't conflict. I am unwilling to fight the emotional & political battles.
The point is: you might be tempted to unify Konqueror with other browsers, but don't forget that you will probably be breaking unification within KDE. So your best bet is to CC: every change to kde-usability@mail.kde.org, especially if the KDE community has any worth to you.
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.
This is a good policy. Check the current 3.2 configuration, I think has what you want. If not, tell me what you need and I'll get kde-usability to discuss it.
I would please ask that you check this yourself, as I have far too many other things to work on. Please report back your findings.
Warren
On December 24, 2003 15:56, Warren Togami wrote:
I would please ask that you check this yourself, as I have far too many other things to work on. Please report back your findings.
I just committed my patch to CVS. Konqueror 3.2 will have CTRL-+ and CTRL-- as zoom accels.
Simon Perreault wrote:
On December 24, 2003 15:56, Warren Togami wrote:
I would please ask that you check this yourself, as I have far too many other things to work on. Please report back your findings.
I just committed my patch to CVS. Konqueror 3.2 will have CTRL-+ and CTRL-- as zoom accels.
Thank you. =)
What is the current function of CTRL-W?
Warren
On December 30, 2003 17:31, Warren Togami wrote:
What is the current function of CTRL-W?
It closes the current tab. If there is only one tab left, does nothing.
On December 24, 2003 15:56, Warren Togami wrote:
I would please ask that you check this yourself, as I have far too many other things to work on. Please report back your findings.
I just committed my patch to CVS. Konqueror 3.2 will have CTRL-+ and CTRL-- as zoom accels.
-- Simon Perreault nomis80@nomis80.org -- http://nomis80.org
Using kdebase-3.2.0-0.4 (based on KDE 3.2.0 and qt 3.3.0), CTRL+- works in shrinking the font, but CTRL++ appears to not work at first glance like Mozilla. However the actual problem is that it literally is set to CTRL++, and CTRL+= does not work, so the user must hit CTRL-Shift-= which is not what is expected.
Would it be possible to set Konqueror's default to work with CTRL+= as well as CTRL++ like Mozilla's default?
Warren Togami wtogami@redhat.com
On February 19, 2004 5:37, Warren Togami wrote:
Using kdebase-3.2.0-0.4 (based on KDE 3.2.0 and qt 3.3.0), CTRL+- works in shrinking the font, but CTRL++ appears to not work at first glance like Mozilla. However the actual problem is that it literally is set to CTRL++, and CTRL+= does not work, so the user must hit CTRL-Shift-= which is not what is expected.
Yes, this is a known problem. If I enabled the CTRL+= shortcut, then the numeric keypad + would not work. We could not quickly find a fix and so we settled for the know-stable way.
I filed #75627 which you can view at http://bugs.kde.org/show_bug.cgi?id=75627.
On December 24, 2003 07:21, Warren Togami wrote:
- 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.
Konqueror key bindings have been modified recently (ie. in the last week or so) for reasons similar to your own. Discussion has taken place on the kde-usability mailing list, so you should search the archives (http://lists.kde.org/?l=kde-usability&r=1&w=2).
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.
Some "unification" keybindings were decided against, because they were in fact disrupting the unification of KDE as a whole. For eaxmple, CTRL-wheel was proposed as a zoom control, like many other browsers do. But this was rejected because in every Qt app, CTRL-wheel works like page up/page down.
The point is: you might be tempted to unify Konqueror with other browsers, but don't forget that you will probably be breaking unification within KDE. So your best bet is to CC: every change to kde-usability@mail.kde.org, especially if the KDE community has any worth to you.
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.
This is a good policy. Check the current 3.2 configuration, I think has what you want. If not, tell me what you need and I'll get kde-usability to discuss it.
Please review and discuss these proposed changes upstream and report back. If they reject a certain change, it would help if you can get reasons.
Font Bigger CTRL+= Shortcut (proposed) CTRL=+ Alternate (proposed) This simple change would make it behave exactly like Mozilla's defaults.
Clear Location Bar Ctrl+L Shortcut (proposed) Simple addition makes it behave very similar to Mozilla.
Full Screen Mode Ctrl+Shift+F Shortcut F11 Alternate (proposed) Simple addition makes it behave like Mozilla and Internet Explorer while retaining the previous shortcut.
Activate Next Tab Ctrl+. Shortcut Ctrl+] Alternate Ctrl+PageDown (proposed) Add Mozilla's binding if possible as another alternate, or replacing the less popular of the two current methods. Which is the less popular of the two? The PageUp and PageDown seems to be a standard for changing between tabs across many GNOME apps. Is there a KDE equivalent standardized?
Activate Previous Tab Ctrl+ Shortcut Ctrl+[ Alternate Ctrl+PageUp (proposed) Add Mozilla's binding if possible as another alternate, or replacing the less popular of the two current methods. Which is the less popular of the two? The PageUp and PageDown seems to be a standard for changing between tabs across many GNOME apps. Is there a KDE equivalent standardized?
New Tab Ctrl+Shift+N Shortcut Ctrl+T Alternate (proposed) Open Terminal currently uses Ctrl+T. This may be a controversial change for this reason. The Ctrl+T function of Mozilla is heavily used. If KDE does not accept this change upstream, I may personally lobby for it for Fedora defaults anyway. Open Terminal would then need a different default shortcut.
Warren Togami wtogami@redhat.com
On February 19, 2004 6:17, Warren Togami wrote:
Font Bigger CTRL+= Shortcut (proposed) CTRL=+ Alternate (proposed) This simple change would make it behave exactly like Mozilla's defaults.
Everyone agrees that this should be done. I will investigate methods to do it.
Clear Location Bar Ctrl+L Shortcut (proposed) Simple addition makes it behave very similar to Mozilla.
In KDE 3.1, that shortcut was present.
Full Screen Mode Ctrl+Shift+F Shortcut F11 Alternate (proposed) Simple addition makes it behave like Mozilla and Internet Explorer while retaining the previous shortcut.
I'm fully in favor of this.
Activate Next Tab Ctrl+. Shortcut Ctrl+] Alternate Ctrl+PageDown (proposed) Add Mozilla's binding if possible as another alternate, or replacing the less popular of the two current methods. Which is the less popular of the two? The PageUp and PageDown seems to be a standard for changing between tabs across many GNOME apps. Is there a KDE equivalent standardized?
The standard KDE shortcut for next tab is CTRL+], but I couldn't find it written anywhere. CTRL+. was added for people with non-us keyboards who have to press a second modifier key to reach the ]. We could add a third shortcut, so there's no need to remove one of the other two.
There is another problem though: CTRL+PageDown is already defined as a standard KDE-wide shortcut. See http://developer.kde.org/documentation/standards/kde/style/keys/cursorKeys.h.... It is used to go down one logical screen, ie. go to the next page. I can imagine this being used in paged media like PDF documents, but on a website it has no meaning.
I will propose this key in addition to the other two. Since it is not used, and will not be used as defined in the standard, I think we can make an exception.
Activate Previous Tab Ctrl+ Shortcut Ctrl+[ Alternate Ctrl+PageUp (proposed) Add Mozilla's binding if possible as another alternate, or replacing the less popular of the two current methods. Which is the less popular of the two? The PageUp and PageDown seems to be a standard for changing between tabs across many GNOME apps. Is there a KDE equivalent standardized?
Same as above.
New Tab Ctrl+Shift+N Shortcut Ctrl+T Alternate (proposed) Open Terminal currently uses Ctrl+T. This may be a controversial change for this reason. The Ctrl+T function of Mozilla is heavily used. If KDE does not accept this change upstream, I may personally lobby for it for Fedora defaults anyway. Open Terminal would then need a different default shortcut.
This has been discussed on kde-usability and is associated with bug #59794, which can be viewed at http://bugs.kde.org/show_bug.cgi?id=59794. There seems to be more people for than against. I will propose a patch that closes this bug.
To be continued...
Simon Perreault wrote:
Font Bigger CTRL+= Shortcut (proposed) CTRL=+ Alternate (proposed) This simple change would make it behave exactly like Mozilla's defaults.
Everyone agrees that this should be done. I will investigate methods to do it.
Committed to CVS.
Clear Location Bar Ctrl+L Shortcut (proposed) Simple addition makes it behave very similar to Mozilla.
In KDE 3.1, that shortcut was present.
Committed to CVS.
Full Screen Mode Ctrl+Shift+F Shortcut F11 Alternate (proposed) Simple addition makes it behave like Mozilla and Internet Explorer while retaining the previous shortcut.
I'm fully in favor of this.
Committed to CVS.
Activate Next Tab Ctrl+. Shortcut Ctrl+] Alternate Ctrl+PageDown (proposed)
There is no way to add a third shortcut. One of the others has to go. But they are both KDE-wide standards. This will require a bit more work and discussion, which I will get to in may, when school's over.
New Tab Ctrl+Shift+N Shortcut Ctrl+T Alternate (proposed)
Committed to CVS, and to much acclaim backported to 3.2.1 branch. Should be available in the 3.2.1 release.
Upstream KDE rules. ;)
Simon Perreault wrote:
Simon Perreault wrote:
Font Bigger CTRL+= Shortcut (proposed) CTRL=+ Alternate (proposed) This simple change would make it behave exactly like Mozilla's defaults.
Everyone agrees that this should be done. I will investigate methods to do it.
Committed to CVS.
Clear Location Bar Ctrl+L Shortcut (proposed) Simple addition makes it behave very similar to Mozilla.
In KDE 3.1, that shortcut was present.
Committed to CVS.
Full Screen Mode Ctrl+Shift+F Shortcut F11 Alternate (proposed) Simple addition makes it behave like Mozilla and Internet Explorer while retaining the previous shortcut.
I'm fully in favor of this.
Committed to CVS.
Activate Next Tab Ctrl+. Shortcut Ctrl+] Alternate Ctrl+PageDown (proposed)
There is no way to add a third shortcut. One of the others has to go. But they are both KDE-wide standards. This will require a bit more work and discussion, which I will get to in may, when school's over.
Is KDE open to adding the option for more than one alternate key combination, or are there other ideas in mind?
New Tab Ctrl+Shift+N Shortcut Ctrl+T Alternate (proposed)
Committed to CVS, and to much acclaim backported to 3.2.1 branch. Should be available in the 3.2.1 release.
Upstream KDE rules. ;)
Thank you Simon for the followup!
It appears that than just upgraded the FC2 KDE to 3.2.1. Can you supply precise patches for us for these CVS keybinding changes that were not backported to KDE 3.2.1, so that we may ship them as default with FC2? Please Bugzilla those patches against the appropriate component and CC me.
Warren Togami wtogami@redhat.com
Warren Togami wrote:
Thank you Simon for the followup!
It appears that than just upgraded the FC2 KDE to 3.2.1. Can you supply precise patches for us for these CVS keybinding changes that were not backported to KDE 3.2.1, so that we may ship them as default with FC2? Please Bugzilla those patches against the appropriate component and CC me.
Warren Togami wtogami@redhat.com
Simon is probably busy right now... so can perhaps someone else extract the exact patches? I would really like this to go in before the freeze too.
Warren
Hi,
Couple high level points:
- consider posting this sort of thing to fedora-desktop-list in future - jrb is currently redoing the MIME UI using a freedesktop.org backend; don't know if this also covers "preferred applications" but it probably should
On Wed, 2003-12-24 at 07:21, Warren Togami wrote:
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...
need_terminal is kind of a relic from the days when something like links would appear in the desktop menus....
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.
Rather than this, we might find some way to simply use the .desktop files the apps already install; I don't know if the fd.org mime spec does this or not. Though I do have some misgivings about overloading .desktop files for more than just menu entries.
- This brings up the larger question of the need for desktop agnostic
configuration for Preferred Applications as KDE does not use gconf.
I think the eventual goal needs to be to unify on a config system such as gconf; dbus may enable this. We should not be too gung-ho about creating zillions of little ad hoc systems in the meantime. However, we may already be doing something ad hoc with MIME.
- 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...
htmlview should simply be deleted, as far as I'm concerned. It's a broken stupid approach that doesn't scale to more preferred applications than just the one.
If we need command line access to preferred apps, something more general like "preferred-open html arg1 arg2 arg3" perhaps. In fact there may already be a gnome-vfs-open.
- 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.
Search old bugzilla; this was already tried (web browser icon launched htmlview) and it breaks. One of the reasons is that you don't know the value for some of the .desktop file keys, such as StartupNotify, for htmlview.
- 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...
This seems pretty unrelated ;-) but yes, annoying.
- 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.
This sort of little thing is why I am pushing to use native widgets for all the major apps.
Windows-like behavior, and there is the option to change all keybindings to be Unix-like globally (where is this setting?).
In .gtkrc-2.0 do gtk-key-theme = emacs.
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?
It's clearly/obviously sane, but hard to do on the distribution level. It sort of needs to be done upstream. It's much much simpler if we just use native widgets apps.
developer.gnome.org has some big keybindings tables maintained by Calum Benson.
Havoc
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?
It's clearly/obviously sane, but hard to do on the distribution level. It sort of needs to be done upstream. It's much much simpler if we just use native widgets apps.
developer.gnome.org has some big keybindings tables maintained by Calum Benson.
This sounds like a candidate for a freedesktop.org standard/recommendation (if it isn't already).
One application that really annoys me with the non standard key bindings is Gnome Terminal with the Ctr+Shift+[xcv] options altough I can see why they're like this due to the app running in the term session possibly using the ctrl+ options.
:Peter
Havoc Pennington hp@redhat.com writes:
Hi,
Couple high level points:
- consider posting this sort of thing to fedora-desktop-list in future
- jrb is currently redoing the MIME UI using a freedesktop.org backend; don't know if this also covers "preferred applications" but it probably should
We've gone back and forth on this on the GNOME/freedesktop lists, and the consensus is that things like preferred applications really isn't part of the MIME system.
On Wed, 2003-12-24 at 07:21, Warren Togami wrote:
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...
need_terminal is kind of a relic from the days when something like links would appear in the desktop menus....
We should still support it.
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.
Rather than this, we might find some way to simply use the .desktop files the apps already install; I don't know if the fd.org mime spec does this or not. Though I do have some misgivings about overloading .desktop files for more than just menu entries.
.desktop files are very overloaded anyway. What's another use or two. But generating the list of terminals/web browsers/mail clients by querying the desktop files makes some sense to me.
If we need command line access to preferred apps, something more general like "preferred-open html arg1 arg2 arg3" perhaps. In fact there may already be a gnome-vfs-open.
gnome-vfs-open is a little bit different -- it won't work for terminals/mail clients. A preferred-open app makes a little more sense.
Windows-like behavior, and there is the option to change all keybindings to be Unix-like globally (where is this setting?).
In .gtkrc-2.0 do gtk-key-theme = emacs.
Actually, it's cleaner to change your "Text editting shortcuts" in the Keyboard Shortcuts dialog. This is GTK+ specific, though.
Thanks, -Jonathan
On Wed, 2003-12-31 at 02:01, Jonathan Blandford wrote:
Havoc Pennington hp@redhat.com writes:
Hi,
Couple high level points:
- consider posting this sort of thing to fedora-desktop-list in future
- jrb is currently redoing the MIME UI using a freedesktop.org backend; don't know if this also covers "preferred applications" but it probably should
We've gone back and forth on this on the GNOME/freedesktop lists, and the consensus is that things like preferred applications really isn't part of the MIME system.
A while ago, I brought up the idea of extending alternatives to have a per-user interface as well as a system-wide interface. That was shot down because alternatives is somewhat inelegant. At that time, people suggested that in the long term term, MIME types could replace alternatives.
Sounds like this is no longer true, but I would just like to bring up the original point that it would be nice if the mechanism for a user's preferred application had some relation to the system default as well.
For example, as an administrator, I may install galeon, epiphany, mozilla, and firebird, but then tell my users they are free to choose, but I will only support firebird. So I would like as an administrator that I can specify a default for 'browser', and my users can choose to depart from that.
Further, I would expect some relation between the mechanism for changing the system default and a user's personal default. Much the way we have /etc/profile and ~/.profile today. If work is being done to reimplement preferred applications, I for one would appreciate it if this relation to system-wide applications could be kept in mind.
On Wed, Dec 31, 2003 at 08:48:18AM -0500, Karl DeBisschop wrote:
So I would like as an administrator that I can specify a default for 'browser', and my users can choose to depart from that.
GConf (where the GNOME preferred app settings are stored) already supports this. You can even set a mandatory value. Mirek
Miloslav Trmac wrote:
On Wed, Dec 31, 2003 at 08:48:18AM -0500, Karl DeBisschop wrote:
So I would like as an administrator that I can specify a default for 'browser', and my users can choose to depart from that.
GConf (where the GNOME preferred app settings are stored) already supports this. You can even set a mandatory value.
I suppose that is true of the gconf schema, however very few things currently pay any attention to gconf. It also doesn't help that there are two redundant places in the schema where the browser can be defined.
Warren
On Wed, Dec 31, 2003 at 02:01:26AM -0500, Jonathan Blandford wrote:
.desktop files are very overloaded anyway. What's another use or two. But generating the list of terminals/web browsers/mail clients by querying the desktop files makes some sense to me.
Ideally you want to tie it into the network back end too
Select your preferred web browser
<> Mozilla [ SOme kind of info on choice] <> Konqueror
<> Look for other browsers to download
In .gtkrc-2.0 do gtk-key-theme = emacs.
Actually, it's cleaner to change your "Text editting shortcuts" in the Keyboard Shortcuts dialog. This is GTK+ specific, though.
Its a bit worse than that. Its "gtk+ except apps which take over and don't do the right thing" - Epiphany for example at least had that disease on its URL bar
On Wed, 2003-12-31 at 02:01, Jonathan Blandford wrote:
We've gone back and forth on this on the GNOME/freedesktop lists, and the consensus is that things like preferred applications really isn't part of the MIME system.
In deciding that, did you come to some decision on how preferred applications should be done?
If you have an HTML file, do you use the text/html association or the preferred web browser? If changing my preferred web browser, does the text/html association also get updated?
Havoc
[ I somehow got trimmed from the CC line and I missed this message. ]
Havoc Pennington hp@redhat.com writes:
On Wed, 2003-12-31 at 02:01, Jonathan Blandford wrote:
We've gone back and forth on this on the GNOME/freedesktop lists, and the consensus is that things like preferred applications really isn't part of the MIME system.
In deciding that, did you come to some decision on how preferred applications should be done?
For the short term, just keys in GConf in GNOME. I don't think we really have any big master plan here.
If you have an HTML file, do you use the text/html association or the preferred web browser? If changing my preferred web browser, does the text/html association also get updated?
No. The two are handled separately and are subtly different. A web-browser is more of a 'protocol' viewer than a file-type viewer. Changing the default text/html handler to an HTML editor is a reasonable task, and shouldn't change my web browser.
Thanks, -Jonathan
-
Alan Cox -
Havoc Pennington -
Jonathan Blandford -
Karl DeBisschop -
Miloslav Trmač -
Nicolas Mailhot -
Peter Robinson -
Simon Perreault -
Warren Togami