Boox (M92) developer community?

[kodomo]

Originally Posted by catharsis

Quick question: I have good experience of developing with Qt, but for Symbian/MeeGo and Desktop under Windows. How easy is it to set up a virtual machine and develop for M92?

Hi catharsis.

I cannot speak for Windows (no experience setting up the SDK there), but for Linux, it is fairly easy, if you're not afraid of using a shell (check out https://wiki.mobileread.com/wiki/Boox...re_development ).

You'll save yourself trouble compiling for x86 by developing in a 32bit environment (a couple of packages cast pointers to integer :P ).

VM: E.g., download the Nokia Maemo Development VM (Ubuntu Linux) as a basis, and use it in VirtualBox. (I do not actually use the scratchbox environment for the M92, though) In Ubuntu, you can install missing (x86) packages with either the synaptics package manager, or with aptitude, or with apt-get.

Cheers.

[kodomo]

Originally Posted by pkbo

Those libraries also used to write gui_shell, of course it doesn't help to modify/debug existing closed source applications but it gives a lot of information about how these applications organized and how they work.


That is correct without source code you can't add a menu item. The only place I've seen plugin interface was dictionary. Theirs code design is not that flexible. For instance in order to add one more keyboard layout they modify SDK by adding [lang]_keyboard_data.[cpp|h]. As a result they have many files with similar code that differ only in character codes and you will need to rebuild SDK and all applications using it to add one more keyboard layout. I find that OpenBOOX approach to not depend too much on Onyx is quite reasonable.

I agree. The thing I'd like to have understood is my motivation to open this thread, though (actually, there are two motivations):
a) getting potential developers together (I see that happening - thank you )
b) (indirectly) showing Onyx that there's a potential developer community to incite them to think about opening up (via a developer program or overall)

While I agree that the OpenBOOX approach is the most sensible given Onyx's current policy (which I fear is indeed not likely to change ),
I'd consider it a shame not to offer them cooperation first.

Having to reimplement things and work around their closed source is a waste of energy to everyone.
_We_ have to reimplement things that already exist (and adapt them when they change APIs).
Extensions appear at a much later time than they could.
_They_ have to invest additional work to make extensions fit their software, which we'd otherwise integrate.

This is why I opened the thread with the proposition to collaborate with Onyx. (Not because I oppose the OpenBOOX approach )

Giving examples on things I'd like to see, but which I see hardly or not possible to hack into their binaries:
- proper integration of snapshots
- disabling the screensaver not to wast battery power on displaying single pages for a long time
- adding different scribble colors (basically, all things that require modification of the menu)
- adding support for stylus buttons

[FDD]

Originally Posted by kodomo

- adding support for stylus buttons

