On 3/21/06, Lillian Angel <[EMAIL PROTECTED]> wrote:
Hello again,
> Below is the output of
> make (at the point where the error occurs).
I realized there is more errors. I am still not sure why there are
happening. I added more to the output below.
If anyone has any ideas, please let me know.
Th
On Mon, 20 Mar 2006 23:53:35 -0800, mikecorn wrote:
>
> I just tried rebuilding my GTK apps for a 64 bit Linux system (Fedora core
> 5), and had an ugly surprise: random segmentation faults. I traced at
> least one of them to my lazy habit of using a literal zero in place of
> NULL for an optiona
Hello,
I am attempting to build gtk+ on the new macbook pro (mac os x 10.4.5 intel).
I have used these instructions:
http://developer.imendio.com/wiki/Gtk_Mac_OS_X/Build_Instructions
I have successfully build all other packages, except gtk+.
It configures fine, but when I run make.. it acts up.
Hi all.
It's been a while since I sent any news on the recent files stuff, and
since a revision is planned, I've thought about writing down a little
overview on the whole code base, and (hopefully) get some replies back.
The code, for the people that haven't noticed and/or haven't cared,
lives in
On Tue, 2006-03-21 at 10:07 -0800, Dave Benson wrote:
> On Tue, Mar 21, 2006 at 11:10:24AM -0500, Owen Taylor wrote:
> > (*) Basically, it's impossible for GObject to know when a type is no
> > longer in use, because we don't have garbage collection in C.
> > So, if you unload and reload GT
> There's no way for the compiler to know that the sentinel is
> supposed to be a pointer. It's simply implemented as a varargs
> function. Maybe we should emphasize the importance of using NULL
> in our documentation.
This is where it would be a bit evil to mention that NULL might be
defined
Enrico Weigelt wrote:
* Owen Taylor <[EMAIL PROTECTED]> schrieb:
(*) Basically, it's impossible for GObject to know when a type is no
longer in use, because we don't have garbage collection in C.
Well, we could have. There're GC's for C out there, which seem to
work quite good.
I voted
Hi!
If unloading glib together with gtk is acceptable you can replace the
g_atexit function so you keep your own list and call it just before
dlclose()
See (and copy/paste) this great code:
http://download.insomniavisions.com/sources/uncompressed/cplusplus/g_atexit.cpp
Of course this works onl
On Tue, Mar 21, 2006 at 11:10:24AM -0500, Owen Taylor wrote:
> (*) Basically, it's impossible for GObject to know when a type is no
> longer in use, because we don't have garbage collection in C.
> So, if you unload and reload GTK+ again, referencing the
> type "GtkButton" is going to t
* Owen Taylor <[EMAIL PROTECTED]> schrieb:
> (*) Basically, it's impossible for GObject to know when a type is no
> longer in use, because we don't have garbage collection in C.
Well, we could have. There're GC's for C out there, which seem to
work quite good.
I voted for that several year
Lets have one...
The meeting is intended for the GTK+ team, but everybody is
welcome to come and listen. The meeting logs will be posted
on the GTK+ website (http://www.gtk.org/plan/meetings).
Place: irc.gnome.org:#gtk-devel
Time: 21:00 UTC (16:00 EST), Tue, March 21
Matthias
_
On Mar 21, 2006, at 8:37 AM, Hubert Figuiere wrote:
Jon A. Cruz wrote:
Thanks. I am using c++ so I must use protptypes. I use -Wall also.
For C++, 0 is supposed to be preferred over NULL. For varargs,
though, the compiler might not know your intent. I've seen places
that state modern comp
Hi Clemens,
in my phd project I had plugins for UI generation. One plugin was using gtk and
initialy I also requested a funtion like gtk_done() as a counterpart for
gtk_init(). I understood that this won't work and I just introduced a static
variable in my plugin to avoid double initialization
Jon A. Cruz wrote:
Thanks. I am using c++ so I must use protptypes. I use -Wall also.
For C++, 0 is supposed to be preferred over NULL. For varargs, though,
the compiler might not know your intent. I've seen places that state
modern compliers treat NULL as exactly 0 (in which case
static_c
On Mar 21, 2006, at 4:21 AM, mikecorn wrote:
Thanks. I am using c++ so I must use protptypes. I use -Wall also.
For C++, 0 is supposed to be preferred over NULL. For varargs,
though, the compiler might not know your intent. I've seen places
that state modern compliers treat NULL as exac
On Tue, 2006-03-21 at 17:24 +0100, Clemens Fruhwirth wrote:
> Milosz Derezynski <[EMAIL PROTECTED]> wrote:
>
> > From the docs GTK+ API docs:
> >
> > gtk_main():
> > [...] You can nest calls to gtk_main(). In that case gtk_main_quit() will
> > make the innermost invocation of the main loop retur
Clemens Fruhwirth wrote:
Milosz Derezynski <[EMAIL PROTECTED]> wrote:
[...]
Grepping through gtk for g_module_open, there are a few other
places. For instance the "im" modules, the filesystem modules and 3 in
gdk-pixbuf/. I presume there will be a list of loaded modules somewhere,
so I guess it
On 3/21/06, Yevgen Muntyan <[EMAIL PROTECTED]> wrote:
2) When you get path/iterator somehow, with error checking, and thenconvert itto iterator/path. E.g. you can get a path from a row reference, and ifit's not NULL,you know it's a valid path, so you don't need to check return value of
gtk_tree_mod
Milosz Derezynski <[EMAIL PROTECTED]> wrote:
> From the docs GTK+ API docs:
>
> gtk_main():
> [...] You can nest calls to gtk_main(). In that case gtk_main_quit() will
> make the innermost invocation of the main loop return.
> gtk_main_quit():
> Makes the innermost invocation of the main loop re
Thanks. I am using c++ so I must use protptypes. I use -Wall also.
The example for multi-threaded apps in the documentation is from 1999 and
the build instructions are out of date. Here is what I am doing for a 64 bit
system, which seems to work. Please let me know if there is a problem here.
g+
On 21/03/06 11:09, mikecorn wrote:
>I see your point about the arg-list-end flag.
>
>It seems it should be OK to use a zero in place of NULL when the argument is
>of a type known to the compiler and NULL is a documented way to denote a
>missing argument (e.g. optional window title string). Agree?
On Wed, Mar 15, 2006 at 10:12:31AM +, Martyn Russell wrote:
> > The owner arguments are there for allowing proper handling of nested
> > tooltips
> > areas. The idea for making this a GObject was taken over from Owen's
> > original plan. It can be any GObject: a widget, a GdkWindow, etc. We
I see your point about the arg-list-end flag.
It seems it should be OK to use a zero in place of NULL when the argument is
of a type known to the compiler and NULL is a documented way to denote a
missing argument (e.g. optional window title string). Agree?
Thanks for the response.
--
View this
On Tue, 21 Mar 2006, mikecorn wrote:
> I just tried rebuilding my GTK apps for a 64 bit Linux system (Fedora core
> 5), and had an ugly surprise: random segmentation faults. I traced at least
> one of them to my lazy habit of using a literal zero in place of NULL for an
> optional function argumen
Tim Janik wrote:
tree model iterators are easily advanced/setup/created in a way that
yields
an invalid iterator, because the denoted location doesn't exist
(anymore).
to cath those cases, the tree model API returns booleans indicating
success,
but testing those booleans is easily forgotton a
25 matches
Mail list logo
