Re: [Iup-users] Formal proposal for a "postMessage" API to send messages to run on the UI thread

[Eric Wing]

On 4/18/18, Ranier VF  wrote:
> Hi,
>
> "This is a proposal to introduce a way to post and run events on the
> main UI thread."
>
> Just my two cents too.
>

> IUP Dialog have a WID (windows HWND). Why not use PostMessage and
> leave Windows do work?
> BOOL WINAPI PostMessage(
>   _In_opt_ HWND   hWnd,
>   _In_ UINT   Msg,
>   _In_ WPARAM wParam,
>   _In_ LPARAM lParam
> );
>

Yes, in my proposal, I talked about Window's PostMessage. My API
proposal name is called "IupPostMessage" partly because I wanted
people familiar with the Windows API to make the connection because my
proposal draws from the same spirit of the idea.

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.

My IupALmixer example, which I linked, started off as a prototype to
see how to implement this without modifying IUP.
But what it showed is that on some platforms, it requires cooperation
by the event loop processing code. And because IUP also
wraps/abstracts the event loop management in a cross-platform way, the
solution requires that the solution be in IUP itself because some
changes need to be made in IUP's platform specific event loop
implementations.

Finally, my specific proposal implementation for Windows refers to
renown Microsoft Engineer, Raymond Chen, and his deep discussion of
PostThreadMessage vs. PostMessage. Please re-read that section where I
explain why PostThreadMessage is the better solution for making this
cross-platform in IUP.

But in spirit, yes, this is the Windows PostMessage API, simply made
cross-platform and available in IUP.

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

Re: [Iup-users] Formal proposal for a "postMessage" API to send messages to run on the UI thread

[Eric Wing]

>
> It's easy to see the problem you're facing.
>
> I'm no IUP expert, however I'm pretty positive that this can be solved
> without introducing another API.
>
> In a similar situation I have been able to abstain from using the complete
> IUP abstraction around the main loop and resort to using IupFlush()
> instead. Doing so allows to queue requests from other threads for execution
>
> in the GUI thread, which processes said queue right before calling
> IupFlush().
>
> Once I had these roughly 40 lines of code in place begin factoring out
> IupFlush()s and run them just once before IupFlush() to reduce some
> flickering.
>
> Maybe such an approach can work for you too.
>

Thanks for the idea. But I don't think IupFlush() addresses the problem.

IupFlush() solves a problem of needing to process a request
immediately already in the event queue.

But the missing piece of the puzzle is *how to put an event (from
another thread) into the event queue*.

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

Re: [Iup-users] Formal proposal for a "postMessage" API to send messages to run on the UI thread

[Ranier VF]

Hi,

"This is a proposal to introduce a way to post and run events on the
main UI thread."

Just my two cents too.

All this is related with GUI update, in another thread, other the main thread.
Then other types updates, should not interfere with IUP.

IUP Dialog have a WID (windows HWND). Why not use PostMessage and
leave Windows do work?
BOOL WINAPI PostMessage(
  _In_opt_ HWND   hWnd,
  _In_ UINT   Msg,
  _In_ WPARAM wParam,
  _In_ LPARAM lParam
);

Best,
Ranier Vilela

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

Re: [Iup-users] Formal proposal for a "postMessage" API to send messages to run on the UI thread

[Ranier VF]

Hi,

"This is a proposal to introduce a way to post and run events on the
main UI thread."

Just my two cents too.

All this is related with GUI update, in another thread, other the main thread.
Then other types updates, should not interfere with IUP.

IUP Dialog have a WID (windows HWND). Why not use PostMessage and
leave Windows do work?
BOOL WINAPI PostMessage(
  _In_opt_ HWND   hWnd,
  _In_ UINT   Msg,
  _In_ WPARAM wParam,
  _In_ LPARAM lParam
);

Best,
Ranier Vilela


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

Re: [Iup-users] Formal proposal for a "postMessage" API to send messages to run on the UI thread

[Matt Welland]

On Wed, Apr 18, 2018 at 1:23 AM, Jörg F. Wittenberger <
joerg.wittenber...@softeyes.net> wrote:

