-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Mon, Jan 12, 2009 at 6:38 PM, Zero3 wrote: > Hi everyone > > I've been working on a new native Windows installer for Freenet for some > time now. It's actually almost done! A quick round-up of the features: > > - Simple customized offline "1-click installer" > - Prechecks for required admin privileges (including Vista UAC > escalation), Windows version, Java version (helps the user > installing/upgrading his Java via the bundled online installer, see > screenshot below) and old installations > - Support for multiple concurrent installations > - Port availability check and automatic selection (hard-coded limit of > 256 checks because of the time requirements) for both fproxy and fcp ports > - Semi-intelligent installation folder selector (checks path for > existing installation, the "Freenet" keyword (if not found, appends > "\Freenet" to avoid installing in root of drive or "Program files" > folder), too long for file system to handle, not enough free space (with > reserve for other software and Windows itself) and write-access. Install > path status is updated live (see screenshot below). > - Checkboxes for "Install start menu shortcuts", "Install desktop > shortcut" and "Browse Freenet after installation" > - Reduced installer file size (9.5 -> 7.5 MB) and number of files installed > - New browse/start/stop bins will be included as well (mostly to fix > Vista issues and support concurrent installs) > > On my to-do before a release is: > - i18n support > - Command line support > - Support for recognizing more browsers in the launcher (need a list of > which we support, btw.) > - Maybe an "advanced" GUI allowing user to pick fproxy and fcp ports > - Maybe support for reinstallation (while keeping identity and settings) > > Screenshots: > http://privat.zero3.dk/FreenetInstaller_MainGUI.png > http://privat.zero3.dk/FreenetInstaller_JavaMissing.png > > However, there are some remaining policy questions to be answered before > I can send out a working alpha. So here we go: > > 1) Is it worth the time to include checks for existing 0.5 installations > in order to not collide with them? > 2) Is there anything in the folder structure that ought to be moved > around? E.g. atm. we have browse.cmd in the install root, but start.cmd > and stop.cmd in the bin folder. My installer also creates a new > installid.dat file containing a string needed to identify the node among > concurrent installations. Is there some kind of guideline about where > files should be placed? I've always thought there should be a \config directory but that would require lots of changes in the code. > 3) If FireFox (or whatever "safe" browsers we support) is not found, and > the launcher falls back to using Internet Explorer, should it warn/nag > the user about the problem with using IE, and suggest installing another > browser? > 4) Would it be a good idea (read: worth the time) to make the installer > log its progress to a logfile in the system's temporary folder for > debugging/troubleshooting reasons? I don't know that users could find the file if needed. I would log it in the Freenet install folder if it can be, fall back to the folder the installer is running and fall back to the system temporary folder if the others aren't creatable\writable. > 5) Is the .fref file association a good idea at all? It's a bit messy, > and very hard to manage in environments with multiple installations or > nodes on another machine than the client. It seems like we are moving > towards friend codes/tokens in the future too, so is it really worth > keeping? Isn't the upload/paste reference features in fproxy good enough > for now? Ugh. If the user is using a .fref file, they probably aren't running multiple nodes on one machine. I'd say the last node installed is the one associated with the extension. > 6) update.cmd was *not* created with concurrent installations in mind > (read: it won't work), and certainly won't be compatible with the > current installer and mine at the same time. The best solution would > probably be to branch update.cmd for my installer. Juiceman, how are you > feeling about it (being the current maintainer)? > I haven't worked on it in a while. Why would it not work? It stays in it's own directory and uses relative folders ..\bin etc etc. Unless you are wanting it to update all installations at once (bad idea imo) it just calls stop.cmd does it's thing and calls start.cmd. All agnostic, right? or am I missing something. I assume the new installer will create a start/stop.cmd with the unique nodes' service name? I would be happy to make changes as needed. > Constructive feedback/questions/suggestions/etc. welcome :) > > - Zero3 > _______________________________________________ > Devl mailing list > [email protected] > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: http://getfiregpg.org iD8DBQFJa/Mo4esu1mlKOs8RApjpAKCFz5H9l7JIkYVZuTdKhcwVWjYqFgCgmCdo CMUei+oeCgW8wfxB0DUxBlY= =QZJy -----END PGP SIGNATURE----- _______________________________________________ Devl mailing list [email protected] http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
