Matthew Toseland skrev:
> On Thursday 22 January 2009 15:13, [email protected] wrote:
>
>> +;
>> +; No usable browser found
>> +;
>> +PopupErrorMessage("Freenet Launcher was unable to find a supported
>>
> browser.`n`nPlease install one of the supported browsers, or
> manually`nnavigate to the URL inside freenet.url.dat.`n`nFreenet Launcher
> supports the following browsers:`n- Mozilla FireFox`n- Internet Explorer (not
> recommended)")
>
>> +ExitApp, 1
>>
>
> Can't we just fall back to using the system browser? We should not give the
> impression that we support Internet Explorer in any way, shape or form!
> Trying Firefox makes sense, of course.
>
We can indeed fall back to a system URL call. We probably should too?
The only problem is that it's hard to tell if such call actually
succeeds. On the other hand, the user's system will be seriously broken
if it doesn't, so we can probably assume that it works just fine. So
what do we do? Simply launch a system call (and cross fingers), or popup
a warning as well?
What do you suggest regarding IE? Fallback (as now), but remove it from
the list of "supported browsers"? (Whoops, I forgot to add Chrome to
that list it seems. Fixing...)
>> +
>> +Gui, Font, s%_FontSize%, MS sans serif
>> ; As default font may vary
>>
> (and thereby mess up custom positioning and layout), we should force a
> specific
>
> Localisation may also mess stuff up. Many languages use twice the width as
> english does to represent the same information. You need to ensure that the
> UI works no matter what language is being used.
>
Because AHK doesn't (yet, at least) have multi-level GUI container
support, some of the GUI element sizes are manually calculated.This
means that translators have to tell the installer how many lines a given
text spans. Therefore the forced font and font size to ensure consistency.
The translator would translate the strings and afterwards open the main
GUI to count the number of lines they span after word-wrapping and
stuff. Then open the translation file again, and correct the number of
lines where necessary (will be a define or a variable or something next
to the string). But in the end, it *should* work.
>> +;
>> +; Create our custom user
>> +;
>> +_CustomUserPassword := GenerateRandomNumberString(12)
>> ; According to
>>
> the old installer, 12 chars is max. to avoid warnings about
> backwards-compatability. The password itself is apparently also needed to run
> services under a custom account.
>
>> +RunWait, %comspec% /c "net user
>>
> Freenet%_InstallSuffix% %_CustomUserPassword% /add /comment:"Freenet service
> user. Please do not
> delete!" /expires:never /passwordchg:no /fullname:"Freenet%_InstallSuffix%
> user"", , Hide UseErrorLevel
>
> On the old installer we tried 3 different patterns in the hope of finding a
> password that is acceptable to the user's security policy ...
>
Hmm. What did you figure out? Any user settings that we might need to
take into consideration?
>> + GuiControl, +Disabled, _cInstallButton
>> + }
>> + Else
>> + {
>> + DriveSpaceFree, _InstallDriveFreeSpace, %_InstallDrive1%
>> + If (_InstallDriveFreeSpace < _RequiredFreeSpace)
>> + {
>> + GuiControl, +cRed, _cInstallDirStatusText
>> + GuiControl, Text, _cInstallDirStatusText, Not enough
>> free space on
>>
> installation drive!
>
>> + GuiControl, +Disabled, _cInstallButton
>> + }
>> + Else IfExist, %_InstallDir%\freenet.jar
>>
>
> IMHO this is not reliable. If freenet auto-updates, it alternates between
> freenet.jar and freenet.jar.new, you should check for both (we don't delete
> the old one however, so it should be reasonable...)
>
> You should probably check whether the directory is empty.
>
I didn't know. I'll add a check for freenet.jar.new as well then.
Checking if the dir is empty seems reasonable as well. Can you think of
any situation where it would be a problem? (I can't, on top of my head)
>> + {
>> + DllCall("RtlFillMemory", "UInt", &pDest + pOffset + A_Index-1,
>> "UInt",
>>
> 1, "UChar", pInteger >> 8*(A_Index-1) & 0xFF)
>
>> + }
>> +}
>>
>
> Ewwwwwwwwwwwww!
>
Sorry, I know. It's taken from one of the official script examples
though (http://www.autohotkey.com/docs/scripts/WinLIRC.htm).
>> +
>> +;
>> +; Remove our custom user
>> +;
>> +Progress, , Removing custom user...
>> +
>> +FileInstall, files_bundle\RemProf.exe, %A_WorkingDir%\RemProf.exe
>> ;
>>
> Extract 3rd party "RemProf" tool from
> http://www.ctrl-alt-del.com.au/CAD_TSUtils.htm. Freeware, but not
> open-source :(. Removes the profile folder and its registry entry of
> specified user
>
>> +RunWait, %A_WorkingDir%\RemProf.exe Freenet%_InstallSuffix%, , Hide
>>
> UseErrorLevel
>
>> +FileDelete, %A_WorkingDir%\RemProf.exe
>>
>
> Grrrr!
>
I know you are not fond of this, but atm. it seems like the best
solution to me. The alternative right now is to leave the profile data
intact (which we do in the Java solution), which seems even worse. Or
what do you think? (I wanted to research the problem and recode the
functionality, but right now I don't have the time.)
- Zero3
_______________________________________________
Devl mailing list
[email protected]
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
