The vapi file that is available for librsvg-2.0 contains a lot less than what the actual library contains
vapi: http://valadoc.org/#!wiki=librsvg-2.0/index
library: https://git.gnome.org/browse/librsvg/tree/
I would have expected to have access to components like an RsvgNode to be able to access and alter the SVG contents directly, but neither the vapi nor the header files that are installed with the devel package contain a lot of what's in the library headers. I assume this has something to do with making the library GObject friendly, but I'm interested in more than what's there.
Is there a way to add headers, extend the vapi, and use the structs and functions that I need?
It's possible that this is not even what I should be doing, the contents of the library use the G_GNUC_HIDDEN macro pretty liberally suggesting that they don't want to give you access. But then I'm wondering how you can edit an SVG document/element live while displaying it in a Cairo context? I'm sure I could edit it using libxml, but I don't know how to refresh the context without reloading the SVG data and recreating the surface.
Thanks.
Just asked Christian Persch about this on IRC. His response was:
that's right, all that stuff is not exported, and it's not in any state to be exported. there is no way with librsvg to change the svg without creating a new context and loading the new svg xml into it
If the library doesn't export the stuff on the C level there isn't really a lot you can do at the Vala level. Creating bindings wouldn't be very difficult, but the API that it binds really needs to be public.
Depending on your use case, perhaps you'd be happier using Clutter?
Related
I'm building up some Dart code that I would like to use in an app where it is essentially a library to the javascript. I'm wondering how I can specify which Dart files I'd like in the project to be part of the library. For example, theres Foo.dart and Bar.dart. How can I have the created product include both Foo.dart and Bar.dart in one file? I'm also concerned about tree shaking since none of the classes are instantiated in Dart.
There's also a Baz.dart, and I would like to have a different build for compiling Foo.dart and Baz.dart into a single file (though this is less important, as I can accomplish this would separate projects and some symlinking).
Thanks!
This use case (build a JavaScript library with Dart) isn't supported yet.
The reworked js-interop package is supposed to allow to do that but I don't know about it's current state.
Working on a large open-source project, we've hit this problem, so this makes a good case study / example:
Our library implements SVG spec
SVG Spec is defined as "including" the DOM and CSS Specs
DOM Spec requires a DOM implementation, but Apple refuses to share their DOM implementation on iOS
We had to re-implement DOM in ObjectiveC, so we could correctly implement SVG
But Apple has accidentally/deliberately put some classes in the global namespace that use the reserved names from DOM. It is impossible for anyone to make a new class with those names
Our current workaround:
We rename affected classes from e.g. "Name" to "AppleHasConflictedThisInGlobalNameSpaceName". Yes, it's not the politest of messages, but it explains to newcomers why we've had to deviate from the spec!
With iOS8, Apple's done it again, and added some more classes with this problem, including "Comment". (Apple? Really? Oh, come on, guys! Think before you spam the global space!). This is getting harder to workaround.
Normal solution: Since C/ObjC has no namespaces (sob!), we'd prefix every class. SVG Spec has an official prefix - "SVG" - which we use. For non-spec classes, we have a longer prefix that's probably unique to our open-source project.
But for DOM, we are including our own DOM implementation, and it's possible that a developer's project might have a different, proprietary DOM implementation. Sensible prefixes are hard to come up with here. Apple has already reserved "DOM" as a prefix on Obj-C platforms.
If we took the prefix "SVGKitDOM", which would be the smallest correct prefix name, that triples the length of the classnames from DOM (!), and often makes the code unreadable. It's also against Apple's preferenece of 2-3 letter prefixes.
The project is open-source, so technically: anyone can global-rename the source to anything they want. But this is a huge pain for people to maintain.
I've been thinking of clever macroing workarounds - e.g. #define OPTIONAL_PREFIX DOM / OPTIONAL_PREFIX SVGKitDOM / ..etc that allows users to quickly rebuild the whole DOM and the dependent SVG libraries in one step with whatever prefix they need.
...but this still seems errorprone and messy. And it'll make new commits a knightmare: we'll have to educate every committer in how to use macros in every classname (if that even works with ObjC).
Argh!
There must be an easier way? Namespace conflicts have been a problem for 30+ years now :).
NOTE: This is Objective-C, so it's a superset of C, but the linking process is not a superset - For instance, Apple bans everyone from dynamic linking. So, we need a solution that's static :(.
Perhaps, you could use the not often mentioned #compatability_alias attribute, as follows:
File: PrefixedHeader.h
#interface my_longly_prefixed_ClassThatDoesSomething : NSObject
#end
File: ConvenienceHeader.h
#compatibility_alias ClassThatDoesSomething my_longly_prefixed_ClassThatDoesSomething
If the user has their own proprietary DOM implementation, then have them not import the convenience headers, otherwise do.
Would this work?
I'm working in a iOS project that includes a static library created by another company.
The library include an old version of AFNeworking and I don't have any source files.
Now i need to use a more recent (and less bugged) version of afneworking, but i cannot include the same class twice in the project (of course) because all the "duplicate symbols".
I understand that it's impossible replacing the version included in the library, but how can i include another version along the old one?
There is a (easy) way to refactor the entire framework before include in my project?
thanks
You'll have to repackage the static library to remove the embedded AFNetworking files.
Unpack the library with:
$ ar x libwhatever.a
And re-package it, including all files except the AFNetworking object files:
$ ar cr libwhatever.a file1.o ... fileN.o
You will then have to link your executable with the new AFNetworking static library and hope that there haven't been API changes which will break the code in libwhatever.a. If there are then I doubt there is much you can do.
I'm afraid this isn't easy to do. Very few environments allow you to link against two separate versions of the same framework at the same time, and Xcode / iOS is not one of them.
As I see it, you have three options:
1) Link against their library and use the same version of AFNetworking they use.
2) Link against their library, and manually load the newer version of AFNetworking and pull symbols from it. Be warned: this will get ugly fast and future maintainers will wonder what you were smoking.
3) Get them to update their library.
On a side note, I don't know the circumstances here, but in general they should be providing you with sources. It's a very backwards practice to provide only a static (static!) library and no way to know what it's doing inside. You'll have to sign a software license agreement and whatnot to protect their interests.
The best and most proper way of handling this would be to contact the the creator of the static library and get them to resolve the situation. They could resolve it either by updating the embedded version of AFNetworking, removing their dependence on AFNetworking, or adding a prefix for their embedded copy of AFNetworking. The last one is probably a good idea anyway when a third party library embeds a different library, because otherwise it would be impossible to use two libraries simultaneously that both include the same third party library.
You could also refactor the copy of AFNetworking that you include yourself to change the names of classes to have a prefix, although this should be unnecessary, as the static library vendor should have done this themselves already.
Lastly, you could find a different library that accomplishes the same thing as your current one but that doesn't embed AFNetworking.
Beyond allowing one file to use another file's attributes, what actually happens behind the scenes? Does it just provide the location to access to that file when its contents are later needed, or does it load the implementation's data into memory?
In short;
The header file defines the API for a module. It's a contract listing which methods a third party can call. The module can be considered a black box to third parties.
The implementation implements the module. It is the inside of the black box. As a developer of a module you have to write this, but as a user of a third party module you shouldn't need to know anything about the implementation. The header should contain all the information you need.
Some parts of a header file could be auto generated - the method declarations. This would require you to annotate the implementation as there are likely to be private methods in the implementation which don't form part of the API and don't belong in the header.
Header files sometimes have other information in them; type definitions, constant definitions etc. These belong in the header file, and not in the implementation.
The main reason for a header is to be able to #include it in some other file, so you can use the functions in one file from that other file. The header includes (only) enough to be able to use the functions, not the functions themselves, so (we hope) compiling it is considerably faster.
Maintaining the two separately most results from nobody ever having written an editor that automates the process very well. There's not really a lot of reason they couldn't do so, and a few have even tried to -- but the editors that have done so have never done very well in the market, and the more mainstream editors haven't adopted it.
Well i will try:
Header files are only needed in the preprocessing phase. Once the preprocessor is done with them the compiler never even sees them. Obviously, the target system doesn't need them either for execution (the same way .c files aren't needed).
Instead libraries are executed during the linking phase.If a program is dynamically linked and the target environment doesn't have the necessary libraries, in the right places, with the right versions it won't run.
In C nothing like that is needed since once you compile it you get native code. The header files are copy pasted when u #include it . It is very different from the byte-code you get from java. There's no need for an interpreter(like the JVM): you just feed it your binary stuff to the CPU and it does its thing.
J2ME lacks the java.util.Properties class. Although it is possible to put application settings in the JAD file this is not recommended for many properties. (Since, some platforms limits the size of JAD file.) I want to put a configuration file inside my jar file and parse it. And I do not want to go with XML because it will be overshooting for my case.
Question is, is there an already existing library for J2ME that can parse properties files or something similar such as INI file. Or would you recommend another method to solve the initial problem?
The best solution probably depends on what is going to be generating the properties files.
If you've got other non-JavaME projects using the same properties files, then stick with them, and write or find a parser. (There is a simple one from GoBible available on Google Code)
However you might find it just as easy to keep your configuration as static final String myproperty="myvalue"; in a Configuration.java file which you compile, and include in the jar instead, since you then do not need any special code to locate, open, read, and parse them.
You do then pick up a limitation on what you call them though, since you can no longer use the common dot separated namespacing idiom.