Giuseppe Bilotta [off-list ref] writes:
Debian and derivatives have an alternatives-based default browser
configuration that uses the /usr/bin/gnome-www-browser,
/usr/bin/x-www-browser and /usr/bin/www-browser symlinks.
When no browser is selected by the user and the Debian alternatives are
available, try to see if they are one of our recognized selection and
in the affermative case use it. Otherwise, warn the user about them
being unsupported and move on with the previous detection logic.
A "please step back a bit" question. Does the packaging guideline of
Debian say that non-browser applications should take these links as "end
user preference" when opening HTML pages?
The behaviour of unconfigured git across platforms would become less
consistent if we do this, while the behaviour of random programs on one
particular platform (Debian) would become more consistent.
I am not saying that is necessarily a bad thing. I just want to
understand the motivation.
+# check if a given executable is a browser we like
+valid_exe() {
Call it valid_browser_executable or something, please.
+ testexe="$1"
+ basename=$(basename $(readlink -f "$testexe"))
Are we saying "readlink" must exist on the system? This dependency is
new, I think.
On Fri, Dec 3, 2010 at 11:15 PM, Junio C Hamano [off-list ref] wrote:
Giuseppe Bilotta [off-list ref] writes:
quoted
Debian and derivatives have an alternatives-based default browser
configuration that uses the /usr/bin/gnome-www-browser,
/usr/bin/x-www-browser and /usr/bin/www-browser symlinks.
When no browser is selected by the user and the Debian alternatives are
available, try to see if they are one of our recognized selection and
in the affermative case use it. Otherwise, warn the user about them
being unsupported and move on with the previous detection logic.
A "please step back a bit" question. Does the packaging guideline of
Debian say that non-browser applications should take these links as "end
user preference" when opening HTML pages?
I'm not sure this is an actual guideline, and I cannot find much
specific information about it online. It _is_ the recommended way to
set the default browser in Debian (plus the BROWSER override), but
there are quite a few applications that don't actually follow it. (And
FWIW, as a Debian user I find this annoying, e.g. when clicking on a
link and having konqueror or iceweasel pop up instead of my preferred
x-www-browser, that happens to be Opera.)
I do believe that Debian encourages the use of sensible-browser (that
does the BROWSER and *www-browser check itself) rather than manually
going to look at those specifications. But that means giving up the
"do anything we can to open stuff in a new tab" that is among the
specified purposes of git-web--browse.
The behaviour of unconfigured git across platforms would become less
consistent if we do this, while the behaviour of random programs on one
particular platform (Debian) would become more consistent.
That's actually the reason why I wasn't so sure it would be
appropriate for inclusion.
I am not saying that is necessarily a bad thing. I just want to
understand the motivation.
The motivation is that, lacking an explicit override, I believe git
web--browse should try and get the information about the preferred
browser from wherever it can. In a way, the *www-browser testing is
akin to the use of start in Windows or open under Mac OS X.
Of course, as I only use Debian, I am not aware of what other
distributions do (if they do anything at all) to allow a user to
specify a preferred browser.
An alternative approach would be to get rid of the *www-browser and
BROWSER patches, and just use xdg-open if it's available. Which again
raises the issue of how to enforce opening the page in a new tab.
quoted
+# check if a given executable is a browser we like
+valid_exe() {
Call it valid_browser_executable or something, please.
Of course.
quoted
+ testexe="$1"
+ basename=$(basename $(readlink -f "$testexe"))
Are we saying "readlink" must exist on the system? This dependency is
new, I think.
The only other use I found of readlink is in a specific area of
t/test-lib.sh, so this seems like a new requirement indeed. I can
either wrap that part in a type readlink check, or I can get rid of
that specific section of the test, and just leave the --version check,
bringing the code back to the previous patch version.
--
Giuseppe "Oblomov" Bilotta
Giuseppe Bilotta wrote:
I do believe that Debian encourages the use of sensible-browser (that
does the BROWSER and *www-browser check itself) rather than manually
going to look at those specifications.
My impression (by analogy with policy §11.4 "Editors and pagers") is
that one is encouraged to make the default configurable at compile
time and use
- first $BROWSER
- then something desktop-specific
- then the configured default
and set that default to www-browser or x-www-browser, depending on
whether your program uses X. That way, non-Debian systems benefit
from the changes you introduce, too.
An alternative approach would be to get rid of the *www-browser and
BROWSER patches, and just use xdg-open if it's available. Which again
raises the issue of how to enforce opening the page in a new tab.
Yes, in this case that is the ideal (assuming xdg-utils has wide
enough adoption).
I think xdg-open has just as much a reason as we do to encourage
opening the page in a new tab. Would it be hard to make that happen?
On Sat, Dec 4, 2010 at 1:42 AM, Jonathan Nieder [off-list ref] wrote:
Giuseppe Bilotta wrote:
quoted
I do believe that Debian encourages the use of sensible-browser (that
does the BROWSER and *www-browser check itself) rather than manually
going to look at those specifications.
My impression (by analogy with policy §11.4 "Editors and pagers") is
that one is encouraged to make the default configurable at compile
time and use
- first $BROWSER
- then something desktop-specific
- then the configured default
and set that default to www-browser or x-www-browser, depending on
whether your program uses X. That way, non-Debian systems benefit
from the changes you introduce, too.
I'm not entirely sure how non-Debian would benefit from the change at
the current state, but I'm willing to present patches for the
mechanism offered by other distributions (e.g. does anybody know how
RedHad/Fedora sets the preferred browser?)
quoted
An alternative approach would be to get rid of the *www-browser and
BROWSER patches, and just use xdg-open if it's available. Which again
raises the issue of how to enforce opening the page in a new tab.
Yes, in this case that is the ideal (assuming xdg-utils has wide
enough adoption).
I think xdg-open has just as much a reason as we do to encourage
opening the page in a new tab. Would it be hard to make that happen?
I have no idea. Also, it's sort-of outside the scope of our reach, and
we would have to wait for a change in that effect to 'trickle down'.
--
Giuseppe "Oblomov" Bilotta