> Hi,
>
> just my two cents.
>
> On Apr 16 2018, Eric Wing wrote:
>
> This is a proposal to introduce a way to post and run events on the
>> main UI thread.
>>
>> Currently (as far as I know), IUP is hands-off on threads.
>>
>
> ...
>
> It's easy to see the problem you're facing.
>
> I'm no IUP expert, however I'm pretty positive that this can be solved
> without introducing another API.
>
> In a similar situation I have been able to abstain from using the complete
> IUP abstraction around the main loop and resort to using IupFlush()
> instead. Doing so allows to queue requests from other threads for execution
> in the GUI thread, which processes said queue right before calling
> IupFlush().
>
> Once I had these roughly 40 lines of code in place begin factoring out
> IupFlush()s and run them just once before IupFlush() to reduce some
> flickering.
>
> Maybe such an approach can work for you too.
>

Hi Jörg, this approach sounds really interesting. Can you provide a little
more detail to clarify how this works? Do you put calls to set attribute in
the queue and then periodically execute the calls in the queue followed by
an IupFlush? I tried this (using the Chicken Scheme IUP binding) and it
seems to work well but I'm concerned there are corner cases to be accounted
for. My (probably naive) test implementation of your approach is pasted
below.


>
> Best
>
> /Jörg
>
>
>
>
>
> 
> --
> 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
>

;; trial of replacing iup:main-loop with a queue
(use (prefix iup iup:) srfi-18)

