> > > What are the main differences between the GUI program flow=20 > > and the type shown above? > > That can work - but the issue is with how you handle the i/o. > > In a console app, i/o via printf (et al) is pretty much synchronous - > your program calls printf, and stuff appears on the console. (Actually > this is a gross simplification but lets pretend for now that it is > true...) > > In a GUI context, that tends not to be the case; the GUI rendering takes > a significant amount of the CPU (in many programs it can be the dominant > element) so you do not necessarily want to redraw the GUI for every > change - especially if the updates are fast, i.e. faster than the > display refresh rate (or indeed faster than a human operator can > perceive.) > > So fltk (in common with many systems) queues up the changes and flushes > them out to the display at a more "moderate" rate, asynchronously to > your programs flow. But to do that, you need to give it some CPU time.=20 > > Generally, GUI programs are driven "by the GUI" and it is that flow that > determines program operation. However, you are coming at this from the > opposite end - i.e. your program flow wants to drive the GUI, and it is > this disconnect that is causing the problem. It is a shift in > perspective that many people encounter when getting into GUI coding... > > In a single threaded program, this can be worked around by having your > "do algorithm" step pump the fltk engine by calling Fl::check(); > periodically. That will let your code work and should more or less do > the Right Thing. > > However, what I would do is have the program run the GUI, then have the > GUI start a worker thread that runs my (lightly modified) console app. > The modified console app would then "print" to the GUI interface (still > running in the main thread) which would display the updates on the > screen - and since it is in its own thread separate to the "console app" > I don't have to worry so much about scheduling asynchronous updates or > etc., as the underlying OS deals with all that. > > The next step along might be to make your console app read/write to a > socket and have the GUI standalone read/write to a socket and handle all > the i/o in that way. > > That's a bit more work to set up of course, but once it is done it opens > up the possibility of running your app remotely on a server or etc. > pretty much "for free" if you want it... > > I think I have an crude example of the threading approach somewhere - if > I find it, I'll post it along... > > > > > SELEX Galileo Ltd > Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS= > 14 3EL > A company registered in England & Wales. Company no. 02426132 > ******************************************************************** > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > ******************************************************************** >
> > > What are the main differences between the GUI program flow=20 > > and the type shown above? > > That can work - but the issue is with how you handle the i/o. > > In a console app, i/o via printf (et al) is pretty much synchronous - > your program calls printf, and stuff appears on the console. (Actually > this is a gross simplification but lets pretend for now that it is > true...) > > In a GUI context, that tends not to be the case; the GUI rendering takes > a significant amount of the CPU (in many programs it can be the dominant > element) so you do not necessarily want to redraw the GUI for every > change - especially if the updates are fast, i.e. faster than the > display refresh rate (or indeed faster than a human operator can > perceive.) > > So fltk (in common with many systems) queues up the changes and flushes > them out to the display at a more "moderate" rate, asynchronously to > your programs flow. But to do that, you need to give it some CPU time.=20 > > Generally, GUI programs are driven "by the GUI" and it is that flow that > determines program operation. However, you are coming at this from the > opposite end - i.e. your program flow wants to drive the GUI, and it is > this disconnect that is causing the problem. It is a shift in > perspective that many people encounter when getting into GUI coding... > > In a single threaded program, this can be worked around by having your > "do algorithm" step pump the fltk engine by calling Fl::check(); > periodically. That will let your code work and should more or less do > the Right Thing. > > However, what I would do is have the program run the GUI, then have the > GUI start a worker thread that runs my (lightly modified) console app. > The modified console app would then "print" to the GUI interface (still > running in the main thread) which would display the updates on the > screen - and since it is in its own thread separate to the "console app" > I don't have to worry so much about scheduling asynchronous updates or > etc., as the underlying OS deals with all that. > > The next step along might be to make your console app read/write to a > socket and have the GUI standalone read/write to a socket and handle all > the i/o in that way. > > That's a bit more work to set up of course, but once it is done it opens > up the possibility of running your app remotely on a server or etc. > pretty much "for free" if you want it... > > I think I have an crude example of the threading approach somewhere - if > I find it, I'll post it along... > > > > > SELEX Galileo Ltd > Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS= > 14 3EL > A company registered in England & Wales. Company no. 02426132 > ******************************************************************** > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > ******************************************************************** > Thanks, Thats some food for thought, the socket idea is an interesting idea. So are you also saying that console applications that presently use printf repeatedly as part of an algorithm would not really be suitable for a GUI application? The thing that confuses me is what about scientific programs? surely they use more of this kind of console output stuff? where the data is fast changing and repeatedly written to screen to monitor it? I have to say the main thing in my search for a suitable tool has been one that can do the updates in this fashion, and i seem to have become stuck at every turn. SDL Graphics API which i usually write mouse driven events and graphics stuff in is too slow to render the data using the fonts extension library, (though i may test using sprintf anyhow now) at the bottom of main() what happens when the return (run()) is called? That is a really confusing one for me! I am so pleased with FLTK as a tool, if i can just get over these teething trroubles then i will be away! _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
