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

[Andrew Robinson]

Hi,

Just a reminder: Don't forget the Model-View-Controller architecture for GUIs.
In a nutshell, all that means is you have an input, an output, and a bunch of
processing that has to be done between entering an input and displaying the
output. The input and the output are handled by the GUI (IUP in this case)
while the processing (the "Model") is handled by your application code. GUIs
do not require external multithreading to function, only the processing
portion may require multithreading, so if you want to thread an application,
don't ask the GUI to do it for you. Using IUP for multithreading your code is
not the appropriate place for that to happen. Let's not let IUP become a
victim of feature-itus nor add something that will make IUP less secure.

Best Regards,
Andrew

On 2018-04-19 at 5:26 AM, Ranier VF  wrote:
>Hi,
>"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."
>
>I think that IUP can be used in threads apps too. But.
>Without add framework, and extra bagage for this.
>Update GUI outside main thread, is very danger and can crash easily app.
>
>Gold rule, don't update GUI outside main thread!
>Use callbacks for this. Windows have a PostMessage function, that solves
>correctly this problem.
>
>IupPostMessage is welcome, but, whithout change behavior to non-threaded
>apps.
>
>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,

"Please ignore anyone who says "I don't need it so you can't have it" -  but, 
obviously, it has to be a
solution that causes them no pain when/if it does go in, and your proposal 
sounds just like that to me."

I do not know if it was addressed to me. But I will answer anyway.
I not agaist IupPostMessage. Ok.

I against windows only implementation proposal, which adds,
unnecessary extra bagage to slow platform!
IUP have a lots features like windows only, GTK only.

Everything I request is use a PostMessage function in windows implementation.
Which requires use IUP function IupSetAttributeHandle to work.
Using PostMessage it is not necessary touch windows event loop and
add filters hooks inside IUP Windows Driver.

Anyway, Eric proposal add one skilled filter IWIN_POSTMESSAGE_ID.
Now if anybody wants add more filters?
Easily we will soon have array of filters inside windows loop.

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

[Pete Lomax via Iup-users]

Hi there Eric,
Thank you for looking at this - I just wanted to add my approval.

I certainly get the point about battery life. The project I am currently 
working uses a background thread
to handle a websocket feed, which arrives every 10s or so. While an IupTimer 
works, I run it at 10 times a
second while my collaborator thinks it should be 100 times a second, so it 
consumes 100-1000 times as much
power as it needs to. All I need is a way for a background thread to say "oi" 
when it has finished some
calculation, downloaded a file, or received a websocket message - maybe I might 
want to be helpful and 
include an IupHandle in the message, often not - it is the responsibility of 
the main gui thread to map
any such events to specific gui elements, and quite often not a 1:1 
relationship anyway.

Please ignore anyone who says "I don't need it so you can't have it" -  but, 
obviously, it has to be a
solution that causes them no pain when/if it does go in, and your proposal 
sounds just like that to me.

Pete

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

I think that IUP can be used in threads apps too. But.
Without add framework, and extra bagage for this.
Update GUI outside main thread, is very danger and can crash easily app.

Gold rule, don't update GUI outside main thread!
Use callbacks for this. Windows have a PostMessage function, that solves
correctly this problem.

IupPostMessage is welcome, but, whithout change behavior to non-threaded
apps.

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,

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

I can not agree. 99% percent of GUI app are non-threaded.
Your patch, change this behavior add one function call to every
message received by event loop, unnecessary, to non-threaded apps.

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,

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

Great.

"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);"

Use IUP style and tools.
IupSetAttributeHandle(my_iup_button, "the_dialog", the_dialog);
Now you have a native handler (windows handler) inside your
button widget and easy use PostMessage to solve GUI update without
add any cost and more unnecessary functions calls

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

Again, IUP have a style for this.

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

IUP have a lot slow algorithms: array dynamic implementation is very 
inefficient,
hash string too. Add more inefficiencies do not help.
Kiss please. Less is more.

"I think we agree again."
Good to know.

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

