Bug 33055

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.

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?

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.

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).

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.

1.  slows down?  how much?  this should be fairly minimal.
2.  that, and "google.com" isn't exactly a valid URL either.

(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...

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?"

(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.

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xdg/xdg-utils/issues/41.