[GSOC 2014] wxWidgets android port

[milj...@gmail.com]

About me

Hello all, my name is Nikola Miljkovic, I am 19 years old student from Serbia. Currently I am first year student in University of Belgrade, School of Electrical Engineering, working towards Software Engineering degree. I write to express my interest in wxWidgets project, as I would love to be part of it during and after Google Summer of Code.  

Project background

As we know smartphones and tablets are one of most important fields of computers today, as that they need to have as much libraries and choices as actual desktops them self's. I am personally interested in porting wxWidgets to Android OS. It should open many new possibilities to application developers, while allowing UI to be programmed at native level more easily it will also bring new complexity to applications making them competitive at market.  

My programming background

I started learning C++ 4 years ago and since then used wxWidgets on few occasions, I found it easy to understand and combined with boost it brought whole new taste to C++, a language that some already call "Not good for app development" which I don’t agree with, and wxWidgets project is one of many counters to that statement. My experience with Android was mostly in Java, however I did explore ndk and since then in last few months planned to write some code in it as I am big fan of mid level programming.

What is this project to me

This project would allow me to learn more graphics development, optimization hobbits on portable devices and improve my low and mid level programming. However this project would also be most challenging and serious in my life, but I am ambitious and I believe I can give good, clean and optimized base for wxWidgets on Android. 

My approach

Implementing a good base should be highest priority, so all low level classes should appear here as similar to other wxWidgets ports as possible, considering this is done for smaller screen and touch input. Optimizing basic classes for Android and touch should be next, there is battery life to consider, but also different android screens and processors. I personally have access to 3 phones 2 with ARM and single one with Intel Atom x32. After polishing  and testing base, I will begin implementation of higher level features, and I also wish to implement good gesture support. 

                            

This project is huge, but I am sure I can make it in next 5 months, if you accept me, I will start working as soon possible. During next 5 months I will have a lot of time to commit to this project, however at end of April and start of June I have exam weeks, during that time I will have either reduced or no time for project.

I have used SVN before and I have contributed to open source projects before, such as SunScripts, ArcEmu, KDE and ArcScript all written in C++.

[Vadim Zeitlin]

On Sat, 15 Mar 2014 07:12:37 -0700 (PDT) wrote:

> Hello all, my name is Nikola Miljkovic,

Hello Nikola and welcome to the list!

> *My approach*

>
> Implementing a good base should be highest priority, so all low level
> classes should appear here as similar to other wxWidgets ports as possible,
> considering this is done for smaller screen and touch input. Optimizing
> basic classes for Android and touch should be next, there is battery life
> to consider, but also different android screens and processors. I
> personally have access to 3 phones 2 with ARM and single one with Intel
> Atom x32. After polishing and testing base, I will begin implementation of
> higher level features, and I also wish to implement good gesture support.

I'd love to see some more details about your plans for implementing this.
While it's hard to disagree with everything you say, from the importance of
mobile platforms to the compatibility with the other ports, it's not really
clear just how exactly do you plan to achieve all these goals. If you look
at the other threads discussing wxAndroid on this list, there are actually
several possible implementation strategies, e.g. one is to wrap native
controls using some kind of helper tool for mapping Java API to C++ API
usable via JNI and using this, while the other one is to "just" implement a
canvas and wxDC/GC classes (how exactly is an open question here though)
and use wxUniv to draw all the controls ourselves.

Please try to make your proposal more detailed, thanks in advance,
VZ

[milj...@gmail.com]

Hey, let me address my thoughts on this, since it is huge topic it is definitely open to big changes.

At first i, we cannot be sure which one is definite to be used, since it requires a lot of exploring, but based from my experience creating ui wrappers through JNI is easy, it allows consistent android design. One of most important things to consider thought is sensor,touch and gesture support. JVM handles it marvelously and allows better compatibility with future Android updates.  Every class that might be technically limited in Java API could be drawn through canvas.


P.S. Should i edit my proposal on official GSoC site?

[Nikola Miljkovic]

On wxWidgets homepage there is following paragraph:

wxWidgets gives you a single, easy-to-use API for writing GUI applications on multiple platforms that still utilize the native platform's controls and utilities. Link with the appropriate library for your platform and compiler, and your application will adopt the look and feel appropriate to that platform. On top of great GUI functionality, wxWidgets gives you: online help, network programming, streams, clipboard and drag and drop, multithreading, image loading and saving in a variety of popular formats, database support, HTML viewing and printing, and much more.

That should be considered, going ANativeWindow route whole approach would be perhaps broken, everything is doable via JNI + DrawableView or other canvas components.

[Vadim Zeitlin]

On Sat, 15 Mar 2014 09:49:05 -0700 (PDT) wrote:

> Hey, let me address my thoughts on this, since it is huge topic it is
> definitely open to big changes.

It's not an easy choice, true. But I think it must be done before the
project beginning as everything else is drastically different depending on
it.

> At first i, we cannot be sure which one is definite to be used, since it
> requires a lot of exploring, but based from my experience creating ui
> wrappers through JNI is easy,

I think it's not too difficult for any given control but I really wonder
if it's doable to do it manually for all of them, which is why I think we
need to find (or write, in the worst case) a tool generating C++ wrappers
for Java controls.

> One of most important things to consider thought is sensor,touch and
> gesture support.

Yes, this is definitely important as well and is just one more things that
should be planned for...

> P.S. Should i edit my proposal on official GSoC site?

Yes, it would be great to have more detailed steps (and estimated schedule
for them) there.

Regards,
VZ

[Nikola Miljkovic]

Here few questions. Who would mentor me, i would like to discuss many implementation topics with him?
What is deadline for patch for wxWidgets?
Must patch be a bug fix, issue fix or can i add something new to wxWidgets?
 
And here is my work plan that i will add to proposal soon, please tell me what you think.

Project realization 

Realizing wxWidgets for android should be done in rather simple bot powerful way. Using JNI(Java Native Interface) calls, we would let operating system draw components that look consistent on android. That would allow us to keep up to date style always and let OS handle possible device differences.  

For testing and demonstrational purposes i would make "Skeleton application" similar this one. Implementation would be done in three phases. First phase would consist of porting base classes such as wxObject, wxTrackable and wxTopLevelWindow, adding event loop and making first JNI wrappers for basic visual components.  

Example: 

Android	wxWidget
ActionBar	wxToolBar
EditText	wxTextCtrl
SearchView	wxSearchCtrl

 

In second phase I would like to address limitations that Android UI could have. Some controls might not exist in current implementation and such it would should be researched what is best way to bring them to Android. 

wxWidget

wxMenuBar

wxRibbonPanel

 

Also expanding existing codebase with non UI classes such as wxTCPConnection, wxRegEx and more events. 

These two phases should all be done and possible during time of GSoC 2014 providing great base for wxAndroid! Yes I gave it a name :)(Its really creative too). 

Third phase is hardest, biggest and most important one. Continuing support and development of wxAndroid, writing documentation, sharing tutorials with community, reporting and fixing bugs while adding all other missing features. 

               My commitment to this project will be following: 

Begin date	End date	Avarge time commited
3rd May	1st June	25 hours/week
2nd June	13th June	10 hours/week(Exam week)
13th June	End of GSoC	40 hours/week
End of GSoC	GSoC 2015	As much as I can

[Vadim Zeitlin]

On Sun, 16 Mar 2014 06:31:31 -0700 (PDT) Nikola Miljkovic wrote:

NM> Here few questions. Who would mentor me,

This is not decided yet as this will depend on the ranking of proposals:
we'll do this first and allocate the mentors later for the projects where
several mentors are potentially available.

NM> i would like to discuss many implementation topics with him?

Please let's have the discussions on the list.

NM> What is deadline for patch for wxWidgets?

We'll start ranking proposals immediately after the end of the submission
period, i.e. March 22. While the proposal ranking could possibly change due
to a reception of a patch even after this date, it would be simpler and
better to have it before.

