Boox (M92) developer community?

[kodomo]

Hi folks.

I've been wondering how many folks around here would like to hack/improve/debug things on the M92, but are stopped by the currently
- missing kernel, gui_shell, system_manager
- broken (outdated?) git repository versions

I don't fully get why Onyx is incommunicado about everything (did they get seriously burned by M90 feedback?).
I do understand that for many things, having a filtering, structuring interface to the customers is very beneficial. Filtering a load of demanding customer requests makes a lot of sense. (As I see it, Booxtor is evolving into their european distributor without the benefit of official status)

However, this is quite frustrating to people who'd like to hack with the device and improve things (as opposed to just requesting features). (It at least is frustrating me ).
Current sources, available communication channels (e.g., _official_ bugtracker) with developers are necessity to even consider debugging things.

If there's sufficient interest, maybe it'd make sense to prompt Booxtor to ask them about a developer program... :-|
I'm opening this thread to see whether there'd be enough folks for a developer community that would be interesting to Onyx.

So please raise you're hand, if you'd like to hack and help improving the M92 by debugging and/or adding features.

[tuxor]

*raising my hand*

[Koudijs]

Hi kodomo,

I am interested in a generic Boox developer community (which is not necessarily attached to Onyx). The Boox user community is already quite small so I think that we can only give the developer community some body by covering different models. At source level the A60 and M92 have more commonalities than differences so this should be possible.

I understand that you would like to see a community that operates in close cooperation with Onyx. This probably would be the most effective but the question is if Onyx will provide the platform for this.

