git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org,
	Christian Couder <christian.couder@gmail.com>,
	Jonathan Nieder <jrnieder@gmail.com>
Subject: Re: [PATCHv2 6/7] web--browse: use (x-)www-browser if available
Date: Fri, 3 Dec 2010 23:45:22 +0100	[thread overview]
Message-ID: <AANLkTinWD53M2VjiWgeA0Qwx3OHzR2A09Y+AB2B9o1df@mail.gmail.com> (raw)
In-Reply-To: <7vaakmmrkj.fsf@alter.siamese.dyndns.org>

On Fri, Dec 3, 2010 at 11:15 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Giuseppe Bilotta <giuseppe.bilotta@gmail.com> 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?

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.

>> +# check if a given executable is a browser we like
>> +valid_exe() {
>
> Call it valid_browser_executable or something, please.

Of course.

>> +     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

  reply	other threads:[~2010-12-03 22:45 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-12-03 16:47 [PATCHv2 0/7] web--browse cleanup and extensions Giuseppe Bilotta
2010-12-03 16:47 ` [PATCHv2 1/7] CodingGuidelines: mention whitespace preferences for shell scripts Giuseppe Bilotta
2010-12-03 21:43   ` Junio C Hamano
2010-12-03 22:02     ` Giuseppe Bilotta
2010-12-03 22:28       ` Junio C Hamano
2010-12-03 22:46         ` Giuseppe Bilotta
2010-12-03 16:47 ` [PATCHv2 2/7] web--browse: coding style Giuseppe Bilotta
2010-12-07 23:38   ` Junio C Hamano
2010-12-03 16:47 ` [PATCHv2 3/7] web--browse: split valid_tool list Giuseppe Bilotta
2010-12-03 16:47 ` [PATCHv2 4/7] web--browse: support opera, seamonkey and elinks Giuseppe Bilotta
2010-12-03 22:01   ` Junio C Hamano
2010-12-03 22:22     ` Giuseppe Bilotta
2010-12-03 16:47 ` [PATCHv2 5/7] web--browse: better support for chromium Giuseppe Bilotta
2010-12-03 21:57   ` Junio C Hamano
2010-12-03 22:25     ` Giuseppe Bilotta
2010-12-03 16:47 ` [PATCHv2 6/7] web--browse: use (x-)www-browser if available Giuseppe Bilotta
2010-12-03 17:40   ` Christian Couder
2010-12-03 17:57     ` Giuseppe Bilotta
2010-12-03 22:15   ` Junio C Hamano
2010-12-03 22:45     ` Giuseppe Bilotta [this message]
2010-12-04  0:42       ` Jonathan Nieder
2010-12-04  7:49         ` Giuseppe Bilotta
2010-12-03 16:47 ` [PATCHv2 7/7] web--browse: look at the BROWSER env var Giuseppe Bilotta
2010-12-03 17:08   ` Jonathan Nieder
2010-12-03 17:16     ` Jonathan Nieder

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=AANLkTinWD53M2VjiWgeA0Qwx3OHzR2A09Y+AB2B9o1df@mail.gmail.com \
    --to=giuseppe.bilotta@gmail.com \
    --cc=christian.couder@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=jrnieder@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).