On 4/18/18, Ranier VF <ranier_...@hotmail.com> wrote:
> Hi,
>
> "But in when using IUP, we can't just reasonably call Window's
> PostMessage because it is not cross-platform. It won't work on any
> other platform except Windows.
> This whole proposal is on how to make something like PostMessage
> cross-platform."
>
> It's OK, but in your app example, I dont see any about event loop in
> GTK, Apple or Android. Only reference about Windows Event Loop.
>
> Can you show why other events loops, do not work like PostMessage
> windows API.
> or
> better saying, touch IUP Event Loop in (GTK, Apple and Android)?
>
> Best regards,
> Ranier Vilela

In the IupALmixer example, there are 4 implementation files named:

MainThreadRedirectApple.m
MainThreadRedirectGTK.c
MainThreadRedirectWindows.c
MainThreadRedirectAndroid.c
Additionally for Android, there is a companion MainThreadRedirect.java
file because all platform native things must be done in Java. (The C
file uses JNI in various ways to ultimately interoperate with the
native Java side of the implementation.)

All 4 of these are implicitly tied to each platform's native event
loop. And by nature of how IUP works, it is also implicitly tied to
each platform's native event loop. The explicit coupling between these
is different for each platform, but the relationship is there because
every platform demands some notion of a native event loop.

So by happenstance of how the Windows event loop works, this is the
one that requires a few additions to IUP's backend implementation.
Again, requoting Raymond Chen: “all modal loops need to remember to
call CallMsgFilter as part of their dispatch loop”.

I want to emphasize that this is just implementation detail. Users of
IUP will never need to know about this. This proposal won't change or
break any current behavior.


In comparison, GTK and Apple appear less intrusive simply due to the
way their event loops work. With GTK, they already built their event
loop to automatically handle g_idle_add. So it doesn't really require
any changes to IUP's GTK event loop implementation.

Similarly, with Apple, as long as we use the proper native Cocoa event
loop, libdispatch will do the right thing and Cocoa's event loop
already automatically properly handles the "main_queue" from
libdispatch. But I should point out, that this does require IUP
properly setup and use the standard Cocoa event-loop in the first
place, or all this breaks. You're not seeing the an explicit
relationship in the code because there is an implicit relationship
which I've already implemented for IupCocoa and IupCocoaTouch to make
sure it does use the proper Cocoa event loop. I talked about event
loop issues in my presentation "IUP Next" at the Lua Workshop 2017
back in October. (I also talked a little about it in my YouTube video,
"IUP for iOS & Android".)

Android is the other platform that is like Windows in that it requires
some explicit internal support by IUP's implementation to support. But
you don't see it because I've already coded these hooks into that
implementation. There are hard/painful rules about dealing with the
native Android event-loop. And there are additional hard/painful rules
about using JNI from background threads. If you look closely, my
example is calling some "private" iupAndroid functions which I've
implemented in a very specific way so we can do the "right" thing. So
this serves as another example of why this needs to be done in IUP
(like Windows), because I'm basically hacking on internal IupAndroid
implementation details which are not technically public API.
Formalizing a IupPostMessage() will guarantee a public stable API
provides this and won't be subject to breakage if the internal private
APIs need to change.

Thanks,
Eric

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Iup-users mailing list
Iup-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iup-users

Reply via email to