NM> Must patch be a bug fix, issue fix or can i add something new to wxWidgets?

You can add something new, but it's generally more difficult than fixing a
bug. And you should definitely discuss any new features here first to
ensure that there is really consensus about implementing the feature in the
first place (again, bug fixes are rarely controversial but new features
sometimes are).

Regards,
VZ

[Nikola Miljkovic]

Could you suggest for me some issue that needs fixing, since these few days i am really busy with school work and i tried exploring but it didnt work out, most of issues i found are outdated or OS X related and i dont posses Mac

[Vadim Zeitlin]

On Sun, 16 Mar 2014 08:34:50 -0700 (PDT) Nikola Miljkovic wrote:

NM> Could you suggest for me some issue that needs fixing, since these few days
NM> i am really busy with school work and i tried exploring but it didnt work
NM> out, most of issues i found are outdated or OS X related and i dont posses
NM> Mac

I see quite a few of non-OS X tickets in the list at

http://trac.wxwidgets.org/tags?q='simple'

I'm not sure which platform do you prefer to work on, but you really should
be able to find something for both MSW and Linux there.

Regards,
VZ

[Nikola Miljkovic]

I don't know how mannered it would be, but i spotted discussion on this topic in other proposal, so i didn't want to interfere.
Whole intent and activity calling is fully possible in C++ via JNI and without, Android gives good native classes that allow us to handle all that in background while giving user feeling that he works with wxWidgets code and not actual android. It is not simple mapping, but it is fully doable in C++.

[Nikola Miljkovic]

Sorry for spam but after reading this it doesn't make much sense. Let me expand:

Keeping Android's way of handling different activities and screens can be hidden behind recognizable wxFrame.

[Nikola Miljkovic]

I was checking out mailing list and other discussions about this project, while they are constructive they don't consider some of biggest issues regarding Android.

After a lot of research i have important view to add to whole discussion.
Android runs across thousands devices, all of them running different hardware and different API versions. Most obvious difference would be in screen size, but a lot more differences exist, from sensors to provided services by OS(Google maps for example). Writing native code to support each of those devices is impossible. NDK has improved in last 1-2 years but still it doesn't provide enough insurance that code will run well even among them.
That is why mapping and writing wxAndroid API is only logical with currently existing OS functions callable through Java. However that doesn't limit us at all.
There is a lot left to be done in native code and through Android by us without help of android SDK.

Please tell me what you think.

[Nikola Miljkovic]

Could i please get insight on last 2-3 mails, i am in process of finishing proposal.

Another addition is developers blog that i would be running, it will help everyone around both interested in project and mentor to have constant updates on what i am doing, way of doing it with exact dates.

[Vadim Zeitlin]

On Thu, 20 Mar 2014 08:31:30 -0700 (PDT) Nikola Miljkovic wrote:

NM> Could i please get insight on last 2-3 mails, i am in process of finishing
NM> proposal.

I don't really know what kind of insight are you looking at. Clearly,
wrapping the native controls has a lot of advantages and I'd be glad if we
could do this. However we still need to implement all the low level classes
and we still need some way to draw (e.g. to implement wxEVT_PAINT), so the
main question here is whether it may make sense to start with wxUniv-based
implementation and switch to native controls later and I don't know the
answer to it.

Regards,
VZ

[Nikola Miljkovic]

I am still for making lowest level classes and mapping done first. That would include base for drawing on SurfaceView, DrawView or other controls.
That base would be bridge between wxUniv objects and android's drawables, interpreting existing code and making sure it gets executed properly on Android.


Future reading: http://developer.android.com/guide/topics/graphics/2d-graphics.html

[Nikola Miljkovic]

https://github.com/SRBNikolaSRB/wx-android

Here is github link, please monitor on it because i will have more commits, for now it only draws a button written in full C++.
Strings are not supported yet, and i am not sure if it is worth writing support for them on these demo's.(It may require a lot of time)
However i will write some OpenGL ES support.

Please note that this isn't even wx implementation yet, this is just simple few JNI calls, i dont have time in next few days but starting next week i will make some wx classes.

I have also written a script that will help you compile JNI code for usage.

Ask anything if you want.

[Vadim Zeitlin]

On Sat, 22 Mar 2014 04:09:10 -0700 (PDT) Nikola Miljkovic wrote:

NM> https://github.com/SRBNikolaSRB/wx-android
NM>
NM> Here is github link, please monitor on it because i will have more commits,
NM> for now it only draws a button written in full C++.

Very nice, thanks!

NM> Strings are not supported yet, and i am not sure if it is worth writing
NM> support for them on these demo's.(It may require a lot of time)

What is the problem with returning strings? I think it should be
relatively simple... But, anyhow, it's true that it's not indispensable for
the demo.

NM> However i will write some OpenGL ES support.

This would be very instructive. And another thing which I'd really like to
check is whether creating a button like the current code does works
correctly when using NativeActivity as the main activity?

NM> Please note that this isn't even wx implementation yet, this is just simple
NM> few JNI calls, i dont have time in next few days but starting next week i
NM> will make some wx classes.

This is something that could wait until the beginning of the project
itself, the real point of this demo is to check whether the APIs we plan to
use really work as we expect them to.

Thanks!
VZ

[Nikola Miljkovic]

Hey i fixed string, there was a function to convert to java's string, i thought i needed to convert char[] to it(my bad didn't read JNI documentation well enough). As for NativeActivity, i am currently researching that topic.

[Nikola Miljkovic]

Ok so last update for today, it shows a example how would specific wxClass be done, in this case wxButton, i implementet copy of wxbutton, it only contains two methods, however this is what i concluded so far.
A specific layer called wxAndroid should handle all env and jni related tasks and it should be only part actually referencing java types, all beyond that should use and implement normal C++ types.
What i want to show in this project is that java can have only 10 lines and allow program to be fully programmed in wxWidgets/C++ without ever thinking about Java.

As for NativeActivity there are ways for it to use JVM, but it actually consists of making a java activity and using code i wrote so technically a small bridge would be needed for it to function.

This is last commit for next 48 hours as i have 3 exams in that time :D took a lot of time, but i hope this gives strong idea of what can and how will be done.

Writing a small make script or py script that would basically make folder structure and move wx files in those proper locations and give basic c++ start file would be great way to "Install" wxAndroid to your native project.

Also this approach JNI one would allow Java to use wx bidings. That can come handy to someone.

[Nikola Miljkovic]

I have question regarding how many java code can we use? While escaping absolutely no java code is almost impossible, can we implement support interface for C++ in java?
It is possible to avoid idea i have here, it is about event implementation as i am currently researching that.
Having a bit of java code wouldn't change much for wxWidgets users, as they won't be require to touch anything besides C++ (ofc if they want they can do w/e they want :D) to get this working.

[Nikola Miljkovic]

Also in experimental branch i will write some pure NativeActivity code(sometimes next week), to test out its flexibility.

What ever i do now as terms of implementation don't mean anything will be done that way!!
And i actually believe that NativeActivity will be best in end.

[Melroy Tellis]

