Re: introduction of x-www-browser virtual package
On Fri, Jan 11, 2019 at 07:01:59PM +, Simon McVittie wrote: To facilitate that, I'd say the definition of that virtual package should include a desktop file with at least text/html, x-scheme-handler/http and x-scheme-handler/https in its MimeType list (I think that's what makes it eligible to be chosen as a per-user preferred web browser), and not just participation in the x-www-browser alternative. Yes that's a good idea. You may be interested in something else I'm (slowly) working on: I would like to encode such requirements of virtual packages. The first step was to rewrite the virtual package list in a structured format, which is now done. I hope to extend the schema to support things like "(should|must|etc) implement alternative /path". The next step would be to write things like lintian tests, UDD queries etc to use that information. And the step after that would be collecting other useful properties, such as these that you describe, that could be useful encoded. If the depending package is part of LXDE and is opening a URL, it could short-circuit the "what desktop are you?" logic and depend directly on something (anything) that implements freedesktop URL handling and has dependencies that would normally be installed by LXDE anyway. For example, if LXDE depends on GLib already, then libglib2.0-bin (for "Exec=gio open %u") would be uncontroversial. Yes. And that's a good specific suggestion for this case. I wasn't too concerned about dependency "bloat" (although the LXDE maintainers might be) so much as resolving the issue of ensuring a browser was installed. Unfortunately I don't think there's a way to express "open the preferred web browser to its default start page" as a URL to be opened. That's an interesting problem to look at. Yes, if you want to depend on "some arbitrary browser" then you need a virtual package. I wasn't making that decision myself, so much as following it through from the decision to put x-www-browser in the .desktop file. It's definitely a good idea to revisit that. However, I agree with Jeremy that "some arbitrary browser" is unlikely to be the UX anyone is actually looking for, and the browser that is preferred by the desktop environment's metapackage (which appears to be Firefox) would lead to more predictable behaviour. We're making an OS distribution here, not just a pile of packages, so it seems appropriate to make a choice, and back it up with some appropriate Recommends. If the LXDE maintainers simply specify firefox in the .desktop and Recommend on firefox-esr, it would be possible to install lxpanel without firefox (or, remove firefox later) and have a non-functioning icon on the toolbar, which is the situation I'm trying to fix now. The .desktop file currently specified Exec= but unfortunately, lxpanel displays an icon for the shortcut even if it is altered to TryExec= and the path is not satisfied. It reports "invalid desktop file lxde-x-www-browser.desktop", which could be improved. (Currently their browser dependency is in Suggests, I think bumping it to Recommends would be a small improvement) As an additional data-point, I'm not sure if lxpanel is maintained upstream any more. https://git.lxde.org/gitweb/ shows a repository for the Debian packaging (last modified nearly 2 years ago; and the version of lxpanel in sid is the same as in stretch) but no upstream repository, there is an lxqt-panel repository. I was under the impression the LXDE people were moving to LXQT, but I have no idea how far they've got on that transition (and whether Debian has caught up). The prospect of tweaking a package dependency to resolve this doesn't seem too bad; hacking on the program itself to alter it's behaviour around Exec=/TryExec= more awkward. For what it's worth, GNOME as packaged in Debian adjusts the default MIME type and URI scheme handler preference in /usr/share/applications/gnome-mimeapps.list to prefer firefox-esr or firefox over other browsers, and adds firefox-esr as a predefined "favourite app" in GNOME Shell using a GSettings override. In both cases, this can be overridden by user configuration. GNOME upstream would normally have used Epiphany (aka "Web", GNOME's own web browser), in both cases, but the Debian GNOME team has chosen to prefer Firefox because multi-year security support for WebKit-GTK+ and Epiphany is not feasible to do within the constraints of Debian stable release policies. That's a very sensible decision for GNOME-in-Debian. I think it would be wise of all the DEs in Debian (with possibly the notable exception of KDE) aligned accordingly. I'll take this to pkg-lxde-maintain...@alioth-lists.debian.net as the next step. Thanks, -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland ⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net ⠈⠳⣄ Please do not CC me, I am subscribed to the list.
Re: introduction of x-www-browser virtual package
On Fri, 11 Jan 2019 at 15:23:11 +, Jonathan Dowland wrote: > Right now we have at least one package (one of the lxde* ones) shipping > a .desktop file that references x-www-browser but does not guarantee > that x-www-browser exists; this can be resolved via a virtual package. > > I agree that it might be better if the .desktop file did not reference > x-www-browser (which is a system-wide preference) and instead used a > tool that respected a user-wide preference. To facilitate that, I'd say the definition of that virtual package should include a desktop file with at least text/html, x-scheme-handler/http and x-scheme-handler/https in its MimeType list (I think that's what makes it eligible to be chosen as a per-user preferred web browser), and not just participation in the x-www-browser alternative. > If that package instead used xdg-open, it would need to depend upon > xdg-utils and whatever transitive dependencies that implied If the depending package is part of LXDE and is opening a URL, it could short-circuit the "what desktop are you?" logic and depend directly on something (anything) that implements freedesktop URL handling and has dependencies that would normally be installed by LXDE anyway. For example, if LXDE depends on GLib already, then libglib2.0-bin (for "Exec=gio open %u") would be uncontroversial. Unfortunately I don't think there's a way to express "open the preferred web browser to its default start page" as a URL to be opened. > and I'm > not sure the result would necessarily guarantee that a GUI web browser > was installed either, so the bug ultimately would not be fixed: we still > need a means to guarantee a GUI web browser is installed, and > x-www-browser is the only scheme I can think of right now. Yes, if you want to depend on "some arbitrary browser" then you need a virtual package. However, I agree with Jeremy that "some arbitrary browser" is unlikely to be the UX anyone is actually looking for, and the browser that is preferred by the desktop environment's metapackage (which appears to be Firefox) would lead to more predictable behaviour. We're making an OS distribution here, not just a pile of packages, so it seems appropriate to make a choice, and back it up with some appropriate Recommends. For what it's worth, GNOME as packaged in Debian adjusts the default MIME type and URI scheme handler preference in /usr/share/applications/gnome-mimeapps.list to prefer firefox-esr or firefox over other browsers, and adds firefox-esr as a predefined "favourite app" in GNOME Shell using a GSettings override. In both cases, this can be overridden by user configuration. GNOME upstream would normally have used Epiphany (aka "Web", GNOME's own web browser), in both cases, but the Debian GNOME team has chosen to prefer Firefox because multi-year security support for WebKit-GTK+ and Epiphany is not feasible to do within the constraints of Debian stable release policies. smcv
Re: introduction of x-www-browser virtual package
On Fri, Jan 11, 2019 at 10:23 AM Jonathan Dowland wrote: > Right now we have at least one package (one of the lxde* ones) shipping > a .desktop file that references x-www-browser but does not guarantee > that x-www-browser exists; this can be resolved via a virtual package. https://git.lxde.org/gitweb/?p=debian/lxpanel.git;a=blob;f=debian/desktop/lxde-x-www-browser.desktop But I wonder whether that .desktop makes sense. Wouldn't users be better served by just having a Firefox ESR .desktop instead? They would know what it is and could delete it if they don't need it. LXDE doesn't ship with any tool that allows customizing what x-www-browser is, right? I don't see that LXDE .desktop as being very useful in practice. Thanks, Jeremy Bicha
Re: introduction of x-www-browser virtual package
On Wed, Jan 09, 2019 at 09:14:07AM +0900, Ansgar Burchardt wrote:
No, the alternatives system is not really useful for users (as only root
can choose an alternative). Having root choose a single
{editor,pager,browser,...} for all users is not a good solution.
Right now we have at least one package (one of the lxde* ones) shipping
a .desktop file that references x-www-browser but does not guarantee
that x-www-browser exists; this can be resolved via a virtual package.
I agree that it might be better if the .desktop file did not reference
x-www-browser (which is a system-wide preference) and instead used a
tool that respected a user-wide preference.
sensible-x-www-browser doesn't exist so we can't use that, and I'll
refrain from commenting on whether it's a good idea or not, for now.
If that package instead used xdg-open, it would need to depend upon
xdg-utils and whatever transitive dependencies that implied; and I'm
not sure the result would necessarily guarantee that a GUI web browser
was installed either, so the bug ultimately would not be fixed: we still
need a means to guarantee a GUI web browser is installed, and
x-www-browser is the only scheme I can think of right now.
Before I file the bugs to create the vpackage, I plan to perform one
further investigation: if the .desktop file used TryExec instead of
Exec, would the LXDE panel display the corresponding button/icon if
the TryExec is not satisfied?
(the x-www-browser vpackage dependency would not proclude also modifying
the .desktop file to use xdg-open)
--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄ Please do not CC me, I am subscribed to the list.
Re: introduction of x-www-browser virtual package
Paul Wise writes:
> On Tue, 2019-01-08 at 13:20 +0100, Bastien ROUCARIES wrote:
>> I could add a sensible-x-www-browser to be more nice to our user to
>> sensible-utils
>
> We already have a x-www-browser alternative, so sensible-x-www-browser
> would just duplicate that and is thus not needed.
No, the alternatives system is not really useful for users (as only root
can choose an alternative). Having root choose a single
{editor,pager,browser,...} for all users is not a good solution.
Ansgar
Re: introduction of x-www-browser virtual package
On Tue, 2019-01-08 at 13:20 +0100, Bastien ROUCARIES wrote: > I could add a sensible-x-www-browser to be more nice to our user to > sensible-utils We already have a x-www-browser alternative, so sensible-x-www-browser would just duplicate that and is thus not needed. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: introduction of x-www-browser virtual package
On Tue, Jan 8, 2019 at 11:46 AM Adam Borowski wrote: > On Tue, Jan 08, 2019 at 02:19:13PM +, Simon McVittie wrote: > > Please use xdg-open instead of reinventing it. Unlike the alternatives > > system, xdg-open respects the per-user configuration written by our > > default GNOME desktop (and hopefully other desktop environments), > > Which raises a question: why does GNOME reinvent this system? Because sensible-utils is not cross-distro. (unless I misunderstood your question) Thanks, Jeremy Bicha
Re: introduction of x-www-browser virtual package
On Tue, Jan 08, 2019 at 02:19:13PM +, Simon McVittie wrote:
> On Tue, 08 Jan 2019 at 13:20:14 +0100, Bastien ROUCARIES wrote:
> > I could add a sensible-x-www-browser to be more nice to our user to
> > sensible-utils
>
> Please use xdg-open instead of reinventing it. Unlike the alternatives
> system, xdg-open respects the per-user configuration written by our
> default GNOME desktop (and hopefully other desktop environments),
Which raises a question: why does GNOME reinvent this system?
> which
> should be a good way to avoid users getting unexpected behaviour ("I
> configured Firefox to be my default browser, why do I get Chromium?" or
> similar). Unlike the use of $BROWSER in sensible-browser, it doesn't
> require setting an environment variable, which only relatively
> Unix-literate users are going to be able to do.
sensible-utils nicely ask the user on the first try, instead of starting
wine's notepad.exe for text files, or gimp for PostScript.
Meow!
--
⢀⣴⠾⠻⢶⣦⠀ Hans 1 was born and raised in Johannesburg, then moved to Boston,
⣾⠁⢠⠒⠀⣿⡁ and has just became a naturalized citizen. Hans 2's grandparents
⢿⡄⠘⠷⠚⠋⠀ came from Melanesia to Düsseldorf, and he hasn't ever been outside
⠈⠳⣄ Germany until yesterday. Which one is an African-American?
Re: introduction of x-www-browser virtual package
On Tue, 08 Jan 2019 at 13:20:14 +0100, Bastien ROUCARIES wrote:
> I could add a sensible-x-www-browser to be more nice to our user to
> sensible-utils
Please use xdg-open instead of reinventing it. Unlike the alternatives
system, xdg-open respects the per-user configuration written by our
default GNOME desktop (and hopefully other desktop environments), which
should be a good way to avoid users getting unexpected behaviour ("I
configured Firefox to be my default browser, why do I get Chromium?" or
similar). Unlike the use of $BROWSER in sensible-browser, it doesn't
require setting an environment variable, which only relatively
Unix-literate users are going to be able to do. Unlike sensible-browser,
it's non-Debian-specific and can be recommended to upstream developers
without having to say "... but this only works on Debian".
In a GNOME environment, xdg-open uses `gio open`, which uses the
configured freedesktop.org default handler for the x-scheme-handler/http
or x-scheme-handler/https pseudo-MIME-types. Those default handlers in
~/.config/mimeapps.list are what GNOME sets when you change the default
web browser, and also what Firefox sets when you tell it to make itself
the default. None of this is GNOME-specific or Debian-specific (`gio`
is a GLib tool, so it's more closely related to GNOME-derived desktop
environments, but it's looking at a cross-desktop source of
configuration), so I would hope that any/all desktop environments can
implement it.
In a "generic" environment, xdg-open seems to reimplement essentially
the same logic that GLib uses, including the x-scheme-handler/foo
pseudo-MIME-types.
In non-GNOME environments that it recognises (KDE, DDE, MATE, Xfce, etc.)
I don't know the specifics of what xdg-open does, but if they're wrong,
that's a bug in xdg-open or the tools/libraries that it uses, and should
be fixed.
smcv
Re: introduction of x-www-browser virtual package
On Tue, Jan 8, 2019 at 6:49 AM Paul Wise wrote: > > On Mon, Jan 7, 2019 at 8:03 PM Jonathan Dowland wrote: > > > I thought I'd post here to see if anyone had any information first. > > I noticed that this idea came up in 2010 and 2014 so I think we never > had x-www-browser, only www-browser. I could add a sensible-x-www-browser to be more nice to our user to sensible-utils > > https://lists.debian.org/20141117130332.ga9...@free.fr > https://lists.debian.org/4b432943.3080...@leat.rub.de > > -- > bye, > pabs > > https://wiki.debian.org/PaulWise >
Re: introduction of x-www-browser virtual package
On Mon, Jan 7, 2019 at 8:03 PM Jonathan Dowland wrote: > I thought I'd post here to see if anyone had any information first. I noticed that this idea came up in 2010 and 2014 so I think we never had x-www-browser, only www-browser. https://lists.debian.org/20141117130332.ga9...@free.fr https://lists.debian.org/4b432943.3080...@leat.rub.de -- bye, pabs https://wiki.debian.org/PaulWise