For the OpenBOOX project I have choosen to not depend too much on Onyx. This way I am able to provide an alternative for the Onyx firmware, it also gives more possibilities to attract users with unique features. Besides this it is also a result of the fact that only a part of the Onyx code is open, the sources of the system manager and main user interface are not available (it can very well be that it doesn't contain GPL code).

What I did last year is that I started to develop an open source user interface, you can see it in action on the projects YouTube channel. The source code is available on SourceForge. Currently it has some hardcoded references to the A60 screen resolution but it should be possible to remove these and make it run on the M92 as well.

[mSSM]

I'd like to have the source, too, preferably hosted on GitHub.

I hope they guys at Onyx are aware that they have to release their sources as required by the GPL...

[raphman]

While time is always a limiting factor, I am interested in fixing bugs, improving the UI and integrating the M92 better into my device ecosystem.

[kodomo]

Originally Posted by Koudijs

I am interested in a generic Boox developer community (which is not necessarily attached to Onyx). The Boox user community is already quite small so I think that we can only give the developer community some body by covering different models. At source level the A60 and M92 have more commonalities than differences so this should be possible.

I agree.

Originally Posted by Koudijs

I understand that you would like to see a community that operates in close cooperation with Onyx. This probably would be the most effective but the question is if Onyx will provide the platform for this.

I know - that's why I created this thread to see whether we can gather enough people to make it attractive to Onyx to open up.
I seriously don't know whether it'll work, but I deem it worth a try.
If it worked, it'd save the community a lot of overhead, and they'll get something out of it, too.

Originally Posted by Koudijs

For the OpenBOOX project I have choosen to not depend too much on Onyx. This way I am able to provide an alternative for the Onyx firmware, it also gives more possibilities to attract users with unique features. Besides this it is also a result of the fact that only a part of the Onyx code is open, the sources of the system manager and main user interface are not available (it can very well be that it doesn't contain GPL code).

What I did last year is that I started to develop an open source user interface, you can see it in action on the projects YouTube channel. The source code is available on SourceForge. Currently it has some hardcoded references to the A60 screen resolution but it should be possible to remove these and make it run on the M92 as well.

I saw (though I wasn't sure whether you actually rewrote the GUI or whether you worked around the existing one).
My main interest lies in a couple of features/bug fixes I already have a rough idea on how to hack, and the time I have for such projects unfortunately is limited.

I agree that porting OpenBOOX to the M92 should be not too much work per se.
The thing I'm not sure about (and that's the reason why I'm first trying to poke Onyx, as it seems a completely different order of magnitude in work to me) is annotation support. I gather that the A60 does not support annotations(?), and guess that this is still missing in OpenBOOX(?) - which I assume to be quite some work to be done.

Some of the annotation support stuff may even be connected to the Adobe reader(?). (btw. I'd need to check on whether I can find that one in the file system, or whether it's part of the missing components... does OpenBOOX include them?)

If we'd have sufficient folks working on that, it might be a real option.
I have to admit that GUI programming is neither my forte nor my real interest. I always considered it more of a nuisance than fun when I had to deal with it. :P

Maybe we should open a thread to discuss the work that'd have to be done to port/extend OpenBOOX?

[FDD]

I'm interested too!
I'm really a C programmer and I don't like GUIs too much, but I'd really love to have a better user interface and I'm (slowly) trying to learn a bit of C++ and Qt.
IMHO right now the worst problem is that there is way too much refreshing in the wrong spots, that makes the whole thing feel kind of sluggish. While some lag is unavoidable because of the way e-ink works, it can be way, way better with a clever design (Sony did a good work with their devices, I think).

To give a try to such sort of things does not depend on having much more than the current SDK, but to design the whole system_manager again from scratch is another story, because it manages a few different things like proxying eink refresh requests, keeping track of usb status etc. I haven't looked at OpenBOOX, so I don't know how this was handled (original system_manager with a brand new gui_shell?).

It would be very nice if we could all agree on what should be the "project" goals, what should be done first and so on... looking forward to this!

Ciao!

[Koudijs]

Originally Posted by kodomo

I agree that porting OpenBOOX to the M92 should be not too much work per se.
The thing I'm not sure about (and that's the reason why I'm first trying to poke Onyx, as it seems a completely different order of magnitude in work to me) is annotation support. I gather that the A60 does not support annotations(?), and guess that this is still missing in OpenBOOX(?) - which I assume to be quite some work to be done.

The A60 supports annotations and scribbles but since it is using an older firmware version compared to the M92 the export functions are not available. OpenBOOX has the same level of annotation support as the official firmware version it is based on (1.5.1 at this moment).

Originally Posted by kodomo

Some of the annotation support stuff may even be connected to the Adobe reader(?). (btw. I'd need to check on whether I can find that one in the file system, or whether it's part of the missing components... does OpenBOOX include them?)

The Adobe reader is called naboo_reader, you can find it in /opt/onyx/arm/bin

Originally Posted by kodomo

If we'd have sufficient folks working on that, it might be a real option.
I have to admit that GUI programming is neither my forte nor my real interest. I always considered it more of a nuisance than fun when I had to deal with it. :P

It is mine neighter, e.g. instead of developing a dialog to enter date and time I integrated an ntp client to get the date and time from the internet
And, to be honest, the new GUI is the first Qt application I develop.

Originally Posted by kodomo

Maybe we should open a thread to discuss the work that'd have to be done to port/extend OpenBOOX?

For OpenBOOX development discussions I propose to use the forum on BooxUsers.com to avoid scattering of information. Feel free to open a thread over there.

[Koudijs]

Originally Posted by FDD

To give a try to such sort of things does not depend on having much more than the current SDK, but to design the whole system_manager again from scratch is another story, because it manages a few different things like proxying eink refresh requests, keeping track of usb status etc. I haven't looked at OpenBOOX, so I don't know how this was handled (original system_manager with a brand new gui_shell?).

Spot on. OpenBOOX uses the system_manager as is, this is no problem because it has no part in the look and feel. The explorer (gui_shell) is written from scratch.

[kodomo]

Originally Posted by Koudijs

Spot on. OpenBOOX uses the system_manager as is, this is no problem because it has no part in the look and feel. The explorer (gui_shell) is written from scratch.

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?

As I said: I'd be interested, but I cannot promise to do more than occasional stuff in the next months, as I'm currently in the hot phase of my thesis writing.
(Basically, hacking on the M92 is a sort of relaxing distraction in the evening, and I have to take care that it's not becoming too distracting... )

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...

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)

[pkbo]

AFAIU the application (gui_shell) source code is not open source but UI and system components are present in the SDK in source form. System manager is in booxsdk/code/src/sys, UI is in booxsdk/code/src/ui, components of file manager are also in the booxsdk/code/src/cms. Am I wrong?

[pkbo]

Originally Posted by kodomo

Hi folks.
communication channels (e.g., _official_ bugtracker) with developers are necessity to even consider debugging things.

There is issues tracker on github but I'm not sure if it does make sense to report the issues there. I'm a bit sceptic about close collaboration with onyx developers and I think I have everything I need to develop applications for onyx except for time or appropriate mood

[kodomo]

Originally Posted by pkbo

AFAIU the application (gui_shell) source code is not open source but UI and system components are present in the SDK in source form. System manager is in booxsdk/code/src/sys, UI is in booxsdk/code/src/ui, components of file manager are also in the booxsdk/code/src/cms. Am I wrong?

I'm afraid so (if subtly, though). gui_shell and system_manager are closed. Abovementioned directories contain the source for libraries required to write own applications... but not to modify/debug the behavior of these two.

E.g., I currently do not see a way to insert a menu item to create snapshots when arbitrary applications are running... or to add additional color options to the annotation menu. (remember that binaries on the M92 are statically compiled - and I fail to recognize a plugin interface, so far.

[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?

[pkbo]

Originally Posted by kodomo

Abovementioned directories contain the source for libraries required to write own applications... but not to modify/debug the behavior of these two.

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.

Originally Posted by kodomo

E.g., I currently do not see a way to insert a menu item to create snapshots when arbitrary applications are running... or to add additional color options to the annotation menu. (remember that binaries on the M92 are statically compiled - and I fail to recognize a plugin interface, so far.

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.