I am experimenting with Native code right now.I managed to create a basic native application(with absolutely no Java code) with all the lifecycle callbacks but no GUI so that it only displays a black screen on running(but doesn't crash).I'll commit it when it's more usable.

[Melroy Tellis]

Based on my preliminary research,it appears that creating a minimal native application with absolutely no Java code is feasible.Also it's possible to implement Event Loopers in a purely native application which might help in porting the wxEventLoop class.

[Nikola Miljkovic]

Those are not problem on native activity, real problem is activity life cycle and proper thread handling. there is sample native activity in ndk check out that.

[Melroy Tellis]

I have already looked at the NativeActivity sample.Handling activity lifecycle events isn't that difficult.As I said,I have already created a basic application with a native-activity that handles all the activity lifecycle callbacks.It's also possible to load a bitmap as an asset and display it.I haven't done much research on threading but will do so when I'm done with creating a native-activity with some primitive GUI.

[Nikola Miljkovic]

You cannot make GUI without thread attach/detach, as for callbacks, its extremely simple in native activity, and that won't be problem in such implementation.
Iv got no time until later today but i will commit some kind of working nativeactivity + jni with event handling, we will see how will that workout.

[Nikola Miljkovic]

Hey so after a lot of testing and trying, i found a way to draw UI interfaces via NativeActivity. I believe its also only way.

It's pure hacking, native activity cannot use Java's Layouts so we need to invoke Activity from NativeActivity and manage it, it is possible to be done in pure c/c++.
However i am pausing on this because i believe this is worst way possible to do this, either go with java + C/C++ bind layer or pure nativeactivity.

Please developers tell me what you think and if you want Java + C/C++ or pure C++/

[Vadim Zeitlin]

On Sun, 23 Mar 2014 08:31:53 -0700 (PDT) Nikola Miljkovic wrote:

NM> Hey so after a lot of testing and trying, i found a way to draw UI
NM> interfaces via NativeActivity. I believe its also only way.

Interesting, but where/how is this done? I don't see any commits in your
repository doing this...

NM> It's pure hacking, native activity cannot use Java's Layouts

I was afraid of this... Is this an official limitation? I.e. is this
documented somewhere?

NM> so we need to invoke Activity from NativeActivity and manage it, it is
NM> possible to be done in pure c/c++. However i am pausing on this because
NM> i believe this is worst way possible to do this, either go with java +
NM> C/C++ bind layer or pure nativeactivity.

Sorry, I'm confused, can we still use native activity if we want to use
the native Java widgets?

NM> Please developers tell me what you think and if you want Java + C/C++ or
NM> pure C++/

I don't mind some fixed Java part which would have to be compiled together
with the C++ code. I'd just like it to be unnecessary to write any Java
code (although it would be acceptable if some things could be only
customized from Java).

Regards,
VZ

[Melroy Tellis]

I think  I might have found a way too.I'll disclose more details if and when I find that it works.
 

[Nikola Miljkovic]

Hey, i have wrote some code but it is not finished yet, i paused on half way when i realized new activity is needed.

VZ>  Sorry, I'm confused, can we still use native activity if we want to use
the native Java widgets?

Yes and no, depending on route we go it will finish up like my original implementation. Also both are possible in pure C++ but i don't consider it best way.

NativeActivity doesn't bring much to table except actually allowing your code to be ran directly from native calls, NActivity is just another Android class with limitations.

If we choose to use some java code, current implementation that is active on github can be extended to work extremely well with it.
If we choose to draw everything, i suggest native activity as it is best way to do it.

[Nikola Miljkovic]

I don't know how much should i compare these but for example qt uses approach where part of bindings is handled by java:
https://qt-project.org/forums/viewthread/30055

Btw, all these are just considerations in testing, if i get chosen by 19th i will have good base and will know exact solution to this project.

[Melroy Tellis]

It's actually a work-around to the many restrictions imposed by Android on Native Activities.

http://www.dynadream.com/ddweb/index.php/Special_Blog?id=20

[Nikola Miljkovic]

I researched that long ago and i stated it here, it can even be done without any Java code, but it is still horrible code, if we want to use java code then it would be best to continue implementation currently in place.

[Melroy Tellis]

Yes the code is indeed horrible and would be a nightmare to debug.

[Melroy Tellis]

OpenGLES does not provide any methods for drawing text to a surface so one method to write text in a NativeActivity is by manipulating individual pixels.Even that is nightmarish.

[Nikola Miljkovic]

Well we won't be first ones to attempt solving such a problem i am sure there are great solutions already, so that won't be a problem.

I committed some kind of event code, but i will most likely remake it as i found a lot better solution.

[Nikola Miljkovic]

I will try finishing NativeActivity code later today, after i commit it should showcase what we shouldn't use.

Also potential mentors, what do you think of work done so far(examples), writing up few Java classes looks like a good way to handle this.

[Vadim Zeitlin]

On Mon, 24 Mar 2014 02:17:50 -0700 (PDT) Nikola Miljkovic wrote:

NM> Also potential mentors, what do you think of work done so far(examples),
NM> writing up few Java classes looks like a good way to handle this.

This definitely looks very promising so far, thanks a lot for your efforts
to you both. I fully expect that we'll have plenty unforeseen problems
later on but it's quite encouraging to see that this approach has at least
a chance of working.

Regards,
VZ

[Nikola Miljkovic]

I wrote to my proposal, please check question out there. I am glad it looks good, I have committed native activity code that i didn't finish but if you want i can. My personal thought is that NativeActivity just makes it more complex and doesn't bring anything good to table.

[Vadim Zeitlin]

On Mon, 24 Mar 2014 07:23:30 -0700 (PDT) Nikola Miljkovic wrote:

NM> I wrote to my proposal, please check question out there.

Sorry, I don't understand what do you mean by separating the bindings from
wxAndroid. Do you mean that creating C++ wrappers for the Java classes
should be a separate project? If so, yes, this would make sense to me, but
this separate project should also be a subproject of wxAndroid...

BTW, have you seen https://github.com/DmitrySkiba/itoa-jnipp ? This looks
like another (since abandoned but possibly still useful) effort to automate
using Java APIs from C++.

NM> My personal thought is that NativeActivity just makes it more complex
NM> and doesn't bring anything good to table.

AFAIU the main benefit of NativeActivity is that you can implement
lifecycle callbacks (onPause(), onResume(), ...) in native code. It's true
that if it's the only thing we get from it, it's not much as we have to
wire these callbacks to wxApp methods anyhow, and we could just call these
wxApp methods directly from the Java callbacks too. Basically we could just
our own equivalent of this code:

https://github.com/android/platform_frameworks_base/blob/master/core/java/android/app/NativeActivity.java

Of course, there is no need to rewrite it if it's going to do exactly the
same thing neither, but having our own wxActivity could help if we need it
to do something different...

Regards,
VZ

[Nikola Miljkovic]

>> BTW, have you seen https://github.com/DmitrySkiba/itoa-jnipp ? This looks
like another (since abandoned but possibly still useful) effort to automate
using Java APIs from C++.

>> Second link:
There are serveral projects like that, they are all great but might be even too wide, we need Android -> C++ not whole Java. At least i think that

My idea was like that one in second link and any similarity between that NativeActivity and ANativeActivity is in name and lifecycle everything else is different.


As for bindings project, yes it is part of wxAndroid, but should be approached as general Android to native binder because of design choices, wxAndroid(all those classes) should be written on binding base.

[Nikola Miljkovic]

I think at this point, there is only single big design choice to make and that is following:

Android -> wxClasses
Android -> AndroidBinder -> wxClasses

Both are good, but i prefer second.
Why?

It will allow anyone who wants to improve wxWidgets simply contribute without studying JNI and things done in binding.

[Vadim Zeitlin]

On Mon, 24 Mar 2014 08:21:41 -0700 (PDT) Nikola Miljkovic wrote:

NM> >> BTW, have you seen https://github.com/DmitrySkiba/itoa-jnipp<https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2FDmitrySkiba%2Fitoa-jnipp&sa=D&sntz=1&usg=AFQjCNFhx_nynPrVk5qc-U3mXoKiHNP4vg>? This looks
NM> like another (since abandoned but possibly still useful) effort to automate
NM> using Java APIs from C++.
NM>
NM> >> Second link:
NM> There are serveral projects like that, they are all great but might be even
NM> too wide, we need Android -> C++ not whole Java. At least i think that
NM>
NM> My idea was like that one in second link and any similarity between that
NM> NativeActivity and ANativeActivity is in name and lifecycle everything else
NM> is different.

Sorry, I don't know if this is due to the use of HTML, but I don't
understand anything at all here :-( What is the second link? What do you
mean by whole Java?

NM> I think at this point, there is only single big design choice to make and
NM> that is following:
NM>
NM> Android -> wxClasses
NM> Android -> AndroidBinder -> wxClasses

I still have no idea what AndroidBinder actually is. It would be great if
you could explain it in more details please.

Thanks,
VZ

[Melroy Tellis]

I think he's referring to some intermediate code that will interact
with Android and then pass the control of the Activity to the natively
written wxAndroid program.

[Nikola Miljkovic]

Android Binder(Random name i came up with) is a helper coded in both Java and C++.
Goal of it should be to make it possible and easier to use java/android classes and methods in native code, it would also handle everything related to JNI.

So when, for example we start making wx_____ class we won't use JNI calls directly we would but them through our binding interface.

[Nikola Miljkovic]

Sorry for extremely bad sentences, i am really tiered and my brain is crushing :P

[Melroy Tellis]

That's pretty much the original plan we had in mind,isn't it?To stick
to the existing wxWidgets nomenclature so that present wxWidgets
developers would be able to write code using wxAndroid along the lines
of existing wxWidgets code.And doing this would undoubtedly require a
wrapper to hide the rather unwieldy JNI names that have to be assigned
to functions.

[Vadim Zeitlin]

On Mon, 24 Mar 2014 08:46:41 -0700 (PDT) Nikola Miljkovic wrote:

NM> Android Binder(Random name i came up with) is a helper coded in both
NM> Java and C++. Goal of it should be to make it possible and easier to
NM> use java/android classes and methods in native code, it would also
NM> handle everything related to JNI.
NM>
NM> So when, for example we start making wx_____ class we won't use JNI calls
NM> directly we would but them through our binding interface.

Yes, right, this was indeed the plan since the very beginning. Just for
clarity, this is what I called "wrapper classes". I.e. instead of using,
say, "android.widget.TextView" directly via JNI, we'd use some
Android::Widget::TextView class which would wrap Java class methods.

The question, which I also had since the very beginning, is how exactly to
create these wrapper classes: manually (straightforward but so dreary) or
automatically (should really save time in the long term, but could lost it
in the short term of a GSoC). And I thought that this itoa-jnipp project
could be a happy middle ground between the two: it does it manually but
using helper macros which make it much simpler to create these wrappers.
I didn't look at it in details, but if it really works like I think it
does, it could be very useful to us.

Regards,
VZ

[Melroy Tellis]

Your point about automation is completely relevant.We should consider
creating an application that would automatically generate the required
wrappers,Makefiles and Manifests so that the developer wouldn't have
to worry about these details.One possible way of doing this could be
by creating a plug-in to an existing IDE,somewhat like wxSmith for
Code::Blocks.

[Nikola Miljkovic]

Should i begin making those wrapper classes? I should i do it on seperate repo? Note, i plan to finish this before wxAndroid, what do you think about that? It is more like my contribution to project before actually proting wx Classes?

[Melroy Tellis]

I think you should first reflect on whether you want to create the
wrappers manually or by automated tools.One particularly important
reason for using automation to generate the wrappers would be that the
wrappers would have to reflect the package name of the app,which
should be unique for each app.If you create the wrappers manually,you
would have to manually replace all references to the previous package
name in the wrappers to reflect the new package name,whenever you
decide to change the package name,which ideally should happen every
time you create a new app.This would be better handled by
automation.If you do create a new repository,add me to
it.Collaboration will decrease the time required.

[Nikola Miljkovic]

Not really, we will have our own package that is to be included, and name will stay same cross project. We will see what wx devs say about this.

[Vadim Zeitlin]

On Mon, 24 Mar 2014 10:56:37 -0700 (PDT) Nikola Miljkovic wrote:

NM> Should i begin making those wrapper classes?

I think this merits a bit more planning. How exactly are you going to do
it? I'm sorry for repeating it over and over again, but I think that we do
need some way if not to automate it, then at least have some helpers
functions/macros to make it less painful then writing everything by hand.

Also, even if you plan to do everything mostly manually, have you thought
about handling issues such as:

1. Inheritance: ideally, wrappers for Java class J2 deriving from J1 should
also derive from each other.

2. Callbacks: how will overriding Java methods work from C++ code?

3. Anything else that I didn't think about in the last 30 seconds?


NM> I should i do it on seperate repo?

I don't think so. Presumably these wrappers will still be wx-specific,
e.g. they would be using wxString, wxDateTime and so on, wouldn't they?

NM> Note, i plan to finish this before wxAndroid, what do you think about
NM> that?

This seems very optimistic to me. There are a *lot* of classes to wrap.

NM> It is more like my contribution to project before actually proting wx
NM> Classes?

Sorry, could you please rephrase this?
VZ

[Vadim Zeitlin]

On Mon, 24 Mar 2014 23:37:04 +0530 Melroy Tellis wrote:

MT> I think you should first reflect on whether you want to create the
MT> wrappers manually or by automated tools.One particularly important
MT> reason for using automation to generate the wrappers would be that the
MT> wrappers would have to reflect the package name of the app,which
MT> should be unique for each app.

Why? Wrappers are C++ classes, they don't need to care about Android Java
package names restrictions. Am I missing something?

Regards,
VZ

[Nikola Miljkovic]

Ok so it will be same repo and yes i planned for it to convert directly to some wx classes like string you mantioned.

When i thought about starting it, I thought about thinking a way to handle all those before actually starting to write.
Merloy wanted to say that native calls use naming convention such as:
class a { native void b() } as part of package com.wx
native function in that would be called via:
Java_com_wx_a_b(...); in Native.

Would making graphs of how i want to handle specific problem help? And than you say what looks good/ what doesnt?

VZ> 2. Callbacks: how will overriding Java methods work from C++ code?
Latest event code kind-a handles that problem, i still want to tune it up and think it through but I think that i am on a right road.

[Melroy Tellis]

I was referring to the fully qualified JNI method names in the
wrappers which would have to include the name of the package.

[Melroy Tellis]

I'm going to write a comparison between the available approaches(most
of which have been covered to some extent in the past few days) in my
revamped proposal.It would greatly help potential mentors.

[Vadim Zeitlin]

On Tue, 25 Mar 2014 00:29:33 +0530 Melroy Tellis wrote:

MT> I was referring to the fully qualified JNI method names in the
MT> wrappers which would have to include the name of the package.

I guess the name of the main package (for callbacks?) would need to be
made globally available somehow.

Regards,
VZ

[Vadim Zeitlin]

On Mon, 24 Mar 2014 11:59:00 -0700 (PDT) Nikola Miljkovic wrote:

NM> Merloy wanted to say that native calls use naming convention such as:
NM> class a { native void b() } as part of package com.wx
NM> native function in that would be called via:
NM> Java_com_wx_a_b(...); in Native.

If "com.wx" is the name of the real main package, then I think we just
need to make its name globally available, presumably somewhere in wxApp.
I.e. we should use a variable for it instead of hardcoding it anyhow.

NM> Would making graphs of how i want to handle specific problem help?

I think words/[pseudo-]code should be enough but why not graphs...

Regards,
VZ

[Melroy Tellis]

That's what I was suggesting.We could create a rudimentary project
creation wizard application that will accept the user-defined package
name and do the needful.In addition,it could also generate the
makefiles,manifests and required directory structure.

[Nikola Miljkovic]

There is no need for such a think, you are complicating way too much, it should just be put these folders in ndk/include but these in project = done

[Bakcsi Zsolt]

Hello,

First of all, its great to see so much progress! Thank you!

Please let me add my 2 cents.

While it is certainly important to do the wx<->java bindings right, I expect much more problems to arise around the wx event loop. Unfortunately, I'm not really familiar with it, but, for example, I occasionally came across wx code that holds the main thread and calls back to the event processing repeatedly. I'm not sure this can be nicely implemented on Android (but also, I don't know whether such code will be necessary in wxAndroid at all).

So, at this stage, I would not put too much effort into the wx<->java bindings. Instead, I'd take the quickest route (probably direct jni calls in wxAndroid c++ code), implement a minimum set of classes (frame, static text, button) with only the functions absolutely necessary to a 'Hello world' app (well, AFAICS it's almost there on Nikola's github), and then I'd take a closer look to the event loop related stuff.

Best Regards,

Zsolt

[Nikola Miljkovic]

Hey, thanks a lot and i am glad you like it.

In case that we cannot make exact technical replica of Event loop , we can simulate it.

[Melroy Tellis]

That's where the problem lies.While it would be much easier to write
event-loops in pure Native Activities,it would be difficult to add
support for standard UI elements unless they are explicitly drawn to
the display by GLES.On the other hand,it's easier to add support for
UI elements in a pseudo-Native activity i.e. an activity which is
written in Java but delegates all its functionality to native code.So
we'll probably have to make some compromises for the sake of creating
a functional wxAndroid port.

[Nikola Miljkovic]

Hey, is plan to use Android's event listeners for group of events supported by it? And rest can be handled by Event loop called from Activity or parent view.
What do you think about that? We can take advantage of Android's handling of some events and rest + drawn get handled by EventLoop controlled from parent view(s) or surface view.

[Melroy Tellis]

I'll try to look into it.Also you have asked whether every object
should be made a global reference.An object needs to be made a global
reference when you want to retain the reference in successive
invocations of the native method.Otherwise,it may be treated as
garbage by the Dalvik VM.

[Nikola Miljkovic]

That is partially right but that is not why i asked, i researched and i got it sorted out where i would use GlobalRef  and where I should not use them.

[Vadim Zeitlin]

On Wed, 26 Mar 2014 11:53:53 -0700 (PDT) Nikola Miljkovic wrote:

NM> Hey, is plan to use Android's event listeners for group of events supported
NM> by it?

Aren't we forced to use them if we use native controls? I.e. what is the
alternative?

Regards,
VZ

[Nikola Miljkovic]

Parent view should be ablle to handle them

[Nikola Miljkovic]

Yes, it is possible activity can take motion event and unpack it if clicked view doesn't have specific EventListener.
Just committed change that shows this :)

[Melroy Tellis]

The code for the onClick event listener is unstable and crashes on execution.

On Thu, Mar 27, 2014 at 4:02 AM, Nikola Miljkovic <milj...@gmail.com> wrote:

Yes, it is possible activity can take motion event and unpack it if clicked view doesn't have specific EventListener.
Just committed change that shows this :)