Again, Raymond Chen, explain: "The correct solution was illustrated last time."
https://blogs.msdn.microsoft.com/oldnewthing/20050427-10/?p=35763
PostTheardMessage is the complicated and wrong way to solve this.

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

I'm sorry, but technical arguments is welcome, bogus arguments not.

"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."
Again, using IUP style and tools.
Add reference  to your controls and you have all necessary to make the work.

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

[Jörg F . Wittenberger]

Eric,

I'm afraid your comment bdelow does not make much sense to me. Also I did 
not suggest any polling.


On Apr 19 2018, Eric Wing wrote:


On 4/19/18, Jörg F. Wittenberger  wrote:

On Apr 19 2018, Eric Wing wrote:


Since there seems to be so much concern and speculation about the
size, complexity, and implementation of what the patch might look
like, I went ahead and implemented a fully working version for Windows
and GTK to provide something completely concrete to review.


I'm afraid there was little concern or speculation about size and 
complexity. The only concerns I read where calling into question whether 
or


not it was a good idea at all. Thus suggestions flowing your way how 
others


would solve or have solved the issue.



That is fair, up to a point. There was lengthy discussion on
PostMessage vs. PostThreadMessage and the consequences of such.


To respond to your previous post/solution...(the IupFlush
clarification), your solution actually could work. I could create an
IupTimer and externally poll. But this has a major downside in battery
consumption...and the higher the responsiveness, the worst the
consumption.

Modern native event loops are highly optimized to not do work when
nothing needs to be done. (Set a breakpoint after Windows GetMessage,
and it is fascinating how often it just sits there not moving.)
Polling though an external mechanism means burning cycles even when
not needed, which also means modern CPUs which have automatic
throttling can't usually do so in this scenario. This is why all the
platforms designed their own event-loops and intertwined their GUI
infrastructure with it, and why IUP had to abstract the native event
loops in the first place.

For the use cases I need, this unfortunately is not an acceptable
trade-off. And I think in general, there is no good reason to have to
make this trade-off. A cross-platform yet native solution is only a
handful lines of code because the native platforms intended to solve
this very problem already and expected you to use it. For the cases
where polling and burning CPU is acceptable, those are typically
games. There we are used to having non-native event loops... SDL is an
example of providing such a loop. But even SDL has the capability of
posting custom messages to its event queue to deal with these exact
same kinds of threading issues.


Thank you for the suggestion though. I understand you were sincerely
trying to solve my problem.

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/19/18, Jörg F. Wittenberger  wrote:
> On Apr 19 2018, Eric Wing wrote:
>
>>Since there seems to be so much concern and speculation about the
>>size, complexity, and implementation of what the patch might look
>>like, I went ahead and implemented a fully working version for Windows
>>and GTK to provide something completely concrete to review.
>
> I'm afraid there was little concern or speculation about size and
> complexity. The only concerns I read where calling into question whether or
>
> not it was a good idea at all. Thus suggestions flowing your way how others
>
> would solve or have solved the issue.
>

That is fair, up to a point. There was lengthy discussion on
PostMessage vs. PostThreadMessage and the consequences of such.


To respond to your previous post/solution...(the IupFlush
clarification), your solution actually could work. I could create an
IupTimer and externally poll. But this has a major downside in battery
consumption...and the higher the responsiveness, the worst the
consumption.

Modern native event loops are highly optimized to not do work when
nothing needs to be done. (Set a breakpoint after Windows GetMessage,
and it is fascinating how often it just sits there not moving.)
Polling though an external mechanism means burning cycles even when
not needed, which also means modern CPUs which have automatic
throttling can't usually do so in this scenario. This is why all the
platforms designed their own event-loops and intertwined their GUI
infrastructure with it, and why IUP had to abstract the native event
loops in the first place.

