Owen Taylor schrieb:
[...]
The glib and gtk+ libraries consist of C source code and the ABI is
the same for all compilers. One set of runtime would work for all
compilers, but the xxx-config scripts would not. A single xxx-config
script would only return the flags that work with the C compiler
Krzysztof Dubowik schrieb:
Hi,
I wanted my timeout function to be called 200 times per second.
Another words, my timeout function to be called every 5 miliseconds.
why? what's the actual problem behind it?
___
gtk-list mailing list
[EMAIL
Owen Taylor wrote:
[..]
Basically, the difference is that bug reports _force_
us to act upon them (even it's a question of WONTFIX)
while if we read a mailing list post, we may think it's
a cool idea, but most likely won't remember it at all
when it comes time to work on features for the next
Owen Taylor wrote:
I don't think this change makes sense though:
A) g_list_free_1() doesn't unlink the list node either,
so just returning next doesn't do any good. g_list_free_1()
simply frees a single list node
that is already unlinked.
B) g_list_delete_link is exactly what you are
The glib2 function g_list_free_1 is currently defined as
void g_list_free_1 (GList*list);
This is not the best option, the function is actually
called in many places to free the head of a glist. In
about *all* places that includes an iteration on to the
-next list item.
say.
cheers, guido
Regards,
Owen
Guido Draheim [EMAIL PROTECTED] writes:
The glib2 function g_list_free_1 is currently defined as
void g_list_free_1 (GList*list);
This is not the best option, the function is actually
called
Owen Taylor wrote:
Guido Draheim [EMAIL PROTECTED] writes:
Owen Taylor wrote:
If you want to make feature enhancment requests, the best procedure
is:
- File them in bugzilla
- (optional) send mail to gtk-devel-list if you think
that discussion on the issue would be good.
the gtk.org
I have made good success with an extension of G_MARKUP_TEXTSTART
to the gmarkup interpreter - it simply guides the xml reader to
issue callbacks for any element before the root element. That
way one can even see ? and other elements instead of dropping
them. It makes gmarkup more useful as a
The current gmarkup parse routines will throw away any whitespace
that runs before/between/after toplevel xml elements - and whatever
other non-element text chars exists in an xml file will make the
parser routine to error out when before the first element.
While that not only violates xml