--
To unsubscribe, send email to wx-dev+un...@googlegroups.com
or visit http://groups.google.com/group/wx-dev

[Nikola Miljkovic]

MT>The code for the onClick event listener is unstable and crashes on execution.

I tested it before commiting, it definetly did work. Could you share crashdump?
Thanks in advice

[Melroy Tellis]

The crash was being caused by a stale reference to the TextView class through m_class in the setText() method for the wxTextCtrl class.I have fixed this issue in the latest commit by retrieving the object class from m_object which is a global reference.I have also done the same for the wxButton class to prevent potential errors in the future.In addition,I have added support for wxNotificationMsg(Toast).I have also added some primitive support for unpacking motion events by wrapping the getRawX() and getRawY() methods in a newly defined wxMotionEvent class. 

[Nikola Miljkovic]

MT>The crash was being caused by a stale reference to the TextView class through m_class in the setText() method for the wxTextCtrl class.I have fixed this issue in the latest commit by retrieving the object class from m_object MT>which is a global reference.I have also done the same for the wxButton class to prevent potential errors in the future.In addition,I have added support for wxNotificationMsg(Toast).I have also added some primitive support for MT>unpacking motion events by wrapping the getRawX() and getRawY() methods in a newly defined wxMotionEvent class. 

Hey, i checked out your commit, it looks good but i have tested what you said was crashing again, and it all works good as m_class doesn't need global reference. Implementation for getRawX/Y can make problems, because one it is not supported in all SDK revisions, there are different ways that we can scale that for older revisions.

