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
Re: What is the minimum number of lines to update a gui window without user clicking a button
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
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
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: What is the minimum number of lines to update a gui window without user clicking a button
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
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
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
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
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
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
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
RE: What is the minimum number of lines to update a gui window without user clicking a button
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: 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
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();
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
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
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
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: What is the minimum number of lines to update a gui window without user clicking a button
Do you see any technical problems with what I posted? Eventually, yes. It depends on the observed execution speed in your application for example. When would you categorise the situation that a specific graphical user interface becomes unresponsive? Do you expect visual feedback in less than a second for your programs? Do you think you could make it more efficient? There are more aspects to consider besides efficiency. How do you think about to apply the design pattern Model-View-Controller? http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller Then, instead of writing three lines to update the gui window, I'd be able to type: gprint(Updated text); Such a desire is fine until you clarify a few more implementation details. 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
On 08/19/2013 02:28 AM, Markus Elfring wrote: Do you see any technical problems with what I posted? Eventually, yes. It depends on the observed execution speed in your application for example. When would you categorise the situation that a specific graphical user interface becomes unresponsive? Do you expect visual feedback in less than a second for your programs? The program executes. The gui is updated in a faction of a second. If I placed a left a button there as I find in most of the examples it would take longer to see the update because a person can't press a button in less than a faction of a second. But again, my code doesn't experience any delay that I can identify. The output is just as immediate as I can see as if it were output with cout to standard out. As far as you seeing a technical problem, is it possible that you could post some code that would actually work to identify the problem? Also do you see the same problem with the code supplied by Alan and discussed in depth here: https://mail.gnome.org/archives/gtkmm-list/2013-August/msg00052.html I tried to model my code based on what I learned from there and from what Kjell provided, as well as everything I can see in the documentation. I don't understand how it differs from Alan's code except mainly that I change it from the Label widget to a textview widget. I was hoping to have the simplest example so that I could use the example to test various widgets and get a good grip on how to build my own. Do you think you could make it more efficient? There are more aspects to consider besides efficiency. How do you think about to apply the design pattern Model-View-Controller? http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller I studied the link you provided above. I can't say I fully understand it. I had studied it before I asked the group for help, of which I received Alan's example that worked. Then, instead of writing three lines to update the gui window, I'd be able to type: gprint(Updated text); Such a desire is fine until you clarify a few more implementation details. I don't currently know how to implement the gprint() goal. But I'm working on it. When my current position is clean enough for a discussion I will present it in a different thread, unless someone else sees the answer while reading this thread and brings it up. Currently if the lines of code that I have already posted could be improved that would satisfy the namesake of this thread. Of course if I could see some code example of the problem that you're describing with my current code, that would be great! I'd be glad to work with it and see the functionality. But so far all the technical suggestions that I'm getting appears to actually already be implemented in the 47 lines of code that I published. -- 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
As far as you seeing a technical problem, is it possible that you could post some code that would actually work to identify the problem? Your function HelloWorld::cpp_app indicated in this example that it will execute for some seconds. I got doubts that the graphical user interface will be as responsive as you might expect it. A well-known approach is to perform long lasting data processing in a dedicated thread which is separate from the one which serves the user interface. You need to be very careful with synchronisation so that you avoid thread-unsafe data accesses. http://en.wikipedia.org/wiki/Synchronization_%28computer_science%29 I can't say I fully understand it. Do you like a different description about GUI architectures? http://martinfowler.com/eaaDev/uiArchs.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
On 08/19/2013 05:22 AM, Markus Elfring wrote: As far as you seeing a technical problem, is it possible that you could post some code that would actually work to identify the problem? Your function HelloWorld::cpp_app indicated in this example that it will execute for some seconds. I got doubts that the graphical user interface will be as responsive as you might expect it. A well-known approach is to perform long lasting data processing in a dedicated thread which is separate from the one which serves the user interface. You need to be very careful with synchronisation so that you avoid thread-unsafe data accesses. http://en.wikipedia.org/wiki/Synchronization_%28computer_science%29 Thanks, Markus. While I can't understand what you're suggesting, I really appreciate the input as well as the specifics. I have all the documentations that the users from the list has given me. I'm studying all of it. It's a lot for a novice. But I'm not taking any of it light. Most of the details don't have examples that I can test and I'm spending a lot of time cross referencing trying to understand the terms in the technical documentations. As far as the function executing for some seconds, it executes for fractions of a second, minutes, hours, perfectly totally as I expect as well as totally as desired. As far as I can see, the function that you picked out is the exact function that was provided to me by Alan, and discussed by a number of the professionals in this mail list as being functional. The only difference as I can see is the name. I took Alan's code and tried to learn it in such that I could rewrite it and give descriptive names according to what I was looking for the function to do. I also changed the widget from label to textview. Can you tell me what is different between the two functions: My example: HelloWorld::cpp_app Alan's example: myLabel::myprocess1 By the way, I left the HelloWorld part because I was trying to keep it as consistent with the example in the documentation tutorial as possible. The class and function names are different in my actual application. I'm able to make this differences because (I thought) I had come to understand what Kjell and Alan had given me. I'm not good enough to read the highly technical links that you're providing me with to make radical changes to the code at this point. Kjell recognized the tutorial conatains a chapter on multi-threaded programs (from this message: New multi-threaded example program in the gtkmm tutorial: https://mail.gnome.org/archives/gtkmm-list/2013-August/msg00055.html He indicated that it lacked an example. The lack of example makes it hard for a novice to grasp (as in my case). So after Alan's assistance, which actually resolved my issue, Kjell added a tutorial with an example, which I tried to model my code after. If there is a difference between Alan's code and my updated version, I'd appreciate knowing the difference. I still wouldn't be able to change it without an example of the specific lines that would fix it. Any changes that I made will actually brake the code and the gui window would lost it's responsiveness, or not display at all. This was happening when I simply tried to change Alan's code from a label widget to a textview widget. The lost of functionality was the purpose of this thread. I was hoping to see the bare essentials. I thought, after many hours that I had found the key (studying Alan's and Kjell's examples). I'm studying in detail the links that you're providing, but I can't see from those links what specific I should change and still have the code function as desired. -- L. James -- L. D. James lja...@apollo3.com www.apollo3.com/~ljames I can't say I fully understand it. Do you like a different description about GUI architectures? http://martinfowler.com/eaaDev/uiArchs.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
I'm studying in detail the links that you're providing, but I can't see from those links what specific I should change and still have the code function as desired. I'm curious when you start playing around with software design extensions for your small program example. ;-) 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
On 08/19/2013 11:50 AM, Markus Elfring wrote: I'm studying in detail the links that you're providing, but I can't see from those links what specific I should change and still have the code function as desired. I'm curious when you start playing around with software design extensions for your small program example. ;-) Regards, Markus I don't know what you mean by design extensions. But I started out programming in assmebly language in the Late 70's. I went to C in the early 80's. It was all in DOS, not Windows. In the late 90's I started using a semi graphical interface by programming perl CGI. I also started using Visual C++ and the MFC environment around that time. Maybe it's the MFC that you're referring to in playing around with software design extensions. For MFC in Visual Studio you basically just draw a box, then output your text to that box with a single line (much like the gprint function I want to design for gtkmm/C++). In around 2005 I started programming in Java (no gui). Then around 2010 I started programming in Java GUI. In 2011 I started programming for the Android. The interface basically used a screen for drawing the window, then a single line to update the text in the window. I started doing the same with Java Applications and Java Applets early this year. Last month I started trying to do the same thing that I was doing with Java (Applications, Applets, and the Android) with C++ via Gtkmm... thus hear I am. So, I'm not new to programming, but playing around with software design extensions is probably something new. Somewhere in between those stages I played with python, mono, and a few other languages. But I never did much productive work, just experiments with them. All the others has easy ways of updating the gui window. At first Gtkmm appeared to be the only interface that didn't have an easy way to update the gui window with new text. The more I play with it, the more it appears to be rather easy. I don't believe it's as complicated as many appears to be saying it is. Looking at most of Alan's messages I believe he gave me most of the code from his phone while he was traveling. A couple of times he asked me to wait a couple of days while he got to his computer so the he could run some test. So, most likely the best answer is that I'm just starting out, playing with software design extensions... maybe in the most definitive terms, I might not have quiet started out yet. I'm mainly just using the simple lines of code provided to me by Alan and Kjell and sending text to the gui window. At present it's working perfectly. Basically I just want to display text to my clients in some manner that it doesn't appear as if the OS is broken. Most of the times when I ask a client to read to me what they see, when they see a black screen, they say they don't see anything. It takes a while for them to realize the black screen has usable information. I'm starting to send the same text to a graphical window. My clients has no problems reading that screen and relating to me what they see. -- 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
On 19/08/2013 19:38, L. D. James wrote: I'm not new to programming, but playing around with software design extensions is probably something new. Somewhere in between those stages I played with python, mono, and a few other languages. But I never did much productive work, just experiments with them. All the others has easy ways of updating the gui window. At first Gtkmm appeared to be the only interface that didn't have an easy way to update the gui window with new text. The more I play with it, the more it appears to be rather easy. I don't believe it's as complicated as many appears to be saying it is. Although it won't help you directly with gtkmm, I would HIGHLY recommend you to buy Andrew Krause's book Foundations of GTK+ development. I came from a background with MFC and quite frankly, I found GTK+ to be plain weird after the simplicity of MFC. However I found it much easier to understand GTK+ after reading Andrew's excellent book. Any good technical bookshop should be able to get it for you. John ___ 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
I don't know what you mean by design extensions. I find that strange to some degree ... But I started out programming in assmebly language in the Late 70's. I went to C in the early 80's. It was all in DOS, not Windows. In the late 90's I started using a semi graphical interface by programming perl CGI. I also started using Visual C++ and the MFC environment around that time. I assume that you are used to the selection and application of design patterns if you mention such a long software development experience. http://en.wikipedia.org/wiki/Software_design_pattern Most of the times when I ask a client to read to me what they see, when they see a black screen, they say they don't see anything. It takes a while for them to realize the black screen has usable information. How do you think about any fine-tuning for text colours in your log console? Might a Curses-based user interface also be sufficient for your use case? http://en.wikipedia.org/wiki/Curses_%28programming_library%29 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
On 08/19/2013 04:18 PM, Markus Elfring wrote: I don't know what you mean by design extensions. I find that strange to some degree ... I've mentioned numerous times that I have some glitches in my experience. I never took up formal education in programming. I studied business and accounting in college. I'm self taught in programming. While I'm self-taught, I do tutor college students who has come to me, often, when they were failing and getting D's. With my assistance it always changes to A's. The owner of one of the most prominent entities on the web was tutored by me. But, yes. I have some real glitches. Some of the gaps are being filled in by the discussions of the threads I have started in this maillist. But I started out programming in assmebly language in the Late 70's. I went to C in the early 80's. It was all in DOS, not Windows. In the late 90's I started using a semi graphical interface by programming perl CGI. I also started using Visual C++ and the MFC environment around that time. I assume that you are used to the selection and application of design patterns if you mention such a long software development experience. http://en.wikipedia.org/wiki/Software_design_pattern Thanks for the definition of software design pattern. And based on what I have just read, I have been using it. I just never used the term. I also promote this in my tutoring. I'm sure it's a component of software design pattern of which the namesake of this thread is about. I have a goal of easily updating a gui window with new text. While that code is working fine (as provided by Alan), I still look forward to implementing a gprint function to consolidate 3 lines into one line. The code to do that might take months and end up being a couple of hundred lines. Just as, I haven't explored the code involved in the function, cout, but I'd be surprised if it's less than a couple of hundred lines. The namesake of this thread is to first understand how to actually achieve an update to the gui window, of which I published the code. You're saying it's broke. While it appears to work perfectly in every way, I'd be glad to see some code that I could test that wouldn't be broken according to your expertise. I sincerely appreciate the jargon that I'm learning in the meantime. Most of the times when I ask a client to read to me what they see, when they see a black screen, they say they don't see anything. It takes a while for them to realize the black screen has usable information. How do you think about any fine-tuning for text colours in your log console? Might a Curses-based user interface also be sufficient for your use case? http://en.wikipedia.org/wiki/Curses_%28programming_library%29 Every thing you mention can be an enhancement. The examples in the gtkmm documentation has lots of font controls, word wrappings, window scrolling and many other features. The examples were rather confusing for me as a beginner. 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. I'd appreciate some validation from you if I have gotten it right (to be able to append text to a blank window), or an example that you consider more right than the code assistance I currently have from Alan. I haven't experimented with colors, but I did very easily change the fonts. I'm sure changing the colors would be just as easy. My main reason for switching from the label widget of the original code from Alan to the textview widget is because in my research it appeared that font and text output manipulation was easier with the textview widget. 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
On 08/19/2013 05:57 PM, Andrew Potter wrote: I've changed Example 4 to use a TextView instead of a Label and renamed report_progress() to gui_print(). Thanks, Andrew. Your gui_print() function appears to be exactly what I was trying to accomplish in my next stage. At present I'm working with it to make it append the text rather than replace the text displayed. I really appreciate your taking the time to understand the question. -- 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
Quoth Andrew Potter:
void gui_print(const Glib::ustring str) {
/* Get a function pointer to the set_text method we want to
* use. We must explicitly declare the method pointer
* signature because Gtk::TextBuffer::set_text is an
* overloaded method. */
void (Gtk::TextBuffer::*fptr)(const Glib::ustring) =
Gtk::TextBuffer::set_text;
/* Create a functor that points at the TextBuffer method we
* want to use. Because tb is a Glib::RefPtr and sigc::mem_fun
* needs the actual Gtk::TextBuffer object, we must use
* operator-(). See GNOME Bugzilla #495762. */
sigc::slotvoid, const Glib::ustring set_text_functor =
sigc::mem_fun(tb.operator-(), fptr);
/* Bind the arguments of the functor to create a
* sigc::slotvoid that can be sent to the callback
* dispatcher.
*/
sigc::slotvoid bound_functor = sigc::bind(set_text_functor,
str);
/* callback_dispatcher can execute any sigc::slotvoid on the
* Main Loop. Since we have one now, send it.
*/
callback_dispatcher.send(bound_functor);
}
Given that sigc magic is hard for many people, you might want to simplify
this with a helper method:
// Called from the blocking operation in the worker thread
void gui_print(const Glib::ustring str) {
sigc::slotvoid, const Glib::ustring print_functor =
sigc::mem_fun(this, Example::gui_print_ui);
sigc::slotvoid bound_functor = sigc::bind(print_functor, str);
callback_dispatcher.send(bound_functor);
}
// Called on the UI thread when the worker thread calls gui_print
void gui_print_ui(const Glib::ustring str) {
tb-set_text(str);
}
This would make it easier for people to modify the actual action taken in
gui_print_ui.
___
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
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
___
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
I have unsubscribed from this list, please delete me from the list.
-Original Message-
From: gtkmm-list [mailto:gtkmm-list-boun...@gnome.org] On Behalf Of Andrew
Potter
Sent: Monday, August 19, 2013 7:08 PM
To: L. D. James
Cc: gtkmm-list@gnome.org
Subject: Re: What is the minimum number of lines to update a gui window without
user clicking a button
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
___
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
You're right about my desire to log text in a gui window. I don't want a list box or control widgets in this particular case. As far as sophisticate widgets, I don't want any widgets at all. There might still be a few more technical details which you would like to consider for your log viewer implementation. If there's something wrong with my example, I appreciate any comments or suggestions. But if someone says it wrong and use programming terms that I don't fully understand, it's not much I can do with it as far as change and actually have it continue to perform the desired task (update the gui window after running a function). How do you think about a message display in several log windows from one application in parallel? How do you keep the graphical user interface responsive during this output? http://c2.com/cgi/wiki?EventDrivenProgramming 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
On 08/18/2013 01:48 PM, Markus Elfring wrote: You're right about my desire to log text in a gui window. I don't want a list box or control widgets in this particular case. As far as sophisticate widgets, I don't want any widgets at all. There might still be a few more technical details which you would like to consider for your log viewer implementation. If there's something wrong with my example, I appreciate any comments or suggestions. But if someone says it wrong and use programming terms that I don't fully understand, it's not much I can do with it as far as change and actually have it continue to perform the desired task (update the gui window after running a function). How do you think about a message display in several log windows from one application in parallel? How do you keep the graphical user interface responsive during this output? http://c2.com/cgi/wiki?EventDrivenProgramming Regards, Markus Thanks, Markus. Since I describe myself as novice to some of this technical jargon you probably think I'm not clear with what I'm looking for. But I actually am. The example that I posted is very consistent with the namesake of this thread. I'm hoping to have the minimum number of lines to update a gui window without the user having to do anything but just periodically look at the screen and notice the updates. Now since I appear to have the minimum (in my example), which performs perfectly. If you analyze it, I believe it'll become clearer what my question is about. Having the minimum lines will help me to study in more detail and understand better what is taking place. Do you see any technical problems with what I posted? Do you think you could make it more efficient? I'm sure, with time, I'll be able to. One of the things I would like to do is turn this lines into one line: // Code Begin // -- texttoprint += Back from running a short 10 second function; m_refTextBuffer-set_text(texttoprint); m_textview.set_buffer(m_refTextBuffer); // -- // Code end Of course I expect this will take a significantly lots more programming lines to make such a class or function. But in the end it'll make using gtk a lot easier for many applications. I hope to create a class or function that could be called and would either append or replace the text being displayed. The function could be called, gprint(). Then, instead of writing three lines to update the gui window, I'd be able to type: gprint(Updated text); And have the text updated that way. Thanks again for your input and your attempts to understand my question. Again, I believe the current question is answered with the last code I posted, unless you see a problem with it. After I have a good clean example of my attempt to create the gprint() class or function, I'll post that and ask for help. -- 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
On 08/15/2013 08:30 AM, Markus Elfring wrote:
You are telling me to do it a different way and at the same time telling me
how complicated it is. Without examples of the different way, I don't know
where to start.
I guess that you want to become familiar with a general program structure
together with the GTK+ software. I assume that you want to display some text in
a log window for your use case. Would you like to reuse a list box or table
control? (Do you need any other higher sophisticated widget?)
How fast do you get the needed data for the desired output?
Regards,
Markus
Hi, Markus.
Thanks for the interest and your questions. I appreciate any feedback.
You're right about my desire to log text in a gui window. I don't want
a list box or control widgets in this particular case. As far as
sophisticate widgets, I don't want any widgets at all.
I wouldn't mind an exit or close button, but at present the close button
in the gui window (along with the minimize button) suits my immediate
needs perfectly.
I had already got a developed a working example with the help of Alan:
Gui Update using the Label Widget:
https://mail.gnome.org/archives/gtkmm-list/2013-August/msg00052.html
It worked perfectly as desired... having only one widget, the label.
However, I decided to change the label widget to the textview widget.
When I tried to change it, the code was broken at first, because I
didn't fully understand what needed to be changed.
So, with this thread, I asked for the minimum amount of lines to do the
same thing, so that I could study the lines and use it as a blank slate
to build upon.
I eventually started to understand it, with the aid of the input from
Kjell and change the widget from label to textview.
Now with the 47 lines of code I'm easily able to update a gui window.
Wile, Chris has insisted there is a problem with the code, I can't
identify a problem. As far as I can see it is exactly consistent with
the HelloWorld tutorial that uses a Button widget. I changed the branch
that happens with a button click to go directly to the function. I
basically renamed the function from void on_button_clicked() to void
cpp_app().
It's only 47 lines and should be very easy to check. I can't identify a
problem with it. It does perfectly what I was trying to do.
With it having such a few lines I'm able to study each line in detail
and easily repeat the code.
I'll eventually start to add other sophisticated widgets for other
applications. This is easier to do now since I have what I believe is
the minimum amount of lines to update text to a gui window.
If there's something wrong with my example, I appreciate any comments or
suggestions. But if someone says it wrong and use programming terms
that I don't fully understand, it's not much I can do with it as far as
change and actually have it continue to perform the desired task (update
the gui window after running a function).
The current cleaned up code is:
(By the way my programming environment is Ubuntu 13.04/Gtkmm3.0 from the
repository)
// Code begin: HelloWorld.cpp
//
#include HelloWorld.h
#include string
using namespace std;
HelloWorld::HelloWorld() : m_textview() {
add(m_textview);
m_textview.show();
Glib::Thread::create(sigc::mem_fun(*this, HelloWorld::cpp_app), true);
}
HelloWorld::~HelloWorld() {
}
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
// This represents the resulting text from the function just run
texttoprint += Back from running a short 10 second function;
m_refTextBuffer-set_text(texttoprint);
m_textview.set_buffer(m_refTextBuffer);
sleep(60); // This is an example of a function that is responding
with text
texttoprint += Just got back from a function that took a minute to
execute.\n;
m_refTextBuffer-set_text(texttoprint);
m_textview.set_buffer(m_refTextBuffer);
}
//
// Code end
// Code begin: HelloWorld.h
//
#ifndef GTKMM_EXAMPLE_HELLOWORLD_H
#define GTKMM_EXAMPLE_HELLOWORLD_H
// #include gtkmm/button.h
// #include gtkmm/window.h
#include gtkmm.h
class HelloWorld: public Gtk::Window {
public:
HelloWorld();
virtual ~HelloWorld();
protected:
//Signal handlers:
// // void on_button_clicked();
//Member widgets:
Gtk::TextView m_textview;
void cpp_app();
};
#endif // GTKMM_EXAMPLE_HELLOWORLD_H
//
Re: What is the minimum number of lines to update a gui window without user clicking a button
You are telling me to do it a different way and at the same time telling me how complicated it is. Without examples of the different way, I don't know where to start. I guess that you want to become familiar with a general program structure together with the GTK+ software. I assume that you want to display some text in a log window for your use case. Would you like to reuse a list box or table control? (Do you need any other higher sophisticated widget?) How fast do you get the needed data for the desired output? 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
On 08/12/2013 12:55 AM, Gavin Lambert wrote: Quoth L. D. James: Thanks Gavin I'm glad that your message suggests that I may have done something right. I have tried. I appreciate your pointing out about bugs in gtkmm. I'm sure with my investigation I'll eventually learn about the bugs and try to assist in the debugging of it, as well as other compoentns that fall short. What? How did you possibly read that from what I said? The code that you wrote has a bug. There is nothing wrong with GTK or GTKMM, you're just using it wrong. You are creating a secondary worker thread. In that worker thread you are accessing a GUI widget. You can't do that. Not being able to do that is not a bug; trying to do it anyway is. Since you think everyone is telling me something different, I'll follow your suggestion and reread the thread and keep studying the thread to see where I'm going wrong. I understand I might be missing something, but at present if I can't see it, I can only report on the results and appreciate any further comments. So far everyone has been saying the same thing, just phrased differently. It appears however that you have not yet understood any of those suggestions. I even explicitly told you what you should be doing instead (using a queue with a mutex and a Dispatcher), which is the same thing that Andrew Potter suggested that you try last week (with a code example, no less). You appear to be telling me to study and use gtk rather than gtkmm. I fear that if I did that and tried to post something, I might be admonished even more for not using gtkmm which this forum is about, and reinventing the wheel. I'll take your advise and start studying gtk, but I'll be very leery to start creating my own interface when you describe it so complicated that it's broken in gtkmm which has been in the development for a number of years. No, that is not what I was suggesting. I was saying that you should first learn how multithreading works in general. Then how multithreading works in GTK+/GTKMM (since the two are basically the same thing, just with different syntactic sugar). And only then try to apply it to your application. I appreciate your constantly admonishment of my lack on knowledge. I hope you appreciate that I am taking the time to study the terminology that you are tossing around. Your message suggests that I'm taking it lightly. I'm not. Please be advised that I'm spending sleepless nights trying to learn the terminology. I'm posting my messages to learn. I'm asking for code examples and working hard trying to compile them. Everything that comes close to doing something, I'm working with it trying to use it. I'm explaining where the code fails and doesn't work in my case. So far in the two treads Alan has given me something that works, of which the code snippet that I posted was modeled after in every way that I can imagine does what is needed. Kjell posted an example and description that does what I have been trying to do. He accepted with respect my reference that I couldn't use it because when I removed the unwanted parts it was broken. I inadvertently would remove crucial parts and didn't know how to fix it without putting it back exactly the way it's written and trying again. He showed a lot of respect for my references, except a little admonishment for talking too much. I'm continuously scolded for talking too much. But at the same time I'm basically saying what you are saying. I don't understand a lot, and a lot of the reading and studying that I'm doing is blurred because of my lack on knowledge. I'm asking questions and trying to fill in the gaps. Many messages appears to be telling me that I'm trying to do something that is very complicated, using terminology that I don't understand and posting code snippets that doesn't do the task.. as I mentioned, the examples that doesn't hang don't update the gui window between sleep() functions. You're mentioning other components of gtk and gtkmm that I should implement, components of which I have no idea where to begin and telling me to go out and study. Are you saying don't do anything in the meantime? If it's as complicated as you suggest, that might take years. I hope you appreciate that I need something in the meantime. Using something in the meantime while I continue to study is helping me to get some type of grip. Kjell told me that I was free to remove everything from his code except for a single entry: ( https://mail.gnome.org/archives/gtkmm-list/2013-August/msg00086.html ) // quote from Kjell -- Since you dislike buttons, can't you remove all buttons and the button box from my example program? Remove all code that has anything to do with the buttons except // Start a new worker thread. m_WorkerThread = Glib::Threads::Thread::create( sigc::bind(sigc::mem_fun(m_Worker, ExampleWorker::do_work), this));
Re: What is the minimum number of lines to update a gui window without user clicking a button
2013-08-11 02:30, L. D. James skrev: Thanks, Chris. I may end up using Glib::spawn_async (but I it doesn't appear to be a call for updating text to a gui window) and I may end up using Glib::signal_io().connect()) to send text to the gui window. This is the first time i see these as ways of updating the gui. Keep in mind that what I'm trying to do is develop a reusable function that I have named, gprint(). I'm sure I'm just about close enough to post a prototype by tomorrow. Thanks again for all your contributions, and patient for my newness with using a gtkmm widgets. My only problem with Kjell's example if being able to remove the unwanted ones. My problem with Alan's solution (which worked perfect) was changing it from label to textview (because of some gaps I was having at the time). I finally got it figured out how to change the widget from label to text view, now I'm trying to implement the gprint() function. I have it in place, but it's not clean enough to post it for comments yet. -- L. James -- L. D. James lja...@apollo3.com mailto:lja...@apollo3.com www.apollo3.com/~ljames You seem convinced that the shorter a program is, the easier it is to understand it. I'm not so sure. I get the impression that you don't understand how a GUI system works, Much work is going on behind the scene. An example: When you call m_TextView.get_buffer()-set_text(Hello world!), the text is stored somewhere, the TextView is invalidated (marked that it shall be redrawn), but the text is *not* written to the screen. That's done later, after your function has returned. If your window is later hidden because another window is moved on top of it, and your window is then still later made visible again, the TextView is once again redrawn without your function being called. It your function contains a long calculation, taking minutes or hours, your window is not redrawn. The best way to avoid that is, like several people have mentioned, to create a separate thread of execution for the long calculation. You are trying to learn two interesting but rather difficult techniques, GUI programming and multi-threading, at the same time and mixed up. Well, GUI programming is not always difficult. It becomes more difficult when your application also needs multi-threading. I wish I could point out some good web sites for you to start with. I'm sure there are some, but I don't know where. There is of course the gtkmm tutorial, https://developer.gnome.org/gtkmm-tutorial/stable/, but it does not explain what's going on behind the scene in a GUI system. I once learnt that by reading Programming Windows by Charles Petzold. It's an excellent introduction to MS Windows programming in C, but it's not the book to read when you want to learn gtkmm. The description of glib's main event loop, https://developer.gnome.org/glib/stable/glib-The-Main-Event-Loop.html, is definitely not written for beginners. Since you dislike buttons, can't you remove all buttons and the button box from my example program? Remove all code that has anything to do with the buttons except // Start a new worker thread. m_WorkerThread = Glib::Threads::Thread::create( sigc::bind(sigc::mem_fun(m_Worker, ExampleWorker::do_work), this)); which you move to ExampleWindow's constructor. And you can change the loop in ExampleWorker::do_work() to make it run forever, if you like. Kjell ___ 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
On Sun, 2013-08-11 at 13:54 +0200, Kjell Ahlstedt wrote: You seem convinced that the shorter a program is, the easier it is to understand it. I'm not so sure. I get the impression that you don't understand how a GUI system works, Much work is going on behind the scene. An example: When you call m_TextView.get_buffer()-set_text(Hello world!), the text is stored somewhere, the TextView is invalidated (marked that it shall be redrawn), but the text is not written to the screen. That's done later, after your function has returned. If your window is later hidden because another window is moved on top of it, and your window is then still later made visible again, the TextView is once again redrawn without your function being called. It your function contains a long calculation, taking minutes or hours, your window is not redrawn. The best way to avoid that is, like several people have mentioned, to create a separate thread of execution for the long calculation. You are trying to learn two interesting but rather difficult techniques, GUI programming and multi-threading, at the same time and mixed up. Well, GUI programming is not always difficult. It becomes more difficult when your application also needs multi-threading. I wish I could point out some good web sites for you to start with. I'm sure there are some, but I don't know where. There is of course the gtkmm tutorial, https://developer.gnome.org/gtkmm-tutorial/stable/, but it does not explain what's going on behind the scene in a GUI system. I once learnt that by reading Programming Windows by Charles Petzold. It's an excellent introduction to MS Windows programming in C, but it's not the book to read when you want to learn gtkmm. The description of glib's main event loop, https://developer.gnome.org/glib/stable/glib-The-Main-Event-Loop.html, is definitely not written for beginners. Since you dislike buttons, can't you remove all buttons and the button box from my example program? Remove all code that has anything to do with the buttons except // Start a new worker thread. m_WorkerThread = Glib::Threads::Thread::create( sigc::bind(sigc::mem_fun(m_Worker, ExampleWorker::do_work), this)); which you move to ExampleWindow's constructor. And you can change the loop in ExampleWorker::do_work() to make it run forever, if you like. Kjell Thanks, Kjell. I might not be as out of it as I appear. I totally am not convinced that the shorter a program is, the easier it is to understand. A program will often be much easier to understand if it had more components in it build up. An example of my understanding that it's more common to be the opposite of what I'm specifically asking for in this thread, the second of the examples are easier for a novice to understand. // code example 1a begin // -- str =+ New text appended; // -- // code example 1a end // code example 1b begin // -- str = str + New text appended; // -- // code example 1b end I started to show two or three examples to let you know that I agree with you on this. I asked for a minimum amount of program lines for the operation to fill in a gap in my current understanding. When a person is learning something new, there will often be gaps in his mind where he might try to have an opportunity to ask the teacher or another student how such a component fits. In this case, I ask to see a minimum amount of lines that will display text to a window, and programmable be able to do something else, then come back and update that display. Also, I don't have a thing against buttons or any of the widgets. I will eventually be using lots of widgets and lots of buttons. I'm kind of trying to get grip of having a blank slate, then building upon it, the widgets of my choice. There are lots of examples in the documentations and sample lists that has many widgets included. At present, when I remove the widgets to start with a blank slate so that I can add the widgets of my choice the example gets broken. I'm having problems starting out with a blank slate. Most of the Helloworld widgets starts out with the Hellow World text on a button. I did that immediately and have no problems with it. I actually spent a lot of time trying to change that button to a textvew widget, but couldn't get it done. When I started working with a textview widget, I had problems, so I started out with a label widget. I figured I'd come back to the text view when I could just output some test, then append to it. I finally got past that hurtle. Then I was trying to change my label widget to a textview widget of which I could append to. I'm able to do it with ease after all the word I have been doing in the past few days, especially yesterday. I'll update an example of what I was trying
Re: What is the minimum number of lines to update a gui window without user clicking a button
On 08/11/2013 07:54 AM, Kjell Ahlstedt wrote: Since you dislike buttons, can't you remove all buttons and the button box from my example program? Remove all code that has anything to do with the buttons except // Start a new worker thread. m_WorkerThread = Glib::Threads::Thread::create( sigc::bind(sigc::mem_fun(m_Worker, ExampleWorker::do_work), this)); which you move to ExampleWindow's constructor. And you can change the loop in ExampleWorker::do_work() to make it run forever, if you like. Kjell Kjell. Thanks again for your input. I have been dissenting your example and still am. I misunderstood some of the full gist of this quote. I mis-read can't to mean I couldn't remove the buttons and still have your code function. That was the case I was already having. But I see you're suggesting for me to remove the buttons and everything that I don't need and showing me the minimum. I'll try this and see if I can get the code to work. This is totally consistent with what I'm trying to do, and the namesake of this thread. I'm still having some problems following the essentials of the examplewindow.cc and the exampleworker.cc parts. But I believe I'm getting there! Of course your reference to where to put my code ExampleWorker::do_worker() clears up a lot. 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
On Sun, 11 Aug 2013 08:33:18 -0400 L. D. James lja...@apollo3.com wrote: [snip] I appreciate all the tips from all the experts here. However, I can tell from many of the comments that a lot of you are thinking I'm trying to do something different that just learn how to work with a blank window and add text to it. I think we all understand that perfectly well. The problem you seem to have difficulty in accepting is that you have to find a way of doing that within the GUI's main loop. The numerous responses you have received have all been for the purpose of showing you how to do this. What your headline console test case does is launch a process using popen() and then read its stdout in blocking mode and print it to the console. You have two choices when faced with doing an equivalent to this with a GUI: 1. Launch the child process asynchronously and connect that process's file descriptors to your main loop. I suggested this, and pointed to the tools glib provides for the purpose, which you thought inadequate for your purposes. However, it is by far the easiest way to do it because it avoids threads. 2. Launch the child process synchronously as your console application does. This requires starting a new thread to carry out the blocking operations and finding some mechanism (which could be Glib::Dispatcher or which could more easily, if it is only text, be a pipe) to convey in a thread-safe way the information you want to convey from the new thread to the main loop thread. What I have said is true of any common GUI system which runs its own main loop, whether GTK+, Qt or Windows. Until you grasp the concept of this you are going to struggle. You will end up programming by coincidence and bafflement. There is no need to respond to this post. But it does set out what your two options are. Chris ___ 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
On 08/11/2013 09:54 AM, Chris Vine wrote: On Sun, 11 Aug 2013 08:33:18 -0400 L. D. James lja...@apollo3.com wrote: [snip] I appreciate all the tips from all the experts here. However, I can tell from many of the comments that a lot of you are thinking I'm trying to do something different that just learn how to work with a blank window and add text to it. I think we all understand that perfectly well. The problem you seem to have difficulty in accepting is that you have to find a way of doing that within the GUI's main loop. The numerous responses you have received have all been for the purpose of showing you how to do this. What your headline console test case does is launch a process using popen() and then read its stdout in blocking mode and print it to the console. You have two choices when faced with doing an equivalent to this with a GUI: 1. Launch the child process asynchronously and connect that process's file descriptors to your main loop. I suggested this, and pointed to the tools glib provides for the purpose, which you thought inadequate for your purposes. However, it is by far the easiest way to do it because it avoids threads. 2. Launch the child process synchronously as your console application does. This requires starting a new thread to carry out the blocking operations and finding some mechanism (which could be Glib::Dispatcher or which could more easily, if it is only text, be a pipe) to convey in a thread-safe way the information you want to convey from the new thread to the main loop thread. What I have said is true of any common GUI system which runs its own main loop, whether GTK+, Qt or Windows. Until you grasp the concept of this you are going to struggle. You will end up programming by coincidence and bafflement. There is no need to respond to this post. But it does set out what your two options are. Chris Thanks, Chris. I learned from my previous thread how to actually update the gui window. I agree that I don't have the terminology to put it into technical words how it's done. But that part is very simple. I believe you're still trying to answer that question in this new thread. I believe you think that I'm ungrateful for not changing to the conversation. You're also responding to an example I showed you about sending something to the console. You're trying to change the discussion to how to best react with the system, since the few lines of a 500 line program had a system call in it. I appreciate also that part of the discussion. But I have already mentioned that I have 10's of programs. That particular example that I should is the only popen() call in all my 10's of C++ program. If I spent a lot of time on using gtkmm to replace that call, I'm still lost with my question of how to update a gui window. I'm just trying to stay focus on this. I understand that you might have reasons for not wanting to discuss that part of my question. It might be too basic for you, or it might be to complex for you to fill that you can relate it to me. But outputing and updating a gui window is what I'm hoping to have addressed by people willing to help, such as Kjell's references in the threads. The gui output part, while described as being very complicated, I have learned from the previous thread is actually simple. At present I'm trying to learn how to apply that simplicity to Kjell's example. I believe responding to Kjell's recent message might help me to clarify where I'm stuck. I'm actually trying to figure out how to blank out everything that I won't be using in the simplest example that will allow me to have a textview window and at will, append to it. I have it working at this time. I'm trying to clean up my example and share it with the group, and hopefully get some educated opinions on how to clean it up. I really appreciate you taking the time that you're taking to try to help. I don't take any message or any suggestion lightly. But again, some of them are not focus directly on the actual point where I'm having problems, and I'm just trying to be clear. You don't have to respond. But when I post my updated code before the day is over, I'd appreciate all the input I can get. -- 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
On Sun, 11 Aug 2013 10:18:59 -0400 L. D. James lja...@apollo3.com wrote: I learned from my previous thread how to actually update the gui window. I agree that I don't have the terminology to put it into technical words how it's done. But that part is very simple. I believe you're still trying to answer that question in this new thread. I believe you think that I'm ungrateful for not changing to the conversation. To be quite honest, I have no idea what you are talking about. However, whatever else I think, be assured I do not think you are ungrateful. Chris ___ 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
I thank everyone who has contributed to this topic and assisted with
your valuable suggestions and comments. As a result I'm able to present
the solution to my problem. Kjell's input was of paramount value.
I used the first helloworld example from the gtkmm tutorial and added
just a few lines and was able to easily update the graphic window with
new text. This example took 68 lines.
I replaced the button widget with the textview widget. Added the thread
signal as suggested by Kjell. Then added my personal c++ function
(cpp_app).
I included a second example with uses a system call function which
displays the content of the root directory. This is exactly what I was
trying to do. Output/append the results of my functions to the gui
screen (or the console or both).
I have two more questions, of which I'll take some time to study and try
to figure out a clear and definitive way of asking.
The code is below. I didn't delete the orginal HelloWorld lines from
the example. I commented out the unneeded lines.
The last code section (of the 4) is an inclusion a system call function
which displays the content of the root directory. This is exactly what
I was trying to do. Output/append the results of my functions to the
gui screen (or the console or both).
// code begin example (main.cc)
// --
//
#include HelloWorld.h
#include gtkmm/main.h
int main (int argc, char *argv[])
{
Gtk::Main kit(argc, argv);
if (!Glib::thread_supported())
Glib::thread_init();
HelloWorld helloworld;
//Shows the window and returns when it is closed.
Gtk::Main::run(helloworld);
return 0;
}
--
// code end
// code begin example (HelloWorld.h)
// --
#ifndef GTKMM_EXAMPLE_HELLOWORLD_H
#define GTKMM_EXAMPLE_HELLOWORLD_H
// #include gtkmm/button.h
// #include gtkmm/window.h
#include gtkmm.h
class HelloWorld : public Gtk::Window
{
public:
HelloWorld();
virtual ~HelloWorld();
protected:
//Signal handlers:
// // void on_button_clicked();
//Member widgets:
Gtk::TextView m_textview;
void cpp_app();
};
#endif // GTKMM_EXAMPLE_HELLOWORLD_H
// --
// code end
// code begin example (HelloWorld.cpp)
// --
#include HelloWorld.h
#include iostream
#include string
using namespace std;
HelloWorld::HelloWorld() :
m_textview() // creates a new button with label Hello World.
{
// Sets the border width of the window.
// // set_border_width(10);
// When the button receives the clicked signal, it will call the
// on_button_clicked() method defined below.
// // m_button.signal_clicked().connect(sigc::mem_fun(*this,
// //HelloWorld::on_button_clicked));
// This packs the button into the Window (a container).
add(m_textview);
// The final step is to display this newly created widget...
m_textview.show();
Glib::Thread::create(sigc::mem_fun(*this, HelloWorld::cpp_app), true);
}
HelloWorld::~HelloWorld()
{
}
void HelloWorld::cpp_app()
{
string texttoprint = ;
Glib::RefPtrGtk::TextBuffer m_refTextBuffer;
m_refTextBuffer = Gtk::TextBuffer::create();
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 that takes 10 seconds to run.
texttoprint += Back from running a short 10 second function;
m_refTextBuffer-set_text(texttoprint);
m_textview.set_buffer(m_refTextBuffer);
}
// // void HelloWorld::on_button_clicked()
// // {
// // std::cout Hello World std::endl;
// // }
// --
// code end
// code begin example (HelloWorld.cpp / with system call form c++ program)
// --
/*
Name: gtkmmHelloworld.cpp
Author : Apollo III Communications
Version :
Copyright : Copyright 2013
Description : Hello World in gtkmm
*/
#include HelloWorld.h
#include iostream
#include string
using namespace std;
HelloWorld::HelloWorld() :
m_textview() // creates a new button with label Hello World.
{
// Sets the border width of the window.
// // set_border_width(10);
// When the button receives the clicked signal, it will call the
// on_button_clicked() method defined below.
// // m_button.signal_clicked().connect(sigc::mem_fun(*this,
// //HelloWorld::on_button_clicked));
// This packs the button into the Window (a container).
add(m_textview);
// The final step is to display this newly created widget...
RE: What is the minimum number of lines to update a gui window without user clicking a button
Quoth L. D. James:
// The final step is to display this newly created widget...
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();
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);
This is all fine right up until that last line, which contains a subtle (but
important) bug.
GTK widgets (and other UI elements of most other GUI frameworks) are
typically not merely thread-unsafe (as most objects are by default: can be
called from any thread provided that they can be guaranteed to not be called
concurrently) but actually thread-bound (can be called only from one
specific thread, typically the one that created them, or a designated main
thread).
It is therefore not permitted to touch m_textview from any thread other than
the main thread, which that last line is doing. (And then since this is
assigning a reference to the buffer, it then becomes unsafe to further
modify that buffer later in the worker thread.)
In short, while this might appear to work on your machine for this contrived
example, if you run it enough times in enough different environments and
with different workloads (eg. more frequent text updates) it's very likely
to either crash or exhibit other strange behaviour. So don't do that.
Others have already pointed you at the correct solutions, and as I am not
sufficiently practiced at GTK myself to give you a precise example I can
only reiterate what those others have said.
From your description of what you're trying to do it seems likely that
carrying out the actual work on a separate thread is indeed the correct
thing to be doing. But you can't just play with GUI objects outside of the
GUI thread. You need to use some method to convey data from one thread to
another (eg. an explicitly thread-safe queue) combined with some way to get
the main thread to wake up and do some processing (eg. Glib::Dispatcher or a
timeout handler).
In your case, I would recommend using a std::queue of text-to-be-added
protected by a mutex (to make it thread-safe) combined with a
Glib::Dispatcher callback that triggers the main thread to dequeue text and
add it to the textview.
(Though again as others have pointed out if your actual work is merely
calling a console application or performing file/network/pipe I/O then you
may want to try using the asynchronous I/O helpers instead, to avoid the
extra thread.)
Multithreading is hard (to get correctly, at least -- it's easy to do it
wrong). Asynchronous is less hard but still confusing until you get used to
the ideas. It may be worthwhile for you to read up on both of these
concepts independently of GTK, then read how they apply to GTK, then finally
how they apply to your applications. You're not going to find a quick and
easy solution -- or at least if you do find one and try to use it without
properly understanding it, you're letting yourself in for a world of hurt.
___
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
On 08/11/2013 09:41 PM, Gavin Lambert wrote: 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); This is all fine right up until that last line, which contains a subtle (but important) bug. Thanks Gavin I'm glad that your message suggests that I may have done something right. I have tried. I appreciate your pointing out about bugs in gtkmm. I'm sure with my investigation I'll eventually learn about the bugs and try to assist in the debugging of it, as well as other compoentns that fall short. GTK widgets (and other UI elements of most other GUI frameworks) are typically not merely thread-unsafe (as most objects are by default: can be called from any thread provided that they can be guaranteed to not be called concurrently) but actually thread-bound (can be called only from one specific thread, typically the one that created them, or a designated main thread). I thought I was communicating in the main thread that created it. With all the complexity of using the gui, it might be a feat that I'm actually able to add a couple of lines to an example and achieve the needed effect, in spite of the tool having known bugs. I'll keep everything that you mention in mind while I'm programming and try to identify any glitches that I experience and figure out how to report it to the community, or how to use the bug work around that might already be distributed. It is therefore not permitted to touch m_textview from any thread other than the main thread, which that last line is doing. (And then since this is assigning a reference to the buffer, it then becomes unsafe to further modify that buffer later in the worker thread.) In short, while this might appear to work on your machine for this contrived example, if you run it enough times in enough different environments and with different workloads (eg. more frequent text updates) it's very likely to either crash or exhibit other strange behaviour. So don't do that. Others have already pointed you at the correct solutions, and as I am not sufficiently practiced at GTK myself to give you a precise example I can only reiterate what those others have said. I thought I was using what others has pointed out. The only components that I thought I wasn't using is the parts that say have difficult or impossible it is. There was some code examples that were presented that either dimmed and became non-responsive, or never gave an update until the application had finished, which weren't usable. I couldn't use those components. From your description of what you're trying to do it seems likely that carrying out the actual work on a separate thread is indeed the correct thing to be doing. But you can't just play with GUI objects outside of the GUI thread. You need to use some method to convey data from one thread to another (eg. an explicitly thread-safe queue) combined with some way to get the main thread to wake up and do some processing (eg. Glib::Dispatcher or a timeout handler). In your case, I would recommend using a std::queue of text-to-be-added protected by a mutex (to make it thread-safe) combined with a Glib::Dispatcher callback that triggers the main thread to dequeue text and add it to the textview. I'll respect your suggestions just as well as I hoped I was respecting all the other suggestions, and still trying to have some representation of the needed output (a gui screen update). I'll try to figure out what you're saying and find a way to implement it without actually breaking the operation. If I add other lines and it stops working, I'd have to come back to what is actually working. At present, I don't know where to begin, except for what I'm already doing, continuing to study and read everything that appears in the maillist... the things in the threads that I create as well as all the other threads, which are not that easy for me to follow. But I'm reading and trying to comprehend all the messages. (Though again as others have pointed out if your actual work is merely calling a console application or performing file/network/pipe I/O then you may want to try using the asynchronous I/O helpers instead, to avoid the extra thread.) You may not know much about my actual work. Most of the lines I used in this message thread was a line that goes into a function called sleep. Then appends some text to the gui window. I took a function out of my tens of thousands of lines of code that I have been writing over the past 25 years (of which I mentioned had only been represented once) and you are using that to say most of my work. The user as me to post an example with less than 50 lines So I created something to go out and fix some output. Then I wrote that to the gui window, of which I thought was the main thread. I believe you make a big mistake when you refer to
RE: What is the minimum number of lines to update a gui window without user clicking a button
Quoth L. D. James: Thanks Gavin I'm glad that your message suggests that I may have done something right. I have tried. I appreciate your pointing out about bugs in gtkmm. I'm sure with my investigation I'll eventually learn about the bugs and try to assist in the debugging of it, as well as other compoentns that fall short. What? How did you possibly read that from what I said? The code that you wrote has a bug. There is nothing wrong with GTK or GTKMM, you're just using it wrong. You are creating a secondary worker thread. In that worker thread you are accessing a GUI widget. You can't do that. Not being able to do that is not a bug; trying to do it anyway is. Since you think everyone is telling me something different, I'll follow your suggestion and reread the thread and keep studying the thread to see where I'm going wrong. I understand I might be missing something, but at present if I can't see it, I can only report on the results and appreciate any further comments. So far everyone has been saying the same thing, just phrased differently. It appears however that you have not yet understood any of those suggestions. I even explicitly told you what you should be doing instead (using a queue with a mutex and a Dispatcher), which is the same thing that Andrew Potter suggested that you try last week (with a code example, no less). You appear to be telling me to study and use gtk rather than gtkmm. I fear that if I did that and tried to post something, I might be admonished even more for not using gtkmm which this forum is about, and reinventing the wheel. I'll take your advise and start studying gtk, but I'll be very leery to start creating my own interface when you describe it so complicated that it's broken in gtkmm which has been in the development for a number of years. No, that is not what I was suggesting. I was saying that you should first learn how multithreading works in general. Then how multithreading works in GTK+/GTKMM (since the two are basically the same thing, just with different syntactic sugar). And only then try to apply it to your application. ___ 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
Mr. James,
This reply has 3 examples. The last time I sent you a complete
solution you never indicated how it was insufficient, so please be
sure read this entire message.
The minimum amount of lines to use a TextView:
//== Example 1 Begin //
#include gtkmm.h
int main(int argc, char *argv[]) {
Glib::RefPtrGtk::Application app =
Gtk::Application::create(argc, argv, com.example);
Gtk::Window win;
Gtk::TextView tv;
tv.get_buffer()-set_text(Hello world);
win.add(tv);
win.show_all();
app-run(win);
return 0;
}
//== Example 1 End //
In your previous emails you have been expressing a desire to output
the result of some long-lasting process to your window. As your
problem was posed to the list it was a contrived problem that had no
simple solution. Most GUI programs start operations by having the user
interact with the window, either by pressing a button or selecting a
menu item.
Nonetheless, I have created another example program that performs a
blocking operation in thread and changes the value of a TextView when
the operation is finished. Note that in the quest for minimality I am
utilizing some features of Gtkmm and C++ that are rarely shown in
beginner examples (such as the ref-to-pointer and sigc::ref()).
This example is 34 lines with no comments or whitespace. But I have
gone ahead and added comments.
//== Example 2 Begin //
#include gtkmm.h
#include unistd.h /* for sleep() */
void cleanup_thread(Glib::Threads::Thread *thread) {
/* We must call Glib::Threads::Thread::join() in order to
* correctly clean up the resource. */
if (thread) {
thread-join();
thread = NULL;
}
}
/* This function is called on a separate thread so as to avoid
* blocking GTK+'s main loop.
*/
void blocking_operation(Glib::Dispatcher dispatcher) {
/* This simulates a blocking process */
sleep(10);
/* When the process is finished, we notify the GTK+ Main Loop by
* using the dispatcher */
dispatcher();
}
/* This function is called on GTK+'s main loop via a
* Glib::Dispatcher */
void blocking_operation_finished(const Glib::RefPtrGtk::TextBuffer tb,
Glib::Threads::Thread *thread) {
cleanup_thread(thread);
tb-set_text(Operation finished.);
}
int main(int argc, char *argv[]) {
Glib::RefPtrGtk::Application app =
Gtk::Application::create(argc, argv, com.example);
Gtk::Window win;
Gtk::TextView tv;
Glib::RefPtrGtk::TextBuffer tb = tv.get_buffer();
Glib::Dispatcher dispatcher;
Glib::Threads::Thread *blocking_operation_thread = NULL;
/* Because I'm not using a class to encapsulate the above objects
* and the methods (to keep it simple), I need to create
* functors that are bound with these local variables.
*
* Note sigc::ref() is used here. Without it sigc::bind would try
* to copy the dispatcher in this scope. We do not need to use
* sigc::ref() on tb because RefPtr is a copyable pointer.
*/
sigc::slotvoid op_functor = sigc::bind(blocking_operation,
sigc::ref(dispatcher));
sigc::slotvoid op_finished_functor =
sigc::bind(blocking_operation_finished,
tb,
sigc::ref(blocking_operation_thread));
/* The dispatcher will be used when the operation has finished.
* Here we set the function the dispatcher will call on the main
* thread -- a.k.a. GTK+'s Main Loop.
*/
dispatcher.connect(op_finished_functor);
/* Create a worker thread to perform the blocking_operation
* function.
*/
blocking_operation_thread = Glib::Threads::Thread::create(op_functor);
/* Now set the text in the buffer.
*/
tb-set_text(Operation started.);
win.add(tv);
win.show_all();
app-run(win);
cleanup_thread(blocking_operation_thread);
return 0;
}
//== Example 2 End //
If one accepts the slight textual overhead of using a class, I have
provided another solution. This allows more straightforward use of
slots/functors, utilizing only sigc::mem_fun().
This example is 46 lines with no comments or whitespace.
//== Example 3 Begin //
#include gtkmm.h
#include unistd.h /* for sleep() */
class Example {
private:
Glib::RefPtrGtk::Application app;
Gtk::Windowwin;
Gtk::TextView tv;
Glib::RefPtrGtk::TextBuffer tb;
Glib::Dispatcher dispatcher;
Glib::Threads::Thread *thread;
/* 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(10);
/* When the process is finished, we notify the GTK+ Main Loop by
* using the dispatcher */
dispatcher();
};
/* This function is called on GTK+'s main loop via a
*
Re: What is the minimum number of lines to update a gui window without user clicking a button
Thank you Andrew.
I misunderstood your first message and am looking at it more in depth
as well as your current post.
You bring up a very important clarification I should make from my
original post in this thread. I should not have counted the comments as
part of the total number of lines. Sometimes I post something, and have
an after though, but believe the general membership would see beyond my
error.
When excluding the important and very well documented comments of
Kjell's example it comes up to nearly have my original number. The
lines of code is about 235. Most of the confusion (for me) is the 11
widgets that, when I try to eliminate, breaks the code and I can't get
it to work. I'm sure, eventually I'll figure it out, the same way if a
person looked at the code for LibreOffice, and spent a lot of time
analyzing and breaking it down.
When I first started programming and was able to output a Hello World,
I was happy. It worked. I made lots of changes and understood it.
When I performed my first I/O it was just a minimum number of lines and
did a strictly limited task. I was able to dissect it in one short
session, then start using it productively in my crude programs.
I'm trying to find this same strict focus with outputting and updating
the gtkmm gui (without user input). If I can understand this, I'll have
a foundation of which I could build upon.
Kjell's example has everything I'm looking for, inclusive. But with my
current understanding of gtkmm, it's too complex for me to be able to
use. If all the widgets were eliminated and it just had a simple gui
window, it would be a bit easier for a beginner to work with.
At a glance it appears that you might have provided the needed solution
(possibly in your first message last week). I apologize for missing
some of the gist, but I will spend a lot of time studying in minute
detail everything you have posted. I appreciate your asking me to point
out what might be insufficient.
I also appreciate Kjell's invitation for the community (including me) to
comment on problems with his example. I'm sure, for experts there would
hardly be any problems. It was very easy to compile. It has a lot
included. However, for a novice, it's a bit overwhelming because it
includes so much. A novice might have to keep everything intact to
ensure that the code will compile, then try to figure out where to put
his functions. As I mentioned, in my case, if I remove the buttons and
progress bars, it becomes broken and I have to start back over with the
full code and try a different approach.
I would like to apologize to the community for being so new and using so
many words to explain my problem. But if I use a minimum amount of
words, someone might spend hours trying to help, but might come up with
something that doesn't address the problem. So I' trying to make the
problem clear, so that whatever time and energy anyone applies would
more likely answer the question.
Thanks!
-- L. James
--
L. D. James
lja...@apollo3.com
www.apollo3.com/~ljames
On Fri, 2013-08-09 at 23:13 -0700, Andrew Potter wrote:
Mr. James,
This reply has 3 examples. The last time I sent you a complete
solution you never indicated how it was insufficient, so please be
sure read this entire message.
The minimum amount of lines to use a TextView:
//== Example 1 Begin //
#include gtkmm.h
int main(int argc, char *argv[]) {
Glib::RefPtrGtk::Application app =
Gtk::Application::create(argc, argv, com.example);
Gtk::Window win;
Gtk::TextView tv;
tv.get_buffer()-set_text(Hello world);
win.add(tv);
win.show_all();
app-run(win);
return 0;
}
//== Example 1 End //
___
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
Thanks you plenty, Andrew for giving so much consideration to my question. I'm really grateful for the generous comments and white spaces for clarity. I should have run this line on Kjell's code before making a reference to 400 lines: // cli command begin cat * | egrep -v ^\s+\*|^$|^/|^\s+/ | wc // cli command end Without the comments and white space, I'd be substantially more lost. At present your presentation is extremely clear and takes me far into resolution of my immediate hurtle. It compiles and works perfectly. I have a few more questions of which I'll try to organize and be clear when I post them. Some of them might be resolved by my dissecting what you've already posted with your clear documentation. By the way, one of the questions is, the significants of the com.example parameter of the Gtk::Application entry. Does the application use that information somewhere? When programing the Android, similar information is used for creating a default storage space. My other questions will relate to my effort to create a reusable gprint function that I can run as a gui counter part of the console cout. The overhead doesn't matter. Just as long as I can have a one or two liner in my function that will resemble: gprint(This is a new line of text); That will either append or replace the text in the current gui window. It might already be covered in the well documented code you've already shared. Hopefully I'll be able to at least understand what you've already shared well enough to get the ball substantially rolling. And oh yea, your example #1 was overwhelmingly clear, for a beginner. Maybe the gtkmm maintainers will consider using something like that for one of the beginner's hello world examples. I believe placing the hello world text on a button rather than some type of text screen leaves some gaps that takes a while to fill. It did in my case. By the way, I hope the gtkmm maintainers appreciate my input. I looked at a lot of gui projects for C++ before choosing gtkmm. I felt that I had chose the best documented and supported solution. The documentation is incredible! It's just that some of it is immediately over my head. Looking at how all the additional widgets falls into play is another lesson. I'm sure once I'm able to fully grasp the use of a single widget (in this case, the textview), the other examples will soon be a cinch to understand. 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
I may be able to eventually figure out how to do it from your example,
but at present it doesn't appear to have the ability to append text,
except for an initial text and one addition.
I'm trying to be able to arbitrarily update the text numerous times
(just like you would with cout).
I thought the dispatcher() function would work reusable like the
gprint() function I'm trying to create. It appears to work correctly
the first time.
The other updates doesn't occur when the dispatcher() function is
called. The gui window becomes non responsive and dimmed until all the
functions are completed, then everything is showed at once. The window
at the end of the operation becomes a normal gui.
Kjell's example works exactly as intended, except that it has many
widgets and I can't figure out how to remove the widgets without
breaking the code. Also it requires a clicking of a button to start.
I realize that, everything that a person needs is included in his
example. My problem is being able to isolate a basic screen and an
update.
I know that I'll eventually understand it, and I'd be able to break it
down for anyone else that might have problems with it, and reuse the
many components in various applications.
I realize how easy it would be for you and other experts to use his
example. But I can't figure out where to put my function and output a
single line to the gui, then perform a followup after some operations.
I also appreciate the your reference to how complicated this task is.
Hopefully I can contribute to making something complicated, easy for the
next person.
I added my example, using your code to demonstrate the problem that I'm
having. I'm sure I'm misusing the dispatcher() function. But I don't
see any other way to update the gui from your example.
Thanks again for your contribution and input!
// Code begin
//
--
#include gtkmm.h
#include unistd.h /* for sleep() */
#include iostream
using namespace std;
class Example {
string textdata = uninitilzed;
private:
Glib::RefPtrGtk::Application app;
Gtk::Windowwin;
Gtk::TextView tv;
Glib::RefPtrGtk::TextBuffer tb;
Glib::Dispatcher dispatcher;
Glib::Threads::Thread *thread;
/* 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);
textdata += First function is complete.\n;
/* When the process is finished, we notify the GTK+ Main Loop
by
* using the dispatcher */
dispatcher();
sleep(5);
textdata += Second function is completed.\n;
dispatcher();
sleep(5);
textdata += Third function is completed.\n;
dispatcher();
sleep(5);
textdata += Fourth function is completed.\n;
textdata += This next funtion may take up to three hours to
complete.\n;
dispatcher();
sleep(60);
textdata += Fifth function is completed.\n;
dispatcher();
};
/* This function is called on GTK+'s main loop via a
* Glib::Dispatcher */
void blocking_operation_finished() {
cleanup_thread();
tb-set_text(textdata);
};
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. */
cleanup_thread();
}
Example(int argc, char *argv[]) : app(Gtk::Application::create(argc,
argv, com.example)), tb(tv.get_buffer()), thread(NULL)
{
/* Create a slot (a.k.a. functor) to the
* blocking_operation_finished() member function for the
* dispatcher to execute.
*/
sigc::slotvoid op_finished_functor = sigc::mem_fun(this,
Example::blocking_operation_finished);
/* The dispatcher will be used when the operation has finished.
* Here we set the function the dispatcher will call on the
main
* thread -- a.k.a. GTK+'s Main Loop.
*/
dispatcher.connect(op_finished_functor);
/* Now set the text in the buffer.
*/
textdata = Starting application.\n;
tb-set_text(textdata);
win.add(tv);
win.show_all();
}
void run() {
/* Create a slot to the blocking_operation() member function
* to pass to Glib::Threads::Thread::create().
*/
sigc::slotvoid op_functor = sigc::mem_fun(this,
Example::blocking_operation);
/* Create a worker thread to perform the blocking_operation
* function.
*/
thread =
Re: What is the minimum number of lines to update a gui window without user clicking a button
On Sat, 10 Aug 2013 05:43:42 -0400 L. D. James lja...@apollo3.com wrote: When I first started programming and was able to output a Hello World, I was happy. It worked. I made lots of changes and understood it. When I performed my first I/O it was just a minimum number of lines and did a strictly limited task. I was able to dissect it in one short session, then start using it productively in my crude programs. I'm trying to find this same strict focus with outputting and updating the gtkmm gui (without user input). If I can understand this, I'll have a foundation of which I could build upon. The point you may not understand is that you would rarely if ever want to do this in a simple real-world application, and particularly where your simple application is a learning exercise about using GTK+. GTK+ is, like almost all other GUI toolkits, event driven, and runs in a main loop. Therefore, if text arrives which you want to put in a widget, it would normally arrive as an event. If you are monitoring I/O, you would use Glib::signal_io().connect() to connect a file descriptor or Glib::IOChannel object to the main loop. Similar convenience functions are available for timeouts and idle handlers. I would strongly advise you not to get involved in using threads until you have more programming experience. Chris ___ 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
Thanks for the advise, Chris I already have a lot of applications of which I hope to put into place for my clients who see a monster when they see a text screen. Many of the task are very simple task, such as connecting to a VPN and giving a status of each step, so that if any component failed, or got stuck, the client could see it and not be turned off by seeing the text screen. I try to get people not to be so turned off by the text screen, but in this world, they are. Also, I'm making some of the task as launchers from the Ubuntu Unity button. The console screen doesn't look appealing, even to me. To many people (not to me of course, because I almost always work with a console terminal and do most of my work remotely) when they see a console screen that think that is evidence that something has crashed, or something bad is happening. I'm taking your advise, and had begun doing a lot of studying before I starting asking my questions and asking for help. I know that I could eventually figure all this out without help. But it'd take me years, whereas I was hoping that there might be some users of this mailing list, such as Alan and Andrew that might not mind parting with some of their experience and helping me over some of my hurtles. I don't mean to aggravate the group with my questions. I assure you, I won't be novice in this matter for long. I'm a very fast learner and at present have some gaps. In my research some new users have been given the opposite advice of what you had suggested to me. Some users have been told to study gtkmm and become familiar with this interface which had done a lot of work with the lower level of gtk and gtk++. They might waste a lot of time trying to reinvent the wheel ( http://stackoverflow.com/questions/3448937/class-extending-gtkwindow ) for something already provided if they try to do it with gtk instead of learning gtkmm. Of course, you may be right, in that gtkmm has not taken into account that a person might want to simply update the gui. I believe there is a need in this capacity. Kjell mention in his message that, the need is there, and the solution is provided, but didn't have any examples. He has started to fill the void. I already mentioned that I debated whether to learn gtkmm or to go a different direction. I even considered as you just suggested in working with gtk instead of gtkmm, but took the advise of another expert to learn how to use the gtkmm interface, rather than doing everything from a low level and reinventing the wheel. I can tell from Kjell's message that what I'm trying to do is already implemented in gtkmm. At present using it, just isn't all that clear. I hope to contribute to the group by assisting in helping things to be clearer, and to help close gaps that might exist. I can already easily update the console with a status without user input. I believe there is also merit in updating agui window without user input, of which, I appreciate the few people who have taking the time to understand the problem and investigated it. As far as realworld applications, most applications have some element of processing and outputting a status to the user without the user having to sit at the concole and constantly click buttons. I really appreciate your input and suggestions. But I believe you're misunderstanding the question. I realize buttons and user input is an important part of applications. However, at present, I would just like to be able to output notifications to my clients into a gui window without my application having to be hung until they come to the computer and click a button. The purpose of what I'm trying to do is allow the user to know at which stage the application has progressed, and to be able to report to me any messages, errors status updates that I present. As far as the VPN connection, if my program is waiting for an internet connection, it will state that. When it has the connection, without the user having to come back and tell the program to continue, it will just update, internet connection established, the remote host is currently off line... will try again in 5 minutes. The present console program eventually says, vpn connection established now configuring the local routing. I have many applications (or c++ routines) to do things such as that. They all output to a black screen. They frighten my customers. I hope to find a simple way of outputting the status to a friendly gui window. I don't mean to sound ungrateful with my reply, but I'm hoping that I'm clarifying what I'm trying to do, and that it does have some merit. -- L. James -- L. D. James lja...@apollo3.com www.apollo3.com/~ljames On Sat, 2013-08-10 at 13:54 +0100, Chris Vine wrote: On Sat, 10 Aug 2013 05:43:42 -0400 L. D. James lja...@apollo3.com wrote: When I first started programming and was able to output a Hello World, I was happy. It worked. I made lots of changes and understood it. When I performed my first
Re: What is the minimum number of lines to update a gui window without user clicking a button
On Sat, 10 Aug 2013 09:32:58 -0400 L. D. James lja...@apollo3.com wrote: [snip] As far as realworld applications, most applications have some element of processing and outputting a status to the user without the user having to sit at the concole and constantly click buttons. I really appreciate your input and suggestions. But I believe you're misunderstanding the question. I realize buttons and user input is an important part of applications. However, at present, I would just like to be able to output notifications to my clients into a gui window without my application having to be hung until they come to the computer and click a button. The purpose of what I'm trying to do is allow the user to know at which stage the application has progressed, and to be able to report to me any messages, errors status updates that I present. As far as the VPN connection, if my program is waiting for an internet connection, it will state that. When it has the connection, without the user having to come back and tell the program to continue, it will just update, internet connection established, the remote host is currently off line... will try again in 5 minutes. The present console program eventually says, vpn connection established now configuring the local routing. I have many applications (or c++ routines) to do things such as that. They all output to a black screen. They frighten my customers. I hope to find a simple way of outputting the status to a friendly gui window. I don't mean to sound ungrateful with my reply, but I'm hoping that I'm clarifying what I'm trying to do, and that it does have some merit. Your posts are no doubt highly meritorious but I am afraid they are not offering much clarification. You would probably make your point better if you shortened your posts by roughly an order of magnitude. However, after cutting through the dense undergrowth, I still think you have failed to understand how programs using event loops work. If the program is not just running a single batch of instructions, it has to have a loop in there somewhere, which is blocking until there is something to process. The simplest loop for your console program would involve blocking on select() or poll(), for which purpose presumably you must have a file descriptor to poll on. In that case, as I said, you can do the same with Glib::signal_io().connect(). Or maybe you are polling using timeouts, in which case the equivalent for gtkmm is Glib::signal_timeout().connect(). Why not get to the heart of the matter, and post a short compilable console program, cut down from the ones which you appear to have written for monitoring VPNs, but of no more than 50 lines, and we can tell you how to do the same using a graphical interface. Chris ___ 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
On Sat, 2013-08-10 at 16:45 +0100, Chris Vine wrote: Your posts are no doubt highly meritorious but I am afraid they are not offering much clarification. You would probably make your point better if you shortened your posts by roughly an order of magnitude. However, after cutting through the dense undergrowth, I still think you have failed to understand how programs using event loops work. If the program is not just running a single batch of instructions, it has to have a loop in there somewhere, which is blocking until there is something to process. The simplest loop for your console program would involve blocking on select() or poll(), for which purpose presumably you must have a file descriptor to poll on. In that case, as I said, you can do the same with Glib::signal_io().connect(). Or maybe you are polling using timeouts, in which case the equivalent for gtkmm is Glib::signal_timeout().connect(). Why not get to the heart of the matter, and post a short compilable console program, cut down from the ones which you appear to have written for monitoring VPNs, but of no more than 50 lines, and we can tell you how to do the same using a graphical interface. Chris I'll accept the admonishment. I'm sorry for the verbose description. It appears that you're starting to get the gist. I appreciate your asking me to expound with an example. The VPN application currently have 500 lines. I'll strip it down to 50, making sure it retains functionality and post it. One of the reasons I didn't post it before, but posted sleep(10) to represent the application was doing something, because the program is designed to make changes to the system. But, I'm sure I'll be able to comment and have such a flow that you might be able to easily follow it just by looking at it, or, on your own, comment out the parts that makes changes. 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
On Sat, 10 Aug 2013 12:16:16 -0400
L. D. James lja...@apollo3.com wrote:
[snip]
The VPN application currently have 500 lines. I'll strip it down to
50, making sure it retains functionality and post it.
One of the reasons I didn't post it before, but posted sleep(10) to
represent the application was doing something, because the program is
designed to make changes to the system. But, I'm sure I'll be able to
comment and have such a flow that you might be able to easily follow
it just by looking at it, or, on your own, comment out the parts that
makes changes.
If an outline of your code just consists of:
void check_stuff() {
if (vpn_connections_changed()) std::cout XXX changed\n;
}
int main(int argc, char* argv[]) {
for (;;) {
sleep(10);
check_stuff();
}
return 0;
}
Then in gtkmm this just becomes:
bool check_stuff() {
if (vpn_connections_changed()) std::cout XXX changed\n;
return true;
}
int main(int argc, char* argv[]) {
Gtk::Main app(argc, argv);
Glib::signal_timeout().connect_seconds(sigc::ptr_fun(check_stuff), 10);
app.run();
return 0;
}
You can go from there and add your graphical interface to check_stuff()
in place of the call to std::cout. You might, for example, want to
display a Gtk::MessageDialog object. With gtkmm-3.0, you might want
to use Gtk::Application instead of Gtk::Main. But first things first.
Chris
___
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
dispatcher() causes the function blocking_operation_finished() to be
called, which in turn calls Glib::Threads::Thread::join(). join() will
block the GTK+ main loop until the thread has completely finished
(i.e. blocking_operation() has returned).
Calling dispatcher() more than once means that
blocking_operation_finished() will be called more than once. I hope
you can understand why that is wrong.
Here is the next step in our example series. I have chosen to abstract
the ability to send parameters a function on the main thread through
the use of the CallbackDispatcher class. Its usage is simple: create a
functor that accepts zero arguments and pass it to send(). That
functor will be executed on the main loop.
A zero argument functor may be created from any function by using sigc::bind.
I have also chosen to use a Gtk::Label for this example, so as to
sidestep the issue of bug 495762.
Using a custom wrapper around Glib::Dispatcher to teach a newbie is,
perhaps, bad etiquette. But the utility of this wrapper in sending
progress back to the main loop has been so great in my experience that
I can't resist.
//== Example 4 Begin //
#include gtkmm.h
#include unistd.h /* for sleep() */
#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::Mutex::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::Mutex mutex;
std::queueMessage queue;
Glib::Dispatcher dispatcher;
void on_dispatch() {
Glib::Threads::Mutex::Lock lock(mutex);
while (!queue.empty()) {
queue.front()();
queue.pop();
}
}
};
class Example {
private:
Glib::RefPtrGtk::Application app;
Gtk::Windowwin;
Gtk::Label label;
CallbackDispatcher callback_dispatcher;
Glib::Threads::Thread *thread;
void report_progress(const Glib::ustring str) {
callback_dispatcher.send(sigc::bind(sigc::mem_fun(label,
Gtk::Label::set_text), str));
}
/* 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);
report_progress(5% complete.);
sleep(5);
report_progress(15% complete.);
sleep(5);
report_progress(35% complete.);
sleep(5);
report_progress(55% complete.);
sleep(5);
report_progress(75% complete.);
sleep(5);
report_progress(95% complete.);
sleep(5);
report_progress(100% complete.);
/* 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();
label.set_text(Operation finished.);
};
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. */
cleanup_thread();
}
Example(int argc, char *argv[]) :
app(Gtk::Application::create(argc, argv, com.example)),
label(),
thread(NULL)
{
win.add(label);
win.show_all();
}
void run() {
/* Create a slot to the blocking_operation() member function
* to pass to Glib::Threads::Thread::create().
*/
sigc::slotvoid op_functor = sigc::mem_fun(this,
Example::blocking_operation);
/* Create a worker thread to perform the blocking_operation
* function.
*/
thread = Glib::Threads::Thread::create(op_functor);
/* Now set the text in the buffer.
*/
label.set_text(Operation started.);
app-run(win);
}
};
int main(int argc, char *argv[]) {
Example example(argc, argv);
example.run();
return 0;
}
//== Example 4 End //
On Sat, Aug 10, 2013 at 5:39 AM, L. D. James lja...@apollo3.com wrote:
I may be able to eventually figure out how to do it from your example, but
at present it doesn't appear to have the ability to append text, except for
an initial text and one addition.
Re: What is the minimum number of lines to update a gui window without user clicking a button
On 08/10/2013 11:45 AM, Chris Vine wrote:
Your posts are no doubt highly meritorious but I am afraid they are not
offering much clarification. You would probably make your point better
if you shortened your posts by roughly an order of magnitude. However,
after cutting through the dense undergrowth, I still think you have
failed to understand how programs using event loops work. If the
program is not just running a single batch of instructions, it has to
have a loop in there somewhere, which is blocking until there is
something to process. The simplest loop for your console program would
involve blocking on select() or poll(), for which purpose presumably
you must have a file descriptor to poll on. In that case, as I said,
you can do the same with Glib::signal_io().connect(). Or maybe you are
polling using timeouts, in which case the equivalent for gtkmm is
Glib::signal_timeout().connect().
Chris, thanks again for your interest in my question. I apologize for
the delayed response, as I was on a support call for most of the day.
When I got back I trimmed down 500 lines of code to the example below.
This is 48 lines of my vpn connection routine. It's 48 out of the 500
line application. In those 48 lines I have 4 lines outputting to the
console. I would like for those lines to output to a gui window.
Those 4 lines are just some of the actually 25 lines of status that will
be output in the course of running the application. While it's running
and checking the connection it outputs either starts * or dots . at
10 second interval while it checks some of the file and connection status.
// code begin
// -
#include iostream
#include fstream
#include unistd.h
#include string
using namespace std;
int main(int argc, char* argv[]) {
string ret;
string server;
string command;
string runit(string c);
setuid(0);
server = argv[1];
string peerentry = /etc/ppp/peers/ + server;
command = ls + peerentry;
ret = runit(command);
if (ret != peerentry){
cout Problems locating server: server endl; //
console out
return 1;
}
string filetest = /var/run/ppp- + server + .pid;
ifstream myfile(filetest.c_str());
if (myfile.is_open()){
cout Connection is in effect endl; // console out
myfile.close();
}
else{
cout Connecting to... server endl; // console out
command = pppd call + server;
ret = runit(command);
cout Results: [ ret ] endl; // console out
}
return 0;
}
string runit(std::string c){
string lret = ;
c += 21;
FILE *in;
char buff[512];
if (!(in = popen(c.c_str(), r))){
return lret;
}
while (fgets(buff, sizeof(buff), in) != NULL){
lret += buff;
}
pclose(in);
return lret;
}
// -
// code end
-- 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
Thanks, Andrew. I'll study and compile your example and comment on if
it's the gist of what I'm trying to accomplish.
Looking at it, it appears like it will work. However, I'm not trying to
send progress statistics, I'm just trying to send general information.
Some of my programs sorts and index, and archives email messages. It
may send a message to the console that there are currently 1000 emails
about to be sorted. Then it's cross reference the headers with messages
addresses in the users' address book. It'll output to the console that
there are 500 email addresses that are not in the address book and sort
them into a separate area. These are all messages to a black console.
Many of my customers are used to seeing the black screen. I'm just want
to take my 10's of programs and have many of them output the text to a
graphics screen rather than the console screen.
I will find it convenient to create a function call gprint(). Where I
have cout ether replace the cout with gprint or use both, but the
gprint() will just update a gui with a message that currently goes to
a black screen.
I apologize for repeating this so much. I have read numerous times the
code of conduct for this forum. I'm trying to comply and not to
aggravate the membership with repetition and verbose messages. But most
of the comments I get gives me the impression that the members are
misunderstanding what I'm looking for.
Just like gtkmm is a convenient wrapper for gtk++, I hope to make a
gprint() routine to be a wapper for however many lines it takes to
create a gui window and be able to run a one or two liner to please a
new message to that gui window.
At a glance it appears that the code you have below might have the gist,
even though it's referencing percentages of progress instead of regular
text output informing the user what the application is currently doing,
and what it might do next, or informing the user of any errors or
problems it might be encountering.
I really apologize for the many words to try to be clear. I just posted
an example of one of my C++ applications. I have done it with Java and
might post a Java application that perfectly fits the bill (as for as
having a window and sending updates to that window). The problem with
the Java, is that you can't set the suid bit for some of the routines
that needs to be run as root.
I was doing that with a C++ wrapper to call the Java program. But now,
I'm trying to do it all in C++ with gtkmm.
Once I develop the gprint() function, I'm sure this will totally make
things clear. I'm sure that many will find it a convenient resource.
-- L. James
--
L. D. James
lja...@apollo3.com
www.apollo3.com/~ljames
On Sat, 2013-08-10 at 12:23 -0700, Andrew Potter wrote:
dispatcher() causes the function blocking_operation_finished() to be
called, which in turn calls Glib::Threads::Thread::join(). join() will
block the GTK+ main loop until the thread has completely finished
(i.e. blocking_operation() has returned).
Calling dispatcher() more than once means that
blocking_operation_finished() will be called more than once. I hope
you can understand why that is wrong.
Here is the next step in our example series. I have chosen to abstract
the ability to send parameters a function on the main thread through
the use of the CallbackDispatcher class. Its usage is simple: create a
functor that accepts zero arguments and pass it to send(). That
functor will be executed on the main loop.
A zero argument functor may be created from any function by using sigc::bind.
I have also chosen to use a Gtk::Label for this example, so as to
sidestep the issue of bug 495762.
Using a custom wrapper around Glib::Dispatcher to teach a newbie is,
perhaps, bad etiquette. But the utility of this wrapper in sending
progress back to the main loop has been so great in my experience that
I can't resist.
//== Example 4 Begin //
#include gtkmm.h
#include unistd.h /* for sleep() */
#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::Mutex::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::Mutex mutex;
std::queueMessage queue;
Glib::Dispatcher dispatcher;
void on_dispatch() {
Glib::Threads::Mutex::Lock lock(mutex);
while (!queue.empty()) {
queue.front()();
queue.pop();
}
}
};
class Example {
private:
Glib::RefPtrGtk::Application app;
Gtk::Windowwin;
Gtk::Label
Re: What is the minimum number of lines to update a gui window without user clicking a button
On Sat, 10 Aug 2013 17:53:41 -0400
L. D. James lja...@apollo3.com wrote:
[snip]
Chris, thanks again for your interest in my question. I apologize
for the delayed response, as I was on a support call for most of the
day. When I got back I trimmed down 500 lines of code to the example
below.
This is 48 lines of my vpn connection routine. It's 48 out of the 500
line application. In those 48 lines I have 4 lines outputting to the
console. I would like for those lines to output to a gui window.
Those 4 lines are just some of the actually 25 lines of status that
will be output in the course of running the application. While it's
running and checking the connection it outputs either starts * or
dots . at 10 second interval while it checks some of the file and
connection status.
// code begin
// -
#include iostream
#include fstream
#include unistd.h
#include string
using namespace std;
int main(int argc, char* argv[]) {
string ret;
string server;
string command;
string runit(string c);
setuid(0);
server = argv[1];
string peerentry = /etc/ppp/peers/ + server;
command = ls + peerentry;
ret = runit(command);
if (ret != peerentry){
cout Problems locating server: server endl; //
console out
return 1;
}
string filetest = /var/run/ppp- + server + .pid;
ifstream myfile(filetest.c_str());
if (myfile.is_open()){
cout Connection is in effect endl; // console out
myfile.close();
}
else{
cout Connecting to... server endl; // console out
command = pppd call + server;
ret = runit(command);
cout Results: [ ret ] endl; // console out
}
return 0;
}
string runit(std::string c){
string lret = ;
c += 21;
FILE *in;
char buff[512];
if (!(in = popen(c.c_str(), r))){
return lret;
}
while (fgets(buff, sizeof(buff), in) != NULL){
lret += buff;
}
pclose(in);
return lret;
}
// -
// code end
This appears to be just a batch job calling popen() which brings up a
ppp connection. There is no program loop anywhere and the while
loop for fgets() in runit() will block until EOF is reached, which
equates to the call to pppd ending and the process in which it is
running closing its stdout. Presumably you run this as a cron job, or
something like that? Or, since you say, while it's running and
checking the connection it outputs either starts '*' or dots '.' at 10
second interval while it checks some of the file and connection status,
possibly you have excised the loop logic, which is the interesting part
for present purposes. (As it happens, it will not compile because the
prototype for runit() is not in namespace scope, but that is no doubt
just a matter of transcription.)
To call up an executable (in this case pppd) in this kind of usage
using glib you would normally use Glib::spawn_async_with_pipes() and
connect to the standard_output and standard_error file descriptors with
Glib::signal_io().connect(). The problem you have got here though is
that you call setuid(0) on a binary which presumably has its suid bit
set in order to launch pppd. You should definitely not do that directly
with a GTK+ program. You would need to have a small wrapper with suid
set which calls up pppd, which is launched by your GTK+ program using
Glib::spawn_async_with_pipes(). (Yuck.)
As it happens, if you want a short cut for a batch job like this which
provides a GTK+ user interface, I would consider a shell script and
zenity, which is what zenity was intended for. A google search will
tell you more. However you would still need to circumvent your setuid
problem.
Chris
___
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
On 08/10/2013 07:09 PM, Chris Vine wrote: This appears to be just a batch job calling popen() which brings up a ppp connection. There is no program loop anywhere and the while loop for fgets() in runit() will block until EOF is reached, which equates to the call to pppd ending and the process in which it is running closing its stdout. Presumably you run this as a cron job, or something like that? Or, since you say, while it's running and checking the connection it outputs either starts '*' or dots '.' at 10 second interval while it checks some of the file and connection status, possibly you have excised the loop logic, which is the interesting part for present purposes. (As it happens, it will not compile because the prototype for runit() is not in namespace scope, but that is no doubt just a matter of transcription.) To call up an executable (in this case pppd) in this kind of usage using glib you would normally use Glib::spawn_async_with_pipes() and connect to the standard_output and standard_error file descriptors with Glib::signal_io().connect(). The problem you have got here though is that you call setuid(0) on a binary which presumably has its suid bit set in order to launch pppd. You should definitely not do that directly with a GTK+ program. You would need to have a small wrapper with suid set which calls up pppd, which is launched by your GTK+ program using Glib::spawn_async_with_pipes(). (Yuck.) As it happens, if you want a short cut for a batch job like this which provides a GTK+ user interface, I would consider a shell script and zenity, which is what zenity was intended for. A google search will tell you more. However you would still need to circumvent your setuid problem. Chris Hi, Chris. I stripped down a 500 line C++ program and included some system calls to give you and example of my many C++ programs. Many C++ programs use calls to the system shell. I can tell that happening with a number of driver installations. This application would not work as a bash script. I mentioned to you that you can not set the suid bit on a bash script. I'm familiar with cron jobs, and have no problems with cronjobs. In fact some of my applications are run by cron. The particular VPN connection application is run currently added to the Ubuntu dash and shows a black screen for the status when it's run. By the way, there are gui applications for batch files, perl files and just about any other programming concept. I appreciate your interest and your questions and suggestions. I understand that I don't have to use or learn gtkmm. But I hope you don't mind my interest in the facility. Some of my applications do not use any system calls. Some of them use some system calls. But I would like for most of them to output to a gui window where than a console. I understand how complicated you think this will be. But it can be done with C++ just as with just about any programming application. By the way, the program does compile. I've already started to add the gui interface. I did it with the gtk label with the help of Alan. I posted the example in a different thread. I ran into problems when I tried to change the label widget into a textview widget because I was having problems understanding the full gist of the gtkmm tools. When Kjell posted his resolution, I saw the light. So I started this thread on trying to break down Kjell's program into components (namely to eliminated the unneeded widgets). I'm getting there with some of the in-between the line suggestions from this new thread. I'm starting to understand more and more how to use gtkmm, of which I'm trying to do. I really don't think it's as complicated and some users are suggesting. I believe it's just a matter of getting a grip of a few vague concepts. While I'm having problems just sending text to a window, you're suggesting that I dive figure and use gtkmm for my other calls. I might get to that at some time. But at present, I just want to use gtkmm to output to a gui screen instead of a black screen. -- 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
On Sat, 10 Aug 2013 19:41:33 -0400 L. D. James lja...@apollo3.com wrote: [snip] While I'm having problems just sending text to a window, you're suggesting that I dive figure and use gtkmm for my other calls. I might get to that at some time. But at present, I just want to use gtkmm to output to a gui screen instead of a black screen. You keep missing the point. If you don't want to use zenity, as I said use Glib::spawn_async_with_pipes() and Glib::signal_io().connect(). That is the correct way to do it. Chris ___ 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
Thanks, Chris. I may end up using Glib::spawn_async (but I it doesn't appear to be a call for updating text to a gui window) and I may end up using Glib::signal_io().connect()) to send text to the gui window. This is the first time i see these as ways of updating the gui. Keep in mind that what I'm trying to do is develop a reusable function that I have named, gprint(). I'm sure I'm just about close enough to post a prototype by tomorrow. Thanks again for all your contributions, and patient for my newness with using a gtkmm widgets. My only problem with Kjell's example if being able to remove the unwanted ones. My problem with Alan's solution (which worked perfect) was changing it from label to textview (because of some gaps I was having at the time). I finally got it figured out how to change the widget from label to text view, now I'm trying to implement the gprint() function. I have it in place, but it's not clean enough to post it for comments yet. -- L. James -- L. D. James lja...@apollo3.com www.apollo3.com/~ljames On Sun, 2013-08-11 at 01:20 +0100, Chris Vine wrote: On Sat, 10 Aug 2013 19:41:33 -0400 L. D. James lja...@apollo3.com wrote: [snip] While I'm having problems just sending text to a window, you're suggesting that I dive figure and use gtkmm for my other calls. I might get to that at some time. But at present, I just want to use gtkmm to output to a gui screen instead of a black screen. You keep missing the point. If you don't want to use zenity, as I said use Glib::spawn_async_with_pipes() and Glib::signal_io().connect(). That is the correct way to do it. Chris ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
