i am using Qt5.7.1 on debian jessie linux virtual machine and deploy my application on the iMx6 processor, also running Qt5.7.1 and debian jessie.
I compiled the QtVirtualkeyboard project to add all languages that Qt supports.
First i compiled it for the PC linux and after for the iMx6.
I copied the new build plugin into the iMx6 Qt install plugin path and the other files required.
So on PC side the "basic" example project shows all languages with no issue.
Running the same example project on iMx6, i get almost all languages except those:
qml: Qt.createQmlObject(): failed to create object:
qrc:/QtQuick/VirtualKeyboard/content/layouts/ja_JP/japaneseInputMethod:1:57: JapaneseInputMethod is not a type
qml: Qt.createQmlObject(): failed to create object:
qrc:/QtQuick/VirtualKeyboard/content/layouts/ko_KR/hangulInputMethod:1:57: HangulInputMethod is not a type
qml: Qt.createQmlObject(): failed to create object:
qrc:/QtQuick/VirtualKeyboard/content/layouts/zh_CN/pinyinInputMethod:1:57: PinyinInputMethod is not a type
qml: Qt.createQmlObject(): failed to create object:
qrc:/QtQuick/VirtualKeyboard/content/layouts/zh_TW/tcInputMethod:1:57: TCInputMethod is not a type
Did i miss to copy a source file for those languages or something?
If yes which files and where should they be copied to?
So i did made it to work.The problem is that QtVirtualkeyboard uses thirdparty libraries and it cannot find it.
To solve the proble you must also compile all QtVirtualkeyboard thirdparty libraries and copy it to your ARM CPU like iMx6.
Example for simple chinese:
cd /home/yourname/Qt5.9.1/5.9.1/Src/qtvirtualkeyboard/src/virtualkeyboard/3rdparty/pinyin
qmake
make
Copy the .dat library for pinyin (dict_pinyin.dat) to directory like
/usr/local/qt5.9.1/qtvirtualkeyboard/pinyin
Now QtVirtualkeyboard should find the simple chinese dictonary. This should be done for japonese and traditional chinese and hundspell as well if you use them.
Related
I'm trying to package my project using snapcraft. I think it is easiest to package the prebuild binaries, which are available here: https://sourceforge.net/p/audiocuesheet
This is a mono and gtk-sharp2 project, so I thought of using snapcraft to bundle my application. But I fight currently getting this to run.
My snapcraft.yml:
name: audiocuesheeteditor
version: '2.4.2'
summary: Write audio cue sheets fast and efficient
description: |
Annoyed of writing your audio cue sheets via text editor? Here comes the solution! Audio Cuesheet Editor helps you editing your audio cuesheet file. With AudioCuesheetEditor you can import text files, edit the imported data and afterwards export to a working audio cuesheet.
apps:
AudioCuesheetEditor:
command: AudioCuesheetEditor/./AudioCuesheetEditor
parts:
audiocuesheeteditor:
source: /home/sven/Downloads/AudioCuesheetEditor-linux-x64-v2.4.2.zip
plugin: dump
I have run once snapcraft, but now the second time i get the following output:
[root#localhost Downloads]# snapcraft
Native builds aren't supported on Fedora. You can however use 'snapcraft cleanbuild' with a container.
Do you have an idea, why I can not rebuild the snap?
Also, how do I make shure, that mono and gtk-sharp2 binaries are installed on the target system?
Thanks for your help guys.
Sven
We are trying to cross compile the wxGTK (2.8.12) to our ARMv5 embedded device.
Since RAM space is limited to 64MB, we thought of not using X11.
So, we have built DirectFB and GTK+ (with gdktarget as directfb and without x).
Now, we are trying to build wxGTK with GTK+. But it seems like, it need X11 header files. Got following compiler errors:
./src/unix/utilsx11.cpp:31:22: warning: X11/Xlib.h: No such file or directory
./src/unix/utilsx11.cpp:33:23: warning: X11/Xutil.h: No such file or directory
./src/unix/utilsx11.cpp:40:22: warning: gdk/gdkx.h: No such file or directory
./src/unix/utilsx11.cpp:44: error: ‘Atom’ does not name a typeenter code here
....
Is it possible to build wxGTK with GTK+ (directfb) but without X?
Thanks,
Hari
wxGTK requires GTK+ and, while GTK+ can use different backends, notably Wayland, it's unlikely to be available on your device.
You could try building wxDirectFB instead, but wxDFB is a very alpha-quality port which hasn't been in use since quite some time, so you should be ready to do some work on it yourself in order to implement the missing parts (there will definitely be at least some).
There is a minimalist GNOME implementation based on the GTK+. It is based on the X11 and GTK+. It can be build using OpenEmbedded or probably downloaded as prebuilt WM.
Now looking at it I think you can try GNOME Embedded with wxGTK.
I am working on a project that is using Leopardboard DM368 interfacing with LI-M024DUAL camera board for stereo vision. The camera uses Aptina's MT09M024 as its image sensor.
After spending a lot of time on the web searching for appropriate drivers I asked the OEM to provide me some support. They provided me with the driver source files. The problem is I am not able to include them to the kernel.
I also looked up for the method to build modules and am fairly comfortable with it. But with the current driver I have a bunch of *.c files that use non-existent header files (I am not able to find these linux header files in the /linux directory).
Now my question is if I have the source code for an image sensor driver and want to build it, what is the general procedure followed for the same.
Any help in this regard would be welcome.
-Kartik
There are two ways to build you module:
1. Statically linking to kernel image (inbuilt)
2. Creating dynamically loadable Modules
Statically linking to kernel image (inbuilt)
For this you must find a appropriate place in kernel folder (somewhere in drivers/) to copy your .c files. copy them there. Edit Kconfig and Makefiles refering to other kernel drivers. and enable the support using menuconfig. Compile.
Creating dynamically loadable Modules
You can built without copying them to Kernel source. Just create a Makefile and place rules in Makefile to compile your module. Here you must link your module to your kernel by providing the kernel source path.
For more google should help.
Below is my scenario,
In my Application i had to make use of libopus library , i downloaded and install, compile --> install procedure is normal as its for any other open source library,
I linked libopus.a with my application, the way i did is , by default it will get installed in /usr/local/lib, so i drag from there and add it to my application,
Worked fine and no error on my machine,
On Another machine, i was expecting it to be run smoothly as i included this library statically, but its throwing error as
dyld: Library not loaded: /usr/local/lib/libopus.0.dylib
so i concluded, libopus.a somehow including libopus.0.dylib also dynamically,
Now i am able ot add a copy phase in my build setting , so it will get copied in ../Framework folder
if i do otool -L libpus.a then it shows following result
otool -L /usr/local/lib/libopus.a
Archive : /usr/local/lib/libopus.a
/usr/local/lib/libopus.a(bands.o):
/usr/local/lib/libopus.a(celt.o):
/usr/local/lib/libopus.a(cwrs.o):
/usr/local/lib/libopus.a(entcode.o):
/usr/local/lib/libopus.a(entdec.o):
/usr/local/lib/libopus.a(entenc.o):
/usr/local/lib/libopus.a(repacketizer.o):
It doesn't show as its depend upon the dylib library
Now my Question is
How to tell Application to look into this path first
I tried following option,
install_name_tool but it seems it will work on other machine , so the user need to run this script NOT DEVELOPER,
trying to set the some option in the xcode to set the RUNTIME Search path to locate that particular dylib but not getting succeed so far
install_name_tool is run by the developer during the build process, not by the user.
If you're building the library, you should use libtool(1) with the option -install_name #rpath; otherwise, you can use install_name_tool(1) with -id #rpath to do the same thing on the dylib. Then, when you're building your application, set the "Runpath search paths" to the path where you will install the library.
Apple has some good documentation on this in their Mach-O Programming Topics and Dynamic Library Programming Topics.
Hoping to have some Eclipse PDE guru's weigh in here in a problem I'm having trouble solving.
I am attempting export (via PDE UI) a feature that has two fragments included where both fragments target the same os (e.g., Linux) but have different architecture values (e.g., x86 and x86_64). Each fragment has their own copy of several .so library files, which were built on the either Linux x86 or Linux x86 64 bit. For example:
FragmentA (os=Linux,arch=x86)
lib1.so
lib2.so
lib3.so
FragmentB (os=Linux,arch=x86_64)
lib1.so
lib2.so
lib3.so
Exporting the hosting feature with using the corresponding delta pack to select either linux (gtk/x86) OR linux (gtk/x86_64), the export works as expected. However, when I select BOTH platforms, the export fails with the following message:
Processing inclusion from feature com.sample.feature:
Bundle com.sample.linux.x86_64_1.0.0.qualifier failed to resolve.:
Unsatisfied native code filter:
lib1.so; lib2.so; lib3.so; processor=x86_64; osname=linux.
Why can't I export both fragments together? I also have a Win32 x86 fragment that I can export with the linux X86 feature but instead of having .so files, it has .dll files with the same file titles (e.g., lib1.dll, lib2.dll, lib3.dll).
Could having .so library files named the same in the two Linux-based fragments cause this issue?
Any help would be much appreciated as this is a critical block to our build process (both manually via the UI and headlessly).