Open GoogleCodeExporter opened 9 years ago
Same problem for me.
Original comment by pierre.b...@gmail.com
on 7 Jun 2010 at 11:36
Thanks, for bringing u this ~forever issue.
Original comment by megeekz%...@gtempaccount.com
on 7 Jun 2010 at 12:55
i used a program called
http://windowsxp.mvps.org/defaultbrowser.htm
it only works on one user only
you have to do them one by one
isn't it possible to add a command-line option to make your browser as the
default one?
Original comment by bleukous...@gmail.com
on 18 Jun 2010 at 7:44
Working on it at http://github.com/andrewsteinborn/arora.
Original comment by megeekz%...@gtempaccount.com
on 18 Jun 2010 at 6:03
It's a WONTFIX, it's in the code, so this bug is for "update the downloads"!
Original comment by megeekz%...@gtempaccount.com
on 18 Jun 2010 at 6:33
hm? andrewsteinborn: got a link to a patch?
Original comment by ice...@gmail.com
on 18 Jun 2010 at 11:33
Turns out, you should update the WINDOWS binary.
Original comment by megeekz%...@gtempaccount.com
on 19 Jun 2010 at 4:41
How would that change the default browser on windows?
Original comment by ice...@gmail.com
on 19 Jun 2010 at 4:47
Put a option inside the installer.
Original comment by megeekz%...@gtempaccount.com
on 19 Jun 2010 at 5:58
[deleted comment]
There are several laysers to this problem.
1) You /can/ associate Arora with .htm, .html, .xhtml, .gif, .jpg, .jpeg and
.png files manually. (This works!)
2) You /can/ associate it with .url shortcuts too... but it doesn't know how to
handle them yet and will just give you an unknown URL error. (probably
"Unrecognised protocol C", taking "C:\some\location\on\your\drive\link.url" as
being a web location.)
3) You should also note that a .url file can point to an https:// location, and
http:// location (which Arora can handle, and a simple Proxy program would fix)
an ftp:// location, a telnet:// location, a mailto:// location, an irc://
location, or even a file:// (though these are kinda hard to make, they do work)
etc. all of which Arora cannot handle, and your proxy program would have to
redirect those to some other application(s). (cuteFTP, puTTY, Eudora, mIRC etc.
for most users, and finally Explorer.exe for file:// URLs)
4) You can associate it with .mht, .mhtml, .xls, .xrm-ms, .mfp, .dtsconfig and
other files which IE normally deals with, but it won't recognise them either.
5) You cannot (in Vista, 2008 or Windows 7) associate it with HTTP, HTTPS or
FTP protocols... and even if you could associate it with the last one, it
cannot handle it and would then loop forever.
Okay, so what needs to be in the code to fix this.
1) The setup program should let you change the users file associations in HKCR
2) It needs to parse Argc and Argv and determine wether it is recieveing a URL
or a .url file, and pluck the URL out of the .url file if it is the latter.
This is simple enough as a .url file is just a Windows .ini file, and in the
"InternetShortcut" section the key "URL" points to the /actual/ URL that your
browser should open.
3) It should check any URL passed to it to see if it can handle it, and if it
can't it should pass it on to the "system default" for /that/ protocol. As far
as I can see, it kind of does this for mailto://, irc:// and ftp:// anyway.
4) Hmm, most of Aroras competition doesn't handle these by default either,
including Firefox, Opera and Chrome... although extensions exist for some of
these files on some of these browsers. So, this is probably not a major issue.
At least not in the short term.
5) This, I'm not so sure about. There should be a mechanism (similar to
registering a port to a specific program in Windows Firewall) for registering a
program as being able to deal with a particular protocol. Firefox, Opera,
Eudora and mIRC all do this, both at install time and when you run them and
they find they are not presently the default. I don't know how that is
implemented.
Original comment by ronnie.b...@gtempaccount.com
on 13 Nov 2010 at 5:10
Just thinking out loud in this thread, I realised that the Proxy for .url files
would be very simple to script up in AutoIt... so I did.
Devs and System Admins may like to look at the script I wrote, which is working
well for me right now at this URL. http://pastebin.com/MnQ4amFB
Original comment by ronnie.b...@gtempaccount.com
on 13 Nov 2010 at 5:36
Okay... I also have a "partial" fix for the "Default Browser" situation in the
form of a .reg file.
http://pastebin.com/4CCJNx0c
This means that if you type "http://www.google.com" into the Start -> Run box,
or the address bar in Explorer, or click links in your (well written) IRC
client or what-ever, they load in Arora, not IE... however, Windows sees that
Arora doesn't "respond in a timely fashion" and produces an error suggesting
that it couldn't find the file or directory you requested.
This can happen if you launch large programs like Corel PaintShop Pro for the
first time while your system is under heavy load too... just because they take
too long to respond to the desktop shell "Hey! I got that file you sent me,
thanks."
Firefox seems to get around this by passing a "-url" parameter combined with a
"-pending" parameter, which (presumably) it deals with by responding to the
desktop right away, before even trying to download the page.
Original comment by ronnie.b...@gtempaccount.com
on 13 Nov 2010 at 6:09
I'd like to modify my last response, since it's now clear to me that it's more
than simply the time before the app gets up and running.
I've modified the Proxy script to accept URLs as well as .url links (Windows
Internet Favorites Links) and re-directed the protocols for HTTP and HTTPS to
point to that instead, and the error box still appears, even though it opens
the right page.
http://pastebin.com/2CLg4H6z < That's my new source, I think you can modify the
.REG file your-selves and re-import it. It's easier if the script is built to
an EXE file, and you can add the Arora icon to have weblinks look like Arora
files, not AutoIt ones. XD
So, now I suspect that there should be some communication using the DDE
messaging system passed from your desktop shell (usually explorer.exe) rather
than just a simple OK return to the OS. (errorlevel = 0)
DDE is kinda scary for me, so I'll leave that last part to someone else, unless
somone want's to take me on as a co-dev / sub-dev on this project so I can work
these bits out in the C code. (Harder than an AutoIt, or even WSH script, but
still not very hard, and then possible / easier to do DDE interaction)
I still haven't learned how to make Arora show up in the list of applications
that support a specific protocol (Namely HTTP and HTTPS) in the "Default
Programs" Control Panel applet. That would be "professional" looking, but so
long as it works, and for me personally, I don't really care. I can package up
Arora with this proxy and the registry settings to set it default at install
time in a Setup.exe if anyone really want's such a fork... but I'm more
concerned with helping the official dev(s) (and System Administrators, who are
probably capable of packaging for themselves) in these posts.
Original comment by ronnie.b...@gtempaccount.com
on 14 Nov 2010 at 4:43
Another refinement... the error box is because of the DDE keys. Arora doesn't
handle DDE communications, so provided you don't currently have Firefox, or
some other browser as your default, simply applying the "command" subkey, and
not the "dde" ones.
I've removed them from the .reg file... but I can't remember if M$ ever got
around to allowing you to delete keys (if they are present) to the standard
RegEdit. (I'm sure I had something that can, and the command line registry
editors I've used in Telnet allow it.)
http://pastebin.com/S12Wp6SX
I've been using it for long enough, now, to know that this makes Arora the
default in Microsoft Help files and anywhere else I've used HTTP:\\ URLs. But
I'm also aware that there are some badly written programs actually pass the URL
directly to IExplore.exe, instead of to the OS for it to pass to the
appropriate URL handler. (This defeats all alternative browsers, of course.)
Original comment by ronnie.b...@gtempaccount.com
on 15 Nov 2010 at 5:43
Okay... the final piece of the puzzle, Default Applications, is down to two
keys in the Local Machine registry Hive.
a) HKLM\Software\RegisteredApplications requires an "Arora" RegSZ value which
points to a key (preferably starting "Software\Clients") which the Default
Applications Applet will look for in the HKLM hive. Suggested
"Software\Clients\StartMenuInternet\ARORA.EXE".
b) The keys and values in the key pointed to by the RegSZ value in a). Should
contain the key "DefaultIcon" whose default value is equal to the Arora
executable full path + ",0". An "InstallInfo" key with no default value, a
HideIconsCommand RegSZ value which points to a program that will put away
desktop and quick launch icons, a IconsVisible RegDWord whose value is either 0
or 1 depending on whether we think the icons are presently visible, a
"ReinstallCommand" RegSZ value which points to the uninstall/reinstall/repair
program and a "ShowIconsCommand" RegSZ value which points to a program which
will un-hide desktop and quick launch icons. Then, a "shell" key, with an
"open" key, containing a "command" key, whose default value (RegSZ) will be the
command to launch Arora (or it's proxy) passing URLs or .url files too it...
this is the bit the "Default Applications" Applet will copy to the Classes Root
hive if you select Arora as your "default application" for certain files or
protocols.
That's more complex, but a setup program should be able to implement it. There
should really be a new Button or Tick Box that appears in the Options dialogue
that allows users to make Arora the default (manipulates the appropriate
registry entries) as well. I presume Mac and Linux people would want it to
change MIME and Appl resource fork associations for them. So it should probably
be present, but linked to completely different code for each platform / build
target.
Original comment by ronnie.b...@gtempaccount.com
on 20 Nov 2010 at 11:42
Original issue reported on code.google.com by
megeekz%...@gtempaccount.com
on 16 Jan 2010 at 5:09