Closed nwrkbiz closed 5 years ago
The Microwindows version in this repo will not work for Android. Please use the binary version in this repo: https://github.com/georgp24/microwindows-android-bin Compiling that from scratch is so time-consuming and tedious that I decided to provide binary files.
In there there is an application note how to get this to run on Android: https://github.com/georgp24/microwindows-android-bin/blob/master/doc/FLTK%20on%20Android%20application%20note.html
Georg
Thanks for your prompt answer, I already checked out your second repo :)
I am trying to build a cross platform template for FLTK applications and made quite some progress so far (https://projects.nwrk.biz/projects/fltk-mvc-templ/wiki/). I wanted to avoid precompiled stuff for transperancy and portability. As I mentioned the app seems perfectly running (i can put debugg messages in logcat), but the display stays black.
Nevertheless I will try to link your precompiled libs and report back if they worked :)
Here is the reicepe I used to compile: https://projects.nwrk.biz/projects/fltk-mvc-templ/repository/revisions/dev/entry/_template/packages/nanox/Makefile
When linking against prebuilt -lPX11 and allegro it works :)
Daniel,
Thanks for publishing your Makefile, it’s an interesting way of specifying the changes you require as well as automating two builds in one file!
It looks like you have a semi-recent version of Microwindows source, do you know when you pulled it? Just so happens I have been making lots of cleanups to the source and config files recently. The config.linux file was replaced with two versions, config.linux-X11 and config.linux-fb. I think the config.linux-X11 should work for you. I have also done work on building using just the local X11 headers for the NX11 build for SDL (see config.sdl).
I would like to help you debug the Android version, and will create a Configs/config.allegro5 using the updated config format and settings from your config_android_arm as defaults. From there we should be able to get you on the new source tree and then get your display problem debugged quickly. I’ll also remove the C++ nanox demos when building for Android.
I have made a number of driver enhancements recently that will allow the screen update to be sped up tremendously, and also have rewritten the Mw/GsSelect() function for polling drivers like Allegro5. Once we get it painting, I can suggest some changes for you to try. In general, the new polling driver format should look close to drivers/*sdl.c, with all screen updates occurring only in the Preselect() entry point using a single draw function and bounding rect.:q
Why do you require the -m32 switches for the Linux build?
After I create an updated config files for you, can you try your Makefile using the latest source? The biggest changes were removing the tons of different driver options and replacing them with SCREEN=, MOUSE= and KEYBOARD= rather than having a large list of =Y/=N options.
I’ll ask Georg about what the differences are between his Android tree and mine, I’m not sure if he’s running updated drivers or instead is just posting the binaries in his tree. I would like to get the Android build automated and working in the master though.
Regards,
Greg
On Jan 31, 2019, at 12:51 PM, Daniel G. notifications@github.com wrote:
Here is the reicepe I used to compile: https://projects.nwrk.biz/projects/fltk-mvc-templ/repository/revisions/dev/entry/_template/packages/nanox/Makefile https://projects.nwrk.biz/projects/fltk-mvc-templ/repository/revisions/dev/entry/_template/packages/nanox/Makefile — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/ghaerr/microwindows/issues/13#issuecomment-459481862, or mute the thread https://github.com/notifications/unsubscribe-auth/ALbi5V8bTkpRYPbmiKQCOksI-30BOBTKks5vI0kkgaJpZM4acNZV.
That’s great news!
We need to diff the drivers/*allegro5.c in his and my tree, and copy Georg’s to the master tree if different. I just described some other changes in the mainline polling mechanism that were required for the SDL2 port, and we can get the Allegro driver updated to the newer mechanism and you should then have a version you can compile from scratch.
Georg - what are the reasons that you were saying that the current source master isn’t compatible with getting an Android version work? Is it just the driver files, or are there other items in the tree that are necessary?
Regards,
Greg
On Jan 31, 2019, at 5:05 PM, Daniel G. notifications@github.com wrote:
When linking against prebuilt -lPX11 and allegro it works :)
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/ghaerr/microwindows/issues/13#issuecomment-459555057, or mute the thread https://github.com/notifications/unsubscribe-auth/ALbi5WIZDCmPJu1zshpPfXGTx1PTEJbXks5vI4SwgaJpZM4acNZV.
Daniel,
I just added a Configs/config.android based on your config_android_arm into the source master. In the cleaned up tree, only the section in Arch.rules under ANDROID will need to be modified. Can you try pulling the new tree and setting that section with your CFLAGS/LDFLAGS and then running your Makefile? This will get us a long way forward to debugging the screen issue, knowing now that Georg’s binary works. I will then add the CFLAGS/LDFLAGS into Arch.rules so that we have a compiling version.
If you change your Makefile to 'cp Configs/config.linux-X11 config' that should work with the new tree also.
Regards,
Greg
On Jan 31, 2019, at 5:05 PM, Daniel G. notifications@github.com wrote:
When linking against prebuilt -lPX11 and allegro it works :)
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/ghaerr/microwindows/issues/13#issuecomment-459555057, or mute the thread https://github.com/notifications/unsubscribe-auth/ALbi5WIZDCmPJu1zshpPfXGTx1PTEJbXks5vI4SwgaJpZM4acNZV.
Daniel, I just added a Configs/config.android based on your config_android_arm into the source master. In the cleaned up tree, only the section in Arch.rules under ANDROID will need to be modified. Can you try pulling the new tree and setting that section with your CFLAGS/LDFLAGS and then running your Makefile? This will get us a long way forward to debugging the screen issue, knowing now that Georg’s binary works. I will then add the CFLAGS/LDFLAGS into Arch.rules so that we have a compiling version. If you change your Makefile to 'cp Configs/config.linux-X11 config' that should work with the new tree also. Regards, Greg … On Jan 31, 2019, at 5:05 PM, Daniel G. @.***> wrote: When linking against prebuilt -lPX11 and allegro it works :) — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#13 (comment)>, or mute the thread https://github.com/notifications/unsubscribe-auth/ALbi5WIZDCmPJu1zshpPfXGTx1PTEJbXks5vI4SwgaJpZM4acNZV.
Thanks for your reply!
I tested your config and added my flags to Arch.rules instead of sed replacing in Makefile.rules and it compiled, but again resulting with a running app without screen output.
regards, giri
That’s great news! We need to diff the drivers/*allegro5.c in his and my tree, and copy Georg’s to the master tree if different. I just described some other changes in the mainline polling mechanism that were required for the SDL2 port, and we can get the Allegro driver updated to the newer mechanism and you should then have a version you can compile from scratch. Georg - what are the reasons that you were saying that the current source master isn’t compatible with getting an Android version work? Is it just the driver files, or are there other items in the tree that are necessary? Regards, Greg … On Jan 31, 2019, at 5:05 PM, Daniel G. @.***> wrote: When linking against prebuilt -lPX11 and allegro it works :) — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#13 (comment)>, or mute the thread https://github.com/notifications/unsubscribe-auth/ALbi5WIZDCmPJu1zshpPfXGTx1PTEJbXks5vI4SwgaJpZM4acNZV.
I already did a diff on the driver/*allegro5 files and did not find any significant changes. The only thing that changeg were some direction macros within the mou_allegro5.c file.
Oh the -m32 switch is needed to compile 32 bit binaries. I do this to get binaries which can be executed on a wider range of machines :) So nothing thats really needed on a normal build.
I tested your config and added my flags to Arch.rules instead of sed replacing in Makefile.rules and it compiled, but again resulting with a running app without screen output.
Can you send me your modified Arch.rules? I would like your working settings.
We are now testing both NX11/PX11 library and libnano-X.a. In order to reduce variables, any chance you can test one of the Nano-X demos, like demo-hello? You will need to set NANOXDEMOS=Y in your config and then possiibly edit demos/nanox/Makefile.
With everything compiling, we should be able to fix things soon. There is a small chance I will have to modify the allegro driver but i think we’re backwards compatible but just not for speed.
Georg contributed the Android port and knows much more about this than I do, we’re waiting for his response on why the current tree won’t support Android.
Regards,
Greg
regards, giri
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/ghaerr/microwindows/issues/13#issuecomment-459573572, or mute the thread https://github.com/notifications/unsubscribe-auth/ALbi5W4zQsC_mfeInXz0uIpT9v1zD7GNks5vI5o3gaJpZM4acNZV.
I tested your config and added my flags to Arch.rules instead of sed replacing in Makefile.rules and it compiled, but again resulting with a running app without screen output. Can you send me your modified Arch.rules? I would like your working settings. We are now testing both NX11/PX11 library and libnano-X.a. In order to reduce variables, any chance you can test one of the Nano-X demos, like demo-hello? You will need to set NANOXDEMOS=Y in your config and then possiibly edit demos/nanox/Makefile. With everything compiling, we should be able to fix things soon. There is a small chance I will have to modify the allegro driver but i think we’re backwards compatible but just not for speed. Georg contributed the Android port and knows much more about this than I do, we’re waiting for his response on why the current tree won’t support Android. Regards, Greg … regards, giri — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#13 (comment)>, or mute the thread https://github.com/notifications/unsubscribe-auth/ALbi5W4zQsC_mfeInXz0uIpT9v1zD7GNks5vI5o3gaJpZM4acNZV.
I have attached my Arch.rules file, but it depends on my project structure and on debians android ndk packages.
Should i test to build the examples for android? Or just if it compiles using the android toolchain when setting the right include paths. For android the programms need to be compiled to a .so and then wrapped into a small android app executing the .so using allegro.
I have attached my Arch.rules file, but it depends on my project structure and on debians android ndk packages.
Thanks, I will edit this slightly and add it so that others can build by setting ANDROID_NDK_HOME and ANDROID_PLATFORM_VER, and ALLEGRO5_INCLUDE. I think the ALLEGRO5_INCLUDE should be set in the config file.
Should i test to build the examples for android? Or just if it compiles using the android toolchain when setting the right include paths.
I would like to see you build demo-hello at least (very basic) and then see whether it runs. It likely won’t, but this at least eliminates libNX11 as a possible problem.
For android the programms need to be compiled to a .so and then wrapped into a small android app executing the .so using allegro.
If you show me a Makefile for doing that, I can add that to the tree also, similar to what was done for EMSCRIPTEN, see demos/Makefile-emscripten,
Thanks!
Regards,
Greg
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/ghaerr/microwindows/issues/13#issuecomment-459580621, or mute the thread https://github.com/notifications/unsubscribe-auth/ALbi5dPvolaD6Gpk39pUHCIQ_GJLHv11ks5vI6OngaJpZM4acNZV.
I have attached my Arch.rules file, but it depends on my project structure and on debians android ndk packages. Thanks, I will edit this slightly and add it so that others can build by setting ANDROID_NDK_HOME and ANDROID_PLATFORM_VER, and ALLEGRO5_INCLUDE. I think the ALLEGRO5_INCLUDE should be set in the config file. Should i test to build the examples for android? Or just if it compiles using the android toolchain when setting the right include paths. I would like to see you build demo-hello at least (very basic) and then see whether it runs. It likely won’t, but this at least eliminates libNX11 as a possible problem. For android the programms need to be compiled to a .so and then wrapped into a small android app executing the .so using allegro. If you show me a Makefile for doing that, I can add that to the tree also, similar to what was done for EMSCRIPTEN, see demos/Makefile-emscripten, Thanks! Regards, Greg … — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#13 (comment)>, or mute the thread https://github.com/notifications/unsubscribe-auth/ALbi5dPvolaD6Gpk39pUHCIQ_GJLHv11ks5vI6OngaJpZM4acNZV.
I just compiled lNX11 and nano-X using georgs source tree and the resulting binaries work. (just to verify if the source matches the precompiled binaries)
Ok i will try to create a demo-hello android .apk
Creating android apps is usually done using gardle. Gardle completely sucks IMO, because it hides everything it does from you and is very painful to configure. So I created a makefile which executes all commands to pack a android app (see the very end of this file): https://projects.nwrk.biz/projects/fltk-mvc-templ/repository/revisions/dev/entry/_template/src/Makefile
I just compiled lNX11 and nano-X using georgs source tree and the resulting binaries work. (just to verify if the source matches the precompiled binaries)
Good news. I’m looking at the android-bin source tree right now.
Try setting “-DHAVE_SELECT=0” in your CFLAGS in Arch.rules. It looks like by default, the Android build is saying its UNIX and that may cause the wrong GsSelect() to be used in nanox/srvmain.c, which could hang in select() and GrDelay().
Ok i will try to create a demo-hello android .apk
Creating android apps is usually done using gardle. Gardle completely sucks IMO, because it hides everything it does from you and is very painful to configure. So I created a makefile which executes all commands to pack a android app (see the very end of this file): https://projects.nwrk.biz/projects/fltk-mvc-templ/repository/revisions/dev/entry/_template/src/Makefile https://projects.nwrk.biz/projects/fltk-mvc-templ/repository/revisions/dev/entry/_template/src/Makefile
Ok, I’ll look at this to educate myself.
Regards,
Greg
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/ghaerr/microwindows/issues/13#issuecomment-459586638, or mute the thread https://github.com/notifications/unsubscribe-auth/ALbi5VUBSwwykgCihs-bGXlQi-whtwJ4ks5vI6t_gaJpZM4acNZV.
Hooooraay thanks!! -DHAVE_SELECT=0 did the trick :))))
If you want to i can try to create a little sample project to create andriod apps within your source structure.
Hooooraay thanks!! -DHAVE_SELECT=0 did the trick :))))
Great!! I have added your CFLAGS/LDFLAGS into Arch.rules and will add the -DHAVE_SELECT=0 also. I will also start doing some cleanup and getting the allegro driver structure moved to the newer style. If there’s a speed issue then it won’t be too much work to make things faster.
Glad we got this working quickly, and you moved to the newer source tree!
Regards,
Greg
If you want to i can try to create a little sample project to create andriod apps within your source structure.
Yes, that would be great. Then others can verify the build by running some pre-written demos.
If the link side is a bit messy, see what was done with demos/Makefile-emscripten. I took Georg’s nice work on getting EMSCRIPTEN initially figured out and ported, and moved the build into the standard Microwindows make system. The EMSCRIPTEN link is a bit complicated for the Microwindows standard link system, so all the demos are now built using this single Makefile after the standard “make”. (see src/make-emscripten and src/link-emscripten for that example).
We could do the same for Android.
Thanks!
Regards,
Greg
Bah I feel really happy right now :) The cross platform fltk MVC template project is now working on android too :D
If you are curious, i just created a fresh build: https://buildbot.nwrk.biz/share/fltk_mvc_template/origin/dev/25/install_package/
The apk works fine on all my testing devices :)
I'll close this issue now. I think next week i have some spare time where I can try to create the andruid builds. I will send a pull request when finished if thats ok?
Thanks again for your help, giri
Hello :)
I am having troubles to get nanox + allegro running on android. Allegro and its examples work fi ne, but when starting an nanox demo application, it seems to run but the screen keeps black.
Here is the config I used to build nano-X.a: config_android_arm.txt
Here is a part of the android logcat: LogCat.txt
Thanks in advanced, and thank you for this project :)