Re: [Iup-users] Formal proposal for a "postMessage" API to send messages to run on the UI thread
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
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
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
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
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
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
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
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
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
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
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
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
>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, 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
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
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
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
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
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
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
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
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
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
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
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
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
> > 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
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
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
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
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
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. > https://bitbucket.org/ewing
[Iup-users] Formal proposal for a "postMessage" API to send messages to run on the UI thread
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. https://bitbucket.org/ewing/iupalmixerthread/src (The bulk of the code is in the source directory, but the Android .java file resides in the CMakeModules subdirectory.) The proof-of-concept I wrote actually was implemented directly in my app, and outside (not-modifying) of IUP (mostly). For Mac, iOS, and GTK, this is pretty trivial to do. Android