I am using Qt in order to build a cross platform GUI app (Windows and Mac). I want to be able to update the app efficiently and automatically whenever there is a new patch available.
I saw this post which got me to take a look at WyBuild. It looks great and probably what I may end up using for the Windows version but what about Mac? What are some alternatives available to me?
I've just started developing a Qt-based autoupdater called Fervor for my own needs. You can try it out, contributions are more than welcome too.
For Mac the best choice is Sparkle used by WebKit, Adium, Cyberduck and more. Its only for Mac but I guess native look matters on Mac a lot.
Not familiar with WyBuild so cannot comment. Sparkle is a fine choice but the poster preferred a single app for both platforms. BitRock InstallBuilder contains an autoupdater written in Qt that can be used independently (disclaimer, I am the original BitRock developer). It is a commercial app, but we have free licenses for open source projects.
There is Updatenode which seems to provide a real Qt cross-platform solution.
It comes with a prebuilt client for Windows, Mac and Linux. The online service lets you manage updates very easy and are able to see good charts of your application usage.
And here another one of the possibilities:
Using the Qt Installer Framework: It provides installers for Windows/Linux/Mac with an build-in updater. If you need an example - The MaintenanceTool of your Qt-Installation uses the framework.
To get an auto-updater from it, all you need to do is:
Create an online installer (Just check the documentation, it's not that hard)
Use the maintenancetool in your application to check for updates.
This cane be done using my QtAutoUpdater. Go there for more information about the whole process
If new updates are available, the maintenancetool can be started in updater mode to install the update
Update the online repository - and your update is out.
Advantages:
Installer and updater in 1 tool - this means less work for you
Easy to use (with or without the QtAutoUpdater library)
Cross-Platform for all desktop platforms supported by Qt
The installer itself is a Qt original
Disadvantages:
No "native" installers (i.e. no .msi on windows or .deb on ubuntu)
Must be used together - if you want to use the update feature, you have to use the framework as installer
This may be obvious, but for Linux you can use the built in package manager. For example, apt-get, yum, pacman, or what have you.
Related
I wrote a WPF program using .NET 5, packed it into the MSIX bundle (Release, x86 and x64) as a framework-dependent package. Everything seems fine, but there is one very annoying thing: on the first run the app says ".NET runtime is missing, would you like to install it?”. If you click yes, the download page opens, where the user has to select the needed runtime, download, and install it. Not the best user experience, I'm thinking about how to improve it.
Is there an option to add .net 5 runtimes (x86 or x64 depending on the user system, or maybe both) as a dependency so it installed automatically?
I know I can define dependencies, but how can I find the right name for the needed dependency?
Also, I know it's possible to define custom install action but I haven't tried it yet, because I want to find a simpler solution. Looks like for that option I'll have to create a small app or script that will check if the needed runtime exists and if not - check the platform and ask the user to install the specific version of the runtime. Not the best user experience too.
Of course, I still have an option to go with self-contained, but I don't want to distribute so many megabytes of .net every time, especially given the fact that I expect frequent updates.
Luckily, I got an answer on techcommunity.microsoft.com
Thanks to Matteo Pagani:
if it's an application based on .NET Core / .NET 5 (as I seem to understand from the description), the suggested and best way to distribuite via MSIX is to use the self-deployment approach. Thanks to MSIX features like differential updates and single disk instance, you don't have to worry too much about the increased size, since the runtime will be downloaded only at the first install.
Dependencies are not a good fit because there are no packages for .net 5 yet.
Custom install actions are possible but more complicated, so I decided to go with self-contained.
I got an app, that is ready to release. On windows, I simply type 'windeployqt.exe MyApp.exe' inside 'release' folder of app build in special qt cmd. I'm trying to do the same on kali linux (I dont have time to install other deb based distro). I'm searching for solution for three hours, and I cant find anything good. So, how to make application executable on other linux computer without Qt Creator installed?
There are many ways to deploy Qt applications on Linux. AppImage created with the help of linuxdeployqt or linuxdeploy-plugin-qt is one option, perhaps even the simplest one but it has its drawbacks. From my personal experience I can think of two:
Your app won't generally be able to use native icon/font/other themes.
Sometimes your AppImages might occasionally cease to work due to some unexpected system update which would, for example, break the binary compatibility of OpenSSL libraries.
Other packaging options for Linux include:
Linking the application with static version of Qt. It is the
approach used e.g. by Telegram. The instructions can be found
here.
Beware, however, that using this approach for commercial closed
source applications generally requires commercial Qt license.
Probably it is possible to get away with LGPL but it would be very
cumbersome: you'd have to provide customers with compiled object
files so that they can replace them and re-link the app. Also beware
of the fact that if the application you intend to create is going to
be an open source one, the maintainers of Linux distributions would
generally not agree to distribute statically linked applications -
that violates the basic rules for many distros according to which
applications should not bundle their dependencies but instead should
use the system provided libraries. It is important from e.g.
security perspective - if some security threat is found in Qt in
future, it can be fixed within a Qt library itself and all
applications using that library would then also be secure -
something not that easily achievable with application built with
static version of Qt.
Creating native packages for target systems - i.e. deb packages for
Debian/Ubuntu systems and their derivatives, rpms for Fedora,
OpenSUSE and other rpm-based distros,
PKGBUILD for Arch
Linux and various other kinds of packages for various other distros,
hundreds of them. The advantage is good integration with the rest of the system: native themes etc. Also you get all the advantages of the security fixes for shared libraries.
Using flatpak or snap packages - these are modern app packaging formats developed by RedHat and Canonical respectively with the goal to simplify the management of app's dependencies.
Using the generic approach using shared libraries - with this approach you'd need to package your app as an archive containing a directory containing you app and all its dependencies in the form of shared libraries - something similar to the approach of deployment on Windows where you put the dlls alongside the app.
I would recommend trying an AppImage first and then creating native packages for target distros.
Our company ships 2 Qt applications, for now, using Qt5.6 but in some time there will be more (using newer Qt versions). So the problem is, how to make them work all together with different Qt versions? We won't be able to rebuild all Qt apps shipped before, especially if there will be plenty of them. I don't think it's a good idea to place all necessary Qt libraries with each app because the repository size will grow fast. And I think it's just not wise to have many Qt dlls of the same version at one place. As long as I know, .NET solve such problem of different versions with assemblies installer, but I don't think it can help me with Qt. So any ideas of how can I solve it would be highly appreciated. Thanks
UPD: The system is Windows
Actually an answer is quite straightforward, you can ship one Qt version (binaries) as long as they are binary compatible. With each release Qt announce binary compatibility or non-compatibility, so if for whatever reasons you need to switch to newer version and ship new applications with newer not compatible version you might want to ship a new Qt DLL chain.. This can be achived differently (depends on how you layout you install), for example you can have a common lib dir with sub directories based on Qt version which you will extend. (of course you will need appropriate PATHS set then running different applications) :
app\
app\app01
app\app02
...
lib\
lib\Qt5.6.1
lib\Qt5.7.0
etc, then you will have (for example) to wrap your exe files to .bat like:
run.bat
SET PATH=....\lib\Qt5.6.1\
app01.exe
etc..
it's all depends on your install layout and goals
I have a project which is using Qt 4.7.4 version (also I can't rebuild it using qt4.8 or qt5 – there are a lot of errors appears, project is big and not mine so fixing issues would be even harder than erasing the whole code and write new code). So I need to make this project, well, working on NativeClient.
Is it even possible? I use Windows and Visual Studio, I was trying to google instructions about qt+nacl on Windows but just can’t find nothing.
Also which pepper version should I use if it depends on it?
Is your qt build supporting native client?
Please check out this
Windows
The Qt-Nacl is not support, for now, in Windows.
By the way, here is the github repository dedicated for it -> https://github.com/msorvig/qt5-qtbase-nacl
In the file nacl-readme it is written :
[...] Windows is not supported as a host platform.
Linux
If you want to compile in Linux, I have made a script that will compile Qt5.4 with NaCl with all the dependencies needed.
https://gist.github.com/theshadowx/438297ac465874a5e226
I also made a video that will show the different steps and a showCase at the end :
https://www.youtube.com/watch?v=q2pMv1Svtqw
I'm starting a new development position with a company that implements many of its products in Adobe Flex. What tools should I look to install (Ubuntu Linux options prefered) for Flex development?
As dirkgently said, installing Flex Builder 3 in Linux is a great way to get going. It's quick and easy to get up and running, and since it's based on Eclipse, the overall environment is decent.
That said, I was able to put together a decent Flex-building environment using Emacs and some third-party packages to get everything running under Linux.
Here's a quick rundown of what I used (this isn't comprehensive--just what I can remember):
Flex 3 SDK for Linux
actionscript-mode.el for AS code
highlighting
nxml bundle for MXML code
highlighting
ani-fcsh.el for running fcsh
from Emacs
ECB for code browsing in Emacs
snippet.el for creating code
templates in Emacs
This link was also helpful for getting started. It links to this article which talks about putting together a Flex development environment in Linux. I was able to put together some shell scripts for compiling and running applications.
Note: I didn't do any debugging, though Adobe has some info about it.
Note #2: If you decide to use Flex Builder, it will install the Flash Player 9 debugger version in your browser (you can tell it not to). I would recommend installing version 10's debugger. The builder will output a warning about not supporting the version, but everything else appears to work.
If you can, try Flex Builder 3 alpha for Linux. That's the you can get (not without its set of pet peeves though!). It lacks the following however:
* Design view
* States view
* Refactoring
* Data Wizards
* Cold Fusion - Data Services Wizard
* Web Services introspection
* Profiler
Since AIR/Flex are cross-platform technologies, I don't see why you want to limit yourself to Linux. At least for the time being, I think you are better off with the proper Flex Builder 3 on Windows for development. You can then test your product(s) on Linux.
about debugging - there is an external AIR debugger called MonsterDebugger which is pretty good