SteveKing wrote:
> (answering to the dev list - this belongs there)
Righto.
> Peter Mounce wrote:
>
>> How would you prefer I do the changes? Some will require the creation
>> of new files, some will require changes in existing files. Would you
>> prefer if I try to do everything at once, or would you prefer if I
>> sent you a succession of patches as I implement each thing?
>
>
> That's completely up to you. I also could give you commit access so you
> can commit your changes directly. You just have to make sure that you
> don't commit a change which doesn't build - otherwise the nightlies
> won't work. (I need your tigris.org ID to give you commit access).
> Lübbe could also open an account in our issuetracker so you can keep
> track of the changes you want/need to make.
Issuetracker access would be good, as well as a category for setup
package work.
Is there scope for a branch, while I work on these potentially-breaking
changes? I mean, no-one else will be working on the setup, right? And
my changes could break the nightly without my necessarily realising. If
work on the trunk means new files are created and installed, those are
easily added to the setup package code. It (the setup package work)
seems like a perfect example of a self-contained piece of work, really.
>> Where do you stand on vertical whitespace? If it were me, I'd want to
>> split up the existing file some, but will certainly accede to any
>> established convention you prefer ;)
>
> I'd prefer to split the file up into several ones too. The file we have
> now was originally generated with dark and edited - that's why it's all
> in one file.
Ah right. Good.
>> This will all wait until I've got the build running on my own machine,
>> of course, so that I can test building the setups.
>>
>> So far, I've come up with this list of requirements based on peoples'
>> replies:
>>
>> - it doesn't remember where you've previously installed TSVN, to
>> populate the suggested path from that.
>>
>> - it doesn't remember your previous preference for installing for
>> everyone's use or just your user account's.
>>
>> - inform the user if they are updating an existing version, that if
>> they do so, they will overwrite their current version? (Obvious, but,
>> well, some people like the warning)
>
>
> I don't think a warning is necessary. People just want to install the
> package - they expect the installer to handle updates/upgrades
> automatically.
Currently, the setup package will look for any version of TSVN, remove
it, and install whatever version is contained within the package. This
allows the user to downgrade - is this by design? Personally, I think
it would be better to only allow upgrades - if the user wants to
downgrade, he should be forced to manually uninstall the existing
version, then install the older version in two distinct operations.
Alternatively, it's possible to code in a warning if the user's trying
to downgrade.
>> - provide one of those tree lists for installing different features?
>> Unfortunately I don't think it's possible to give features a url, and
>> then have the package interactively download them as the user requests
>> - that would seem ideal for the translations and the dictionaries...
>
>
> I've already removed the thesaurus. The installer is now about 5.5MB
> which should be small enough.
Ok, shan't bother with customised installs, then - all features will be
installed.
>> - [the setup package code] be split up into WiX fragments, so we
>> separate out the UI from the main guts (for example)? (If so, this
>> will require an edit to the build script, I think; just the files to
>> candle)
>
> A change to build.bat shouldn't be necessary. Just the build script of
> the installer.
Yes.
>> - [the setup package code] use a wxi include file for things like the
>> UpgradeVersion GUID, the version number, and other things used in more
>> than one place that can be referred to with
>> $(var.VariableNameFromWxiFile) syntax.
>
> Are those used in more than one place?
The Upgrade GUID is. The version number isn't currently, but can be
inserted into things like the ARPxxx fields and some of the wizard's
strings (like "You are about to install TSVN _version x.y.z.build_").
Same goes for things like product name and manufacturer, and some others.
>> - this includes the various COM component GUIDs (I assume they're
>> for COM components, anyhow) that recur about 4 times each - they would
>> be better off in an include file, strictly speaking. Depends how
>> "proper" you'd prefer things to be...
>
> We don't have self registering COM components. So the GUID's must be set
> in the installer. But separating them into an include file seems to be a
> good idea.
Oh, ok. In that case, I don't know what all those GUIDs are for, and
won't be able to give them meaningful variable names. If I call them
things like Jeff and Sally, you can think up meaningful ones and do a
find/replace, if you like; or I can simply leave them.
>> - the 'show changelog' checkbox only works the first time. If you
>> deselect, then select it again, the changelog isn't shown anymore.
>>
>> - The installer should stop the TSVNCache.exe process (send a WM_CLOSE
>> message?) before trying to update the file
>> - not certain how to do this from an MSI yet; a custom action is
>> likely needed, and I don't know how to produce an unmanaged-C++ dll to
>> do that.
>
> Maybe it's possible to just kill a process?
One hopes; I have to check.
>> - there may be an existing CA dll in the WiX project; I'll ask on
>> their list in a bit...
>>
>> - Is it possible to ask for the program group where the TSVN links are
>> to be installed in?
>> - use a simple textbox for the user to type a path in from the
>> start menu root.
>
>
> If possible, the progress indicator should be improved too. Currently,
> the progress indicator runs through several times instead of showing the
> overall progress. Also, a text indicating which components are currently
> being installed would be great.
Hopefully possible. I don't know for certain. I do know the example UI
that the WiX tutorial makes available has a set of standard strings that
it uses for things like that, though. Progress bars in Windows are
generally accepted to be dubious anyway ;)
Pete
e: pete@molehole.org m: +44(0)7968 484098 h: +44(0)23 8026 5515
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Thu Jul 21 22:52:41 2005