Bug 33055 - Add xdg-browser or xdg-www
Summary: Add xdg-browser or xdg-www
Status: NEW
Alias: None
Product: Portland
Classification: Unclassified
Component: xdg-utils (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: Portland Bugs
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-01-13 04:40 UTC by Vincent Untz
Modified: 2014-05-15 17:56 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Attachments
xdg-browser script (11.44 KB, text/plain)
2011-06-17 05:42 UTC, Fatih Arslan
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Vincent Untz 2011-01-13 04:40:56 UTC
It was pointed out that it's sometimes needed to just start the browser, without an URL. So xdg-open cannot be used for that.

Mandriva had a script for this: http://svn.mandriva.com/cgi-bin/viewvc.cgi/soft/desktop-common-data/trunk/bin/www-browser?revision=243941&view=markup
Comment 1 Fatih Arslan 2011-06-17 05:42:49 UTC
Created attachment 48083 [details]
xdg-browser script

I've also needed omething like xdg-browser.Thus I've just created a new script called "xdg-browser" which uses xdg-utils functions and codebase. It's acutally based on xdg-terminal, xdg-open and xdg-settings.

I've also add LXDE support. Tested on KDE, LXDE and XFCE without any problem.

I would be glad if someone could review it. If it's OK i'll can create a patch directly from the git repo. I just wanted to notice you. If we could merge this into upstream codebase, then anyone can benefit from it.
Comment 2 Rex Dieter 2011-06-17 05:46:12 UTC
Hrm... a patch against git would be more welcome, though I'm still trying to reconcile if it's worth a completely separate utility just because xdg-open currently can't open a blank browser.

What's the use-case for this?
Comment 3 Fatih Arslan 2011-06-17 06:51:40 UTC
For example some could use generic web-browser.desktop file which uses

Exec=/usr/bin/xdg-browser

That's very handy. Some distros are adding these kind of desktop entries to the panel or desktop. Thus we need something that just launches the preferred browser.

I don't know what Vincent's use-case is. Maybe he can provide more examples.
Comment 4 Rex Dieter 2011-06-17 07:02:42 UTC
That one I don't (necessarily) buy, as the same can generally be accomplished by using xdg-open on some local/default html file too (albeit, you lose the ability to display a users' "home" page that way).
Comment 5 Fatih Aşıcı 2011-06-20 06:24:44 UTC
The main problem with xdg-open is that it tries to learn mimetype of the URL. This slows down the opening of the browser. OTOH, the command "xdg-open google.com" fails as it searches for a file named "google.com". These behavioural changes are important for some applications.
Comment 6 Rex Dieter 2011-06-20 06:28:17 UTC
1.  slows down?  how much?  this should be fairly minimal.
2.  that, and "google.com" isn't exactly a valid URL either.
Comment 7 Nathan Phillip Brink (binki) 2011-06-20 06:54:30 UTC
(In reply to comment #5)
> OTOH, the command "xdg-open
> google.com" fails as it searches for a file named "google.com". These
> behavioural changes are important for some applications.

I agree with rdieter that this is intended/correct behavior. However, there's also the case of a file in the current working directory called http://google.com/ which would properly be accessed with something like file://${PWD}/http://google.com/.

What we need to know is a proper way to get a browser launched without having to specify some dummy URL. Or to be given a dummy URL which is guaranteed to at least open a web-browser. Would something like

$ xdg-open about:blank

be suitable? I.e., is about: a protocol that is recognized by xdg-open as something which a browser should deal with regardless of an about:blank file existing in the current directory or could that be added?

With xdg-utils-1.1.0_rc1_p20110519, I found the following behavior:

The following works if there is no file called `about:blank':
$ xdg-open about:blank

The following opens in my browser, but my browser's launcher script realizes that a file is being referred to and opens it as a file instead of using its internal about:blank URL handler:
$ echo test > about:blank
$ xdg-open about:blank

The following opens the about:blank file with my ${EDITOR}:
$ echo test > about:blank
$ xdg-open file://${PWD}/about:blank

Here it looks like xdg-open is somehow interpretting `about:blank' as a fully-formed URI but isn't convincing my browser to do so since my browser sees the file...
Comment 8 Rex Dieter 2011-06-20 07:02:23 UTC
I suppose we should take this onlist, bugzilla isn't really a good forum to carry on a conversation.

Last point I'd like to make here,
"What we need to know is a proper way to get a browser launched without having
to specify some dummy URL".

I'm still waiting for an answer to the question, "why, what's the use-case?"
Comment 9 Jerome Leclanche 2011-11-13 10:10:02 UTC
(In reply to comment #8)
> I'm still waiting for an answer to the question, "why, what's the use-case?"

The use case, regarding what a DE could want, is not limited to the web browser. So yes, having a separate tool for just opening a web browser is not ideal.
What needs to be implemented in freedesktop is a platform-neutral way to store and launch a set of common services, such as:
 - Web browser
 - File manager
 - IM client
 - Window decorator

None of those should *have* to have a URL. What if, as a developer, I just want to open your default IM client? Currently, settings have to be parsed in different ways for each DE, and they are usually stored in DE-specific folders or files, making other DEs unable to share them or their model (and simplifying the developer's life).

It baffles me that this hasn't been done. I think I might put something together unless there's already been work in this area.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.