Could you just share crash dump of previous version as it would really help me out in tracking of problem.

[Melroy Tellis]

03-27 13:43:11.490: D/dalvikvm(885): Not late-enabling CheckJNI (already on)
03-27 13:43:12.010: I/dalvikvm(885): CheckJNI enabled: not enabling JNI app bug workarounds.
03-27 13:43:14.110: D/dalvikvm(885): Trying to load lib /data/app-lib/com.example.hellojni-2/libwxJNI.so 0xb4d8d770
03-27 13:43:14.250: D/dalvikvm(885): Added shared lib /data/app-lib/com.example.hellojni-2/libwxJNI.so 0xb4d8d770
03-27 13:43:14.250: D/dalvikvm(885): No JNI_OnLoad found in /data/app-lib/com.example.hellojni-2/libwxJNI.so 0xb4d8d770, skipping init
03-27 13:43:17.230: I/System.out(885): 0
03-27 13:43:18.270: I/Choreographer(885): Skipped 41 frames!  The application may be doing too much work on its main thread.
03-27 13:43:18.610: D/gralloc_goldfish(885): Emulator without GPU emulation detected.
03-27 13:43:21.060: E/dalvikvm(885): JNI ERROR (app bug): accessed stale local reference 0x1ee00041 (index 16 in a table of size 9)
03-27 13:43:21.060: W/dalvikvm(885): JNI WARNING: jclass is an invalid local reference (0x1ee00041) (GetMethodID)
03-27 13:43:21.060: W/dalvikvm(885):              in Lcom/example/hellojni/wxJNI;.handleEvent:(ILjava/lang/Object;)V (GetMethodID)
03-27 13:43:21.070: I/dalvikvm(885): "main" prio=5 tid=1 RUNNABLE
03-27 13:43:21.070: I/dalvikvm(885):   | group="main" sCount=0 dsCount=0 obj=0xb4ad8ca8 self=0xb89df380
03-27 13:43:21.070: I/dalvikvm(885):   | sysTid=885 nice=0 sched=0/0 cgrp=apps handle=-1224986284
03-27 13:43:21.070: I/dalvikvm(885):   | state=R schedstat=( 710000000 4210000000 260 ) utm=54 stm=17 core=0
03-27 13:43:21.070: I/dalvikvm(885):   at com.example.hellojni.wxJNI.handleEvent(Native Method)
03-27 13:43:21.070: I/dalvikvm(885):   at com.example.hellojni.wxJNI.onClick(wxJNI.java:52)
03-27 13:43:21.080: I/dalvikvm(885):   at android.view.View.performClick(View.java:4438)
03-27 13:43:21.080: I/dalvikvm(885):   at android.view.View$PerformClick.run(View.java:18422)
03-27 13:43:21.080: I/dalvikvm(885):   at android.os.Handler.handleCallback(Handler.java:733)
03-27 13:43:21.080: I/dalvikvm(885):   at android.os.Handler.dispatchMessage(Handler.java:95)
03-27 13:43:21.090: I/dalvikvm(885):   at android.os.Looper.loop(Looper.java:136)
03-27 13:43:21.090: I/dalvikvm(885):   at android.app.ActivityThread.main(ActivityThread.java:5017)
03-27 13:43:21.090: I/dalvikvm(885):   at java.lang.reflect.Method.invokeNative(Native Method)
03-27 13:43:21.090: I/dalvikvm(885):   at java.lang.reflect.Method.invoke(Method.java:515)
03-27 13:43:21.090: I/dalvikvm(885):   at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:779)
03-27 13:43:21.090: I/dalvikvm(885):   at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:595)
03-27 13:43:21.090: I/dalvikvm(885):   at dalvik.system.NativeStart.main(Native Method)
03-27 13:43:21.090: E/dalvikvm(885): VM aborting
03-27 13:43:21.090: A/libc(885): Fatal signal 6 (SIGABRT) at 0x00000375 (code=-6), thread 885 (xample.hellojni)
03-27 13:43:42.980: D/dalvikvm(1044): Trying to load lib /data/app-lib/com.example.hellojni-2/libwxJNI.so 0xb4d94d60
03-27 13:43:42.980: D/dalvikvm(1044): Added shared lib /data/app-lib/com.example.hellojni-2/libwxJNI.so 0xb4d94d60
03-27 13:43:42.980: D/dalvikvm(1044): No JNI_OnLoad found in /data/app-lib/com.example.hellojni-2/libwxJNI.so 0xb4d94d60, skipping init
03-27 13:43:43.680: I/System.out(1044): 0
03-27 13:43:44.250: D/gralloc_goldfish(1044): Emulator without GPU emulation detected.
03-27 13:43:46.030: E/dalvikvm(1044): JNI ERROR (app bug): accessed stale local reference 0x1ee00041 (index 16 in a table of size 9)
03-27 13:43:46.030: W/dalvikvm(1044): JNI WARNING: jclass is an invalid local reference (0x1ee00041) (GetMethodID)
03-27 13:43:46.040: W/dalvikvm(1044):              in Lcom/example/hellojni/wxJNI;.handleEvent:(ILjava/lang/Object;)V (GetMethodID)
03-27 13:43:46.040: I/dalvikvm(1044): "main" prio=5 tid=1 RUNNABLE
03-27 13:43:46.040: I/dalvikvm(1044):   | group="main" sCount=0 dsCount=0 obj=0xb4ad8ca8 self=0xb89df380
03-27 13:43:46.040: I/dalvikvm(1044):   | sysTid=1044 nice=0 sched=0/0 cgrp=apps handle=-1224986284
03-27 13:43:46.040: I/dalvikvm(1044):   | state=R schedstat=( 490000000 1670000000 196 ) utm=29 stm=20 core=0
03-27 13:43:46.040: I/dalvikvm(1044):   at com.example.hellojni.wxJNI.handleEvent(Native Method)
03-27 13:43:46.040: I/dalvikvm(1044):   at com.example.hellojni.wxJNI.onClick(wxJNI.java:52)
03-27 13:43:46.040: I/dalvikvm(1044):   at android.view.View.performClick(View.java:4438)
03-27 13:43:46.080: I/dalvikvm(1044):   at android.view.View$PerformClick.run(View.java:18422)
03-27 13:43:46.150: I/dalvikvm(1044):   at android.os.Handler.handleCallback(Handler.java:733)
03-27 13:43:46.160: I/dalvikvm(1044):   at android.os.Handler.dispatchMessage(Handler.java:95)
03-27 13:43:46.160: I/dalvikvm(1044):   at android.os.Looper.loop(Looper.java:136)
03-27 13:43:46.160: I/dalvikvm(1044):   at android.app.ActivityThread.main(ActivityThread.java:5017)
03-27 13:43:46.160: I/dalvikvm(1044):   at java.lang.reflect.Method.invokeNative(Native Method)
03-27 13:43:46.160: I/dalvikvm(1044):   at java.lang.reflect.Method.invoke(Method.java:515)
03-27 13:43:46.160: I/dalvikvm(1044):   at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:779)
03-27 13:43:46.170: I/dalvikvm(1044):   at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:595)
03-27 13:43:46.180: I/dalvikvm(1044):   at dalvik.system.NativeStart.main(Native Method)
03-27 13:43:46.180: E/dalvikvm(1044): VM aborting
03-27 13:43:46.180: A/libc(1044): Fatal signal 6 (SIGABRT) at 0x00000414 (code=-6), thread 1044 (example.hellojni)

