Re: compiler error
Gtkmm2 is not compatible with gtk3. It doesn't depend on the compiler. If you want to use glibmm2, you must also use gtk2. 2013-08-09 00:18, Kemin Zhou bmsid=00337162 skrev: I am trying to compiler gtkmm2.99, Some some packages, they don't like gtk3.* I am not sure this is because that I am using a newer compiler or not: cal/include/c++/4.8.1 -MT event.lo -MD -MP -MF .deps/event.Tpo -c -o event.lo event.cc libtool: compile: g++ -DHAVE_CONFIG_H -I.. -I../.. -DG_LOG_DOMAIN= \gdkmm\ -DGDKMM_BUILD=1 -pthread -pthread -I/usr/local/include/giomm-2.4 -I/usr/local/lib/giomm-2.4/include -I/usr/local/include/glibmm-2.4 -I/usr/local/lib/glibmm-2.4/include -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include -I/usr/local/include/sigc++-2.0 -I/usr/local/lib/sigc++-2.0/include -I/usr/local/include/pangomm-1.4 -I/usr/local/lib/pangomm-1.4/include -I/usr/local/include/cairomm-1.0 -I/usr/local/lib/cairomm-1.0/include -I/usr/local/include/pango-1.0 -I/usr/local/include/cairo -I/usr/local/include -I/usr/local/include/freetype2 -I/usr/local/include/gtk-3.0 -I/usr/local/include/atk-1.0 -I/usr/local/include/gio-unix-2.0/ -I/usr/local/include/gdk-pixbuf-2.0 -I/usr/local/include/harfbuzz -I/usr/include/pixman-1 -I/usr/include/libpng12 -I/usr/include/at-spi2-atk/2.0 -Wall -I/usr/local/include/boost -I/usr/local/include/c++/4.8.1 -MT event.lo -MD -MP -MF .deps/event.Tpo -c event.cc -fPIC -DPIC -o .libs/event.o event.cc: In static member function ‘static GType Glib::ValueGdk::ExtensionMode::value_type()’: event.cc:51:38: error: ‘gdk_extension_mode_get_type’ was not declared in this scope return gdk_extension_mode_get_type(); ^ event.cc:52:1: warning: control reaches end of non-void function [-Wreturn-type] } Kemin ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
cairomm
I'm trying to build gtkmm and its associated components from their git sources. I've already checked out (cloned) atkmm, glibmm, gtkmm and pangomm which were all checked out from 'git://git.gnome.org/xxxmm' (where xxx is the root name of the specific library). Everything checked out fine except for cairomm. When I try to access git://git.gnome/cairomm, my git client consistently reports The remote end hung up unexpectedly. Should I be obtaining cairomm from somewhere else? John ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: cairomm
On 11/08/2013 11:35, John Emmas wrote: Everything checked out fine except for cairomm. When I try to access git://git.gnome/cairomm, my git client consistently reports The remote end hung up unexpectedly. Oops... the actual URL I'm using is git://git.gnome.org/cairomm (that was just a typo in my earlier post). John ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: cairomm
2013-08-11 12:35, John Emmas skrev: I'm trying to build gtkmm and its associated components from their git sources. I've already checked out (cloned) atkmm, glibmm, gtkmm and pangomm which were all checked out from 'git://git.gnome.org/xxxmm' (where xxx is the root name of the specific library). Everything checked out fine except for cairomm. When I try to access git://git.gnome/cairomm, my git client consistently reports The remote end hung up unexpectedly. Should I be obtaining cairomm from somewhere else? John ___ See http://www.cairographics.org/cairomm/ If you want to build almost everything from the latest versions in git repositories, you ought to use jhbuild, https://wiki.gnome.org/Jhbuild. I may take a while to get it going the first time, but it's worth it, if you're going to build gtkmm from the git repository now and then in the future. Kjell ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: cairomm
On 11/08/2013 12:01, Kjell Ahlstedt wrote: See http://www.cairographics.org/cairomm/ If you want to build almost everything from the latest versions in git repositories, you ought to use jhbuild Many thanks, 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
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
