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: compiler error
Oops, I see now that the gtkmm-2.9x versions (2.90, 2.91, 2.99) are actually unstable very early versions of gtkmm-3. They can probably only be used together with equally early versions of gtk+-3. I recommend that you don't use them. If you need gtkmm-2, use gtkmm-2.24.4, if you have gtk+-2.24.x installed, or else compatible versions of gtkmm-2.xx and gtk+-2.xx. Don't use gtkmm-2.24.3. It has many problems, as discussed in bug https://bugzilla.gnome.org/show_bug.cgi?id=697835. It's not necessary to install gtk+-2 and gtk+-3 with different prefixes. gtk+-2 and gtk+-3, as well as gtkmm-2 and gtkmm-3, can be installed in parallel in /usr. But it does no harm to install them at different locations. Kjell 2013-08-12 16:08, Zhou, Kemin skrev: Kjell, Thanks a lot. I have gtk2 install at /usr, and gtk3 install at /usr/local Is there a way to tell it to use gtk2 (from /usr) in the configuration step? I also have a lower version of g++ at /usr. Some other packages depends on Newer G++, so I installed it at a different location. I can switch to g++ to a different version easily. Is there an option At the configuration step? Kemin Zhou Phone: 609 818-4265 -Original Message- From: Kjell Ahlstedt [mailto:kjell.ahlst...@bredband.net] Sent: Sunday, August 11, 2013 5:13 AM To: Zhou, Kemin Cc: gtkmm-list@gnome.org Subject: 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: ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
auto-generated file 'gtkmm/widget.h' (widget.hg)
I'm building gtkmm on Windows (using MSVC). Rather than building from a tarball I'm using the git sources (which means me having to build all the auto-generated stuff, using gmmproc etc). Everything builds pretty well. I've even built glibmm, atkmm and pangomm the same way. The only hiccup I seem to have is with the file 'gtk/src/widget.hg' At line 3546 in the finished file (widget.h) I seem to end up with this code:- //Note that the deprecated keyword has no effect on _WRAP_SIGNAL() yet. //It doesn't seem like a good idea to put virtual functions in #ifdefs, because that would change the size of the class instances. /** @deprecated This should never have been in the API. It was never meaningful. * #ifndef GTKMM_DISABLE_DEPRECATED * @par Slot Prototype: * ttGlib::RefPtrAtk::Object on_my_%get_accessible()/tt * */ Glib::SignalProxy0 Glib::RefPtrAtk::Object signal_get_accessible(); #endif // GTKMM_DISABLE_DEPRECATED Note that the line ' ifndef GTKMM_DISABLE_DEPRECATED is getting generated inside a comment. In any case, I think it's the wrong #define. Looking at the hg file it looks as if the correct line should have been #ifdef GTKMM_ATKMM_ENABLED . I don't really understand the format of a hg file but from a simple observation of 'widget.hg' I can see that the declaration which corresponds to the mis-generated code seems to be the only occurence of #ifdef GTKMM_ATKMM_ENABLED which has the word deprecated after it. Might that explain the problem?? This is with version 2.24.4, cloned from Git just a couple of days ago. John ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: auto-generated file 'gtkmm/widget.h' (widget.hg)
It depends on which version of glibmm (and thus gmmproc) you use. The same bug is mentioned in https://bugzilla.gnome.org/show_bug.cgi?id=697835#c16 (glibmm version unknown). https://bugzilla.gnome.org/show_bug.cgi?id=697835#c21 shows a different result with glibmm 2.32.0. The gtkmm 2.24.4 tarball shows a third result (glibmm version unknown). All of https://bugzilla.gnome.org/show_bug.cgi?id=697835 discusses problems with gtkmm 2.24.3. Version 2.24.4 was released as a result of those problems. It rurned out that it's important to use the correct version of glibmm (gmmproc). Unfortunately I can't find it mentioned in the bug what version of glibmm is the correct one to use. Does anyone know? Can't you use the tarball? Nothing has been added to git branch gtkmm-2-24 since tarball gtkmm 2.24.4 was released. Kjell 2013-08-12 17:38, John Emmas skrev: I'm building gtkmm on Windows (using MSVC). Rather than building from a tarball I'm using the git sources (which means me having to build all the auto-generated stuff, using gmmproc etc). Everything builds pretty well. I've even built glibmm, atkmm and pangomm the same way. The only hiccup I seem to have is with the file 'gtk/src/widget.hg' At line 3546 in the finished file (widget.h) I seem to end up with this code:- //Note that the deprecated keyword has no effect on _WRAP_SIGNAL() yet. //It doesn't seem like a good idea to put virtual functions in #ifdefs, because that would change the size of the class instances. /** @deprecated This should never have been in the API. It was never meaningful. * #ifndef GTKMM_DISABLE_DEPRECATED * @par Slot Prototype: * ttGlib::RefPtrAtk::Object on_my_%get_accessible()/tt * */ Glib::SignalProxy0 Glib::RefPtrAtk::Object signal_get_accessible(); #endif // GTKMM_DISABLE_DEPRECATED Note that the line ' ifndef GTKMM_DISABLE_DEPRECATED is getting generated inside a comment. In any case, I think it's the wrong #define. Looking at the hg file it looks as if the correct line should have been #ifdef GTKMM_ATKMM_ENABLED . I don't really understand the format of a hg file but from a simple observation of 'widget.hg' I can see that the declaration which corresponds to the mis-generated code seems to be the only occurence of #ifdef GTKMM_ATKMM_ENABLED which has the word deprecated after it. Might that explain the problem?? This is with version 2.24.4, cloned from Git just a couple of days ago. John __ ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: auto-generated file 'gtkmm/widget.h' (widget.hg)
On 12/08/2013 18:25, Kjell Ahlstedt wrote: It depends on which version of glibmm (and thus gmmproc) you use. The same bug is mentioned in https://bugzilla.gnome.org/show_bug.cgi?id=697835#c16 (glibmm version unknown). https://bugzilla.gnome.org/show_bug.cgi?id=697835#c21 shows a different result with glibmm 2.32.0. The gtkmm 2.24.4 tarball shows a third result (glibmm version unknown). All of https://bugzilla.gnome.org/show_bug.cgi?id=697835 discusses problems with gtkmm 2.24.3. Version 2.24.4 was released as a result of those problems. It rurned out that it's important to use the correct version of glibmm (gmmproc). Unfortunately I can't find it mentioned in the bug what version of glibmm is the correct one to use. Does anyone know? Thanks for the quick response Kjell. It's getting a bit late in my part of the world (and I've had a long day!) but I'll be sure to follow up those leads tomorrow. FWIW my copy of gmmproc is only about 2 weeks old (dated 27 Jul 2013) and comes from glibmm version 2.37.4 Can't you use the tarball? Nothing has been added to git branch gtkmm-2-24 since tarball gtkmm 2.24.4 was released. Yes, I can definitely use the tarball if all else fails but it'd be nice to see a fix so that the hg file can get built correctly. BTW 'widget.cc' also seems to suffer from a similar problem when auto-generated :-( John ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: auto-generated file 'gtkmm/widget.h' (widget.hg)
You're right, the latest version of glibmm (gmmproc) generates erroneous code. I thought it was an old version that did that. This is something I should look into, I think. Anyway, you will have other problems if you let a new version of gmmproc generate code for gtkmm 2.24.4. That's what bug 697835 is all about. Gtkmm 2.24.4 (and probably all versions of gtkmm-2) must have its code generated by an old version of gmmproc that adds #include glibmm.h to all generated .h files. New versions of gmmproc, from 2.31.0.1 (2011-10-26), adds #include glibmm/ustring.h #include sigc++/sigc++.h That change was done to speed up compilation, but #include directives had to be added in many .hg files in gtkmm and other modules. Kjell 2013-08-12 20:04, John Emmas skrev: On 12/08/2013 18:25, Kjell Ahlstedt wrote: It depends on which version of glibmm (and thus gmmproc) you use. The same bug is mentioned in https://bugzilla.gnome.org/show_bug.cgi?id=697835#c16 (glibmm version unknown). https://bugzilla.gnome.org/show_bug.cgi?id=697835#c21 shows a different result with glibmm 2.32.0. The gtkmm 2.24.4 tarball shows a third result (glibmm version unknown). All of https://bugzilla.gnome.org/show_bug.cgi?id=697835 discusses problems with gtkmm 2.24.3. Version 2.24.4 was released as a result of those problems. It rurned out that it's important to use the correct version of glibmm (gmmproc). Unfortunately I can't find it mentioned in the bug what version of glibmm is the correct one to use. Does anyone know? Thanks for the quick response Kjell. It's getting a bit late in my part of the world (and I've had a long day!) but I'll be sure to follow up those leads tomorrow. FWIW my copy of gmmproc is only about 2 weeks old (dated 27 Jul 2013) and comes from glibmm version 2.37.4 Can't you use the tarball? Nothing has been added to git branch gtkmm-2-24 since tarball gtkmm 2.24.4 was released. Yes, I can definitely use the tarball if all else fails but it'd be nice to see a fix so that the hg file can get built correctly. BTW 'widget.cc' also seems to suffer from a similar problem when auto-generated :-( John ___ ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: auto-generated file 'gtkmm/widget.h' (widget.hg)
On 12 Aug 2013, at 20:32, Kjell Ahlstedt wrote: You're right, the latest version of glibmm (gmmproc) generates erroneous code. I thought it was an old version that did that. This is something I should look into, I think. Anyway, you will have other problems if you let a new version of gmmproc generate code for gtkmm 2.24.4. That's what bug 697835 is all about. Gtkmm 2.24.4 (and probably all versions of gtkmm-2) must have its code generated by an old version of gmmproc Thanks Kjell. That bug report suggests that Kalev has already produced a new tarball for 2.24.4 which includes the correct (i.e. older) version of gmmproc. Is it possible that the older version just needs to be added to ver 2.24.4 in Git? Or isn't it as simple as that? John ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