--

[Nikola Miljkovic]

Apparently only happens on emulator, tried on older and kitkat android phone and it worked properly. Lets leave it like this then.

[Vadim Zeitlin]

On Fri, 28 Mar 2014 15:17:58 -0700 (PDT) Nikola Miljkovic wrote:

NM> Apparently only happens on emulator, tried on older and kitkat android
NM> phone and it worked properly. Lets leave it like this then.

I didn't follow this discussion in details (it's very difficult to do...),
but the conclusion is eminently suspicious. Unless Android emulator is
known to be incredibly buggy, I'd strongly suspect that the reason for the
crash is a bug in your code which, for whatever reason, doesn't always
manifest itself, and not a bug in the emulator which somehow went unnoticed
by all the millions of people who use it.

It also seems that there is some confusion between the different kind of
references used in JNI. Again, I wasn't even able to understand what the
problem is, so I could be missing something, but there should be nothing
unclear/unpredictable about the use of global vs local references, it's
actually pretty simple...

Regards,
VZ

[Nikola Miljkovic]

VZ>It also seems that there is some confusion between the different kind of
VZ>references used in JNI. Again, I wasn't even able to understand what the
VZ>problem is, so I could be missing something, but there should be nothing
VZ>unclear/unpredictable about the use of global vs local references, it's
VZ>actually pretty simple...

There is no confusion at all. I do understand global/local references which i demonstrated in my previous commits. I did test it and didn't see that some of code i made would crash an emulator as i test my code on two different devices and everything worked fine.Yes, it is mistake from my part but it has nothing to do with understanding/not understanding different reference scopes.
As for emulator, AVD emulator is known for being buggy.

[Melroy Tellis]

The bug has been fixed now and there shouldn't be any cause for
worry.And with a little more work,we'll probably get to the point
where we can create a minimal app with support for a decent number of
controls and their associated methods.Like you,I too am sure that it's
not a bug with the emulator but is rather related to the quite
unpredictable process of garbage collection by the Dalvik VM and that
the bug would probably surface on an actual device at some point of
time in the future if left untreated.

[Nikola Miljkovic]

MT>Like you,I too am sure that it's not a bug with the emulator but is rather related to the quite
MT>unpredictable process of garbage collection by the Dalvik VM and that
MT>the bug would probably surface on an actual device at some point of
MT>time in the future if left untreated.

I have said that bug was my mistake, and didn't change anything on repository. Emulator is buggy, but i never blamed it for this crash.

Porting as much controls and methods as possible is pointless, as this is not actual project but proof of concept there are more important things to do:

* Finish NativeActivity project, there is one committed on repository but i believe there is no need to work on it as it would just complicate our approach, especially since i added OnTouch(); which can bring us everything we wanted from NativeActivity, however you said you might have a way other then current one for drawing UI components on to it.

* Construct proper helper classes on Android side, that would be easy to use from JNI.

* Canvas component, i will try getting this done today.

* Reorganize folders and files, java project to show how would we do it in actual wxAndroid for easy usage.

* wxApp is pretty much figured out, we can maybe port that for proof of concept purposes.

* Other important classes should be researched like wxWindows, currently there is LinearLayout instead of that.

* There are many more ways to contribute, this is honestly just research project and nothing we do here is actually final.

[Melroy Tellis]

We could and ideally should start working on other layout styles like
RelativeLayout.The implementation of ViewGroups such as ListView also
merits some research.
As for naming,the package name should ideally be
"org.wxwidgets.wxandroid" as per standard Android package name
conventions.The directory structure would also have to be changed to
comply with wxWidgets conventions.
The Canvas component should not be difficult to implement since I have
come across extensive materials on it (although I haven't gone through
them in detail yet) and I'm pretty sure you would have come across
them too.
Since we have achieved quite a lot on the UI controls front,it would
also be a good idea to start working on the porting of some of the
base non-GUI classes such as wxString.
Although this may be just a research project,the outcome of this
project could and probably would benefit the final implementation of
wxAndroid.

[Nikola Miljkovic]

MT>We could and ideally should start working on other layout styles like
MT>RelativeLayout.The implementation of ViewGroups such as ListView also
MT>merits some research.