For the use cases I need, this unfortunately is not an acceptable
trade-off. And I think in general, there is no good reason to have to
make this trade-off. A cross-platform yet native solution is only a
handful lines of code because the native platforms intended to solve
this very problem already and expected you to use it. For the cases
where polling and burning CPU is acceptable, those are typically
games. There we are used to having non-native event loops... SDL is an
example of providing such a loop. But even SDL has the capability of
posting custom messages to its event queue to deal with these exact
same kinds of threading issues.


Thank you for the suggestion though. I understand you were sincerely
trying to solve my problem.

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

[Jörg F . Wittenberger]

On Apr 19 2018, Eric Wing wrote:


Since there seems to be so much concern and speculation about the
size, complexity, and implementation of what the patch might look
like, I went ahead and implemented a fully working version for Windows
and GTK to provide something completely concrete to review.


I'm afraid there was little concern or speculation about size and 
complexity. The only concerns I read where calling into question whether or 
not it was a good idea at all. Thus suggestions flowing your way how others 
would solve or have solved the issue.


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

[Jörg F . Wittenberger]

On Apr 18 2018, Matt Welland wrote:


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.


Hi Matt,

Exactly that's what I did. (Slightly more elaborate than your example code, 
e.g. using a configurable sleep time and not using thread-sleep! but 
waiting with timeout on a condition-variable, which has the added advantage 
that urgent signals can easily terminate the wait by signaling the 
condition variable, while non-critical changes may be postponed until the 
regular update takes place.)


But the principle is the same.

Yes, you are right, there can be corner cases. You really, really want to 
be sure that your Iup callbacks don't capture continuations. But it is a 
while ago that this was fixed right in the iup egg. From your code I'm 
afraid another such corner case would be whether or not you empty the queue 
one-by-one (as I would suggest) or all at once. Your case of doing the 
latter but flushing the queue only _after_ processing it looks a bit error 
prone to me.


BEst

/Jörg






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

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

[Eric Wing]

Since there seems to be so much concern and speculation about the
size, complexity, and implementation of what the patch might look
like, I went ahead and implemented a fully working version for Windows
and GTK to provide something completely concrete to review.

You can find the repo here:
https://github.com/ewmailing/IupCocoa/tree/IupPostMessage
Make sure you clone/switch to the IupPostMessage branch.

The IupPostMessage() as implemented is not intended to be final form.
There are 4 parameters (2 unused) because I didn’t feel like adding a
new callback type to iupcbs.h until we made a final decision on the
API. Also, I decided to rename my proposed “UITHREAD” to
“POSTMESSAGE_CB”.


I’m also attaching the patch for those who find it convenient, as it
is small enough to include in this post without exceeding the mailing
list maximum post size threshold. My source tree was originally based
off of SVN revision 4768.

The repo also contains a test program called postmessage.c in
html/examples/tests. (The diff/patch didn’t capture it since it is a
new file.) It is a single-threaded example showing that it is also
usable in single threaded situations, i.e. those who just want to
schedule an event to fire on the next event-loop pass. Those familiar
with certain async patterns may recognize this.


I also added a version 2 of the IupALmixerThreads example which now
uses this patch as a test and further demonstration.
https://bitbucket.org/ewing/iupalmixerthread2

Thanks,
Eric
diff --git a/html/examples/tests/config.mak b/html/examples/tests/config.mak
index 0910be9..7ab409f 100644
--- a/html/examples/tests/config.mak
+++ b/html/examples/tests/config.mak
@@ -46,6 +46,7 @@ SRC += dialog.c
 SRC += calendar.c
 SRC += predialogs.c
 SRC += timer.c
+SRC += postmessage.c
 SRC += label.c
 SRC += canvas.c
 SRC += frame.c
diff --git a/include/iup.h b/include/iup.h
index 1c67a3f..9eac444 100644
--- a/include/iup.h
+++ b/include/iup.h
@@ -42,6 +42,7 @@ int   IupLoopStepWait  (void);
 int   IupMainLoopLevel (void);
 void  IupFlush (void);
 void  IupExitLoop  (void);
