On Sat, 2007-01-20 at 09:10 +0100, eric jrdn2 wrote:
I did not understand your answer, Paul.
I think that lg2c has been replaced by lgfortran now that gfortran has
replaced g77.
By the way, thank you, John, for your results on ubuntu. Now I know it
works on gentoo and ubuntu.
Why does
Murray Cumming wrote:
On Sat, 2007-01-20 at 09:10 +0100, eric jrdn2 wrote:
I did not understand your answer, Paul.
I think that lg2c has been replaced by lgfortran now that gfortran has
replaced g77.
By the way, thank you, John, for your results on ubuntu. Now I know it
works on
Eric,
Not sure about the g2c being replaced, but I tried compiling like you
had and I was getting linker errors about undefined symbols. When I
replaced -lgofortran with -lg2c it worked. I was still compiling with
gfortran which the manpage says is a fortran 95 compiler.
HTH,
Paul
On 1/20/07,
Thanks,
After I have posted the first message I have read about HINT_MASK and had
removed that mask from event mask...I have also posted mail to gtkmm mailing
list that I solved my problem but apparently mail has lost somewhere...but
thank you anyway for more detail explanation and samples
Hey everyone,
I'm contemplating how best to perform testing on some of my gtkmm
code. I've looked through the list archives for gtk and gtkmm and
didn't find anything worth noting. I've heard of using accesibility
api's to do GUI testing, but that seems like a Bad Idea (TM).
So basically this is
Am Samstag, den 20.01.2007, 05:08 -0600 schrieb Paul Davis:
Hey everyone,
I'm contemplating how best to perform testing on some of my gtkmm
code. I've looked through the list archives for gtk and gtkmm and
didn't find anything worth noting. I've heard of using accesibility
api's to do GUI
Murray,
Both of those look interesting but they also both require me figuring
out the accesibility api stuff. In general, this is something that I
could see using in the future.
Currently I was mostly thinking of firing signals which would of
course tie the tests to the gtkmm api, but it seems
On Sat, 2007-01-20 at 05:43 -0600, Paul Davis wrote:
Murray,
Both of those look interesting but they also both require me figuring
out the accesibility api stuff. In general, this is something that I
could see using in the future.
Currently I was mostly thinking of firing signals which
Murray,
I had no intention of creating an entire unit test framework. I
already use boost's unit test framework for my non-GUI libraries, I
was just wondering if there were tricks like firing signals from code
and also dealing with the X output that I could use within that
framework to do unit
On Friday 19 January 2007 07:44, Daniel Elstner wrote:
Hello everyone,
I recently learned that the POSIX memory visibility rules aren't as
strict as I thought them to be (thanks to Chris for pointing this out).
Given this, I'm now considering an API addition to glibmm, namely a
Am Samstag, den 20.01.2007, 12:22 + schrieb Chris Vine:
It will be necessary to provide synchronisation of course - Glib::SignalIdle
does this through attaching to the glib main loop, whereas Glib::Dispatcher
is only attached once and thereafter can be invoked from time to time with
On Sat, 2007-01-20 at 12:26 +0100, Daniel Elstner wrote:
b) changing GConf keys at runtime (if applicable)
See gconftool-2 --break-key for a fairly thorough way of doing this.
John
___
gtkmm-list mailing list
gtkmm-list@gnome.org
Hi,
I don't know if this is right mailing list but I can't find mailing list
associated to pangomm...so when I'm creating Pango::Layout from cairo context
it returns me NULL...but with C API I can obtain C PangoLayout pointer... the
wrap_auto function return NULL..I'm using GTK/GTKmm 2.10.6.1
On Saturday 20 January 2007 13:07, Daniel Elstner wrote:
[snip]
I don't get it. Why should there be a need for any synchronization
beyond the memory barrier when passing pointers to custom types? Note
that I'm proposing to stream the data argument through the pipe. Some
pseudo code:
Am Samstag, den 20.01.2007, 19:16 + schrieb Chris Vine:
On Saturday 20 January 2007 13:07, Daniel Elstner wrote:
Only for the pointer specializations (and not really *around* the
read/write, I got that wrong in my proposal mail). And even for pointer
types this will be only the
Ok
solved with help of
http://bugzilla.gnome.org/show_bug.cgi?id=352063
and found Pango::init() (I think I should read doc carefully)
sorry
Trigve
- Original Message
From: Trigve Siver [EMAIL PROTECTED]
To: gtkmm-list@gnome.org
Sent: Saturday, January 20, 2007 6:16:46 PM
Subject:
On Sat, 2007-01-20 at 19:16 +, Chris Vine wrote:
On a completely different point, also applicable to Glib::Dispatcher: the
Posix standard guarantees atomic writes to pipes between different processes
where the data is PIPE_BUF or less in size, but not between different threads
in the
On Saturday 20 January 2007 19:57, Daniel Elstner wrote:
[snip]
By static I meant unchanging over the lifetime of the thread. I know
that dereferencing is the issue here. But if the data in question was
only written to before the thread was created, or if you synchronize
access yourself by
Am Samstag, den 20.01.2007, 15:42 -0500 schrieb Paul Davis:
FYI, we discovered that FIFO's on OS X are dog slow. When Stephane Letz
ported JACK, which uses FIFO's to accomplish directed process wakeup, he
was forced to drop down to the Mach layer and use Mach ports to get
equivalent
19 matches
Mail list logo