I wanted to do that myself, and I came up with a workaround. The whole setup is based on tslib, which dinamically loads plugins (/opt/onyx/arm/lib/ts/*), so it is possible to change the hanvon plugin.

My idea was to create a socket a "smart" application can open to get raw (or simply more informative) packets, diverting them from the normal route. This way you can have full resolution data (1280ppi, versus video resolution, 160ppi), full button control and, more important for me, proper press/release information - right now those events are ignored and some poor man hack is done instead.

[kodomo]

Originally Posted by FDD

I wanted to do that myself, and I came up with a workaround. The whole setup is based on tslib, which dinamically loads plugins (/opt/onyx/arm/lib/ts/*), so it is possible to change the hanvon plugin.

My idea was to create a socket a "smart" application can open to get raw (or simply more informative) packets, diverting them from the normal route. This way you can have full resolution data (1280ppi, versus video resolution, 160ppi), full button control and, more important for me, proper press/release information - right now those events are ignored and some poor man hack is done instead.

Is the hanvon plugin source publicly available?

I guess one would have to bother with that one anyways... but I don't see how to make gui_shell react to the input... I've pondered about using the DBus, but so far, neither gui_shell, nor system_manager showed any reaction to my (half-hearted) attempts to send them signals.

[FDD]

Originally Posted by kodomo

Is the hanvon plugin source publicly available?

I guess one would have to bother with that one anyways... but I don't see how to make gui_shell react to the input... I've pondered about using the DBus, but so far, neither gui_shell, nor system_manager showed any reaction to my (half-hearted) attempts to send them signals.

The hanvon source is available in the onyx-intl-toolchain, pkgs/tslib/plugins directory. The hanvon digitizer really uses Wacom's IDSV4 protocol, so that plugin isn't badly needed, but there it is

I'm not sure I understand your second sentence... you are trying to make gui_shell do things from the shell (or script etc.)? By the way I didn't look what kind of events they (gui_shell and system_manager) signal to each other over the DBUS

[kodomo]

Originally Posted by FDD

The hanvon source is available in the onyx-intl-toolchain, pkgs/tslib/plugins directory. The hanvon digitizer really uses Wacom's IDSV4 protocol, so that plugin isn't badly needed, but there it is

I'm not sure I understand your second sentence... you are trying to make gui_shell do things from the shell (or script etc.)? By the way I didn't look what kind of events they (gui_shell and system_manager) signal to each other over the DBUS

ah - thx - I had overlooked that directory...

I originally was talking about problems extending onyx's versions of gui_shell and system_manager.
Thus the second part was about _using_ the extended functionality in Onyx's firmware. New applications could use the described socket, but gui_shell would not.

The next idea was a daemon using the DBus to trigger events in gui_shell and system_manager... but so far I had no luck.
The only signals that are broadcast on the system DBus (eavesdropped with dbus-monitor --system) seem
* 'Idle'
* Volume-related signals,
* starting/stopping of applications,
* aboutToSuspend
* and when a new wifi connection was established.

But simply reproducing the signals on the bus by use of dbus-send did not elicit responses, so I assume that applications pay heed to the sender... so I guess that you'd have to spoof the sender. (currently don't know how to do that)

[Koudijs]

Originally Posted by kodomo

hm - ic - so it's not as much as I thought it'd be... unfortunately, some of the stuff I need is actually in the system_manager... do you have a clear view on how gui_shell and system_manager interface, and whether there are forseeable API issues between the A60 and M92 version?

It's not too bad, or actually, there is a lot that can be done via the Onyx libraries from the SDK. The libonyx_sys library provides the interface to the system manager, you can find the sources in code/src/sys (checkout sys_status.cpp). I have used this to implement custom screensaver support and at this moment I'm adding a wifi connection icon to the statusbar showing the signal strength.


There is one major issue, the only documentation available is the code itself, so it can be pretty time consuming to find out how everything should be used

Originally Posted by kodomo

What would you deem the first step?
If your gui_shell can be compiled as a single binary which I may copy onto the regular firmware and try starting it, I could check whether it compiles in my M92 devel setup...

Probably the easiest way to build the "gui_shell" is by using/checking the OpenBOOX build system, because it requires some libraries that are not part of the standard firmware. I also saw that the M92 uses a newer version of Qt of which I don't know if it's backwards compatible.

Originally Posted by kodomo

Would you like some M92 binaries (e.g., naboo) to check on whether they run on the A60? (It seems to me that it makes sense trying to salvage as much of the closed source from the newer firmware as we can... when I think about their promised multitasking functionality, I'm a bit worried about serious API modifications)

I tried the M92 build of evopedia that can be found here, it does not run because it requires a different version of libstdc++.so.6. I think this means that the A60 and M92 are not binary compatible. I'm still hoping for a 1.7 version for the A60.

[kodomo]

Originally Posted by Koudijs

It's not too bad, or actually, there is a lot that can be done via the Onyx libraries from the SDK. The libonyx_sys library provides the interface to the system manager, you can find the sources in code/src/sys (checkout sys_status.cpp). I have used this to implement custom screensaver support and at this moment I'm adding a wifi connection icon to the statusbar showing the signal strength.
Attachment 84848

I see (I'm currently hacking some tiny apps to get a grip on what is possible, and how it is done)... but if I get this correctly, an application itself decides on the menu structure...(?) which means that even if we got the gui_shell source, we could not add e.g. additional colors to naboo (or easily change its response to stylus button events)

Please correct me, if I got this wrong (I would very much like to be on this point :-| ).
At the moment, it seems to me like one'd have to change the naboo source to add new icons to the menu, or to implement new event slots for e.g., stylus button events... that would be unfortunate and most annoying...

Originally Posted by Koudijs

There is one major issue, the only documentation available is the code itself, so it can be pretty time consuming to find out how everything should be used

Indeed... at the moment, I'm confused by screen refreshing... is there any documentation about it? (Need to say: I never programmed with Qt before)
Writing an application, which simply opens a MessageDialog, was easy - I didn't even need to use the screen_update_watchdog explicitely.

However, copying the PasswordDialog into another class (I needed access to its private fields), applying only trivial modifications (e.g., changing the window title), I cannot make the screen update behave even if I set a screen_update_watchdog onto it... can someone enlighten me here?

Update: Solved - I forgot to setSystemBusy(false)

Originally Posted by Koudijs

Probably the easiest way to build the "gui_shell" is by using/checking the OpenBOOX build system, because it requires some libraries that are not part of the standard firmware. I also saw that the M92 uses a newer version of Qt of which I don't know if it's backwards compatible.

Have to try when I find time...

Originally Posted by Koudijs

I tried the M92 build of evopedia that can be found here, it does not run because it requires a different version of libstdc++.so.6. I think this means that the A60 and M92 are not binary compatible. I'm still hoping for a 1.7 version for the A60.

Interesting... isn't it linked statically?

[kodomo]

Side product of my first steps using the SDK:
I've hacked a few simple applications that may serve as ui primitives when scripting.
There's an application to open a message window, an application to open an input dialog, and an application to open a confirmation request window.

Moreover, there's an example script using these to allow input of a simple noninteractive shell command and to output its result.

Maybe the hacks will be of use to someone.
Source and binaries attached.

Cheers.

[FDD]

Originally Posted by kodomo

I've hacked a few simple applications that may serve as ui primitives when scripting.

These are really handy! Well done!

[tuxor]

Did somebody try to build Python for M92? Unfortunately, cross-compiling won't work. But maybe there is a chance to compile it inside of an ARM VM. Or did somebody try to cross-compile gcc to compile stuff directly on M92? I admit, that'd be a pretty ... unusual solution though ;-)

Why Python? Simply, because I love it :P

Haven't had the time yet to look over your ui primitives, kodomo. But it sounds great and will definitely turn out extremely useful sooner or later.

[kodomo]

Originally Posted by tuxor

Did somebody try to build Python for M92? Unfortunately, cross-compiling won't work. But maybe there is a chance to compile it inside of an ARM VM. Or did somebody try to cross-compile gcc to compile stuff directly on M92? I admit, that'd be a pretty ... unusual solution though ;-)

Why Python? Simply, because I love it :P

Let $scripting_language flame wars begin
(one argument for python would be the integration of peter-x's scribble-to-svg scripts, though )

What's the trouble cross-compiling?
(cross-compiling bigger projects on the ARM may... take... (more?...) time... '.' )

[tuxor]

I didn't even try cross-compiling because on the internet I found lots of disappointed developers that have been unsuccessful trying to cross-compile Python. But okay, there are some reports about working cross-compiling and they aren't even old. See http://randomsplat.com/id5-cross-com...ded-linux.html

Maybe I'll try Python 2.7.2 sometime in the next few days/weeks.

BTW: How good are the chances that PyQt will run on M92? I guess not very good because you need those onyx-e-paper modifications?

[Koudijs]

Originally Posted by tuxor

Did somebody try to build Python for M92? Unfortunately, cross-compiling won't work. But maybe there is a chance to compile it inside of an ARM VM. Or did somebody try to cross-compile gcc to compile stuff directly on M92? I admit, that'd be a pretty ... unusual solution though ;-)

Why Python? Simply, because I love it :P

Have you checked this thread?

[tuxor]

Veeeery nice. Will continue the discussion in that thread then