On 4/7/11, Adam Strzelecki <o...@java.pl> wrote: > Below you will find patches for latest HG head of *surf* which I am using in > my project using integrated Linux station. > > (1) surf-1-respect-GNOME-URL-handlers.patch > > This patch makes *surf* respect URL schema handlers registered in > GNOME/Gtk/GConf, when requested url is using other schemas than http: or > https:. > Since anyway *surf* is Gtk program it was easy to add GConf handling inside > to open other program registered on > /desktop/gnome/url-handlers/<schema>/command, such as IRC, IMs. > Upstream should avoid depending on GConf. I wouldn't be surprised if some here would prefer P9 plumbing.
> (2) surf-2-delete-_SURF_GO-once-received.patch > > This xprop (atom) may be used to tell *surf* to go to specific URL. It is > safer to remove this atom just after it is set in case we send some URL > containing passwords or auth tokens such as > http://login:mypassw...@myserver.com/ > Anyway _SURF_URI will represents current page URL, so keeping _SURF_GO makes > no sense. In our case it is matter of safety to not expose this one. > Is there no race condition inherent? What happens if you try to read _SURF_GO just after it's set? > (3) surf-3-close-and-reopen-stdout-when-sending-XID.patch > > When using -x option making *surf* emit its window XID currently it does not > close stdout so: > > SURFXID=`surf -x 2>/dev/null &` > > will hand forever because no EOF is encountered. > > So this patch reopens stdout to /dev/null just after sending XID using -x > option, so caller process (shell) will receive EOF for stdout and return the > control. > Quite useful indeed. > I hope these small patches gets accepted into HG repo so, we will be able to > use *surf* out of the box in our project without need for custom patching. > Thanks for submitting, I'll patch locally, in the least.