Opened 17 years ago

Closed 16 years ago

Last modified 16 years ago

#7000 closed (wontfix)

Provide option to automatically open development server URL with webbrowser (std lib)

Reported by: Jannis Leidel Owned by: Jannis Leidel
Component: Core (Other) Version: dev
Severity: Keywords: browser command runserver
Cc: flori@… Triage Stage: Design decision needed
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

I think it would be a very useful addition in the daily development work to have an option that opens the URL of the develeopment server in the default system browser.

For example restview makes use of Python's webbrowser module that is used in the attached patch.

Attachments (1)

open_browser.1.diff (4.1 KB ) - added by Jannis Leidel 17 years ago.
patch including docs

Download all attachments as: .zip

Change History (12)

by Jannis Leidel, 17 years ago

Attachment: open_browser.1.diff added

patch including docs

comment:1 by Jeff Anderson, 16 years ago

Triage Stage: UnreviewedDesign decision needed

This looks useful. The only thing I would suggest is that the code for opening a browser should be executed once when the command is invoked initially, so the autoreload can still be enabled. If I were to use this feature, I'd probably run the command once, ctrl+c, remove the --browser option, and start it again. In my opinion, it almost defeats the purpose.

comment:2 by Marc Fargas, 16 years ago

I'm not sure about that, mainly, as webbrower docs say, if it needs to use a text browser for some reason the server will lock.

in reply to:  1 comment:3 by Jannis Leidel, 16 years ago

Replying to programmerq:

Right, having autoreload would be useful, I'm going to change the patch to call webbrowser.open outside of the inner_run() loop.

Replying to telenieko:

Since "--browser" is off by default there is no way a developer on a text shell would accidentally use it. Though I agree that this should be documented by stating --browser is most useful in graphical environments. I think it saves serious time in daily work.

comment:4 by Jannis Leidel, 16 years ago

milestone: post-1.0
Status: newassigned

I'm setting this to post-1.0 since it's just not that important.

comment:5 by Alex Gaynor, 16 years ago

Correct me if I'm wrong, but won't that fail on users who enter 0 or 0.0.0.0 as their ip(since it is a catchall)?

comment:6 by Alex Gaynor, 16 years ago

And I stand corrected, it will indeed work.

comment:7 by Marc Fargas, 16 years ago

RFC1700, around page 4, 0.0.0.0 *must* only be used as a source address (i.e.: bind to all interfaces) but not as destination.
It'd be better to translate 0.0.0.0 to "localhost" before opening the browser.

comment:8 by flosch, 16 years ago

Cc: flori@… added

comment:9 by Jannis Leidel, 16 years ago

As a compromise I suggest adding that feature to the runserver_plus command of the django_extensions app. What do you think?

comment:10 by Jannis Leidel, 16 years ago

Resolution: wontfix
Status: assignedclosed

Closing as wontfix after adding the option to the revision 113 of the django_extensions app.

comment:11 by (none), 16 years ago

milestone: post-1.0

Milestone post-1.0 deleted

Note: See TracTickets for help on using tickets.
Back to Top