+void  IupPostMessage   (Ihandle* ih, char*, void* message_data, int);
 
 int   IupRecordInput(const char* filename, int mode);
 int   IupPlayInput(const char* filename);
diff --git a/src/gtk/iupgtk_loop.c b/src/gtk/iupgtk_loop.c
index f156607..61fd14d 100644
--- a/src/gtk/iupgtk_loop.c
+++ b/src/gtk/iupgtk_loop.c
@@ -6,6 +6,7 @@
 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -113,3 +114,33 @@ void IupFlush(void)
   if (old_gtk_idle_cb)
 iupdrvSetIdleFunction((Icallback)old_gtk_idle_cb);
 }
+
+
+typedef struct {
+  Ihandle* ih;
+  void* messageData;
+} gtkPostMessageUserData;
+
+static gint gtkPostMessageCallback(void *user_data)
+{
+  gtkPostMessageUserData* message_user_data = 
(gtkPostMessageUserData*)user_data;
+  Ihandle* ih = message_user_data->ih;
+  /* TODO: Figure out callback type. For now, I'm reusing an existing type so 
I don't have to add one until we decide. */
+  IFnsVi post_message_callback = (IFnsVi)IupGetCallback(ih, "POSTMESSAGE_CB");
+  if (post_message_callback)
+  {
+void* message_data = message_user_data->messageData;
+post_message_callback(ih, NULL, message_data, 0);
+  }
+  free(user_data);
+  return FALSE; // call only once
+}
+
+/* TODO: Make decision on final API. For now, this API is just to get a usable 
demo. */
+void IupPostMessage(Ihandle* ih, char* unusedchar, void* message_data, int 
unusedint)
+{
+  gtkPostMessageUserData* user_data = 
(gtkPostMessageUserData*)malloc(sizeof(gtkPostMessageUserData));
+  user_data->ih = ih;
+  user_data->messageData = message_data;
+  g_idle_add(gtkPostMessageCallback, user_data);  
+}
diff --git a/src/iup.def b/src/iup.def
index bbbd45a..69b3278 100644
--- a/src/iup.def
+++ b/src/iup.def
@@ -260,6 +260,7 @@ IupDial
 IupGauge
 IupColorbar
 IupColorBrowser
+IupPostMessage
 
 iupdrvSetVisible
 iupdrvSetFontAttrib
diff --git a/src/iup_classbase.c b/src/iup_classbase.c
index 7620c72..95868fc 100644
--- a/src/iup_classbase.c
+++ b/src/iup_classbase.c
@@ -571,6 +571,7 @@ void iupBaseRegisterCommonCallbacks(Iclass* ic)
   iupClassRegisterCallback(ic, "ENTERWINDOW_CB", "");
   iupClassRegisterCallback(ic, "LEAVEWINDOW_CB", "");
   iupClassRegisterCallback(ic, "HELP_CB", "");
+  iupClassRegisterCallback(ic, "POSTMESSAGE_CB", "");
   iupClassRegisterCallback(ic, "K_ANY", "i");
 }
 
