Re: How to update both the Console and the GTKMM gui window after running other functions

["L. D. James" <ljames apollo3 com>]

Some people gets aggravated and annoyed at the rate that some learn.  It almost sounds by the tone of your message that you maybe getting a little annoyed at my slowness in fully grasping this application.

I appreciate that you have the patience to suggest that I may not have to fully understand the full implementations to use some of the features.  I believe some of the purpose of gtkmm (over gtk) is to provide an easy to use interface for the users, so they don't spend a lot of time reinventing the wheel.

However, since I don't have a working example of the ability to be in my routine and arbitrarily change the buffer (display) of the gui window, I'm spending time trying to figure out how to reinvent what might already be provided.

I already wrote a number of pieces trying to implement what you've described.  I'm going to try to clean it up a bit and post it.  The many versions of the code is still doing the same thing, but in a different place (a separate thread/method/routine) than the main.

I know there are differences between the terminology.  I might misunderstand when you say thread and think you're talking about a routine.

Hopefully you'll be patient with the code that I post, when you tell me that my function isn't a thread (or vice-versa).

By the way, I appreciate your taking the time to let me know that changing the content of the window displayed can be as simple in gtkmm as it is in Java.  This makes things very hopeful to me.

-- L. James

--
L. D. James
ljames apollo3 com
www.apollo3.com/~ljames

On Wed, 2013-07-31 at 10:15 -0700, Alan Mazer wrote:

On 7/31/2013 9:24 AM, L. D. James wrote:

Java is very easy.  The Window and Frame is up and has a buffer.  All you have to do is just append or change the buffer.  The window will always  reflect the content of the buffer you modify.

And you can do this in gtkmm as well.  I think someone else already posted a way to do that as part of window initialization.  My concern is that unless you're doing your (long) computation in a separate thread, you may tie up window message processing, which will typically prevent/delay normal window behaviors like repaint.  You don't want to do that.

My problem is how to be in my routine while the window is displayed.

That's why you use multiple threads.  It lets "you" be in two places at the same time, both the GUI message-processing thread and your computational thread.

I believe it should take priority over the signals I'm currently trying to understand (which I have to admit, I don't).

The signals concept is very powerful, but it's also very difficult to grasp in some ways.  You don't have to understand the implementation to use signals.  I wouldn't spend a lot of time on it, personally.

I have lots of work cut out for me.

Good luck.  If you're not familiar with threaded programming, this is a great exercise for learning it, and it's widely useful for gtkmm and other stuff.

-- Alan