My plan is to have our own version of RelativeLayout for basing wxPanel on, it would be similar to old AbsoluteLayout which Android unfortunately ditched.

MT>The Canvas component should not be difficult to implement since I have
MT>come across extensive materials on it (although I haven't gone through
MT>them in detail yet) and I'm pretty sure you would have come across
MT>them too.

There is nothing actually special about Canvas and GLSurfaceView, it would be just another wrapper. However one of those, most likely Canvas could be used for rendering controls not supported by Android, how would we do that?

I believe that one large part of research has been done with this small project. However there is still exploring left to do, that to-do list contains few of many problems we can face later on in development, and adding more and more UI control's that use same code all over and over doesn't contribute to this.

I am just curious to what mentor's think about all this, do they think that we should convert what we currently have here to basic wxAndroid, or continue to try out things between Android and NDK.

[Vadim Zeitlin]

On Sat, 29 Mar 2014 12:47:39 -0700 (PDT) Nikola Miljkovic wrote:

NM> I am just curious to what mentor's think about all this, do they think that
NM> we should convert what we currently have here to basic wxAndroid, or
NM> continue to try out things between Android and NDK.

Globally I'm pretty happy that you haven't run into any insurmountable
problems so far, this is definitely good news. However I don't know what
_exactly_ have you learned as it's rather difficult to understand it from
dozens of mailing list messages. It would be great to have some summary of
your experience. I also still don't know the answers to some of the
questions that I had repeatedly asked since the beginning, such as (but not
at all limited to):

1. Are we really going to wrap Java stuff by hand or is there any chance of
using a tool (cppjvm...) or at least some C++ helpers (jnipp...) to
somehow automate this?

2. How is event loop going to be implemented? Can we get all the events
that we need, including wxEVT_SIZE, wxEVT_PAINT and so on? Can we
implement wxEVT_IDLE generation efficiently?

3. What is the global approach to drawing? Having wxGLCanvas is good, but
we really need to have wxDC and/or wxGraphicsContext implementation, at
least eventually.

Maybe you've already decided something about this, but if so, I don't know
about this, so it'd be great if you could explain this in above-mentioned
summary.

TIA,
VZ

P.S. Just to make it clear: I'm in general replying to Nikola's messages
just because there are more of them, i.e. whenever I have time to look
at this thread, the last message is always one of Nikola's ones. But
"you" in everything I wrote above applies to both Melroy and Nikola.

[Nikola Miljkovic]

VZ> However I don't know what
VZ> _exactly_ have you learned as it's rather difficult to understand it from
VZ> dozens of mailing list messages.

I am sorry for that.

VZ> Are we really going to wrap Java stuff by hand or is there any chance of
VZ> using a tool (cppjvm...) or at least some C++ helpers (jnipp...) to
VZ> somehow automate this?

I would love to use some tools, but i would love to try them out first before coming to conclusion.

VZ> How is event loop going to be implemented? Can we get all the events
VZ> that we need, including wxEVT_SIZE, wxEVT_PAINT and so on? Can we
VZ> implement wxEVT_IDLE generation efficiently?

Java event listeners should handle dispatching events to top of our EventLoop stack, where we would analyze data if needed, get corresponding objects and finally proceed them to our wxEventLoopBase for future dispatching.

wxEVT_IDLE could be handled by thread or timer that resets on user input.
I am not sure about wxEVT_SIZE since window/app resizing works differently on PC and Android phones, we might need to make compromises here.
There are a lot of events that we need to visit and think about considering this is a lot different system then what wxWidgets is used to.


VZ> What is the global approach to drawing? Having wxGLCanvas is good, but
VZ> we really need to have wxDC and/or wxGraphicsContext implementation, at
VZ> least eventually.

In next few days i will try addressing these.
Android components similar to these classes do exist, and can be used to achieve desired effects.

[Vadim Zeitlin]

On Sun, 30 Mar 2014 16:02:30 -0700 (PDT) Nikola Miljkovic wrote:

NM> I would love to use some tools, but i would love to try them out first
NM> before coming to conclusion.

I think it would be great to do it relatively soon, if we can use a tool
it would potentially change a lot of things.

NM> VZ> How is event loop going to be implemented? Can we get all the events
NM> VZ> that we need, including wxEVT_SIZE, wxEVT_PAINT and so on? Can we
NM> VZ> implement wxEVT_IDLE generation efficiently?
NM>
NM> Java event listeners

How does this work exactly? I.e. where are these listeners defined? Do we
need to have them for each and every window (which would be pretty bad) or
can we have some central way to get all the notifications?

NM> I am not sure about wxEVT_SIZE since window/app resizing works differently
NM> on PC and Android phones,

How does it work under Android?


Anyhow, what I'm saying is that just wrapping the widgets creation and
manipulation is great, of course, and it will take a big part of the GSoC
coding period to just do this, but this is probably not the most difficult
part...

Regards,
VZ

[Melroy Tellis]

VZ>I think it would be great to do it relatively soon, if we can use a tool
VZ>it would potentially change a lot of things.

I did take a look at itoa-jnipp and it does seem promising for creating the wrappers although I haven't tried it yet.

VZ>How does this work exactly? I.e. where are these listeners defined? Do we
VZ>need to have them for each and every window (which would be pretty bad) or
VZ>can we have some central way to get all the notifications?

The event listeners would actually be defined in the Java code for each activity and would essentially forward the events to a native method that would process the event and delegate it to the corresponding UI element's event handler which would be defined by the app developer in the same manner as present wxWidgets applications.To the best of my knowledge,there would have to be separate event listeners for each activity. 

VZ>How does it work under Android?

Here's a link which shows the concept of resizing in Android
http://blog.vogella.com/2010/10/25/android-windowsoftinputmode/

VZ>Anyhow, what I'm saying is that just wrapping the widgets creation and
VZ>manipulation is great, of course, and it will take a big part of the GSoC
VZ>coding period to just do this, but this is probably not the most difficult
VZ>part...

You're perfectly right about that.However I'm sure you would agree that wrapping the Java code would be the best way to start since it would provide a usable base on which we can write the code for the more difficult tasks that will eventually have to be dealt with.

I hope I've answered your questions satisfactorily.

[Vadim Zeitlin]

On Mon, 31 Mar 2014 18:29:41 +0530 Melroy Tellis wrote:

MT> The event listeners would actually be defined in the Java code for each
MT> activity

Doesn't this mean that some Java code would need to be written for each
activity (i.e. every top level window as I think that it would make sense
to use different activities for different windows)? Or can we somehow do it
only once to avoid it?

MT> VZ>How does it work under Android?
MT> Here's a link which shows the concept of resizing in Android
MT> http://blog.vogella.com/2010/10/25/android-windowsoftinputmode/

This is useful, thanks, but I don't think it's the only case in which
resizing happens. The most important one is probably the initial wxEVT_SIZE
which is used to layout everything correctly.

Regards,
VZ

[Nikola Miljkovic]

VZ> Anyhow, what I'm saying is that just wrapping the widgets creation and
VZ> manipulation is great, of course, and it will take a big part of the GSoC
VZ> coding period to just do this, but this is probably not the most difficult
VZ> part...

Well I have said that my self in above mails, there is no point in making more wrappers cause it is pretty much explored topic.
There is plenty of what I have done here besides basic wrappers. I would like for it to get recognized, because this repository doesn't just show 30 copy-paste wrappers.

MT> The event listeners would actually be defined in the Java code for each activity and would essentially forward the events to a native method that would process the event and delegate it to the corresponding UI element's event MT> handler which would be defined by the app developer in the same manner as present wxWidgets applications.To the best of my knowledge,there would have to be separate event listeners for each activity. 

You are not right there, activity and event listeners are not related, my last commits showcase good way to handle this problem.
I am still not hundred percent sure on how will we handle this on java side, on our C++ side it is actually pretty straight forward.

