possa / winunciator Goto Github PK

Copied from colsolgrp issue tracker

tshif:
Give Winunciator the ability to check for its own updates. Updates shall come from the dev live update respistory.

1. On a schedule, or on demand
2. Allow rollback in the event the user hates the new version.
3. Allow for silent or "next" driven upgrades

tshif:
There are a couple ways to approach this. The easiest would be to rely upon a third-party component -- but I have been unable to find one that is suitable for inclusion in an open-source project of this nature.
The next method would be to write our own product updater and essentially include that as part of the Win-nunciator. Under these circumstances, the user actually launches the stub updater, and the stub updater checks to see if there are updates available and offer them to the user if they are. When that process is done, whether or not there are updates, the stub updater program actually launches the Win-nunciator.
Because the updater executables would essentially be running and in charge during the update process, we would not have any problem updating the winunciator executable because it won't be running yet. It will be a little bit more challenging if we have to actually update the updater program-but we can cross that bridge if we get to it.

mykroft:
How about this approach:
Wincunciator starts up and checks for a new version of itself (config option avail to uset to allow this), easiest way would be to pull a specific url that just comes back with the current release filename with the release version part of the filename that we are specifically checking against - (ex winunciator-installer.1.1.3.exe).
If no, continue on normal startup, if yes, spawn a small update program that accepts one param - the url the main program came back with for the new version.
Upon spawn, main program will exit, updater should check and wait for this to happen, then download and install the update.
The updater program needs to display nothing unless there is a problem so in theory it should never need to be updated.
Also the main installer program should have a param like -q avail for quiet install mode to keeps things looking nice and perty and would prob have to check if it is not installed in the default location, so maybe a -p param also should be avail - it would just prepopulate the path and the -q param would skip asking the user about the install path
Once finished updater program would start up the main program again, and exit itself.
This is how the curse gaming client works that I use for world of warcraft, usually only takes 30 secs or less to update and rerun main program. This way one updater program can be made and it is not depending on any version of the main program.

tshif:
The beginnings of this have been laid out - and the code is being developed.
This is pretty much how the live update function for the data sources works, and how we plan on making the exe updater work as well. That way, the update comes direct from the SVN, like the others do.
easiest way would be to pull a specific url that just comes back with the current release filename with the release version part of the filename that we are specifically checking against - (ex winunciator-installer.1.1.3.exe).
I hadnt thought about quietmode - not sure I like it - Making the user click next a couple times might help them realize / remember they have done an update.
The next release already stores its installation location in the registry, along with its version ID, so the installed app and the updater, will have those two pieces of info available to them.
Also the main installer program should have a param like -q avail for quiet install mode to keeps things looking nice and perty and would prob have to check if it is not installed in the default location, so maybe a -p param also should be avail - it would just prepopulate the path and the -q param would skip asking the user about the install path
Hmmm. Did I miss anything?

bsau:
The installer code has access to the app reg entries - so quiet installs should be not a problem. I agree with MyKroft also - the installer should support a command line quiet option like /q. This way, only one build of each new version installer need be made. The autoupdate can launch it with the /q, and the new first time installers get the full "click next" experience.
Currently, the reg entires dont include the version or installation location information, but tshif has said those are in his current working copies and will hit svn shortly - so it looks like this dev is underway for this cool function.

mykroft:
Personally for me, if I check the option to auto update in a util like this, I dont want to be bothered by having to click buttons, the curse client that i beta tested for - when updated, automatically brought up the change log in a window on top of the client - so when i can back, i could just read what was bug fixed, added, changed etc and then click the ok button and we are ready to go.
So please consider a quiet option to just install the bugger and then display the change log - pull a html file in a simple window with a scroll bar and ok/close button in the bottom right corner....
just my 2 cents - thanks for listening

tshif:
How about an option in the config that allow the user to select silient, or non silent updates? Thats kind of what I was thinking of doing.

1. Silent update config option will have the application update itself silently on schedule when a new version exists.
2. When non-silent upgrade is selected via config, get the pop up descrption, change log and etc, and choose then and there if they want to update. We should allow them to opt-out of any specific update forever if they choose, or to be prompted later.
   Does this sorta get all the important parts included? if not - please let me know what Im missing.

bsau:
Thats what I think also - its what I meant when I said make the installer callable with or without the silent option so we only have to build it once. I think the option to do itlike MyKroft says is a great idea - completely silent etc, when its being done by auto update. At least the option to be silent.

tshif:
Dev: Activated silent installs & uninstalls. Removed choices for install destination
The installer has now been updated to support the silentmode installs needed for update purposes.
As part of this change, the user nolonger has the ability to select the installation location of the program. It will go into program files (or equiv on win vista nd win 7) folder, CallerID Superfecta Folder, and the Group will be Named "CallerID Superfecta"
Completely silent upgrades (and installs), and silent uninstalls are now possible using the same single installation program. (No publishing two versions for different behaviors.)

tshif:
Added coding for voice announcement when no caller ID information (caller ID name or caller ID number) is received.
Added speech rules (conditions), "speak name and number", "speak name only (if available)"
these two configurations will be used to form the logic of when and how caller ID information is spoken.
Added program updates settings configuration.
Added update types silent auto update, auto update with progress bar, auto download / manual update, and a manual update only.
Added update schedule configuration option. Options include check for updates daily, check for updates once every seven days, check for updates once every 30 days, and check for updates once every 90 days.
added registry entries for current product version, and path to install directory. These registry fields may be used during subsequent update activities of the auto updater
Added speak settings details for all of the new fields that can be configured.
Upgraded look and feel of the configuration screen.
Created basic update screen, for when updates are set to display status information.
Great about 20% of the logic to complete auto updates.

tshif:
I have decided to seperate the dev effort for autoupdate and the new speak rules - auto update is taking longer than hoped for, and I'd like to see the new speak rules deployed sooner rather than later. This should mean another alpha or beta release of 1.1.4 in the next couple of days.

tshif:
Work will now focus on the auto update function for Winunciator.

Copied from colsolgrp issue tracker

First reported by tshif:

Winunciator.exe doesnt send web page response to its data source - causeing the data source to report that it can't communicate with the .exe - when if fact it is successfull. This is somewhat a cosmetic issue, but it should be corrected.

Copied from colsolgrp issue tracker

mycroft:
I dont know about other users etc, but I use a Nivida setup (dual monitor) and use their util programs to add the Nivida control buttons to the program windows next to the control buttons in the upper right corner. Right now the default window widths are too narrow and everything gets jumbled up and smashed together on the title bar. Can we either make the default window widths wider or have the program remember its location and size on the desktop?

tshif:
I like the idea of having it remember its location and size settings on the desktop. I agree, and will add that ability.

bsau:
I was thinking this a few days ago also. It would be good for it to remember where it lives on the screen, and its shape and size. I vote yes for this update.

tshif:
Replaced resize component that was not compatible with this resize with restart with regular code.
Added registry settings as needed. Added support in installer. Adjusted installer to remove previously installed resizer components.
Added changelog display step to installer.

tshif:
Testers report that the resizer component is still in use in the config and debug boxes. YUP, they are. That was dumb as hell of me.
I will remove these dependancies now.

tshif:
finished removing the resizer control from all forms.

tshif:
Testers indicate success with resize and rememebr changes.
Changes accepted for 1.1.4 build.

tshif:
This ticket has been reopened. The resize/remember and restore functions are buggy as hell and need to be reworked.