Just, as we mentioned yesterday, put a ! before the
Glib::thread_supported call and remove the else clause.
-- Alan
On 8/5/2013 7:07 PM, L. D. James wrote:
Thanks, Moh. I had lots of redundancy and other most likely useless
arguments included just to make my original code compile. I didn't
Thanks, Alan. I understand those lines better with your explanation.
I'm able to strip the example down by 5 lines.
-- L. James
--
L. D. James
lja...@apollo3.com
www.apollo3.com/~ljames
On 08/06/2013 10:29 AM, Alan Mazer wrote:
Just, as we mentioned yesterday, put a ! before the
Thanks, Alan. It compiles without errors. When run I get this error at
the console:
Threads aren't supported!
// c++ code begin
// ---
#include gtkmm.h
#include iostream
using namespace std;
class myLabel: public Gtk::Window
{
Ah. Perhaps it's how you built it. If you're using Linux, I link with
-lgthread-2.0. I actually like with -lpthread as well, although that
might not be necessary. I have multiple types of threads in some apps.
Try that and see if that helps.
-- Alan
On 8/5/2013 12:05 PM, L. D. James
Ah. You need to call the thread init routine first. Can't remember the syntax
now. Perhaps someone else can remind me or I'll check later when I get back to
my office.
Sent from my Android phone using TouchDown (www.nitrodesk.com)
-Original Message-
From: L. D. James
Thanks!
I added the two libraries. Performed clean make and get the same output.
This is the Makefile and other files used by Eclipse:
// Code - Makefile
// --
Hi,
I think you should put:
if (Glib::thread_supported())
instead of:
if (!Glib::thread_supported()) == Your code
see the ! difference.
On Mon, 2013-08-05 at 16:27 -0400, L. D. James wrote:
Thanks!
I added the two libraries.
and my Makefile:
begin Makefile
all:
g++ -std=c++11 -Wall -g3 -c *.cc `pkg-config gtkmm-3.0
--cflags`-pthread
g++ -std=c++11 -Wall -g3 *.o `pkg-config gtkmm-3.0 --libs` -lpthread -o
thread
clean:
rm -rf *.o thread
begin Makefile
Thanks, Moh. That resolved the error issue. As far as I can see, it's
functioning perfect!
I'll have some questions on Threading. But I'll reserve this for a new
topic.
-- L. James
--
L. D. James
lja...@apollo3.com
www.apollo3.com/~ljames
On Mon, 2013-08-05 at 22:07 +0100, Moh B. wrote:
So weird. I always use the ! and that's the example I see on the web as
well. It looks like the intended usage of this routine is that it
returns false if threading needs to be initialized, in which case you
call Glib::thread_init. If threading doesn't need to be initialized,
though, there
On 8/5/2013 2:17 PM, L. D. James wrote:
Thanks, Moh. That resolved the error issue. As far as I can see,
it's functioning perfect!
Also, just in case someone else is using this code as a template for
something, note that this code does still require a dispatcher to be
robust. It's
And another thing:
You declared a void myprocess1(void); member function == WITH void
parameter list BUT in the myLabel::myLabel() constructor you called the
myprocess1() WITHOUT any parameter list: This may cause problems to the
compiler:
protected:
Gtk::Label m_label;
Quoth Moh B:
You declared a void myprocess1(void); member function == WITH void
parameter list BUT in the myLabel::myLabel() constructor you called the
myprocess1() WITHOUT any parameter list: This may cause problems to the
compiler:
protected:
Gtk::Label m_label;
string
Thanks, Moh. I had lots of redundancy and other most likely useless
arguments included just to make my original code compile. I didn't have
a clear understanding about what was doing what. I was looking at the
examples and trying to implement the objective of outputting to both the
console
I haven't forgotten your end goal. You need threading to get there if you want
the GUI to be responsive while the long computations are taking place. I sent
you a little sample code already but I can show you how it fits together on
Monday. There's not much left to be done.
Sent from my
Thanks, Alan. I'm all excited about getting close.
I was thinking the problem existed because I was trying to use label
instead of some of the other widgets such as textview, of which I'm
currently studying.
I appreciate all your support and input. I'm sure by Monday I'll
understand even more
OK, if you don't care about making the window unresponsive while
processing is happening then this example should be helpful:
https://git.gnome.org/browse/gtkmm-documentation/tree/examples/book/idle
You should worry about making the window unresponsive, regardless of the
programming language, but
I don't know what you mean by unresponsive. I hope you don't mean that
the window would be dimmed and have the appearance of being locked up
and appear crashed, without the ability to copy and past from it, or to
resize it. If that is what you're saying, it would be horrible. Some
of my current
Sorry, I'm not interested in being in a big email thread with such
verbose responses. If you have specific problems with specific actual
code, I'm sure people will offer specific help.
--
Murray Cumming
murr...@murrayc.com
www.murrayc.com
www.openismus.com
Murray, I most sincerely apologize. I thought I was helping by giving
more description of the problem to help avoid people who might
contribute spending a lot of time on something that won't work.
Based on most of the responses it has taken more than one message to
clarify the problem.
I
Hi, Alan. I've worked on the last example in many ways. The program
compiles without errors and shows a gui window, but nothing is ever
output to the window.
If you have experimented up to this point and found a method, can you
help me with an example.
I'll remind you that I'm embarrassed
Thanks.
I forgot to remind you of important details. For one I forget to
mention that the “sleep(10)” function represented a function that is
processing such as searching all the network drives for a string and
doing other chores that might take up to three hours or more.
Then when it gets back
You said:
-
You're problem is that your myLabel class isn't a label but a window.
You're deriving it from Gtk::Window.
Normally, you wouldn't derive your own label, I wonder what you wanted
to accomplish with that...
You wrote:
/I'm just trying to have a gui window set that I can continually update
from a function, ie (myfunction())./
But _when_ should the window be updated?
If you want to update the UI every X seconds, you can use a timeout
signal. You shouldn't let the code execute independently from
Actually, Jonas, there is something like that in Gtkmm. Alan understand
what I have explained, and this is what we are working on.
I appreciate your description to me about how complicated it is, and
your advise to me that it might be too complicated for me to handle...
and of course, that is
I think you kind of misunderstand the problem. It is quite simple to
open another thread and call set_text of your label from there. The
problem is that this will probably crash your program, as gtkmm is not
thread-safe. That's why you need to make sure that your set_text doesn't
overlap with
Jonas, the suggested approach that I sent earlier uses a dispatcher to
avoid this problem, which I think is the preferred approach. Also, the
poster is trying to update a GUI window *asynchronously*. He doesn't
want to use timeouts, and he doesn't want it to be button driven. I
think that
Yes I know that this should be solved with a seperate thread and I now
have read the documentation for Glib::Dispatcher and understand the
basics of it, even though I don't understand why it doesn't allow arguments.
I also found an example for this with a lot of comments (in german, I
could
I hope translation from the German won't be necessary :-). I think the
documentation and examples of dispatcher use are more intimidating than
they should be.
In your main thread, create a dispatcher object.
Connect the object to a routine that draws.
In your separate thread, call the
On Thu, Aug 1, 2013 at 7:24 AM, Jonas Platte jonaspla...@myopera.com wrote:
Am 01.08.2013 16:11, schrieb L. D. James:
// sample code begin
// -
String updatetext = About to run a process that might take an hour... sit
back and wait...\n;
On Thu, Aug 1, 2013 at 9:52 AM, Alan Mazer alan.s.ma...@jpl.nasa.gov wrote:
P.S. I don't know why it doesn't take arguments either, but one can work
around that with globals and a mutex.
There's actually a really nice solution I've been using lately. It
uses C++11, but it can be rewritten
Hi, Andrew. I don' t understand what you mean about standard GUI design
principals. But in Java (and possibly in Gtkmm) it's possible to have a
gui window there. The buffer sits in the window. Changing the content
of the string shouldn't have have interfere with the integrety of the
gui
Hi,
On review, you're using Gtk::Main::run(), which is in the process of
getting deprecated, and probably shouldn't be used in new code unless
you're working with a gtkmm version 3.0 The progress bar example in
the book has the new version,
Glib::RefPtrGtk::Application app =
Thanks, Ian. And yes. I know that my code is performing outside the
gui environment. I gave the example so that the community would
understand what I was trying to do and tell me what changes had to
happen to have the code perform inside the gui environment.
I have already found examples that
Gtk::Main::run runs until the window is closed. If you want to let the
window open while executing code that takes time to finish (like copying
many files in an installation), you should create a seperate thread that
does those things and updates the UI respectively.
For changing the label
Thanks Jonas. I have a basic understanding of what you're saying. I
kind of figured most of this before my post. I just can't figure out
how to actually do it. I'm still searching and reading all the
documenting that I can find to help me to figure out how to do it. I
have been reading so
The sigc++ things aren't so hard to use once you understand them.
Basically all you have to do is to create a functor (an object
representing a function) for your signal handler and pass it to the
connect function of a signal (e.g. signal_show of any widget,
signal_clicked of a button), then
See here for a timing example. Hope this helps you!
http://stackoverflow.com/questions/1118227/glibmm-timeout-signal
===
On Wed, 2013-07-31 at 08:50 -0400, L. D. James wrote:
Thanks Jonas. I have a basic understanding of what you're
As I understand it, you just want a window that display the progress of
a computation in ASCII readable text.
Here's how I would approach it.
1. Write a program that creates a window. This should be trivial,
something you already know how to do.
2. Derive a class from your window class and
Thanks, Alan. Your approach sounds very matter of fact, most likely
exactly what I'm trying to do.
I do it easily with Java, Python, Visual Studio (modal dialog), Android
sdk... to name a few.
Java is very easy. The Window and Frame is up and has a buffer. All
you have to do is just append or
On 7/31/2013 9:24 AM, L. D. James wrote:
Java is very easy. The Window and Frame is up and has a buffer. All
you have to do is just append or change the buffer. The window will
always reflect the content of the buffer you modify.
And you can do this in gtkmm as well. I think someone else
Some people gets aggravated and annoyed at the rate that some learn. It
almost sounds by the tone of your message that you maybe getting a
little annoyed at my slowness in fully grasping this application.
I appreciate that you have the patience to suggest that I may not have
to fully understand
On 7/31/2013 2:28 PM, L. D. James wrote:
Some people gets aggravated and annoyed at the rate that some learn.
It almost sounds by the tone of your message that you maybe getting a
little annoyed at my slowness in fully grasping this application.
I'm not annoyed. I'm just trying to make sure
Hi, Alan. I'm a little embarrassed at the code I'm showing you. I'm
still stuck, but I'm sure I have the gist. I can figure it out from
here. It's just a matter of time in looking at all the examples from
the gtkmm documentation and filling in the glitches I have here.
I'm very self-taught in
You're problem is that your myLabel class isn't a label but a window.
You're deriving it from Gtk::Window.
Normally, you wouldn't derive your own label, I wonder what you wanted
to accomplish with that...
To make clear how you would structure your code with an own Window class
normally, here
Can someone help to clear up the confusion of how to update a gui window
without user input.
In other words, I would like to be able to output text to either or both
the console our the gui window.
At present I can call the gui window (Window with a label for example)
and output the initial
//main.cpp:
//---
// Look at this modified code and pay attention to the order of
execution and call th the functions
#include gtkmm.h
#include iostream
using namespace std;
int main(int argc, char* argv[])
{
Gtk::Main kit(argc, argv);
Gtk::Window window;
On 07/30/2013 04:53 PM, Moh B. wrote:
//main.cpp:
//---
// Look at this modified code and pay attention to the order of
execution and call th the functions
#include gtkmm.h
#include iostream
using namespace std;
int main(int argc, char* argv[])
{
Gtk::Main kit(argc, argv);
Hi,
Have you looked at the code for the progress bar example?
https://developer.gnome.org/gtkmm-tutorial/stable/sec-progressbar.html.en
Ian.
On 31/07/13 09:33, L. D. James wrote:
On 07/30/2013 04:53 PM, Moh B. wrote:
//main.cpp:
//---
// Look at this modified code and pay attention to
49 matches
Mail list logo