EventListener for each event would only have single instance in our application, no matter the activity, and it would get created/instanced only when our code requires it. This can be done by creating dynamic list or map that uses name of class/interface as key, while value contains reference to our instance. After that we dispatch those events to our C++ event handlers, therefore with little effort it will behave same way as any other wxWidgets implementation.

MT> Here's a link which shows the concept of resizing in Android
MT> http://blog.vogella.com/2010/10/25/android-windowsoftinputmode/

That is good, but it just allows resizing, for actual events there are onDraw(), onMesure(), onSizeChanged().


[Melroy Tellis]

NM> You are not right there, activity and event listeners are not related, my last commits showcase good way to handle NM> this problem.
NM> I am still not hundred percent sure on how will we handle this on java side, on our C++ side it is actually pretty straight forward.

I did take a look at your commit and saw that you're essentially creating a intermediate Java class to implement the functionality of the event handler.The project in its current state doesn't support multiple Activities since there is no way to add or handle a new activity purely by native code.It can only be done if the code for the new activity is written manually in Java.The only foreseeable way to remedy this would be to create a wxAndroid Project Creation Wizard(even a simple console application should do) application of sorts which would automate this with some user-inputs regarding the Activity name ,links to the native code and so on,which you earlier argued was unnecessary and complicated.

 
NM> That is good, but it just allows resizing, for actual events there are onDraw(), onMesure(), onSizeChanged().


I was aware of these events.I was just pointing out one of the ways in which Android handles resizing.

[Nikola Miljkovic]

MT> I did take a look at your commit and saw that you're essentially creating a intermediate Java class to implement the functionality of the event handler.The project in its current state doesn't support multiple Activities since there is MT> no way to add or handle a new activity purely by native code.It can only be done if the code for the new activity is written manually in Java.The only foreseeable way to remedy this would be to create a wxAndroid Project Creation MT> Wizard(even a simple console application should do) application of sorts which would automate this with some user-inputs regarding the Activity name ,links to the native code and so on,which you earlier argued was
MT> unnecessary and complicated.

That is not needed at all, as i said Instances of each event listener is just simple class with one method, it exists independently from any activity, so when you need certain class you create instance.

As for activities we use, there is "public class wxJNI" and it is only activity we will ever use. It is only class but not only instance, as you see our activity is totally blank in java and everything we added is added from C++, we can make infinite different instances of this activity and therefore no tool or JAVA code is needed. Each instance of such class is unique.

[Nikola Miljkovic]

MT> The project in its current state doesn't support multiple Activities since there is

MT> no way to add or handle a new activity purely by native code.

MT> It can only be done if the code for the new activity is written manually in Java.
MT> The only foreseeable way to remedy this would be to create a wxAndroid Project Creation

MT> Wizard(even a simple console application should do) application of sorts which would automate

MT> this with some user-inputs regarding the Activity name ,links to the native code and so on,which you earlier argued was
MT> unnecessary and complicated.

I have committed "support" for activity changing from C++, it uses "activity stack" while most likely that would be best way to handle it, there are other possible solutions.

VZ> Are we really going to wrap Java stuff by hand or is there any chance of
VZ> using a tool (cppjvm...) or at least some C++ helpers (jnipp...) to
VZ> somehow automate this?

I have tried cppjvm, after few hours of trying to get it working on Windows
without any success i got it compiled and working on Linux.
Considering that building it required many packages like Oracles JDK,
lack of documentation and no support for Android SDK I wouldn't use it.

On the other hand we can use jnipp as it is made for Android.
I will try adding and testing it on current repository.

Also i will be trying to find good solutions for our event system,
currently it is not bad but i would like to avoid writing classes for each and every event.

P.S. I am sorry if i message too much, but i am not used to mailing lists, and have
recently realized my formatting is bad and that people use different screen sizes.
I will try improving on this.

Kind regards, Nikola :)

[Nikola Miljkovic]

I have recently improved whole repository. Traditional building is mostly supported now.
If any mentor could respond to my recent commits,
because i believe there are some big changes, that respond to VZ's "how will we build"
question. If you didn't check them out here is a little guide:


Old skeleton application has been removed.
Now you build wxAndroid shared library and add it to your project.
This can be done without any additional Java code.
You build jni folder as any other ndk code, in root directory you take compiled libs.
You paste that to your new project's jni folder, add included headers
and write your app like any other wxWidgets app.

You can see how this is done in my skeleton example.

Also there are other things i proposed here. I commit a lot to this project,
and a little response would mean a lot to me.

Kind regards, Nikola :)

[Bakcsi Zsolt]

On Thu, Apr 3, 2014 at 11:10 PM, Nikola Miljkovic <milj...@gmail.com> wrote:

I have recently improved whole repository. Traditional building is mostly supported now.
If any mentor could respond to my recent commits,

I should be able to take a closer look on Monday. Sorry for the delay.

Zsolt

[Nikola Miljkovic]

Hey, thank you all for support, it feels great to be part of this community.

I have been quite because of schoolwork, however i have tested
many new things that i will share here.
I hope to get input from mentors and community members.

Before 19th may i plan to finish as much schoolwork as possible and
test out research few more things before i start coding major parts.

~ Regards, Nikola Miljkovic

[Vadim Zeitlin]

On Tue, 29 Apr 2014 14:42:21 -0700 (PDT) Nikola Miljkovic wrote:

NM> Before 19th may i plan to finish as much schoolwork as possible and
NM> test out research few more things before i start coding major parts.

Hello,

Looking forward to it! Please let us know about any new information you
find/discover and post your plans for at least until the mid term here.

Good luck,
VZ

[Nikola Miljkovic]

Hey in next 5 days i won't be able to respond, i am out of country for personal reasons.
Anyway, i have things to finish/publish when i return.

Meanwhile i want to know few things:


Will we use my GitHub repository or will new one be made?

How is current folder structure, way of compiling and
app building structure for wxWidgets standards?

Are there some questions related to work i have done so far?

[Vadim Zeitlin]

On Tue, 6 May 2014 12:20:49 -0700 (PDT) Nikola Miljkovic wrote:

NM> Will we use my GitHub repository or will new one be made?

No, we need a new one, your existing repository isn't a fork of the main
one and so can't be merged into it.

NM> How is current folder structure,

The directory structure will need to be changed, the files should be
organized differently with

1. C++ headers under include/wx/android
2. C++ sources under src/android (or maybe a subdirectory)
3. Java sources under src/android/java
4. Documentation under docs/android
5. Samples under samples/android

NM> way of compiling

There will need to be some way of building wxWidgets (shared?) library.
AFAICS currently there is none yet.

NM> app building structure for wxWidgets standards?

Sorry, not sure what do you mean here.

Regards,
VZ

[Bakcsi Zsolt]

On Tue, May 6, 2014 at 9:20 PM, Nikola Miljkovic <milj...@gmail.com> wrote:

way of compiling

You might want to take a look here:

http://review.bakefile.org/r/362/diff/6/

And/or:

https://github.com/cwalther/wxWidgets/tree/android

I think you could use these as a starting point for your work, if you find it easier. (I mean the Android-specific content, not the repository itself.)

For compiling, see build/android/readme.txt and the build/android/jni folder. (I think using the Android command line tools is probably easier than using vs-android+Visual Studio.)

Zsolt

[Nikola Miljkovic]

Hey i am back home now, thanks for response i will check out everything
 in detail today.

VZ>There will need to be some way of building wxWidgets (shared?) library.
VZ>AFAICS currently there is none yet.

I have done this already, current implementation compiles shared library that
you are supposed to include in your project, see build readme and sample app.

[Nikola Miljkovic]

Coding starts today :) i made branch and will commit initial files and folders.
I will first start implementing wxApp, and JNI macros.

Could mentor contact me on my mail (i cannot see anyone's email here),
having direct private contact will be great for rapid consulting.