I read about the architecture of Gobject introspection.
On one side i have a .so dynamic library, on the other side i have a gir file (some sort of xml file) for javascript bindings, which leads to the compiled typelib file.
Most of my typelib files are in the directory /lib/x86_64-linux-gnu/girepository-1.0
for example WebKit2-4.0.typelib.
how do i know, that i have to use, (where are the definitions?)
const Webkit=imports.gi.WebKit2;
because i tried
const Webkit=imports.gi["WebKit2-4.0"]; or
const Webkit=imports.gi.WebKit;
if i use imports.gi , gjs searches for a typelib file. The directories where it searches, i can get with
Gir=imports.GIRepository; log (Gir.Repository.get_search_path());
for other ids then 'gi', imports[directory][...][filename], it searches in the directories defined in the array imports.searchPath for a Javascript file, right?
last problem - the references on gjs page: there are a lot of functions, which exists in the references, but then are not available. Are there any other good references outthere, with examples?
how do i know, that i have to use, (where are the definitions?)
Probably the easiest way to find a GIR import name you don't know is by browsing the API Documentation, such as for WebKit2. Of course, you'll have to have the appropriate packages installed for those libraries.
for other ids then 'gi', imports[directory][...][filename], it searches in the directories defined in the array imports.searchPath for a Javascript file, right?
Yes, the imports.searchPath array is for JavaScript sources. You can read about those imports in the GJS project documentation.
the references on gjs page: there are a lot of functions, which exists in the references, but then are not available. Are there any other good references outthere, with examples?
You'd have to be clearer about which GJS page you're looking at and which functions. Below are some links to documentation for GJS:
gjs.guide (Tutorials, topic-specific guides, tips and examples)
GJS Project Documentation (Documentation about GJS itself)
API Documentation (Documentation for introspected C libraries)
We also have Matrix channels for GJS where you can ask for help:
https://matrix.to/#/#javascript:gnome.org (JavaScript)
https://matrix.to/#/#extensions:gnome.org (GNOME Shell Extensions)
Related
Hydra provides a way to dynamically create a hierarchical configuration by composition and override it through config files and the command line, leveraging OmegaConf. I look for a recommended way to document the parameters but I could not find (a documented) one. What are best practices for that? Coming from argparse, I like the way of documenting the parameter inline, i.e. close to the code.
Excellent question! The answer is: parameter-by-parameter documentation is not yet implemented (as of Hydra v1.1, OmegaConf v2.1).
The future plans are:
in OmegaConf, expose an API allowing users to attach documentation (and other metadata) to each field of a structured config. See this open OmegaConf issue.
Once the above is complete, implement a Hydra feature allowing a parameter-specific help messages to be printed based on the parameter's metadata. See this open Hydra issue.
For now, the best we can do is to customize the general application help message (i.e. the --help command line flag).
I am creating an application in Qt which can be used by users to read some confidential text file. The idea is that if a user wants to access this file, he can only do so through this application and not read it directly. I am planning to add this file using qrc resource.
What I would like to know is that:
Is it possible for a user of the application to somehow "extract" the embedded resource from the compiled executable?
If so, in order to prevent this, is it possible to encrypt or hash the said resource before compiling?
P.S.Maybe someone out there has already faces this scenario and came up with a better solution then what I am thinking. If so, new ideas are always welcome.
Depending on your level of expertise, you could make retrieving the text a bit more difficult, but you won't get a secure result this way.
rcc (Qt's resource compiler) tries to compress a resource and if the resource compresses to less than 30%, it will compress the resource. Otherwise the resource will go uncompressed into your executable. As a starting point, you could persuade rcc to always compress by calling rcc with option -threshold 1.
Next you will have to make sure, that all debug symbols are erased from your delivery, otherwise an astute code reader will do something like this:
objdump -all-headers your.app/Contents/MacOS/your | grep qrc
and will get something like this:
00000001002162f0 l F __TEXT,__text __GLOBAL__sub_I_qrc_resources.cpp
Where 00000001002162f0 is a good starting point for disassembling your executable.
Still: Even if you remove all debug symbols, your resources will always pop up in the DATA section of your code.
So even if you are following this and further advice people might give, it's just obfuscation. Welcome to the wonderful world of cryptology and steganography.
I usually follow the unofficial Meteor FAQ on how to structure my codebase, but I can't figure out where I should put my global constants.
To give an example: I have some database entries with a constant GUID that I need to reference in many points of my app. So far I just attached the constants to the relevant collection, such that in collections/myCollectionWithGuids.coffee it would say:
#MyCollectionWithGuids = new Meteor.Collection "myCollectionWithGuids"
#MyCollectionWithGuids.CONSTANT_ID = "8e7c2fe3-6644-42ea-b114-df8c5211b842"
This approach worked fine, until I need to use it in the following snippet, located in client/views/myCollectionWithGuidsView.coffee, where it says:
Session.setDefault "selectedOption", MyCollectionWithGuids.CONSTANT_ID
...which is unavailable because the file is being loaded before the Collections are created.
So where should I put my constants then, such that they are always loaded first without hacking in a bunch of subdirectories?
You could rely on the fact that a directory names lib is always treated first when it comes to load order.
So I would probably advise you to organize your code as follow :
lib/collections/collection.js
client/views/view.js
In your particular use case this is going to be okay, but you might find cases when you have to use lib in your client directory as well and as the load order rules stack (subdirectories being loaded first), it will be loaded BEFORE the lib folder residing in your project root.
For the moment, the only way to have full control over the load order is to rely on the package API, so you would have to make your piece of code a local package of your app (living in the packages directory of your project root).
It makes sense because you seem to have a collection and a view somehow related, plus splicing your project into a bunch of collaborative local packages tends to be an elegant design pattern after all.
Creating a local package is really easy now that Meteor 0.9 provide documentation for the package.js API.
http://docs.meteor.com/#packagejs
I would put your collection definitions in a lib directory. File structure documentation explains that all files under the lib directory get loaded before any other files, which means your variable would be defined when you attempt to access it in your client-side code.
Generally speaking, you always want your collections to be defined before anything else in your application is loaded or executed, since your application will most likely heavily depend upon the use of the collection's cursor.
I've developed a program and I am trying to make this program work with a controllable light source manufactured by some other company. I've emailed the company and they have agreed to send me their external library as a DLL.
I have developed all of my software using Qt 4.8.1 and it has been compiled using MSVC2008.
The controllable light's DLL was compiled in Visual Studio 2008 and was written in either C++ or C# (the manufacturer is uncertain). All I have been given is the DLL and a text file saying that I must:
Add the DLL as a reference to my project
Add using LightName; to the top of the class
Instantiate an instance of the object like so: LightName *ln = new LightName();
Call function void turnOn() with the newly created LightName instance.
Firstly, I find it odd that an external library requires me to instantiate an instance of their object especially when its for a simple piece of hardware.
Secondly, the other company has provided me with no interface files.
My question is:
How can I possibly link to a C++ DLL and expose the functions nested in this library without having an interface header file in a Qt environment? Is there someway to make an interface for an external library?
I have already attempted using QLibrary and doing the following:
QLibrary myLib("mylib");
typedef void (*MyPrototype)();
MyPrototype myFunction = (MyPrototype) myLib.resolve("mysymbol");
if (myFunction)
myFunction();
However, this doesn't work because the DLL I was given was not a C DLL and I have no interface so Qt doesn't have a clue about what symbols it needs to resolve.
I've attempted to display all the definitions exported from my DLL using the dumpbin /EXPORTS command. Unfortunately this was unable to produce anything. I was hoping that I would get some sort of mangled C++ from this that I could then unscramble to make my own header.
I've attempted to use the dependency walker(very useful tool) however it couldn't resolve any symbols to give me some function definitions.
QLibrary only helps you if the library has functions exported as C symbols. If that is C++ you can dump the symbol table and look if that is sufficient for you. Names must be demangled: try to look for dumpbin or similar. It is however possible that you can't do this, it depends on how the symbols have been defined. In that case you'll have to ask for the header: read this.
Well it's absolutely legal to ask you for "instantiating an instance of their object". It's been simply their design decision to make the dll interface object oriented (as contrary to plain extern "C"). QtCore.dll is just someone else's DLL too, and you are instantiating their objects all the time.
But it also means that you will have harder time to call the DLL. The symbols are not "C" symbols (you can't export class that way) so QLibrary can't do anything for you. You can try dumpbin /EXPORTS from the DLL and then tediously unmangle them to reconstruct the class declaration. Luckily there are tools to help you (even online)
But not providing a header file for such DLL is completely dumb in the first place.
We are creating ReST Web Services using ASP.NET and OpenRasta.
Is there any tool that can could help us:
create WADL file
or/and create human readable API documentation similar which decribed resources/HTTP
methods supported for each resource, etc ?
Looks like REST Describe & Compile should do the trick.
On the WADL developer site Marc Hadley
maintains a command line tool named
WADL2Java. The ambitious goal of REST
Describe & Compile is to provide sort
of WADL2Anything. So what REST
Describe & Compile does is that it:
Generates new WADL files in a completely interactive way.
Lets you upload and edit existing WADL files.
Allows you to compile WADL files to source code in various programming
languages.
For OpenRasta, it'd be possible to use a UriDecorator to have help-like URIs defined for your resources (such as /myResource$help). You can then rewrite the URI before parsing to something yo can document easily, parse teh uri, find the resource type, and rewrite to /help/{resourcetype}
From there you register a resource for your help system:
ResourceSpace.Has.ResourcesOfType()
.AtUri("/help/{resourceType}")
.HandledBy()
.RenderedByXxx()
Then you can create your handler to return the documentation about a resource. You could for example use the IOperationCreator service to know which http methodds are available and with what input arguments, use the ICodecRepository to see what media types may be accepted as input, and potentially what a media type serialization would look like by calling the codec and generating an html friendly view of it.
That's definitly an area we're going to work on for the next version.