(define *queue* '())
(define *queue-mutex* (make-mutex))

(define (process-queue)
  (for-each (lambda (entry)(entry))(reverse *queue*))
  (print "processed queue")
  (set! *queue* '()))

(define (iattr . params)
  (mutex-lock! *queue-mutex*)
  (if (not (null? *queue*))
  (process-queue))
  (let ((result (apply iup:attribute params)))
(mutex-unlock! *queue-mutex*)
result))

(define (iattr-set! . params)
  (mutex-lock! *queue-mutex*)
  (set! *queue* (cons (lambda ()(apply iup:attribute-set! params)) *queue*))
  (mutex-unlock! *queue-mutex*))

(define button1 (iup:button
 "Push me"
 action: (lambda (o)
   (print "Got here at " (current-seconds))
   (iattr-set! o "BGCOLOR" "255 255 255"

(define tl (iup:show
(iup:dialog
 (iup:vbox
  button1
  (iup:button "Exit" action: (lambda (o)(exit)))

(define (main)
  (let* ((th1 (make-thread (lambda ()
 (let loop ()
   (mutex-lock! *queue-mutex*)
   (process-queue)
   (mutex-unlock! *queue-mutex*)
   (iup:main-loop-flush)
   (thread-sleep! 1) ;; use a really long delay just for
illustration
   (loop)))
   "flush loop"))
 (th2 (make-thread (lambda ()
 (let loop ()
   (print "set to green")
   (iattr-set! button1 "BGCOLOR" "70 249 73")
   (thread-sleep! 0.2)
   (print "set to red")
   (iattr-set! button1 "BGCOLOR" "253 33 49")
   (thread-sleep! 0.2)
   (loop)
 (th3 (make-thread (lambda ()
 (let loop ()
   (print (iattr button1 "BGCOLOR"))
   (thread-sleep! (random 5))
   (loop))
(thread-start! th1)
(thread-start! th2)
(thread-start! th3)
(thread-join! th1)))

(main)
--
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

Re: [Iup-users] Formal proposal for a "postMessage" API to send messages to run on the UI thread

[Andrew Robinson]

IUP should not be the solution to every problem. It would be like
incorporating a cross-platform C-runtime into IUP when that is the wrong
approach. IUP is great as it is and for specialized problems it will never be
able to beat a mature third party app, and right now my favorite app for the
kinds of issues you are discussing is ØMQ (http://zeromq.org),  but I'm sure
there are other apps out there that will do just fine.

Best Regards,
Andrew

On 2018-04-18 at 1:57 PM, Eric Wing  wrote:
>On 4/18/18, Ranier VF  wrote:
>> Hi,
>> Obviously I'm not saying to Call PostMessage Windows function,
>> in other platforms.
>> So I understood, only have problem is Windows Loop Event (IUP),
>> and the autor what do you cite, say clearly that PostThreadMessage
>> is wrong way to solve this (update GUI in another thread).
>>
>> Best,
>> Ranier Vilela
>
>As I tried to explain in my proposal, saying it is "the wrong way" is
>more nuanced than that. (That's why he wrote the blog article in the
>first place.) For *most* people, it is "the wrong way" because there
>is a much simpler way, PostMessage.
>
>But as I tried to point out, PostMessage is "wrong for us" because it
>artificially couples the posting of a message with a window handle.
>None of the other platforms couple their widgets with their event loop
>control. Only Windows does that, which creates an impedance mismatch
>for all the other platforms. (Apple is a strong counter-example to the
>Windows design. Apple has a strong division between their GUI
>framework (AppKit) and their non-GUI framework (Foundation). You can
>write command line and server daemons in Foundation without ever
>touching AppKit. All the event loop stuff is in Foundation, not
>AppKit. AppKit however builds on top of Foundation and leverages the
>event loops.)
>
>Furthermore, in ALmixer example, I operate on the button widget, not a
>window widget. Using PostMessage is wrong from an API standpoint
>because now this weird implementation detail restriction that says you
>must only operate on things that happen to be windows on MS-Windows
>platforms. If we allow that implementation detail to creep into the
>public API of IupPostMessage(), I have no doubt it will become a
>gotcha for a lot of people and we'll get a ton of never-ending support
>questions of "Why does this work in GTK, but on Windows, nothing is
>happening?.
>
>Additionally, if we allow that implementation detail to creep into the
>public API, the question then becomes, what does that mean for the
>other platforms? (The first question I "ask" in my IUP for iOS &
>Android video, is "What does Dialog mean for iOS & Android?" because
>they don't use "windows" like desktops.)
>
>PostThreadMessage() is the more general API that allows us to post
>messages, without the explicit window coupling. And with Raymond
>Chen's solution, we don't have to sacrifice anything for using it. So
>for IUP, I believe this is the "right" solution.
>
>
>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


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

Re: [Iup-users] Formal proposal for a "postMessage" API to send messages to run on the UI thread

[Eric Wing]

On 4/18/18, Ranier VF  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

Re: [Iup-users] Formal proposal for a "postMessage" API to send messages to run on the UI thread

[Eric Wing]

On 4/18/18, Ranier VF  wrote:
> Hi,
> Obviously I'm not saying to Call PostMessage Windows function,
> in other platforms.
> So I understood, only have problem is Windows Loop Event (IUP),
> and the autor what do you cite, say clearly that PostThreadMessage
> is wrong way to solve this (update GUI in another thread).
>
> Best,
> Ranier Vilela

As I tried to explain in my proposal, saying it is "the wrong way" is
more nuanced than that. (That's why he wrote the blog article in the
first place.) For *most* people, it is "the wrong way" because there
is a much simpler way, PostMessage.

But as I tried to point out, PostMessage is "wrong for us" because it
artificially couples the posting of a message with a window handle.
None of the other platforms couple their widgets with their event loop
control. Only Windows does that, which creates an impedance mismatch
for all the other platforms. (Apple is a strong counter-example to the
Windows design. Apple has a strong division between their GUI
framework (AppKit) and their non-GUI framework (Foundation). You can
write command line and server daemons in Foundation without ever
touching AppKit. All the event loop stuff is in Foundation, not
AppKit. AppKit however builds on top of Foundation and leverages the
event loops.)

Furthermore, in ALmixer example, I operate on the button widget, not a
window widget. Using PostMessage is wrong from an API standpoint
because now this weird implementation detail restriction that says you
must only operate on things that happen to be windows on MS-Windows
platforms. If we allow that implementation detail to creep into the
public API of IupPostMessage(), I have no doubt it will become a
gotcha for a lot of people and we'll get a ton of never-ending support
questions of "Why does this work in GTK, but on Windows, nothing is
happening?.

Additionally, if we allow that implementation detail to creep into the
public API, the question then becomes, what does that mean for the
other platforms? (The first question I "ask" in my IUP for iOS &
Android video, is "What does Dialog mean for iOS & Android?" because
they don't use "windows" like desktops.)

PostThreadMessage() is the more general API that allows us to post
messages, without the explicit window coupling. And with Raymond
Chen's solution, we don't have to sacrifice anything for using it. So
for IUP, I believe this is the "right" solution.


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

Re: [Iup-users] Formal proposal for a "postMessage" API to send messages to run on the UI thread

[Ranier VF]

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

Re: [Iup-users] Formal proposal for a "postMessage" API to send messages to run on the UI thread

[Ranier VF]

Hi, 
Obviously I'm not saying to Call PostMessage Windows function, 
in other platforms.
So I understood, only have problem is Windows Loop Event (IUP),
and the autor what do you cite, say clearly that PostThreadMessage
is wrong way to solve this (update GUI in another thread).

Best,
Ranier Vilela

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

Re: [Iup-users] Formal proposal for a "postMessage" API to send messages to run on the UI thread

[Jörg F . Wittenberger]

Hi,

just my two cents.

On Apr 16 2018, Eric Wing wrote:


This is a proposal to introduce a way to post and run events on the
main UI thread.

Currently (as far as I know), IUP is hands-off on threads.


...

It's easy to see the problem you're facing.

I'm no IUP expert, however I'm pretty positive that this can be solved 
without introducing another API.


In a similar situation I have been able to abstain from using the complete 
IUP abstraction around the main loop and resort to using IupFlush() 
instead. Doing so allows to queue requests from other threads for execution 
in the GUI thread, which processes said queue right before calling 
IupFlush().


Once I had these roughly 40 lines of code in place begin factoring out 
IupFlush()s and run them just once before IupFlush() to reduce some 
flickering.


Maybe such an approach can work for you too.

Best

/Jörg




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

Re: [Iup-users] Formal proposal for a "postMessage" API to send messages to run on the UI thread

[Eric Wing]

On 4/18/18, Eric Wing  wrote:
> On 4/18/18, Andrew Robinson  wrote:
>> IUP should not be the solution to every problem. It would be like
>> incorporating a cross-platform C-runtime into IUP when that is the wrong
>> approach.

And just to be clear, everything in this patch is using only
platform-specific mechanisms to provide this feature, just like
everything IUP does wrapping native widgets. This is nothing like
incorporating a cross-platform C-runtime.

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

Re: [Iup-users] Formal proposal for a "postMessage" API to send messages to run on the UI thread

[Eric Wing]

On 4/18/18, Ranier VF  wrote:
> Hi,
> I strong believe thar PostMessage solves the request:  "update gui, outside
> main thread"
> Native handles, like Windows Handle, is hidden from the user perspective.
> Therefore using in Windows driver and not using in GTK, IOS and Android
> drivers, will not disturb users.

I think we're in agreement here. The idea of "IupPostMessage",
inspired from Windows PostMessage solves this problem elegantly. The
implementation specific ways to pull this off on each platform are
hidden from the user perspective.


> In your example, You use a button widget, but can receive and process all
> messages is the Window Handler inside "Ihandle the_dialog."
> In this way, add one field to store native handler, in user_data structure
> and use only with Windows Functions API formal proposal.

>From my "Idea 2" proposal, what I'm suggesting is the IUP API should
be able to take *any* Ihandle*.

// All I want to do is change my button's ACTIVE state.
IupPostMessage(my_iup_button, 42, audio_data);

This is more natural in how people may want to use it. I want to
change the button. From an objective standpoint, if I just want to
change the button, it makes no sense to think about a dialog.

So I think it is less reasonable to demand that I do:
// All I want to do is change my button's ACTIVE state. Why am
I passing a dialog?
IupPostMessage(some_dialog, 42, audio_data);

And then in the callback, figure out how to get my_iup_button.


> Touching Windows Event Loop will add one branch and one function call,
> in every message received by app, slowing down more and more.

I don't think this is a legitimate or fair argument. Unless you can
demonstrate in a real world context where this one call will have a
measurable performance impact, the cost of this one instruction is a
rounding error. (There's quite a bit of other stuff you would want to
focus on first in the IUP codebase if you were worried about this
minutia of performance.) Remember, we're talking about Windows where
they've optimized the heck out of this low-level stuff and everybody
is on powerful CPUs with branch-prediction and tons of cache. We're
not talking about 6502's here.


> Summing up:
> All drivers are free to implement in your own way, and from the users
> perspective,
> no matter how it was solved.

I think we agree again.

> Using Native Handler (windows), inside API, hidden from the user, works.

We agree again.

> PostMessage solves the problem, without add any cost and slowing event
> loop.

I merely argue that PostThreadMessage is a better, more general, and
more correct solution than PostMessage. If PostMessage can be made to
work and address the shortcomings I believe it has, then I would
happily give it my blessing.

Ultimately, this is an implementation issue. It's only constraint is
what we want the public API to be able to handle. Nobody in the end is
going to know the difference if we do it right.


> Attempts to confuse the discussion, with evasive allegations, as users
> doubts, they do not help!

Again, I think that is a very unfair accusation to level against me.
I have presented a working prototype, a specification of the feature,
and a general implementation plan.

As part of the Windows specific implementation, I include explanation
of why I think PostThreadMessage is better than PostMessage: because
it allows us to construct a general API that takes any widget,
allowing the user focus on any widget instead of a just a dialog.

If I misunderstand how PostMessage works, and it can be used for
arbitrary controls (e.g. the button and not just dialogs), then I will
happily cede to that point. That is the thing I hope somebody will
address, but so far, nobody has corrected that specific point.


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

Re: [Iup-users] Formal proposal for a "postMessage" API to send messages to run on the UI thread

[Eric Wing]

On 4/18/18, Andrew Robinson  wrote:
> IUP should not be the solution to every problem. It would be like
> incorporating a cross-platform C-runtime into IUP when that is the wrong
> approach. IUP is great as it is and for specialized problems it will never
> be
> able to beat a mature third party app, and right now my favorite app for the
> kinds of issues you are discussing is ØMQ (http://zeromq.org),  but I'm sure
> there are other apps out there that will do just fine.
>
> Best Regards,
> Andrew

I agree that IUP should not be the solution to every problem. But in
this case, I strongly argue that it is the correct solution because
IUP itself already took over responsibility for the event loop. (The
moment IupMainLoop() or IupLoopStep() were created, that ship sailed.)
IUP wrapped native GUIs and by that fact, it also is responsbile for
dealing with the platform idiosyncrasies they demand for their event
loops (in this case, multithreading rules).

This proposal is a tiny patch to IUP, one that nobody except the
implementors will notice. It does not break current behavior or create
any trade offs. But it solves real problems deal with the fact that
the real world uses threads, even inside the native platforms. If you
don't have this problem, then it doesn't matter because this change
won't affect you.

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

Re: [Iup-users] Formal proposal for a "postMessage" API to send messages to run on the UI thread

[Ranier VF]

Hi,
I strong believe thar PostMessage solves the request:  "update gui, outside 
main thread" 
Native handles, like Windows Handle, is hidden from the user perspective.
Therefore using in Windows driver and not using in GTK, IOS and Android 
drivers, will not disturb users.
In your example, You use a button widget, but can receive and process all 
messages is the Window Handler inside "Ihandle the_dialog."
In this way, add one field to store native handler, in user_data structure
and use only with Windows Functions API formal proposal.

Users do not will ask if IUP_PostMessage is implemented in different ways
in Windows, GTK, IOS or Android. Running...

Touching Windows Event Loop will add one branch and one function call,
in every message received by app, slowing down more and more.

Summing up:
All drivers are free to implement in your own way, and from the users 
perspective,
no matter how it was solved.
Using Native Handler (windows), inside API, hidden from the user, works.
PostMessage solves the problem, without add any cost and slowing event loop.

Attempts to confuse the discussion, with evasive allegations, as users doubts, 
they do not help!

Best regards,
Ranier Vilela

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

Re: [Iup-users] Formal proposal for a "postMessage" API to send messages to run on the UI thread

[Andrew Robinson]

>I agree that IUP should not be the solution to every problem. But in
>this case, I strongly argue that it is the correct solution because
>IUP itself already took over responsibility for the event loop. (The
>moment IupMainLoop() or IupLoopStep() were created, that ship sailed.)

IUP is an event based model so the message based model of Windows is the only
ship that has sailed here. I want the IUP model to stay just the way it is
because the IUP model is superior to the Windows one. Just try and find a
different third party solution, say like incorporating ØMQ, which can do
everything you want and much, much, much more.

>IUP wrapped native GUIs and by that fact, it also is responsbile for
>dealing with the platform idiosyncrasies they demand for their event
>loops (in this case, multithreading rules).

You are correct that IUP only wraps the GUI and the last time I looked
multithreading was not a GUI problem. Multithreading (a kernel issue) is
outside the scope of what IUP is supposed to do (GUI wrapper) and that means
what you are discussing is not a problem for IUP to solve.

And just so we are clear here, the C-Runtime is also outside the scope of what
a GUI wrapper is supposed to do, so incorporating a cross-platform
pseudo-PostMessage would be EXACTLY like incorporting a cross-platform
C-runtime.

>This proposal is a tiny patch to IUP, one that nobody except the
>implementors will notice. It does not break current behavior or create
>any trade offs. But it solves real problems deal with the fact that
>the real world uses threads, even inside the native platforms. If you
>don't have this problem, then it doesn't matter because this change
>won't affect you.

Don't try to brush me off like that because it won't work.


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

Re: [Iup-users] Formal proposal for a "postMessage" API to send messages to run on the UI thread

[Ranier VF]

Hi,
I strong believe thar PostMessage solves the request:  "update gui, outside 
main thread" 
Native handles, like Windows Handle, is hidden from the user perspective.
Therefore using in Windows driver and not using in GTK, IOS and Android 
drivers, will not disturb users.
In your example, You use a button widget, but can receive and process all 
messages is the Window Handler inside "Ihandle the_dialog."
In this way, add one field to store native handler, in user_data structure
and use only with Windows Functions API formal proposal.

Users do not will ask if IUP_PostMessage is implemented in different ways
in Windows, GTK, IOS or Android. Running...

Touching Windows Event Loop will add one branch and one function call,
in every message received by app, slowing down more and more.

Summing up:
All drivers are free to implement in your own way, and from the users 
perspective,
no matter how it was solved.
Using Native Handler (windows), inside API, hidden from the user, works.
PostMessage solves the problem, without add any cost and slowing event loop.

Attempts to confuse the discussion, with evasive allegations, as users doubts, 
they do not help!

Best regards,
Ranier Vilela

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

Re: [Iup-users] Formal proposal for a "postMessage" API to send messages to run on the UI thread

[Eric Wing]

Ranier,

I feel like maybe your are trying to address my concern about wanting
to work on with button and not the dialog, i.e.,

// I want to do this:
IupPostMessage(my_iup_button, 42, audio_data);

// I don't want to be forced to do this
IupPostMessage(some_dialog, 42, audio_data);

 with your statement:

> In your example, You use a button widget, but can receive and process all
> messages is the Window Handler inside "Ihandle the_dialog."
> In this way, add one field to store native handler, in user_data structure
> and use only with Windows Functions API formal proposal.

I don't think I fully understand what you are saying here, but if you
are telling me how we can accomplish:
IupPostMessage(my_iup_button, 42, audio_data);

using PostMessage instead of PostThreadMessage, can you elaborate more
and maybe show a sample of how this would actually be implemented in
IUP? I am still unable to see how to solve this using only
PostMessage.

Thanks,
Eric



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