Allowing Java-C++ interaction

Mon Apr 2 08:13:40 UTC 2012

Hi,

At first look seems to be ok, I'll need more time to test it properly, because I need to setup a Ministro repository to check if all existing apps on android market if still works, I'll keep you post with the progress.

What I can ensure you is that this patch will be part of alpha4 release :) !

Many thanks for your effort !

Cheers,
BogDan.

>________________________________
> From: Tyler Mandry <tmandry at gmail.com>
>To: BogDan <bog_dan_ro at yahoo.com> 
>Cc: Necessitas <necessitas-devel at kde.org> 
>Sent: Sunday, April 1, 2012 1:16 AM
>Subject: Re: Allowing Java-C++ interaction
> 
>
>Done! https://git.reviewboard.kde.org/r/104450/
>
>
>On Fri, Mar 30, 2012 at 5:41 AM, BogDan <bog_dan_ro at yahoo.com> wrote:
>
>Hi Tyler,
>>No I didn't had time to change it, I've been busy with android style.plugin, it will be great if you can update it by the end of next week, I'll have enough time to review it before release.
>>Thanks.
>>Cheers,
>>BogDan.
>>Sent from Yahoo! Mail on Android 
>>
>>
>>
>>________________________________
>> From:  Tyler Mandry <tmandry at gmail.com>; 
>>To:  BogDan <bog_dan_ro at yahoo.com>; 
>>Cc:  Necessitas <necessitas-devel at kde.org>; 
>>
>>Subject:  Re: Allowing Java-C++ interaction 
>>Sent:  Thu, Mar 29, 2012 11:56:53 PM 
>>
>>
>>
>>Hi BogDan,
>>
>>
>>Sorry for the really long delay, life has been crazy here, but I think I should have time to update my patch this weekend. In the meantime, did you do any work on this? I just don't want to be doing something you've already done.
>>
>>
>>Thanks,
>>Tyler
>>
>>
>>On Thu, Feb 2, 2012 at 6:41 AM, BogDan <bog_dan_ro at yahoo.com> wrote:
>>
>>Hi,
>>>
>>>  I'm sorry I think I don't really understand you ... :) Android qt plugin is already loaded (before you application is loaded) and it will contain a simple function which does what you already did it, so I still don't see where is the problem here !
>>>
>>>  The only problem I see, is that we have to enforce that the main function will be exported properly, otherwise the symbol will be stripped away and the plugin will not find main function anymore, I'm thinking to use the same technique as I'm doing now (create another function which just calls the main function).
>>>
>>>Also, if possible, I'd like to have backward compatibility with alpha3.
>>>
>>>So if you have time for this job, please update your patch and upload it to https://git.reviewboard.kde.org/dashboard/ .
>>>
>>>Cheers,
>>>BogDan.
>>>
>>>
>>>>
>>>
>>>>
>>>>Hi BogDan,
>>>>
>>>>Sounds good. If the plugin can do it that's great. The only problem I see is that you'll have to load it manually, then call main, after which Qt will load the plugin "again." (This should actually work, and Qt will just get a reference to the already-loaded .so from dlopen. That's exactly how my main() function gets a reference to the application's .so.) Let me know if I can be of any help.
>>>>
>>>>
>>>>Cheers
>>>>Tyler
>>>>
>>>>
>>>>
>>>>On Wed, Feb 1, 2012 at 12:10 PM, BogDan <bog_dan_ro at yahoo.com> wrote:
>>>>
>>>>Hi Tyler,
>>>>>
>>>>>
>>>>>Ok, I'll review again your patch (I'd like to get rid of the new library, IMHO the plugin can do this job) then I'll push it to alpha4 branch !
>>>>>
>>>>>
>>>>>
>>>>>Thank you !
>>>>>
>>>>>Cheers,
>>>>>BogDan.
>>>>>
>>>>>>
>>>>>> Here's what I got back:
>>>>>>Subject: Re: Native libraries loaded by different class loaders
>>>>>>>From: Elliott Hughes <e... at google.com>
>>>>>>>To: android-ndk <android-ndk at googlegroups.com>
>>>>>>>
>>>>>> 
>>>>>>if you're calling dlopen(3) and dlsym(3) yourself, it doesn't matter
>>>>>>>what dlopen(3) or dlclose(3) calls the runtime's JNI implementation
>>>>>>>has or hasn't made, and ClassLoaders are irrelevant.
>>>>>>
>>>>>>
>>>>>>His point about dlopen and dlsym is true - if the JVM didn't load the library, it would be loaded anyway by the call to dlopen in android-main. "ClassLoaders are irrelevant" is the answer we were looking for, though. Since this guy's e-mail is @google.com I'd say we're in the clear!
>>>>>>
>>>>>>On Sat, Jan 28, 2012 at 9:59 PM, Tyler Mandry <tmandry at gmail.com> wrote:
>>>>>>
>>>>>>Done! https://groups.google.com/forum/#!topic/android-ndk/Z8GDn8JuopI
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>On Fri, Jan 27, 2012 at 2:42 AM, BogDan <bog_dan_ro at yahoo.com> wrote:
>>>>>>>
>>>>>>>Hi Tyler,
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>>Hi BogDan,
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>Good point. I assume you are referring to native libraries being able to access other native libraries loaded by different class loaders in Java?
>>>>>>>>
>>>>>>>>
>>>>>>>>Yes !
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> If so, we should ask about it, but I really don't think it would break. It's pretty low-level stuff that allows dynamically-linked code to be found, used, and reused within a process. So breaking this would mean changing the OS/kernel itself in a non-standards-compliant way (unlikely.) Or the JVM somehow splitting our single application/activity into more than one process, which is also unlikely and would contradict some of the documentation for Activity (thus breaking other apps.) If there are other ways it could break, I don't see them.
>>>>>>>>>
>>>>>>>>
>>>>>>>>I also have doubts they can do it, but doesn't hurt to ask :)
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>>That said, it's always a good idea to ask. Let me know if we're thinking of the same thing or not. I'm willing to post to android-ndk, but you're welcome to do it instead.
>>>>>>>>>
>>>>>>>>
>>>>>>>>Please post the question (and share with us the link :) ).
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>>Have a great day!
>>>>>>>>>Tyler
>>>>>>>>>
>>>>>>>>
>>>>>>>>Cheers,
>>>>>>>>BogDan.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>>On Thu, Jan 26, 2012 at 2:48 AM, BogDan <bog_dan_ro at yahoo.com> wrote:
>>>>>>>>>
>>>>>>>>>Hi Tyler,
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>  The big question is if Google can change android in order to hide the symbols if they are loaded by different classloaders ?
>>>>>>>>>>
>>>>>>>>>>If they can't do it, I think your solution is ok, but if it is possible to do it, then we risk to break everyones applications !
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>  Before we make a decision I think we should ask google if they are planning to change current behavior or not. Do you want to open a topic to android-ndk[1] or should I do ?
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>Cheers,
>>>>>>>>>>BogDan.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>[1] http://groups.google.com/group/android-ndk
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>________________________________
>>>>>>>>>>> From: Tyler Mandry <tmandry at gmail.com>
>>>>>>>>>>>To: necessitas-devel at kde.org
>>>>>>>>>>>Sent: Monday, January 23, 2012 7:40 AM
>>>>>>>>>>>Subject: Allowing Java-C++ interaction
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>This accidentally didn't get sent to the list; forwarding. Sorry about that.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>---------- Forwarded message ----------
>>>>>>>>>>>From: Tyler Mandry <tmandry at gmail.com>
>>>>>>>>>>>Date: Tue, Jan 17, 2012 at 12:19 AM
>>>>>>>>>>>Subject: Re: Allowing Java-C++ interaction
>>>>>>>>>>>To: BogDan <bog_dan_ro at yahoo.com>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>Hi BogDan,
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>That definitely could work. But it does add to the complexity, and possibly start-up time, of the app. An alternative solution would be: simply to load the bundled libs in the main classloader, UNLESS they are bundled Qt libs that are used by the .jar, in which case they are loaded in the child CL. This could be accomplished by separating these two kinds of libs into different categories, or even auto-detecting them by their names at runtime. What do you think?
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>(One thing I've found: native libs loaded in different classloaders can always talk to each other, since they're part of the same process. In other words, you could load core Qt libs in the child CL and QtWebKit in the parent CL and it will all work. I don't know if this is useful but thought it might be.)
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>Thanks,
>>>>>>>>>>>Tyler
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>On Mon, Jan 16, 2012 at 2:22 AM, BogDan <bog_dan_ro at yahoo.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>Hi Tyler,
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>   Thanks you for sharing this with us, it helped me to understand better what is the problem.
>>>>>>>>>>>>I also check your patch [1] but it doesn't seem to fix all the problems, bundle libs will have the same problem, so I tried to find another solution which hopefully will handle all this situations. The solution is create a separate package with your own java files, and this package to be loaded by the same class loaded which loads the plugin .jar files.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>Please let me know if this approach is ok for you.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>Cheers,
>>>>>>>>>>>>BogDan.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>[1] http://sourceforge.net/p/necessitas/tickets/140/
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>________________________________
>>>>>>>>>>>>> From: Tyler Mandry <tmandry at gmail.com>
>>>>>>>>>>>>>To: BogDan <bog_dan_ro at yahoo.com>
>>>>>>>>>>>>>Sent: Friday, January 13, 2012 6:43 AM
>>>>>>>>>>>>>Subject: Re: Allowing Java-C++ interaction
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>Hi BogDan,
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>What currently happens is the native library is loaded in the child class loader (by the code in the .jar, in fact,) so application code (loaded by the parent class loader) can't see any native functions loaded by the native library. And no, I don't try to access anything in the .jar in my application.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>I did make a simple testcase that fails before the patch and works after. Since the patch involves changing QtActivity.java, it's difficult to send a complete project and see the before and after. Instead, do the following:
>>>>>>>>>>>>>    1. Create a new Qt Quick Application project in Qt Creator, with an Android target
>>>>>>>>>>>>>    2. (i) Replace main.cpp with the attached main.cpp, and (ii) add in the Java source to the tree (copy the android/src/org/kde/necessitas/example folder in attached archive to android/src/org/kde/necessitas in the project)
>>>>>>>>>>>>>    3. Go to QtActivity.java and add (i) "import org.kde.necessitas.example.simpleapp.MyNative;" at the top, and (ii) the following at the END of loadApplication():
>>>>>>>>>>
>>>>>>>>>>>>>//dostuffafter loading
>>>>>>>>>>>>>MyNativenat=newMyNative();
>>>>>>>>>>>>>nat.doSomething();
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>[Modifying QtActivity.java is currently the only way I know to run your own Java code as the application loads.]
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>After that, run the project and you should see "No implementation found for native Lorg/kde/necessitas/example/simpleapp/MyNative;.doSomething ()V" along with an UnsatisfiedLinkError in the log.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>Then point Qt Creator to a build of Qt with the patch and do the process again with that version of Qt. (**Of course you'll need to deploy and use local Qt libs!**) You should see "This is a native function, doing something!!" in the logs, and no crash.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>I hope this is clear enough and that it sheds some light on what I'm trying to accomplish :). Let me know if anything is unclear.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>Thanks for all your hard work!!
>>>>>>>>>>>>>Tyler
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>On Thu, Jan 12, 2012 at 8:46 AM, BogDan <bog_dan_ro at yahoo.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>Hi Tyler,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>    I reviewed my code and seems to be ok, when I create m_classLoader (check QtActivity.java) I pass its parent correctly, so, even if your library is loaded by a class which was loaded by m_classLoader and there your package is not visible, m_classLoader should search also into its parent for that class.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>    I hope your package don't try to access classes from .jar file, because those classes are private, and they should be used *ONLY* by platform plugin.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>Would you please create a simple example which fails, it will help me to understand the problem better ?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>Thank you !
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>Cheers,
>>>>>>>>>>>>>>BogDan.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>+ CC: necessitas-devel
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>Hi BogDan,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>No worries, I just didn't want it to be overlooked :)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>In a nutshell, any (user) Java code the application had couldn't see the user's native JNI code, because their native library was loaded in a class loader that was different from the (primary) class loader that their Java code ran in. This upset a few people that have custom Java and JNI code, like me :). The only way to make calls between different class loaders is to use reflection, so instead I made a way for the application native library to be loaded in the primary class loader.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>That was a mouthful, but I hope it helps. Let me know if you have further questions!
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>Thanks,
>>>>>>>>>>>>>>>Tyler
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>On Tue, Jan 10, 2012 at 1:49 PM, BogDan <bog_dan_ro at yahoo.com> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>Hi Tyler,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>Please accept my apologize for slow reply.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>I need a few days to understand what is wrong with current design and to check your patch, then I'll come back with feedback !
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>Thank you very much for your patience !
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>Cheers,
>>>>>>>>>>>>>>>>BogDan.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>BogDan,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>Do you think this patch can be included in the next alpha? If not, what needs to be done?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>Thanks,
>>>>>>>>>>>>>>>>>Tyler
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>On Thu, Dec 29, 2011 at 12:48 AM, Tyler Mandry <tmandry at gmail.com> wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>Here is the patch (against alpha4 head 2469081) to make everything work. I've tested and it works. The basic approach is to compile qtmain_android.cpp into its own .so during Qt compilation, and load it in the application. It uses dynamic linker calls to find the main() function at runtime. So there is no awkward back-and-forth library loading needed after all.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>Backward compatibility: I made sure my changes to the JAR allowed it to still work with existing built applications as-is, and light testing confirms that it is. This required a few extra lines that are marked as such in case you want to remove them.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>I didn't touch Ministro, however, and I suspect that my addition to lib/rules.xml will cause new versions of Ministro to try to load libqtmain.so, which won't exist in old/current applications. I'll leave that issue for someone more familiar with Ministro to look at, if it's a concern.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>Finally, I mentioned creating a new category of user-defined bundled libs in case the user wants to use JNI with those libs, but did not implement that.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>I hope you like it and that it can be included in the next alpha. Let me know if you have any questions or comments :)
>>>>>>>>>>>>>>>>>>Tyler
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>On Sat, Dec 24, 2011 at 11:28 PM, Tyler Mandry <tmandry at gmail.com> wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>BogDan,
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>Merry Christmas again! When you have time:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>Separating out qtmain_android.cpp into its own shared lib allows us to build it during the Qt build rather than with the application projects. (We have to remove the --no-undefined linker option, but it works.) My question is, where should that library go in the Qt install? It isn't technically a Qt plugin, so I don't know about putting it with plugins, and lib/ is all official Qt libs. It fits in best with jar/, but then the directory name doesn't make sense :). We could also make another directory, though it seems unnecessary. I'll probably stick it in jar/ unless I hear from you.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>I've proved that this method works, and now I'm just working on integrating all the changes in code.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>Cheers,
>>>>>>>>>>>>>>>>>>>Tyler
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>On Fri, Dec 23, 2011 at 2:14 AM, Tyler Mandry <tmandry at gmail.com> wrote:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>One thing I've encountered: If I'm not mistaken, people can/will use bundled libraries to bundle Qt libraries along with their application (to bypass Ministro.) Others will use bundled libs of their own for other purposes. We will want to load the Qt bundled libs inside the child class loader, so our JAR can talk to them, and the other bundled libs inside the main Java class loader, in case they want to interact with those native bundled libs via JNI. This will require us to make a new distinction on the type of bundled library.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>Other thoughts: I've been looking and it looks like this isn't a difficult change to make. It's very minimal in the way it changes how things are done right now. It does require a change to the JAR files to accomodate for that back-and-forth lib loading that I described. Anyway, I plan to implement all this tomorrow and see how it goes.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>On Thu, Dec 22, 2011 at 8:51 PM, Tyler Mandry <tmandry at gmail.com> wrote:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>Hi all, and Merry Christmas.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>We were discussing the importance of allowing Java and C++ to interact for many people's apps in android-qt (thread: C++ and Java interaction in Alpha3.) With the new separation of the JAR files, and use of a different class loader for the app code, it has become very difficult to allow this. Traditional native interface classes can no longer see the native methods that are loaded by the separate class loader.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>I did some playing around, and I think I found a simple solution that works. If we separate out the code in qtmain_android.cpp into its own (very small!) shared library, and allow the user's application code to be in one library all by itself, we can load them in separate class loaders. While you can't do Java-Java or Java-native interaction easily across the class loader barrier, native-native interaction works fine since it's all the same process. Simply load the Qt library in the /child/ class loader, followed by the application code library in the /main/ class loader, followed by the qtmain_android code in the /child/ class loader. Then the user's Java code can see the user's C++ code and vice versa, because they are all loaded under the same class loader.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>I did a testcase of this (with libraries of my own, not Qt) and confirmed that it works in a simple case. If no one sees any problems with this let's implement it.
>>>>>>>>>>>>>>>>>>>>>--
>>>>>>>>>>>>>>>>>>>>>Tyler Mandry
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>--
>>>>>>>>>>>>>>>>>>>>Tyler Mandry
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>--
>>>>>>>>>>>>>>>>>>Tyler Mandry
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>--
>>>>>>>>>>>>>>>>>Tyler Mandry
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>--
>>>>>>>>>>>>>>>Tyler Mandry
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>--
>>>>>>>>>>>Tyler Mandry
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>--
>>>>>>>>>>>Tyler Mandry
>>>>>>>>>>>
>>>>>>>>>>>_______________________________________________
>>>>>>>>>>>Necessitas-devel mailing list
>>>>>>>>>>>Necessitas-devel at kde.org
>>>>>>>>>>>https://mail.kde.org/mailman/listinfo/necessitas-devel
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>--
>>>>>>>>>Tyler Mandry
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>--
>>>>>>>Tyler Mandry
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>--
>>>>>>Tyler Mandry
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>--
>>>>Tyler Mandry
>>>>
>>>>
>>>>
>>>
>>
>>
>>
>>-- 
>>Tyler Mandry
>> 
>
>
>
>-- 
>Tyler Mandry
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/necessitas-devel/attachments/20120402/95072d21/attachment-0001.html>