diff --git a/src/win/iupwin_drv.h b/src/win/iupwin_drv.h
index ca66b82..22d3eda 100644
--- a/src/win/iupwin_drv.h
+++ b/src/win/iupwin_drv.h
@@ -17,7 +17,8 @@ extern "C" {
 extern HINSTANCE iupwin_hinstance;  /* iupwin_open.c */
 extern int   iupwin_comctl32ver6;   /* iupwin_open.c */
 extern HINSTANCE iupwin_dll_hinstance;  /* iupwindows_main.c */
-
+extern DWORD iupwin_mainthreadid;   /* iupwin_open.c, iupwin_loop.c */
+extern HHOOK iupwin_threadmsghook;  /* iupwin_open.c, iupwin_loop.c */
 
 /* open */
 void iupwinShowLastError(void);
@@ -104,6 

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

[Jörg F . Wittenberger]

Eric,

sorry, you missunderstood my proposed solution.

I wanted to suggest to NOT put additional events into whatever queue Iup 
uses behind the scenes.


Instead better maintain you own queue and process this before you complete 
Iup's queue once using IupFlush.


On Apr 18 2018, Eric Wing wrote:



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





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

[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

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

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

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

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

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

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

[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

[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

[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

[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

[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

[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/17/18, Antonio Scuri  wrote:
>   Hi,
>
>   I got your message. But It will take a couple of days to figure this out.
>
> Best,
> Scuri
>

No problem. I know there is a lot to read over. While I think the
actual implementation and impact on IUP is very small, since this
focuses on concerns not usually discussed with IUP, I felt I needed to
describe everything in detail to get everybody on the same page.



Here is a little more information I would like to add.


First, I made a copy/paste mistake in Idea 2 concerning the
IupSetAttribute(). That should have been deleted since in that case,
that would just work automatically since we have an Ihandle*.



Second, here are a few more edge-case details to fill out a more
complete specification of the feature proposal:


===
- IupPostMessage() should also be safe to call on the main UI thread.

- It should not cause a deadlock.

Discussion: Effectively, all the implementations are adding the
message to the platform’s native event loop queue. That message will
get processed in due time as the queue is processed on the main UI
thread. If IupPostMessage() gets posted from the main UI thread, this
is fine, because the message is still simply added to the queue, and
will be processed sometime in the future when the event queue is
processed.

It is useful to demand we not deadlock because there may be situations where:

a) The user may not know for certain if they are on a background
thread (for cross-platform projects, maybe on some platforms they are,
and others are not)

b) This feature can also be useful for those who want to implement
single-threaded async-like patterns.




=
Further discussion about how to do other platform implementations not
mentioned (e.g. Motif, Haiku, etc):

Note: I am not familiar with these other backends so my comments are
very general, assuming a bad case scenario where nothing is available.
It could be that all the platforms we care about have an easy solution
like the others.


- Presumably all GUI platforms all have some concept of an event
queue. So any implementation should be looking for a way to add the
message to its event queue which presumably gets processed on the main
UI thread.

- In the absence of such a mechanism, we have a few fallback
positions we can decide between:

a) Do nothing and mark as unsupported in the documentation.

b) Implement our own private event queue and using a polling
mechanism (either from pumping the platform’s native event loop, or
using something like IupTimer to poll periodically), then process the
event.

c) Invoke the callback immediately when IupPostMessage() is 
called.


Discussion of (a):
Pros: Easy to implement (don’t have to do anything)
Cons: Can break cross-platform code that was expecting a callback to
happen. And this thing can be hard to debug if they don’t understand
that this will be a no-op on the platform they are testing. (Perhaps
an assert can be thrown if called to alert the developer that this is
unsupported.)

Discussion of (b):
Pros: Writing our own event queue and polling for it manually should
be possible in all real world cases I can imagine. The fact that we
are expected to have IupTimer() means we have a way to poll
periodically if the native event loop is not accessible to us for some
strange reason.
Cons: Requires more implementation on our part, including writing a
thread-safe queue.

Discussion of (c):
In the absence of any other mechanisms, we can just immediately turn
around and invoke the callback
Pros: This solves the missing callback problem of (a).
This is also very easy to implement.

Cons: This may be technically wrong since we are potentially invoking
on a background thread and may confuse the user. (But presumably, if
they are using a backend that we can’t support, it is an old platform
and they probably weren’t using threads to begin with and the call is
actually on the main thread, which is safe.))

- Addition note: I noticed that Motif seems to have a global locking
API that locks the entire GUI so it is safe to call from any thread.
So one possibility is in cases like this, we call lock, then run the
callback, and then unlock. Effectively, this will achieve the original
goal of allowing the user to call GUI code safely from a background
thread.



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

[Antonio Scuri]

  Hi,

  I got your message. But It will take a couple of days to figure this out.

Best,
Scuri


2018-04-16 16:18 GMT-03:00 Eric Wing :

> 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.
>
> The problem I need to solve is that there are many libraries or
> situations where you are on another thread, but then need to change
> something in the GUI which is on the main thread. This can lead to
> disaster depending on the platform and implementation since most are
> not thread-safe. Examples of libraries that I often encounter that
> like to callback on background threads are networking and audio. (In
> fact, the native speech synthesizer I presented in my IUP Next talk at
> the Lua Workshop struggled with these issues since many of the speech
> synth implementation utilized background threads.)
>
> Since threads are a fact of life (even the web is getting web workers
> now), and since platform thread-safety GUI issues involve native
> implementation details that leak out everywhere, we need a
> cross-platform solution in IUP to tame these issues.
>
> So my proposal is very small and simple, “post message”  mechanism
> that I believe can be implemented for all the major platforms moving
> forward. To be clear, this is NOT a proposal to introduce threads to
> IUP, but merely be able to message/dispatch something on the main
> thread for those who find themselves on a background thread because of
> any variety of reasons (including sometimes out of their control).
>
>
>
>
> To set up some context about the backends:
>
> Mac, iOS, and Android *must* do UI stuff on the main UI thread.
> Attempts to call GUI APIs on other threads will lead to crashes,
> halting, etc. But because not-blocking the UI thread is so important
> for responsiveness, all these platforms are aggressive about finding
> non-UI things to compute on background threads. Thus all of these
> platforms provide ways to dispatch code back on the UI thread from the
> other threads. And because these mechanisms are so easy to invoke,
> many libraries that are provided callback on background threads and
> assume the user will take responsibility for dispatching back to the
> main UI thread if they need to. But since IUP abstracts away the
> native GUI parts, but doesn’t currently abstract the main UI dispatch
> mechanisms, we are left with a roadblock.
>
> Additionally, Windows and GTK are not guaranteed to be thread safe.
> While these platforms aren’t as explicit about advertising the
> threading rules as Apple and Android, the restrictions are effectively
> the same. Hence why Windows has a PostMessage() API and GTK offers
> g_idle_add, both of which are advertised as techniques for
> communicating back with the main UI thread.
>
> And it appears the web worker design also provides a postMessage()
> mechanism in this same spirt.
>
>
>
> So now. let me give a concrete example of the threading problem which
> I propose to solve.
>
>
> I have written a normal IUP program that works across all the
> different platforms I mentioned. But my program also uses an audio
> library, ALmixer, to play back sounds. ALmixer however has an
> audio-callback API for certain types events, which calls back on a
> background thread. For simplicity, let’s just focus on ALmixer’s
> “sound finished playing” callback notification.
>
> In my IUP program,
> - I have a button you press to start playing a sound.
> - When you press the button, I make the button inactive (ACTIVE=0) and
> play the sound.
> - When the audio finishes playing, I want to make the button active,
> so the user can play the sound again by pressing the button again.
>
> The problem is that the callback is on a background thread, so it is
> unsafe to call any IUP GUI APIs.
>
> So I need a mechanism where I can send a message to the main UI thread
> and start running a callback there, so I can make the button active
> again.
>
> My proposal is to introduce a new callback, in spirit of the Windows
> PostMessage(), maybe also web worker’s postMessage(). On GTK we can
> implement this with g_idle_add. On Apple, we can implement this easily
> with Apple’s libdispatch: dispatch_async/dispatch_get_main_queue.
> Android can be done with Handler.post() using Looper.getMainLooper()
> (assuming you designed the backend correctly, which I’ve done).
>
>
> The overall proposal idea for IUP is to introduce a new callback event,
> e.g.
> IupSetCallback(ih, “UITHREAD”, uicallback);
>
> and a API to trigger it from a background thread, e.g.
>
> IupPostMessage(Ihandle* ih, void* message_data);
>
> (I’ve suggest more proposal variations of this further below.)
>
>
>
> I’ve actually already implemented a working proof-of-concept for all
> the platforms I mentioned, except Windows. (I’ll explain why
> not-Windows in a moment.)
>
> My proof of concept example using ALmixer with IUP can be found here.
>