One of the first things a user sees of a product is the installer, so it is especially important for a project like qtamaze to make the installer easy to use, since qtamaze presumable mainly has first-time, casual users. For Amaze 1.1 release 1 through 16, we have used a WiX-based MSI installer for Windows (XP and later), and a Debian package (using dpkg-buildpackage) for Ubuntu.
The installation itself is fairly minimal: we have a single executable, a man-page (Ubuntu only), some icons, the Qt libs (package dependency on Ubuntu; shipped as DLLs in WinXP). a license text, and some localization files (*.qm). On Windows it all goes into a single directory, and we add a Start menu item and desktop shortcut. On Ubuntu, the files go into default locations as per the standard (mainly /usr/local/share).
Installation is done on both operating systems from a finder by opening the ".msi"/".deb" file and clicking the defaults. Easy, no? On Ubuntu you can also use the CLI: dpkg -install amaze-1.1-xx.deb.
Re-installation is a bit more tricky on Windows: currently you have to first go through Control panel > Add or remove programs, and remove the current installation of Amaze. Then, proceed like a fresh installation. I tried adding code to the WiX file for a "minor update", but msiexec balks with "already installed", and using the recommended bunch of extra switches gets me more error messages. I'd really like to make update installation easier, right now it is too much work for the user. The WiX "major upgrade" cycle may offer a way out, but I'm not sure I want to dive into more MSI adventures.
MSI may be powerful and the best solution for enterprise-level apps with complex release cycles and segmentation into components, but trying to apply it to a simple case like qtamaze has had a steep learning curve, with limited success to show for all the effort. Since I don't want to invest a lot more time into becoming the requisite MSI guru to effectively use WiX, and there is real requirement that qtamaze shall use MSI-based installers, I'm considering switching to another method; may be looking at NSIS, InnoSetup and InstallerJammer, in that order.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ultimately, I'd like to be able to offer the user to update qtamaze by downloading and reinstalling from within qtamaze itself. Ideally, qtamaze would have an "update to current version" button, or something similar.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Spent a day on trying to extend the "Update…." dialog to not just tell the user where to download the new version, but to have a "Download" button (with "Save As") so the user could download directly from the dialog; in future, we could add an "Install" button after that. Would make the updates so much more convenient.
No success so far: we can download the official URL fine, but that just redirects to another URL. Rinse, repeat. Eventually you land on an HTML page with a "direct link" - which after two more rounds ends up in the same spot. Reading up, it appears we need to probably store/supply cookie in this process to break the loop, like wget(1) does. Don't want to shell/exec out to wget/curl (and what about on Win XP). This is ballooning into a bigger hurdle and time sink than anticipated, so may shelve the auto-download feature for now.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
For more fun, there *is* an attribute on QNetworkRequest to save incoming cookies, but it's not clear to me if that requires keeping the same QNetworkAccessManager instance around; if so, then we need to rewrite the entire query code, because it's now tied to a single throw-away thread per query… If we're going to need the same mess of code to drag-and-drop outline images from a browser URL, then that is probably going to get shelved for a while too.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Just to close off the preceding posts: the last couple of releases feature a more-or-less fully functional "Download latest version" dialog. What still fails is the last step on Windows: when the MSI installer is invoked, it fails to uninstall the previous version (which is obviously present, else you would not be seeing the dialog). This is due to me not being able to figure out how to get the "minor upgrade" procedure working in WiX.
Producing a workable Windows installer is a serious drag on this project, it takes a lot of low-productive searching and experimentation to achieve very basic things. As a product, qtamaze is really very simple: one executable, a few 3rd-party DLLs, a few localization files (Qt's "qm" files), a Start-menu link to the executable and a standard desktop-shortcut are all it needs. The little config data that it has (color and size preferences) is stuffed into a single per-user Registry entry by Qt at runtime, and the installer does not bother to touch it. Very simple and common case for a minimal application, you'd think. So it should be trivial to do, right? How naive I was…
I started out with an MSI installer since it is Microsoft's "recommended practice", and used WiX since it is the only open and well-developed MSI generator that I could find. Many sleepless nights later, the installer *almost* works (except for the open issues with uninstallation, multi-user shortcuts, properly adding shortcut arguments with brackets, etc. etc.), but we now have a new problem: the Administrators group name fails to work unless the user is running an English locale Windows version. Instead, it appears, you'd have to use the SID number, which in turn requires adding C/C#/C++ code extensions because WiX can't handle them directly. This the point I pretty much feel like giving up on WiX/MSI and switching to some other installer. Best candidate seems NSIS, *but* it does not support Unicode (except if you use an unofficial fork), and with >50% of qtamaze downloads being from China sticking to 8-bit code pages is not an option.
Do I really need to fall back to ZIP-files? Or write my own installer-generator? Or wait for NSIS to officially support Unicode (apparently the topic been under discussion/development since 2007 or so)? I'm really surprised this turned out to be so much of an unmitigated hassle, the Ubuntu build environment and installer took <5% of the effort (with no prior experience).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Started on an NSIS-installer, going pretty smoothly so far. The wiki has an open issue list on this: http://sourceforge.net/apps/mediawiki/qtamaze/index.php?title=Open_Issues#NSIS (under construction). For 1.1-22 there may be both an MSI and an NSIS-generated executable installer. I'm building under WinXP, the alluded possibility of cross-compiling the app for Windows on Linux is attractive but may be more hassle that justified by the time-savings of not rebooting into Windows. To test the installer I need to boot into WinXP anyway.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
For 1.1-22, the Update dialog still tries to get the MSI file, and calls "msiexec" to run it.
Not sure yet how to transition between MSI and NSIS installer.
Maybe this should be the occasion to go to a new version (1.2-1) instead of release (1.1-22).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
There has been a 4-year hiatus in this project -- other things took precedence, and the project was sufficiently usable for a lot of people. However, 4 years is a long time: Windows XP is now all but dead, many people shifted from Ubuntu to Mint, Qt went from 4.x to 5.x, the Blender 2.49 exports will not work with the current Blender 2.73, the wiki system on SourceForge changed (breaking the online help in qtamaze), and so on.
I'm picking up where things left off, and will start out with a new Amaze version 1.2-x, updating all the dependencies and targeting current platforms. I'm looking at the new NSIS (now has Unicode support) and the MXE cross-compilation environment to generate an NSIS installer for Windows cross-compiled on Linux. Not sure yet whether to drop the 32-bit version and go 64-bit only; target will be Windows 7 or later. As for Linux, I'm sticking with a ".deb" package, but will remove the mandatory dependence on the Ubuntu-only control center, so we can install on a vanilla Debian or Mint system as well.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Got Windows version with NSIS installer cross-compilation on Linux Mint running, and passing initial testing on Win7!
For non-Ubuntu updates, I'll change the logic to detect and use the "software center" is present, and else launch a "sudo dpkg" of the downloaded deb-file inside a gnome-terminal. We could put in more or fancier fallbacks later.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Revisited the possibility of generating an RPM (RedHat/Fedora) binary package as well, cross-generated on Debian. Looks somewhat cumbersome, but may succeed, and it would be a nice addition.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
One of the first things a user sees of a product is the installer, so it is especially important for a project like qtamaze to make the installer easy to use, since qtamaze presumable mainly has first-time, casual users. For Amaze 1.1 release 1 through 16, we have used a WiX-based MSI installer for Windows (XP and later), and a Debian package (using dpkg-buildpackage) for Ubuntu.
The installation itself is fairly minimal: we have a single executable, a man-page (Ubuntu only), some icons, the Qt libs (package dependency on Ubuntu; shipped as DLLs in WinXP). a license text, and some localization files (*.qm). On Windows it all goes into a single directory, and we add a Start menu item and desktop shortcut. On Ubuntu, the files go into default locations as per the standard (mainly /usr/local/share).
Installation is done on both operating systems from a finder by opening the ".msi"/".deb" file and clicking the defaults. Easy, no? On Ubuntu you can also use the CLI: dpkg -install amaze-1.1-xx.deb.
Re-installation is a bit more tricky on Windows: currently you have to first go through Control panel > Add or remove programs, and remove the current installation of Amaze. Then, proceed like a fresh installation. I tried adding code to the WiX file for a "minor update", but msiexec balks with "already installed", and using the recommended bunch of extra switches gets me more error messages. I'd really like to make update installation easier, right now it is too much work for the user. The WiX "major upgrade" cycle may offer a way out, but I'm not sure I want to dive into more MSI adventures.
MSI may be powerful and the best solution for enterprise-level apps with complex release cycles and segmentation into components, but trying to apply it to a simple case like qtamaze has had a steep learning curve, with limited success to show for all the effort. Since I don't want to invest a lot more time into becoming the requisite MSI guru to effectively use WiX, and there is real requirement that qtamaze shall use MSI-based installers, I'm considering switching to another method; may be looking at NSIS, InnoSetup and InstallerJammer, in that order.
Oops previous should read: "…is *no* real requirement that qtamaze shall use…".
Ultimately, I'd like to be able to offer the user to update qtamaze by downloading and reinstalling from within qtamaze itself. Ideally, qtamaze would have an "update to current version" button, or something similar.
Spent a day on trying to extend the "Update…." dialog to not just tell the user where to download the new version, but to have a "Download" button (with "Save As") so the user could download directly from the dialog; in future, we could add an "Install" button after that. Would make the updates so much more convenient.
No success so far: we can download the official URL fine, but that just redirects to another URL. Rinse, repeat. Eventually you land on an HTML page with a "direct link" - which after two more rounds ends up in the same spot. Reading up, it appears we need to probably store/supply cookie in this process to break the loop, like wget(1) does. Don't want to shell/exec out to wget/curl (and what about on Win XP). This is ballooning into a bigger hurdle and time sink than anticipated, so may shelve the auto-download feature for now.
For more fun, there *is* an attribute on QNetworkRequest to save incoming cookies, but it's not clear to me if that requires keeping the same QNetworkAccessManager instance around; if so, then we need to rewrite the entire query code, because it's now tied to a single throw-away thread per query… If we're going to need the same mess of code to drag-and-drop outline images from a browser URL, then that is probably going to get shelved for a while too.
Just to close off the preceding posts: the last couple of releases feature a more-or-less fully functional "Download latest version" dialog. What still fails is the last step on Windows: when the MSI installer is invoked, it fails to uninstall the previous version (which is obviously present, else you would not be seeing the dialog). This is due to me not being able to figure out how to get the "minor upgrade" procedure working in WiX.
Producing a workable Windows installer is a serious drag on this project, it takes a lot of low-productive searching and experimentation to achieve very basic things. As a product, qtamaze is really very simple: one executable, a few 3rd-party DLLs, a few localization files (Qt's "qm" files), a Start-menu link to the executable and a standard desktop-shortcut are all it needs. The little config data that it has (color and size preferences) is stuffed into a single per-user Registry entry by Qt at runtime, and the installer does not bother to touch it. Very simple and common case for a minimal application, you'd think. So it should be trivial to do, right? How naive I was…
I started out with an MSI installer since it is Microsoft's "recommended practice", and used WiX since it is the only open and well-developed MSI generator that I could find. Many sleepless nights later, the installer *almost* works (except for the open issues with uninstallation, multi-user shortcuts, properly adding shortcut arguments with brackets, etc. etc.), but we now have a new problem: the Administrators group name fails to work unless the user is running an English locale Windows version. Instead, it appears, you'd have to use the SID number, which in turn requires adding C/C#/C++ code extensions because WiX can't handle them directly. This the point I pretty much feel like giving up on WiX/MSI and switching to some other installer. Best candidate seems NSIS, *but* it does not support Unicode (except if you use an unofficial fork), and with >50% of qtamaze downloads being from China sticking to 8-bit code pages is not an option.
Do I really need to fall back to ZIP-files? Or write my own installer-generator? Or wait for NSIS to officially support Unicode (apparently the topic been under discussion/development since 2007 or so)? I'm really surprised this turned out to be so much of an unmitigated hassle, the Ubuntu build environment and installer took <5% of the effort (with no prior experience).
Started on an NSIS-installer, going pretty smoothly so far. The wiki has an open issue list on this: http://sourceforge.net/apps/mediawiki/qtamaze/index.php?title=Open_Issues#NSIS (under construction). For 1.1-22 there may be both an MSI and an NSIS-generated executable installer. I'm building under WinXP, the alluded possibility of cross-compiling the app for Windows on Linux is attractive but may be more hassle that justified by the time-savings of not rebooting into Windows. To test the installer I need to boot into WinXP anyway.
For 1.1-22, the Update dialog still tries to get the MSI file, and calls "msiexec" to run it.
Not sure yet how to transition between MSI and NSIS installer.
Maybe this should be the occasion to go to a new version (1.2-1) instead of release (1.1-22).
There has been a 4-year hiatus in this project -- other things took precedence, and the project was sufficiently usable for a lot of people. However, 4 years is a long time: Windows XP is now all but dead, many people shifted from Ubuntu to Mint, Qt went from 4.x to 5.x, the Blender 2.49 exports will not work with the current Blender 2.73, the wiki system on SourceForge changed (breaking the online help in qtamaze), and so on.
I'm picking up where things left off, and will start out with a new Amaze version 1.2-x, updating all the dependencies and targeting current platforms. I'm looking at the new NSIS (now has Unicode support) and the MXE cross-compilation environment to generate an NSIS installer for Windows cross-compiled on Linux. Not sure yet whether to drop the 32-bit version and go 64-bit only; target will be Windows 7 or later. As for Linux, I'm sticking with a ".deb" package, but will remove the mandatory dependence on the Ubuntu-only control center, so we can install on a vanilla Debian or Mint system as well.
Got Windows version with NSIS installer cross-compilation on Linux Mint running, and passing initial testing on Win7!
For non-Ubuntu updates, I'll change the logic to detect and use the "software center" is present, and else launch a "sudo dpkg" of the downloaded deb-file inside a gnome-terminal. We could put in more or fancier fallbacks later.
Revisited the possibility of generating an RPM (RedHat/Fedora) binary package as well, cross-generated on Debian. Looks somewhat cumbersome, but may succeed, and it would be a nice addition.