Please let me present the idea. I would like to build a Qt app which allows the user to load functionality from a external file (.dll ?) while the app is running. The file could be downloaded from the internet.
I'm planning to build the user interface with QUiLoader and I think the functionality should come from such an external file. Does it make sense?
As an example, to begin with, I'm imagining to provide the user simple functionality like sum and multiplication. And other functionality should be provided afterwards.
Since I have no ideia where to begin (as the question might suggest), I'm here to ask for directions?
Yes, what you need is a plugin mechanism.
For developing a plugin, you should decide how those plugin to be load and to get information from plugin, i.e. you should define a interface first hand, by that interface, your program can communicate with plugins developed by others.
Related
I wonder if it is possible to create an application as a plugin so it can be use inside another Gui application. Something like a media player with Qml in front (not widgets) inside a digital instrument cluster so that we can load/unload it whenever we need.
I know about shared objects and routine of making a c++ plugin.but I need GUI/qml apps as a plugin. Please let me know if it is possible and the steps required?
Thanks
You can create your (almost) whole application as a plugin. But you will at some point need an executable to load your plugin.
But making your whole application as a plugin isn't the best way. Only use plugins for the parts of your application that you will change, so that you only have to update the plugins file that are dynamically loaded, and let the rest stay static.
Now you also need to do some research by yourself, read the documentation, find out how to make and use a Qt plugin... Your question isn't specific and answers are not tutorials...
I'm creating a bukkit plugin that's making a world in Minecraft outside the ordinary and that includes having NPCs (bots) entities that look like actually players and not villagers. I've already got the bots working programming wise but I want to have each bot have a different skin based upon it's name. Can I do this with maybe a resource pack or something? currently they take the names of Minecraft players with the same name but I'd like to override this.
TL;DR
Can I change the appearance of player entities by name with:
a Resourcepack?
a server side command?
playerConnection.sendPacket?
This is currently not possible without modifications to the client. If you want to, you can use Spoutcraft, but this requires users of the plugin to have the Spoutcraft launcher for the textures to show correctly.
There's no way to do this with the vanilla client, however, short of buying a bunch of Minecraft accounts and assigning them appropriate skins.
You should try out the DisguiseCraft plugin for a quick fix. DisguiseCraft is currently available on the Bukkit website. Do keep in mind that it also requires ProtocolLib to function properly, and you will need to have both installed on your server. You may find a link for ProtocolLib through the DisguiseCraft page. I currently use the two on my server and have had no issues with functionality.
If you would prefer a more direct approach however, since you are coding your own plugin, consider looking over the Lib's Disguises Developer API. Like DisguiseCraft, it too requires ProtocolLib, but the source for Lib's is publicly available and is intended to target developers. Just like DisguiseCraft, you may find a link for ProtocolLib through the Lib's page.
I've already written some backend *.dll files that I intend to use in a project. I need to visualize a simulation of the code, for which I intend to use charts and graphs from Chart.JS, by using it along with TideSDK for a desktop application.
I have no clue on how to call the C libraries via JS though. And I want to avoid creating wrapper classes in Python and going through that circuitous route. Any other options? Or are there any alternatives when trying to create an HTML/CSS/JS desktop application connected to a backend C/C++ library? Will AppJS make things easier?
TideSDK is capable of extension with modules that can be compiled and included in its runtime. It was written to be extended but I would recommend waiting for TideKit. TideSDK is a bit old and setting up a toolchain could be problematic at this point.
We've been investing in a broader vision with TideKit that is getting ready for release. You will be able to extend it with native modules and you won't need to wait too much longer to see what we've been up to. http://youtu.be/aE7gN-d0GhUthat
If you have started anything with TideSDK, you will be able to migrate your code easily to TideKit. The ability to work with with native or JavaScript modularity, and to develop for all screens from a single project code base is where all our efforts have been going.
Note that AppJS was discontinued earlier this year. An alternative is writing C extensions in node through node-webkit. Note that if you are going cross platform on this and you needed OSX as well, you cannot achieve Apple AppStore compliance with node-webkit due to private APIs as a result of its port of webkit.
I have been experimenting with WinRT components using C#, C++/CX and WRL in C++. So far I managed to do everything I tried even if compared to COM some stuff have changed and are either confusing or frustrating.
The last thing I'm trying and that so far I couldn't do is a basic architecture pattern of COM. I simply want to create an instance of a WRL component without referencing the DLL in the project which is using the component. As far as I remember this is the basic behavior of COM, provide the GUID of the CoClass of the COM, the using program knows only about the interface and CoCreateInstance will dynamically loads the COM and create an instance attached to the interface you're requesting.
I cannot find how to do that with WRL. I have defined few simple interfaces and I cannot even find them in the registry. However as it is possible with COM to use object without the registry and that there is now window metadata I suppose that this is the reason.
Does someone out there knows if this is not a restriction of WinRT (which would make it a very poor architecture...) or in the case it is possible how to achieve late binding with WRL.
To make it clear, in the calling program I would like to only provide the information of the interface (this can be the .h) then I need to be able to create an instance of the WinRT component using its GUID or a moniker name. This is an architecture pattern I have used in C++/COM, C# and Java as you can write an application and support new features without touching a line of the application, not even recompiling it.
Thanks
O. Rouit
So far it's unclear what you're actually trying to do. WRL is just a C++ helper library for WinRT, if you're using C++ (think of it as WRL-is-to-WinRT-as-ATL-is-to-COM).
Let's take C++, since that's the 'most raw' and has no vm or runtime like C# or JS. You're trying to instantiate a WinRT object that you didn't link with? If so, that's simple - ActivateInstance(activateableclassid). The real question is what are you trying to instantiate? If it's a 1st party (inbox/Windows) component, it should just work. This is very much like COM, where there ACID is like a CLSID and ActivateInstance() is like CoCreateInstance().
If you're trying to instantiate a 3rd party WinRT component (not shipped w/Windows), it's a little simpler. The ONLY way to register 3rd party WinRT components is by including them in your package. Packages are isolated from each other, so you cannot have, e.g. AngryBirds deliver a FOO WinRT object and use it in an app in the Scrabble package. Unlike COM where registration is machine wide (or in the rare even you register under HKCU instead of HKLM, user-wide), WinRT 3rd party (package'd) WinRT objects are only registered for use by apps in that package.(1)
(1) That's a little white lie. Technically your application can instantiate WinRT components provided with Windows and WinRT components provided by packages in your package graph. You can make a Framework package which includes WinRT objects, and have your application's package dependent on that. Windows figures our your package depends on the framework and thus your 'package graph' has 2 packages in it -- your app's package and the framework package. BUT you cannot submit Framework packages to the Store. Local development and enterprise/side-loading deployments can do this (they don't go through the Store and thus don't need to meet Store submission criteria), but any application package submitted to the Store can only depend on the Windows provided frameworks (WinJS, VCLibs, PlayReady/DRM). That's how PlayReady works - it's a Framework package containing (among other things) some WinRT objects; if your application's package declares a on it your package graph will contain 2 packages (your app's package + playready's package), and ActivateInstance() can resolve ACIDs across the union of packages in your package graph.
There's a lot of protections built into the application model. This is one of them. This prevents 'COM Hell' and 'DLL Hell' - everything's fine, then 6 months later you install app Y and for no apparent reason app X no longer works. The new appmodel is designed to prevent that scenario.
Another protection is the limitation of where package'd WinRT objects can be found. Even if you put a file in your app's local folder (e.g. ApplicationData.current.localFolder), ActivateInstance() won't find it. WinRT doesn't look under AppData (or oodles of other places) for registered WinRT objects -- only those in your package graph (and 1st party (Windows) components provided with the OS, e.g. StorageFolder).
provide the GUID of the CoClass of the COM, the using program knows
only about the interface and CoCreateInstance will dynamically load
the COM and create an instance attached to the interface you're
requesting.
The WinRT equivalent is to provide the ACID of the runtimeclass of the WinRT [component], the using program knows only about the interface and ActivateInstance() will dynamically load the WinRT [component] and create an instance attached to the interface you're requesting.
The caveat is, the WinRT component's implementation must be registered in your package graph, i.e. must be listed in your app's package's AppXManifest.xml, or a dependency's AppXManifest.xml.
That's at the most raw level, if you deal directly with WinRT at the ABI level. C++ projections are equivalent, just more convenient syntax. The CLR and JS runtimes provide their own additions and variations of enforcement (e.g. search for "windows 8 javascript local vs web compartment") but they just further color the behavior. They can't overrule the underlying OS' baseline behavior.
As Damir noted
You won't be able to put new files to install folder any other way and
that's the only location from which executable code can be loaded by
the app.
"Executable code" comes in varying forms, depending on your definition.
WinRT components can be loaded from other places (Windows provided WinRT components, dependent packages e.g. the PlayReady framework package).
(Non-WinRT, non-COM) 'native' DLLs can be loaded from other places (executable's directory, System32, etc). See Search Order for Windows store apps.
.NET assemblies in DLLs have their own similar restrictions e.g. Assembly.Load().
Some people consider Javascript "code", and there's the whole local vs web compartment thing to further color where code can be resolved from.
As a general rule, you can dynamically load code in a variety of ways, but it needs to be known code. There's no supported way you can create e.g. a C++ app that will load DLLs (WinRT or non-WinRT) that's not known at Store submission time. You can write an app using optional (conditionally loaded) code, you can have 'plugins' -- but they need to be in your package when you submit to the Store.
You can't build e.g. Outlook as is today, where Outlook is submitted to the Store with an open-ended plugin model and sometime later install an OutlookNiftyCalendar add-on which Outlook could find and use. Not in Windows 8.
(there are some ways you can bend this rule a bit in a Javascript app via web compartment, but that's a complex topic in its own right, and even that has limits both hard and soft/policy. And irrelevant if you're not writing a Javascript applications)
Does someone know if there is a way to pack everything-application related into one (single) exe-file?
My product is fully written in C++, has a lot of external plugins (dll) and some external data packages. It should be accessible using the network and without installation (launch in one click).
Are there some tools to make something like virtual filesystem and unpack everything application-related to memory?
Or probably I have to somehow (manually) integrate all the dlls and the data? Is this possible?
Thank you
Try an .msi file, or ClickOnce deployment (assuming Windows, assuming at least VS 2005).
Edit: Based on a comment below, I don't know in general if you can do exactly what you are asking with an arbitary set of DLLs. You can include, say, Microsoft Foundation Classes statically rather than dynamically. But the distributor of a DLL may not want to allow complete incorporation into your code. Even if you could, you might be running against license agreements and the like.
Not sure if that's what you want but UPX is made to generate a single exe from an application made of several ones : http://upx.sourceforge.net/
However if you want a virtual folder system, maybe you just need to use PhysicsFS ? http://icculus.org/physfs/
Anyway your question is not really clear...