Trigger an event manually.

2013-08-20 Thread sourav
I am using Gtkmm and would like to pragmatically fire an event (say like a
click event), which simulates the on_button_click event. How am I supposed
to do that.
That is, when execution reach a particular method in my application, the
manual event should get fired.
Any help is greatly appreciated.
Thanks !!



--
View this message in context: 
http://gtk.10911.n7.nabble.com/Trigger-an-event-manually-tp82184.html
Sent from the Gtkmm mailing list archive at Nabble.com.
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list


Re: What is the minimum number of lines to update a gui window without user clicking a button

2013-08-20 Thread Markus Elfring



HelloWorld::HelloWorld() : m_textview() {

add(m_textview);
m_textview.show();
Glib::Thread::create(sigc::mem_fun(*this, HelloWorld::cpp_app), 
true);

}

[...]

void HelloWorld::cpp_app() {
string texttoprint = ;
Glib::RefPtrGtk::TextBuffer m_refTextBuffer;
m_refTextBuffer = Gtk::TextBuffer::create();
string runit(std::string c);

texttoprint +=
About to run a number of c++ functions\nand display the 
results\n;

m_refTextBuffer-set_text(texttoprint);
m_textview.set_buffer(m_refTextBuffer);

sleep(10);  // This sleep function represents any c++ function 
performaing a task


I would like to clarify implementation details a bit more from this 
programming attempt. Can it be that the referenced text buffer is 
written in a thread-unsafe way here?
How do think about to apply improved techniques and software ingredients 
like locks for memory consistency?
(Andrew Potter and Gavin Lambert suggested also an alternative program 
structure. - 
https://mail.gnome.org/archives/gtkmm-list/2013-August/msg00135.html )


Regards,
Markus
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list


Re: What is the minimum number of lines to update a gui window without user clicking a button

2013-08-20 Thread Markus Elfring


I'm sure I can add a lot of highlights and decorations now.  But I 
can't emphasis how important I consider having  the rawest and most 
basic (blank) slate to begin with.
The absolute only thing that matters at this point is for me to 
actually be able to have a gui window and update it with appended or 
new text.


Are you also interested to write any message to a file?

How do you think about to deal with documents?
http://bakery.sourceforge.net/

Would you like to scroll through the logs?

Regards,
Markus
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list


Re: What is the minimum number of lines to update a gui window without user clicking a button

2013-08-20 Thread L. D. James

On 08/20/2013 04:44 AM, Markus Elfring wrote:



HelloWorld::HelloWorld() : m_textview() {

add(m_textview);
m_textview.show();
Glib::Thread::create(sigc::mem_fun(*this, HelloWorld::cpp_app), 
true);

}

[...]

void HelloWorld::cpp_app() {
string texttoprint = ;
Glib::RefPtrGtk::TextBuffer m_refTextBuffer;
m_refTextBuffer = Gtk::TextBuffer::create();
string runit(std::string c);

texttoprint +=
About to run a number of c++ functions\nand display the 
results\n;

m_refTextBuffer-set_text(texttoprint);
m_textview.set_buffer(m_refTextBuffer);

sleep(10);  // This sleep function represents any c++ function 
performaing a task


I would like to clarify implementation details a bit more from this 
programming attempt. Can it be that the referenced text buffer is 
written in a thread-unsafe way here?
How do think about to apply improved techniques and software 
ingredients like locks for memory consistency?
(Andrew Potter and Gavin Lambert suggested also an alternative program 
structure. - 
https://mail.gnome.org/archives/gtkmm-list/2013-August/msg00135.html )


Regards,
Markus

Makus. As always I appreciate your taking the time to give input.

The lines that you quote are almost identical to the lines in the 
documentation, HelloWorld (the first example of the Gtkmm 
documentation).  It's totally modeled after Alan's submission of which I 
linked to.  The only difference is Alan's submission uses the label 
widget and the one you're quoting above uses textview.  I could be wrong 
and you might see something else subtle that I'm missing.  If you could 
specify specifically I'll message Alan for help to make whatever change 
you suggest, if it would be applicable.  But I can't make changes at 
this time.  It's working perfectly and making changes would brake it.


Again, I'd gladly test any lines that you post and tell you if the code 
still works.


-- L. James

--
L. D. James
lja...@apollo3.com
www.apollo3.com/~ljames
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list


Re: What is the minimum number of lines to update a gui window without user clicking a button

2013-08-20 Thread L. D. James

On 08/20/2013 06:42 AM, Markus Elfring wrote:


I'm sure I can add a lot of highlights and decorations now.  But I 
can't emphasis how important I consider having  the rawest and most 
basic (blank) slate to begin with.
The absolute only thing that matters at this point is for me to 
actually be able to have a gui window and update it with appended or 
new text.


Are you also interested to write any message to a file?

How do you think about to deal with documents?
http://bakery.sourceforge.net/

Would you like to scroll through the logs?

Regards,
Markus
I don't have any problems with any of the things you're listing. I'm 
trying to be specific in this particular thread and concentrate on one 
thing, updating a gui window without a user pressing a button.


It took me about a week to convert Alan's label widget example to a 
textview widget.  I started this thread when I was having problems. But 
after getting the label widget changed to a textview widget and having 
the code actually work, the task was done.


While you're giving me lots of documentation to read, and I have enough 
lined up that I'll be studying it for a very long time, I have found 
that most of what I actually have needed (as Kjell mentioned) is already 
there in the Gtkmm tutorial.  I believe the only thing it lacked was a 
clear example of updating a gui window without buttons... a blank slate 
to work with.  So in this thread I'm hoping for clarity on that.


It's common for a new user to an environment to want to see something 
very clear... to print a HelloWorld as a starting reference.  Many 
people might not have problems if the HelloWorld included file IO, 
scroll locks, window decorations, and more.  But for most beginners, the 
simplest would be come the easiest to get an immediate grip for 
starting.  If they are able to look at the simplest, understand it, and 
possibly be able to recreate it from memory they may have a better 
grip.  That's the way it works in my case.


Thanks again for all the suggestions!

-- L. James

--
L. D. James
lja...@apollo3.com
www.apollo3.com/~ljames
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list


Re: Trigger an event manually.

2013-08-20 Thread Kevin Brightwell
Not to be condescending but you should try searching for your problem first.

Just invoke the signal_on_clicked() result directly. If you need a better
result, try searching through the docs for button.

Kevin
On 2013-08-20 4:09 AM, sourav nordic_ku...@yahoo.co.in wrote:

 I am using Gtkmm and would like to pragmatically fire an event (say like a
 click event), which simulates the on_button_click event. How am I supposed
 to do that.
 That is, when execution reach a particular method in my application, the
 manual event should get fired.
 Any help is greatly appreciated.
 Thanks !!



 --
 View this message in context:
 http://gtk.10911.n7.nabble.com/Trigger-an-event-manually-tp82184.html
 Sent from the Gtkmm mailing list archive at Nabble.com.
 ___
 gtkmm-list mailing list
 gtkmm-list@gnome.org
 https://mail.gnome.org/mailman/listinfo/gtkmm-list

___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list


Re: Trigger an event manually.

2013-08-20 Thread Jonas Platte
Most events have additional methods to trigger them, for Gtk::Button 
this is clicked().

But why do you want to do that?

Am 20.08.2013 10:09, schrieb sourav:

I am using Gtkmm and would like to pragmatically fire an event (say like a
click event), which simulates the on_button_click event. How am I supposed
to do that.
That is, when execution reach a particular method in my application, the
manual event should get fired.
Any help is greatly appreciated.
Thanks !!



--
View this message in context: 
http://gtk.10911.n7.nabble.com/Trigger-an-event-manually-tp82184.html
Sent from the Gtkmm mailing list archive at Nabble.com.
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list


___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list


Re: Trigger an event manually.

2013-08-20 Thread Kevin Brightwell
My memory failed me. This is what I was trying to remember.
On 2013-08-20 8:20 AM, Jonas Platte jonaspla...@myopera.com wrote:

 Most events have additional methods to trigger them, for Gtk::Button this
 is clicked().
 But why do you want to do that?

 Am 20.08.2013 10:09, schrieb sourav:

 I am using Gtkmm and would like to pragmatically fire an event (say like a
 click event), which simulates the on_button_click event. How am I supposed
 to do that.
 That is, when execution reach a particular method in my application, the
 manual event should get fired.
 Any help is greatly appreciated.
 Thanks !!



 --
 View this message in context: http://gtk.10911.n7.nabble.**
 com/Trigger-an-event-manually-**tp82184.htmlhttp://gtk.10911.n7.nabble.com/Trigger-an-event-manually-tp82184.html
 Sent from the Gtkmm mailing list archive at Nabble.com.
 __**_
 gtkmm-list mailing list
 gtkmm-list@gnome.org
 https://mail.gnome.org/**mailman/listinfo/gtkmm-listhttps://mail.gnome.org/mailman/listinfo/gtkmm-list


 __**_
 gtkmm-list mailing list
 gtkmm-list@gnome.org
 https://mail.gnome.org/**mailman/listinfo/gtkmm-listhttps://mail.gnome.org/mailman/listinfo/gtkmm-list

___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list


Re: What is the minimum number of lines to update a gui window without user clicking a button

2013-08-20 Thread L. D. James

On 08/19/2013 07:07 PM, Andrew Potter wrote:

Adding these methods to the Example class show how you can use a local
helper function. The downside is you having an extra method lying
around and remembering to use the right one in the right context; in
C++11 you could get rid of gui_append_mainloop() by using a lambda.

Edit: This uses the approach Gavin just suggested. He's right in that
I probably should have used that approach in the first place.

// Extra methods for Example 5
 /* Append to the textbuffer in a thread UNsafe manner. Should only
  * be used on the Main Loop. */
 void gui_append_mainloop(const Glib::ustring str) {
 Glib::ustring text =  tb-get_text();
 text += \n + str;
 tb-set_text(text);
 }

 /* Threadsafe access to gui_append_mainloop */
 void gui_append(const Glib::ustring str) {
 callback_dispatcher.send(sigc::bind(sigc::mem_fun(this,
Example::gui_append_mainloop), str));
 }
// Extra methods for Example 5


Thanks again, Andrew for taking the time to diligently write code and 
contribute to my efforts.  You asked me to comment on any problems with 
the code you submit.


When clicking on the close button to cancel the operation the gui window 
dims ad become non-responsive... locked up.  That is a problem, in that 
some of the programs might only take seconds or minutes to complete.  
Some of the programs takes hours and days to complete.  It's a problem 
if the user can't cancel the application by closing the gui window.  The 
code that I previous posted modeled after Alan's example and Alan's 
example has this functionality.


I have tried to figure out how to fix the code you submitted so that it 
won't dim or lockup when clicking the close button, but at this time I 
can't.


I will continue to study the lines and try to figure out how to add the 
gui_print() function to the code that is currently working (Alan's Label 
example and my TableView example posted).


If you are able to identify why your example5 locks up when clicking the 
close button I'd be glad to test it and tell you if it's works.


Thanks!

-- L. James

--
L. D. James
lja...@apollo3.com
www.apollo3.com/~ljames
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list


RE: What is the minimum number of lines to update a gui window without user clicking a button

2013-08-20 Thread Mazer, Alan S (389M)
I'm pretty sure this is NOT thread safe. You generally need a dispatcher for 
that in from. I would expect lockups without a dispatcher.

Sent from my Android phone using TouchDown (www.nitrodesk.com)

-Original Message-
From: Markus Elfring [markus.elfr...@web.de]
Received: Tuesday, 20 Aug 2013, 1:44am
To: L. D. James [lja...@apollo3.com]
CC: gtkmm-list@gnome.org [gtkmm-list@gnome.org]
Subject: Re: What is the minimum number of lines to update a gui window without 
user clicking a button


 HelloWorld::HelloWorld() : m_textview() {

 add(m_textview);
 m_textview.show();
 Glib::Thread::create(sigc::mem_fun(*this, HelloWorld::cpp_app),
 true);
 }
[...]
 void HelloWorld::cpp_app() {
 string texttoprint = ;
 Glib::RefPtrGtk::TextBuffer m_refTextBuffer;
 m_refTextBuffer = Gtk::TextBuffer::create();
 string runit(std::string c);

 texttoprint +=
 About to run a number of c++ functions\nand display the
 results\n;
 m_refTextBuffer-set_text(texttoprint);
 m_textview.set_buffer(m_refTextBuffer);

 sleep(10);  // This sleep function represents any c++ function
 performaing a task

I would like to clarify implementation details a bit more from this
programming attempt. Can it be that the referenced text buffer is
written in a thread-unsafe way here?
How do think about to apply improved techniques and software ingredients
like locks for memory consistency?
(Andrew Potter and Gavin Lambert suggested also an alternative program
structure. -
https://mail.gnome.org/archives/gtkmm-list/2013-August/msg00135.html )

Regards,
Markus
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list


Re: What is the minimum number of lines to update a gui window without user clicking a button

2013-08-20 Thread Markus Elfring


The only difference is Alan's submission uses the label widget and the 
one you're quoting above uses textview.  I could be wrong and you 
might see something else subtle that I'm missing.


Do you understand the involved consequences from the software technique 
multi-threading?


Regards,
Markus
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list


Re: What is the minimum number of lines to update a gui window without user clicking a button

2013-08-20 Thread L. D. James

On 08/20/2013 09:33 AM, Markus Elfring wrote:


The only difference is Alan's submission uses the label widget and 
the one you're quoting above uses textview.  I could be wrong and you 
might see something else subtle that I'm missing.


Do you understand the involved consequences from the software 
technique multi-threading?


Regards,
Markus
I have some idea.  This is why I'm trying to learn as much as I can 
about the application.


I'm just curious if you understand that so far, Alan's code is the only 
one that actually works at this time.  Will you look at it and tell me 
what needs to happen so that it will not pose a problem? Currently it 
doesn't.


I like the fact that Andrew's example has the gui_print() function.  
However, when I run it, currently it doesn't work.  It locks up.  I 
described the circumstances.  Both Alan's and Andrews compiles quickly 
and easily and can be easily tested.  If I develop a glitch, I'll study 
it and try to figure out how to fix it.  But at present, I'm just stuck 
with using what actually works at this time.


-- L. James

--
L. D. James
lja...@apollo3.com
www.apollo3.com/~ljames
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list


Re: What is the minimum number of lines to update a gui window without user clicking a button

2013-08-20 Thread Markus Elfring


But after getting the label widget changed to a textview widget and 
having the code actually work, the task was done.


I got the impression that there are still some open issues remaining.


It's common for a new user to an environment to want to see something 
very clear... to print a HelloWorld as a starting reference. 


That is fine, of course.


Many people might not have problems if the HelloWorld included file 
IO, scroll locks, window decorations, and more.


You can choose from which abstraction level and tool box the experiments 
should start. I try to point out not to reinvent a coding wheel.




That's the way it works in my case.


You might be a beginner with GTK+ functions and classes while you 
evolved to an advanced or even expert software developer in other areas 
through the years eventually. I hope that you enjoy the next technical 
challenges.


Regards,
Markus
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list


Re: What is the minimum number of lines to update a gui window without user clicking a button

2013-08-20 Thread L. D. James

On 08/20/2013 10:00 AM, Markus Elfring wrote:


But after getting the label widget changed to a textview widget and 
having the code actually work, the task was done.


I got the impression that there are still some open issues remaining.


It's common for a new user to an environment to want to see something 
very clear... to print a HelloWorld as a starting reference. 


That is fine, of course.


Many people might not have problems if the HelloWorld included file 
IO, scroll locks, window decorations, and more.


You can choose from which abstraction level and tool box the 
experiments should start. I try to point out not to reinvent a coding 
wheel.




That's the way it works in my case.


You might be a beginner with GTK+ functions and classes while you 
evolved to an advanced or even expert software developer in other 
areas through the years eventually. I hope that you enjoy the next 
technical challenges.


Regards,
Markus

Thanks! Markus.

And, No.  There aren't any significantly open issues.  The code 
presented by Alan works perfectly.  It has already been in production 
with my clients for over a week without a glitch.


I would be glad to implement a gprint() function to ease the flow for 
some of my other programs/C++ scripts/applications that haven't been 
implemented with the gui window, as well as some of my future project 
and overall understanding and learning.  But as I mentioned, I'm 
reserving that development for a future thread.


I really appreciate all the support I have had with this maillist in 
helping me with my tasks... and of course I'm testing everything posted 
to enhance the integrity of my coding.  I hope my testing and reporting 
back with keep the community interested in my next phase and continue to 
offer input.


Out of appreciation for the support that I'm getting, I'm also studying 
how I can become a contributor.  In other projects where I have worked, 
I have contributed in documentation writing, translating, and proofing.  
That is were I'm currently researching 
(https://wiki.gnome.org/DocumentationProject/Contributing).


From my reading and the standards described I see it takes a lot of 
dedication.  I appreciate the patience the community is showing with 
me.  I hope to give back to the community with my dedication by 
following all the provided steps.


Thanks!

-- L. James

--
L. D. James
lja...@apollo3.com
www.apollo3.com/~ljames
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list


Re: What is the minimum number of lines to update a gui window without user clicking a button

2013-08-20 Thread Markus Elfring


There aren't any significantly open issues.  The code presented by 
Alan works perfectly.


Would you like to show a specific source code version which was accepted 
for your execution environment?


Regards,
Markus
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list


ONE MORE TIME.

2013-08-20 Thread Incongruous
ONE MORE TIME.
I have clicked on unsubscribed and you keep sending these emails. Let's not get 
annoying here. I don't want to get nasty, OK?

-Original Message-
From: gtkmm-list [mailto:gtkmm-list-boun...@gnome.org] On Behalf Of L. D. James
Sent: Tuesday, August 20, 2013 10:58 AM
To: Markus Elfring
Cc: gtkmm-list@gnome.org
Subject: Re: What is the minimum number of lines to update a gui window without 
user clicking a button

On 08/20/2013 10:00 AM, Markus Elfring wrote:

 But after getting the label widget changed to a textview widget and 
 having the code actually work, the task was done.

 I got the impression that there are still some open issues remaining.


 It's common for a new user to an environment to want to see something 
 very clear... to print a HelloWorld as a starting reference.

 That is fine, of course.


 Many people might not have problems if the HelloWorld included file 
 IO, scroll locks, window decorations, and more.

 You can choose from which abstraction level and tool box the 
 experiments should start. I try to point out not to reinvent a coding 
 wheel.


 That's the way it works in my case.

 You might be a beginner with GTK+ functions and classes while you 
 evolved to an advanced or even expert software developer in other 
 areas through the years eventually. I hope that you enjoy the next 
 technical challenges.

 Regards,
 Markus
Thanks! Markus.

And, No.  There aren't any significantly open issues.  The code presented by 
Alan works perfectly.  It has already been in production with my clients for 
over a week without a glitch.

I would be glad to implement a gprint() function to ease the flow for some of 
my other programs/C++ scripts/applications that haven't been implemented with 
the gui window, as well as some of my future project and overall understanding 
and learning.  But as I mentioned, I'm reserving that development for a future 
thread.

I really appreciate all the support I have had with this maillist in helping me 
with my tasks... and of course I'm testing everything posted to enhance the 
integrity of my coding.  I hope my testing and reporting back with keep the 
community interested in my next phase and continue to offer input.

Out of appreciation for the support that I'm getting, I'm also studying how I 
can become a contributor.  In other projects where I have worked, I have 
contributed in documentation writing, translating, and proofing.  
That is were I'm currently researching
(https://wiki.gnome.org/DocumentationProject/Contributing).

 From my reading and the standards described I see it takes a lot of 
dedication.  I appreciate the patience the community is showing with me.  I 
hope to give back to the community with my dedication by following all the 
provided steps.

Thanks!

-- L. James

--
L. D. James
lja...@apollo3.com
www.apollo3.com/~ljames
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list


RE: What is the minimum number of lines to update a gui window without user clicking a button

2013-08-20 Thread Gavin Lambert
Quoth L. D. James:
 And, No.  There aren't any significantly open issues.  The code
 presented by Alan works perfectly.  It has already been in production
 with my clients for over a week without a glitch.

Several people (including myself) have tried to tell you that the code you
have posted here thus far is not at all thread-safe and is very likely to
explode in your face at some point.  That it appears to be working during
your testing is merely coincidental.  (One of the joys of programming with
threads, in any language or framework, is that you have to pay very close
attention to the data interactions -- it's very easy to write something that
appears to work most of the time but will do something very strange in
corner conditions.)

I'm not sure why you seem to be ignoring this.

 I would be glad to implement a gprint() function to ease the flow for
 some of my other programs/C++ scripts/applications that haven't been
 implemented with the gui window, as well as some of my future project
 and overall understanding and learning.  But as I mentioned, I'm
 reserving that development for a future thread.

If you look at the most recent example that Andrew Potter posted, that is
pretty much exactly your desired gprint() method done in an actually
thread-safe manner.


Regarding your other question, about closing the window freezing up the
program: this is because the window cannot be closed while the background
thread is running, and you should not allow it to do so.  If you want to be
able to cancel the background operation, then you have to add in code
specifically to request that the background operation be cancelled (in a
thread safe manner) when the user attempts to close the window, and then
wait for it to actually complete running before closing down.


___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list


RE: ONE MORE TIME.

2013-08-20 Thread Gavin Lambert
Quoth Incongruous:
 ONE MORE TIME.
 I have clicked on unsubscribed and you keep sending these emails. Let's
 not get annoying here. I don't want to get nasty, OK?

Posting messages here is not going to help anything, nor would getting
nasty.

It is an automated system.  If you are still receiving messages then you are
not actually unsubscribing correctly.

Go to https://mail.gnome.org/mailman/listinfo/gtkmm-list (the link is at the
bottom of every email) and use the unsubscribe button at the bottom of the
page.  Make sure that you use the email address that you actually subscribed
with in the first place and pay attention to any messages that it shows you.
 

___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list


Re: What is the minimum number of lines to update a gui window without user clicking a button

2013-08-20 Thread L. D. James

On 08/20/2013 08:51 PM, Gavin Lambert wrote:

Quoth L. D. James:

And, No.  There aren't any significantly open issues.  The code
presented by Alan works perfectly.  It has already been in production
with my clients for over a week without a glitch.

Several people (including myself) have tried to tell you that the code you
have posted here thus far is not at all thread-safe and is very likely to
explode in your face at some point.  That it appears to be working during
your testing is merely coincidental.  (One of the joys of programming with
threads, in any language or framework, is that you have to pay very close
attention to the data interactions -- it's very easy to write something that
appears to work most of the time but will do something very strange in
corner conditions.)

I'm not sure why you seem to be ignoring this.


I would be glad to implement a gprint() function to ease the flow for
some of my other programs/C++ scripts/applications that haven't been
implemented with the gui window, as well as some of my future project
and overall understanding and learning.  But as I mentioned, I'm
reserving that development for a future thread.

If you look at the most recent example that Andrew Potter posted, that is
pretty much exactly your desired gprint() method done in an actually
thread-safe manner.


Regarding your other question, about closing the window freezing up the
program: this is because the window cannot be closed while the background
thread is running, and you should not allow it to do so.  If you want to be
able to cancel the background operation, then you have to add in code
specifically to request that the background operation be cancelled (in a
thread safe manner) when the user attempts to close the window, and then
wait for it to actually complete running before closing down.


Gavin, I'm not ignoring any suggestions or comments that are coming from 
anyone. I'm here asking for help and responding the best and most 
respectful that I know of. I'm making it clear that I don't understand 
all the technical terms. I'm posting everything I learn and giving any 
other details that I can put into words.


I'm not ignoring any code that is given. I'm working with all the code 
the best that I can. When someone specify something that I should do, 
but without code examples, I'm making it as clear as I can that I'm stuck.


While I'm stuck and have gaps, I'm letting everyone know at which point 
I happen to be.


It's my experience that no form wants someone to just post questions and 
wait for people to give them everything without posting some code of 
what they are working with.


I posted what I have figure out how to compile, that is a perfect 
working example of what I'm trying to do. I mentioned that it's working 
perfectly and the lines are very simple where it's very easy for anyone 
to quickly compile it and look at it. I was thinking about making a 
video so that the community could see what I was trying to do.


If I didn't post it and say it was working perfectly I might keep 
getting questions about more widgets, colors, and other enhancements 
which, at present, I'm not looking for.


I have given Andrew all the praise I can muster up. I realize he has 
taken a lot of time to look at my messages and get a good idea of what 
I'm trying to do. I believe it's working now. When it wasn't I couldn't 
use it. I could only use the best that I could do.


I hope the group is understanding my humble appreciation and sharing 
what I'm learning and trying to do.


Thank you very kindly for your input!

I hope I'm being clear that I'm taking everything in the best way I can. 
I'm an old man and I have gaps, but I'm trying.


-- L. James

--
L. D. James
lja...@apollo3.com
www.apollo3.com/~ljames
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list


Fwd: Re: What is the minimum number of lines to update a gui window without user clicking a button

2013-08-20 Thread Andrew Potter
I missed the list in my last reply, so I'm copying it here for the record.
In addition to using a cancelable I changed CallbackDispatcher to use a
recursive mutex so gui_print can be called from the main thread as well.

While providing such an in depth example to L. James maybe goes against the
learn-the-fundamentals-and-help-yourself culture, I'd just like to have a
final answer and close the thread after a month and 100+ messages.

-- Forwarded message --
From: Andrew Potter agpot...@gmail.com
Date: Aug 20, 2013 11:22 AM
Subject: Re: What is the minimum number of lines to update a gui window
without user clicking a button
To: L. D. James lja...@apollo3.com
Cc:

 On Tue, Aug 20, 2013 at 6:01 AM, L. D. James lja...@apollo3.com wrote:
  When clicking on the close button to cancel the operation the gui window
  dims ad become non-responsive... locked up.  That is a problem, in that
some
  of the programs might only take seconds or minutes to complete.

 I designed it that way because I didn't know if it was safe to have
 your blocking operation terminated suddenly; instead it ensures that
 your blocking operation runs until it fully completes. If it is safe
 to stop at any point then you can remove thread_cleanup() from
 Example::~Example(). Otherwise it is best to periodically check in the
 blocking operation whether the window has been closed.
 Gio::Cancellable can be used for this.

 // Example 6
 #include gtkmm.h
 #include unistd.h
 #include queue

 class CallbackDispatcher {
 public:
 CallbackDispatcher() {
 dispatcher.connect(sigc::mem_fun(this,
 CallbackDispatcher::on_dispatch));
 }

 typedef sigc::slotvoid Message;
 void send(Message msg) {
 Glib::Threads::RecMutex::Lock lock(mutex);
 queue.push(msg);
 dispatcher();
 }

 private:
 /* CallbackDispatcher may not be copied, so we must hide these
  * constructors. */
 CallbackDispatcher(const CallbackDispatcher);
 CallbackDispatcher operator=(const CallbackDispatcher);

 Glib::Threads::RecMutex mutex;
 std::queueMessage queue;
 Glib::Dispatcher dispatcher;

 void on_dispatch() {
 Glib::Threads::RecMutex::Lock lock(mutex);
 while (!queue.empty()) {
 queue.front()();
 queue.pop();
 }
 }
 };

 class Example {
 private:
 Glib::RefPtrGtk::Application app;
 Gtk::Windowwin;
 Gtk::TextView  tv;
 Glib::RefPtrGtk::TextBuffer  tb;
 CallbackDispatcher callback_dispatcher;
 Glib::Threads::Thread *thread;
 Glib::RefPtrGio::Cancellable cancellable;

 /* Appends str to the textbuffer. Like all methods that use the
  * Gtk namespace, it is not safe to call from another thread. */
 void gui_print_cb(const Glib::ustring str) {
 tb-insert(tb-end(), str);
 }

 /* Provides threadsafe access to gui_print_cb() */
 void gui_print(const Glib::ustring str) {
 sigc::slotvoid slot = sigc::bind(sigc::mem_fun(this,
 Example::gui_print_cb), str);
 callback_dispatcher.send(slot);
 }

/* This function is called on a separate thread so as to avoid
 * blocking GTK+'s main loop.
 */
 void blocking_operation() {
 /* This simulates a blocking process */
 sleep(5);
 gui_print(5% complete.\n);
 if (cancellable-is_cancelled()) return;

 sleep(5);
 gui_print(15% complete.\n);
 if (cancellable-is_cancelled()) return;

 sleep(5);
 gui_print(35% complete.\n);
 if (cancellable-is_cancelled()) return;

 sleep(5);
 gui_print(55% complete.\n);
 if (cancellable-is_cancelled()) return;

 sleep(5);
 gui_print(75% complete.\n);
 if (cancellable-is_cancelled()) return;

 sleep(5);
 gui_print(95% complete.\n);
 if (cancellable-is_cancelled()) return;

 sleep(5);
 gui_print(100% complete.\n);

 /* When the process is finished, we notify the GTK+ Main Loop by
  * using the dispatcher */
 callback_dispatcher.send(sigc::mem_fun(this,
 Example::blocking_operation_finished));
 };

 /* This function is called on GTK+'s main loop via a
  * Glib::Dispatcher */
 void blocking_operation_finished() {
 cleanup_thread();
 gui_print(Operation finished.\n);
 };

 void cleanup_thread() {
 /* We must call Glib::Threads::Thread::join() in order to
  * correctly clean up the resource. */
 if (thread) {
 thread-join();
 thread = NULL;
 }
 }

 public:
 ~Example() {
 /* This will prevent the Window from being closed while
  * the blocking operation is ongoing. */
 cancellable-cancel();
 cleanup_thread();
 }

 Example(int argc, char *argv[]) :
 app(Gtk::Application::create(argc, argv, 

RE: Re: What is the minimum number of lines to update a gui window without user clicking a button

2013-08-20 Thread Incongruous
Israel is a terrorist state

http://www.youtube.com/watch?v=noln8nx43Sk

 

From: gtkmm-list [mailto:gtkmm-list-boun...@gnome.org] On Behalf Of Andrew 
Potter
Sent: Tuesday, August 20, 2013 9:46 PM
To: gtkmm-list@gnome.org
Subject: Fwd: Re: What is the minimum number of lines to update a gui window 
without user clicking a button

 

I missed the list in my last reply, so I'm copying it here for the record. In 
addition to using a cancelable I changed CallbackDispatcher to use a recursive 
mutex so gui_print can be called from the main thread as well.

While providing such an in depth example to L. James maybe goes against the 
learn-the-fundamentals-and-help-yourself culture, I'd just like to have a final 
answer and close the thread after a month and 100+ messages.

-- Forwarded message --
From: Andrew Potter agpot...@gmail.com
Date: Aug 20, 2013 11:22 AM
Subject: Re: What is the minimum number of lines to update a gui window without 
user clicking a button
To: L. D. James lja...@apollo3.com
Cc:

 On Tue, Aug 20, 2013 at 6:01 AM, L. D. James lja...@apollo3.com wrote:
  When clicking on the close button to cancel the operation the gui window
  dims ad become non-responsive... locked up.  That is a problem, in that some
  of the programs might only take seconds or minutes to complete.

 I designed it that way because I didn't know if it was safe to have
 your blocking operation terminated suddenly; instead it ensures that
 your blocking operation runs until it fully completes. If it is safe
 to stop at any point then you can remove thread_cleanup() from
 Example::~Example(). Otherwise it is best to periodically check in the
 blocking operation whether the window has been closed.
 Gio::Cancellable can be used for this.

 // Example 6
 #include gtkmm.h
 #include unistd.h
 #include queue

 class CallbackDispatcher {
 public:
 CallbackDispatcher() {
 dispatcher.connect(sigc::mem_fun(this,
 CallbackDispatcher::on_dispatch));
 }

 typedef sigc::slotvoid Message;
 void send(Message msg) {
 Glib::Threads::RecMutex::Lock lock(mutex);
 queue.push(msg);
 dispatcher();
 }

 private:
 /* CallbackDispatcher may not be copied, so we must hide these
  * constructors. */
 CallbackDispatcher(const CallbackDispatcher);
 CallbackDispatcher operator=(const CallbackDispatcher);

 Glib::Threads::RecMutex mutex;
 std::queueMessage queue;
 Glib::Dispatcher dispatcher;

 void on_dispatch() {
 Glib::Threads::RecMutex::Lock lock(mutex);
 while (!queue.empty()) {
 queue.front()();
 queue.pop();
 }
 }
 };

 class Example {
 private:
 Glib::RefPtrGtk::Application app;
 Gtk::Windowwin;
 Gtk::TextView  tv;
 Glib::RefPtrGtk::TextBuffer  tb;
 CallbackDispatcher callback_dispatcher;
 Glib::Threads::Thread *thread;
 Glib::RefPtrGio::Cancellable cancellable;

 /* Appends str to the textbuffer. Like all methods that use the
  * Gtk namespace, it is not safe to call from another thread. */
 void gui_print_cb(const Glib::ustring str) {
 tb-insert(tb-end(), str);
 }

 /* Provides threadsafe access to gui_print_cb() */
 void gui_print(const Glib::ustring str) {
 sigc::slotvoid slot = sigc::bind(sigc::mem_fun(this,
 Example::gui_print_cb), str);
 callback_dispatcher.send(slot);
 }

/* This function is called on a separate thread so as to avoid
 * blocking GTK+'s main loop.
 */
 void blocking_operation() {
 /* This simulates a blocking process */
 sleep(5);
 gui_print(5% complete.\n);
 if (cancellable-is_cancelled()) return;

 sleep(5);
 gui_print(15% complete.\n);
 if (cancellable-is_cancelled()) return;

 sleep(5);
 gui_print(35% complete.\n);
 if (cancellable-is_cancelled()) return;

 sleep(5);
 gui_print(55% complete.\n);
 if (cancellable-is_cancelled()) return;

 sleep(5);
 gui_print(75% complete.\n);
 if (cancellable-is_cancelled()) return;

 sleep(5);
 gui_print(95% complete.\n);
 if (cancellable-is_cancelled()) return;

 sleep(5);
 gui_print(100% complete.\n);

 /* When the process is finished, we notify the GTK+ Main Loop by
  * using the dispatcher */
 callback_dispatcher.send(sigc::mem_fun(this,
 Example::blocking_operation_finished));
 };

 /* This function is called on GTK+'s main loop via a
  * Glib::Dispatcher */
 void blocking_operation_finished() {
 cleanup_thread();
 gui_print(Operation finished.\n);
 };

 void cleanup_thread() {
 /* We must call Glib::Threads::Thread::join() in order to
  * correctly clean up the resource. */
 if (thread) {
 thread-join();
 

RE: What is the minimum number of lines to update a gui window without user clicking a button

2013-08-20 Thread Incongruous
Iran is not a terrorist country, Israel is.
http://www.youtube.com/watch?v=KLSlmLx4Fls

-Original Message-
From: gtkmm-list [mailto:gtkmm-list-boun...@gnome.org] On Behalf Of L. D. James
Sent: Tuesday, August 20, 2013 9:09 PM
To: Gavin Lambert
Cc: gtkmm-list@gnome.org
Subject: Re: What is the minimum number of lines to update a gui window without 
user clicking a button

On 08/20/2013 08:51 PM, Gavin Lambert wrote:
 Quoth L. D. James:
 And, No.  There aren't any significantly open issues.  The code 
 presented by Alan works perfectly.  It has already been in production 
 with my clients for over a week without a glitch.
 Several people (including myself) have tried to tell you that the code 
 you have posted here thus far is not at all thread-safe and is very 
 likely to explode in your face at some point.  That it appears to be 
 working during your testing is merely coincidental.  (One of the joys 
 of programming with threads, in any language or framework, is that you 
 have to pay very close attention to the data interactions -- it's very 
 easy to write something that appears to work most of the time but will 
 do something very strange in corner conditions.)

 I'm not sure why you seem to be ignoring this.

 I would be glad to implement a gprint() function to ease the flow 
 for some of my other programs/C++ scripts/applications that haven't 
 been implemented with the gui window, as well as some of my future 
 project and overall understanding and learning.  But as I mentioned, 
 I'm reserving that development for a future thread.
 If you look at the most recent example that Andrew Potter posted, that 
 is pretty much exactly your desired gprint() method done in an 
 actually thread-safe manner.


 Regarding your other question, about closing the window freezing up 
 the
 program: this is because the window cannot be closed while the 
 background thread is running, and you should not allow it to do so.  
 If you want to be able to cancel the background operation, then you 
 have to add in code specifically to request that the background 
 operation be cancelled (in a thread safe manner) when the user 
 attempts to close the window, and then wait for it to actually complete 
 running before closing down.


Gavin, I'm not ignoring any suggestions or comments that are coming from 
anyone. I'm here asking for help and responding the best and most respectful 
that I know of. I'm making it clear that I don't understand all the technical 
terms. I'm posting everything I learn and giving any other details that I can 
put into words.

I'm not ignoring any code that is given. I'm working with all the code the best 
that I can. When someone specify something that I should do, but without code 
examples, I'm making it as clear as I can that I'm stuck.

While I'm stuck and have gaps, I'm letting everyone know at which point I 
happen to be.

It's my experience that no form wants someone to just post questions and wait 
for people to give them everything without posting some code of what they are 
working with.

I posted what I have figure out how to compile, that is a perfect working 
example of what I'm trying to do. I mentioned that it's working perfectly and 
the lines are very simple where it's very easy for anyone to quickly compile it 
and look at it. I was thinking about making a video so that the community could 
see what I was trying to do.

If I didn't post it and say it was working perfectly I might keep getting 
questions about more widgets, colors, and other enhancements which, at present, 
I'm not looking for.

I have given Andrew all the praise I can muster up. I realize he has taken a 
lot of time to look at my messages and get a good idea of what I'm trying to 
do. I believe it's working now. When it wasn't I couldn't use it. I could only 
use the best that I could do.

I hope the group is understanding my humble appreciation and sharing what I'm 
learning and trying to do.

Thank you very kindly for your input!

I hope I'm being clear that I'm taking everything in the best way I can. 
I'm an old man and I have gaps, but I'm trying.

-- L. James

--
L. D. James
lja...@apollo3.com
www.apollo3.com/~ljames
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list


RE: What is the minimum number of lines to update a gui window without user clicking a button

2013-08-20 Thread Incongruous
This is why we must not believe these people, terror specialist deliverer.
http://www.youtube.com/watch?v=b4LDQixpCa8

-Original Message-
From: gtkmm-list [mailto:gtkmm-list-boun...@gnome.org] On Behalf Of L. D. James
Sent: Tuesday, August 20, 2013 9:09 PM
To: Gavin Lambert
Cc: gtkmm-list@gnome.org
Subject: Re: What is the minimum number of lines to update a gui window without 
user clicking a button

On 08/20/2013 08:51 PM, Gavin Lambert wrote:
 Quoth L. D. James:
 And, No.  There aren't any significantly open issues.  The code 
 presented by Alan works perfectly.  It has already been in production 
 with my clients for over a week without a glitch.
 Several people (including myself) have tried to tell you that the code 
 you have posted here thus far is not at all thread-safe and is very 
 likely to explode in your face at some point.  That it appears to be 
 working during your testing is merely coincidental.  (One of the joys 
 of programming with threads, in any language or framework, is that you 
 have to pay very close attention to the data interactions -- it's very 
 easy to write something that appears to work most of the time but will 
 do something very strange in corner conditions.)

 I'm not sure why you seem to be ignoring this.

 I would be glad to implement a gprint() function to ease the flow 
 for some of my other programs/C++ scripts/applications that haven't 
 been implemented with the gui window, as well as some of my future 
 project and overall understanding and learning.  But as I mentioned, 
 I'm reserving that development for a future thread.
 If you look at the most recent example that Andrew Potter posted, that 
 is pretty much exactly your desired gprint() method done in an 
 actually thread-safe manner.


 Regarding your other question, about closing the window freezing up 
 the
 program: this is because the window cannot be closed while the 
 background thread is running, and you should not allow it to do so.  
 If you want to be able to cancel the background operation, then you 
 have to add in code specifically to request that the background 
 operation be cancelled (in a thread safe manner) when the user 
 attempts to close the window, and then wait for it to actually complete 
 running before closing down.


Gavin, I'm not ignoring any suggestions or comments that are coming from 
anyone. I'm here asking for help and responding the best and most respectful 
that I know of. I'm making it clear that I don't understand all the technical 
terms. I'm posting everything I learn and giving any other details that I can 
put into words.

I'm not ignoring any code that is given. I'm working with all the code the best 
that I can. When someone specify something that I should do, but without code 
examples, I'm making it as clear as I can that I'm stuck.

While I'm stuck and have gaps, I'm letting everyone know at which point I 
happen to be.

It's my experience that no form wants someone to just post questions and wait 
for people to give them everything without posting some code of what they are 
working with.

I posted what I have figure out how to compile, that is a perfect working 
example of what I'm trying to do. I mentioned that it's working perfectly and 
the lines are very simple where it's very easy for anyone to quickly compile it 
and look at it. I was thinking about making a video so that the community could 
see what I was trying to do.

If I didn't post it and say it was working perfectly I might keep getting 
questions about more widgets, colors, and other enhancements which, at present, 
I'm not looking for.

I have given Andrew all the praise I can muster up. I realize he has taken a 
lot of time to look at my messages and get a good idea of what I'm trying to 
do. I believe it's working now. When it wasn't I couldn't use it. I could only 
use the best that I could do.

I hope the group is understanding my humble appreciation and sharing what I'm 
learning and trying to do.

Thank you very kindly for your input!

I hope I'm being clear that I'm taking everything in the best way I can. 
I'm an old man and I have gaps, but I'm trying.

-- L. James

--
L. D. James
lja...@apollo3.com
www.apollo3.com/~ljames
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list


RE: ONE MORE TIME.

2013-08-20 Thread Incongruous
http://www.youtube.com/watch?v=ZLsrTsITEc4

-Original Message-
From: Gavin Lambert [mailto:gav...@compacsort.com] 
Sent: Tuesday, August 20, 2013 8:55 PM
To: 'Incongruous'
Cc: gtkmm-list@gnome.org
Subject: RE: ONE MORE TIME.

Quoth Incongruous:
 ONE MORE TIME.
 I have clicked on unsubscribed and you keep sending these emails. 
 Let's not get annoying here. I don't want to get nasty, OK?

Posting messages here is not going to help anything, nor would getting nasty.

It is an automated system.  If you are still receiving messages then you are 
not actually unsubscribing correctly.

Go to https://mail.gnome.org/mailman/listinfo/gtkmm-list (the link is at the 
bottom of every email) and use the unsubscribe button at the bottom of the 
page.  Make sure that you use the email address that you actually subscribed 
with in the first place and pay attention to any messages that it shows you.
 


___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list