I have created an app package from a win32 app using the Desktop App Converter. It needs to install two truetype fonts in order to display music. It uses the windows.sharedFonts extension in the AppxManifest.xml for this purpose. When I submit to the store I receive the following error:
Package acceptance validation error: You can't use extension windows.sharedFonts with this account. Contact our support team if you'd like to request permissions to use this extension.
Is there a better alternative to install these fonts? Otherwise how do I best contact the support team?
You could contact the dev centre team via aka.ms/storesupport the same as one would for any other publishing permissions issue.
If you only need the fonts in their app then you can include them there and use them directly. SharedFonts is only needed to provide fonts to other applications on the system.
First of all, to create an appx/msix package you should start looking at the MSIX Packaging tool (now publicly available, not just for Windows Insider) or free tools like Advanced Installer Express (recommended by MSFT), the Desktop App Converter is kind of discontinued.
Now, regarding fonts, as you can see in this thread on the MSIX community this is on their roadmap for MSIX packages. I haven't test any older appx packages, but since MSIX is an update for AppX I doubt they ever worked for packages created with the Desktop App Converter either.
Disclaimer: I work on the team building Advanced Installer.
Related
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.
Is there any script or example of Qt installer framework for "Un-installer"? I want to remove some folders using the maintenance tool.
According to the official documentation for Qt installer framework, the "uninstall" part is simply built in. Running the maintenance tool after install will provide the end user with the option of removing components or the entire package.
So for each component you have previously specified in your configuration, it will automatically show up as something that you can un-install.
Here is the screenshot from the documentation for reference:
Our company's svn cannot allow single file larger than 40mb, realm framework needs 140mb+，so how can I build realm-cocoa with source code on github?
You could instead use the dynamic framework, which is a lot smaller (28,5 MB), through being already linked, but you won't be able to support iOS 7 in that way.
Alternatively I would recommend using a dependency manager like CocoaPods, which helps you with the setup and integration. But as a Core Member of this project, I'm obviously biased in that regard.
If that shouldn't be available for you, then you could theoretically use SVN externals to checkout the realm-cocoa repo (GitHub supports SVN transports), add the Realm.xcodeproj to your Xcode project, set the iOS framework target as dependency target of your app target and link to Realm.framework. But please not that this is not an officially supported way of integration.
I just want to use source tree which installed on windows machine . But my requirement is to integrate source tree into spring tool suite and need to access source tree from STS ..
How do i do that .. any help Appreciate.
Source-tree seems to be a standalone Windows app that functions as a client for git or mercurial. So I don't think you can 'integrate' STS or Eclipse with sourcetree. However...
Eclipse and STS already has tooling for 'git' called 'egit' which is installed by default. So if you are using git, then there is nothing to do as Eclipse 'egit' already provides git integration. Egit works fairly well and I use it myself.
For Mercurial there are also integration options available. For example:
MercurialEclipse. You can install these on top of STS (or Eclipse). I don't know how good it is as I haven't used it myself. You can also do a google search to try and find more Eclipse plugins that support Mercurial.
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.