UTF8 strchug/chomp/strip
I noticed that glib doesn't contain g_utf8_strchug, g_utf8_strchomp, g_utf8_strstrip (macro), which would be UTF8 safe versions of the functions in gstrfuncs.c. Conveniently, these functions already exists in file-roller, which I found here: http://tinyurl.com/6xpjv9 Can these be pulled down into gutf8.c / gunicode.h? Thanks, -Andrew ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
g_object_new(G_TYPE_OBJECT, NULL)
Everyone, is there any reason why anyone would want to instantiate actual GObjects using g_object_new(G_TYPE_OBJECT, NULL)? As a follow-up to that question, was there a design decision in mind when not flagging GObject G_TYPE_FLAG_ABSTRACT to prevent this? What can one say to someone who wishes to do this? In my opinion, it just *feels* wrong... All over the documentation, GObject is referred to as a base class, but that implies abstract to me because the intention is for everyone to created subclassed types. Am I missing something? Andrew Paprocki Bloomberg LP ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Fwd: Re: Depending on C99 (Re: GtkBindingSignal changes)
I disagree with this completely. We compile all of our code on Solaris/AIX with SunPRO cc IBM xlc without c99 extensions enabled for our own reasons. Code can take advantage of c99 features, but only if they can be abstracted out in gmacros/config.h/etc. Andrew Paprocki Bloomberg LP - Original Message - From: Michael Natterer [EMAIL PROTECTED] At: 1/ 5 6:37 On Thu, 2006-01-05 at 12:01 +0100, Tim Janik wrote: On Wed, 4 Jan 2006, Xavier Bestel wrote: On Wed, 2006-01-04 at 15:26, Matthias Clasen wrote: Thats a gcc extension/C99 addition though. We use [1] in other places where flexible arrays are used. Oh, I imagine there must be good reasons (read: already debated to death) for not taking advantage of C99 improvements. Sorry. no, it actually hasn't as far as i know. and i think it makes sense to at least start discussing this possibility. could people please speak up if they think depending on C99 would be a bad idea for glib gtk+ (e.g. with the next major release) and why this would be a problem for them? in the end, the w32 compilers are C99 compliant i'd assume and on older unixes when there're no modern compilers available, there's always a C99 compliant gcc that can be used. I'm all for this step. GIMP struggles over stone age compilers on old unixes all the time, and asking people to use a complier that's a bit younger than 20 years isn't too much to ask for. So please, let's get rid of some legacy and enable everybody to use a bit more modern C. ciao, --mitch ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Fwd: Re: Fwd: Re: Depending on C99 (Re: GtkBindingSignal cha
does this make? there is no reason why software from the year 2006 needs to be compiled with compilers from the year 1986. cc: Sun C 5.5 Patch 112760-09 2004/03/31 That does not look like a compiler from 1986 to me. I said we disable c99 features for internal reasons. When you are dealing with millions of lines of C code (some of which have not been modified since 1986), simply enabling a compiler to use c99 is not acceptable without spending a lot of time cleaning up code. We do not use glib/gtk as shared libraries, therefore the archives need to be built using our standard build process which mandates how the compiler is invoked. Remember: Just because c99 is a 'standard' does not mean it is standard in practice. CSS is a 'standard', but IE is so full of bugs, everyone codes to the buggy software rather than the 'standard' because IE is _standard_, not CSS. Good developers understand this and write code which is portable and works in IE, Firefox, and every other random browser. In my opinion, glib _is_ the buffer between different platforms and compiler versions. If glib itself starts becoming platform/compiler centric (which it seems to have avoided at all costs up to this point), then much of that benefit is lost. This is exactly what autoconf is for. In the words of Johnny Cochrane: If the HAVE_ doesn't exist, you must acquiesce. :) ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Depending on C99 (Re: GtkBindingSignal changes)
I think things need to be checked, but VC++7.x might be the shift to VC++.NET. If so, then there's a bit more reason people could be sticking with it. AFAIK, VC++6.0 == last vc++ without branded .net VC++7.0 == visual studio .net VC++7.1 == visual studio .net 2003 VC++8.0 == visual studio .net 2005 Andrew Paprocki Bloomberg LP ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Perennial ISO C99 Validated Products List
FYI, for the current discussion: http://www.peren.com/pages/cvsa_isocvpl.htm Dinkumware, Ltd. Dinkum Unabridged Library 4.0 Edison Design Group EDG C/C++ Compiler (C99 Language Implementation) 3.0.1 IBM Visual Age Compiler VAC 6.0.0.8 Lund LMPCC C99 Compiler for Linux / PowerPC 1.3 Sun Studio 9 5.6 As tested by the Perennial C Compiler Validation Suite. http://www.peren.com/pages/cvsa.htm Andrew Paprocki Bloomberg LP ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Fwd: Re: Fwd: Re: GTK_FLOATING broken in 2.9?
Yevgen Muntyan wrote: New code: object = fancy_not_gtk_object_new(); g_object_ref_sink(object); /* because I don't know what will container do */ fancy_container_add(container, object); g_object_unref(object); What I want the container code to do is assert if an object is not floating, and ref_sink internally. So the user's code will look like: object = fancy_not_gtk_object_new(); fancy_container_add(container, object); Andrew Paprocki Bloomberg LP ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Fwd: Re: ABI and API for g_object_ref_sink() (Re: GTK_FLOATI
it seems like just waiting for 3.0 is a nicer, more stable approach. Just general questions: 1) When is 3.0 scheduled to be released? 2) If it was decided to wait until 3.0, can GtkObject be removed entirely? (Or can we work to eliminate GtkObject if there are any other remaining functionality?) Andrew Paprocki Bloomberg LP ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Fwd: Re: comments on g_list_slice / g_list_splice
I just realized that all of the APIs need to return the original list because it can be modified. The way I'm playing with it now, the slice calls would simply unlink 'link' and it is up to the caller to reuse the same 'link' pointer as the newly separated list.. - Original Message - From: Paul Leonerd Evans [EMAIL PROTECTED] At: 11/30 5:49 On Wed, 30 Nov 2005 00:57:42 -0500 ANDREW PAPROCKI, BLOOMBERG/ 731 LEXIN [EMAIL PROTECTED] wrote: GList * g_list_slice(GList *list, GList *link, gint n_links); GList * g_list_remove_slice(GList *list, GList *link, gint n_links); GList * g_list_splice(GList *list, GList *splice_list, gint position); GList * g_list_splice_before(GList *list, GList *splice_list, GList *sibling); I added myself GPtrArray* g_ptr_array_slice(const GPtrArray* orig, guint first, gint last); I have found it more useful to pass offset indexes. For arrays this is the only sensible choice, but for lists it's somewhat harder to say what is the correct way of indexing them. Offset count, or link node pointer? Either way, the presence of functions which do that job, sound very useful. -- Paul LeoNerd Evans [EMAIL PROTECTED] ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list signatur.asc Description: Binary data ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
comments on g_list_slice / g_list_splice
Does anyone have any comments on the possibility of creating g_list_slice and g_list_splice functions? I find myself needing to remove/add contiguous sections of a GList, and believe these functions might be useful to others. The idea would be: GList * g_list_slice(GList *list, GList *link, gint n_links); GList * g_list_remove_slice(GList *list, GList *link, gint n_links); GList * g_list_splice(GList *list, GList *splice_list, gint position); GList * g_list_splice_before(GList *list, GList *splice_list, GList *sibling); g_list_slice() would return a newly allocated GList as a copy of the segment of 'list' beginning with 'link' and extending 'n_links'. g_list_remove_slice() would function similar g_list_remove_link(), except it would remove 'n_links' from 'list' and the returned list would consist of the removed links. g_list_splice()/g_list_splice_before() would do the reverse and function similar to g_list_insert()/g_list_insert_before(), except they would take the 'splice_list' and fully insert it into 'list' instead of a inserting a single piece of data. Is this useful to anyone else? There are some details that could work in a few ways. The splice calls could either insert by copying 'splice_list' or insert by taking ownership of 'splice_list', for instance. My use for these calls is to pull out a section of a GList and move it somewhere else in the list, so I would primarily be looking for remove_slice and splice calls that take ownership. Comments? Andrew Paprocki Bloomberg LP ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Sun's fopen() fd limit of 256
I'm not sure if everyone is aware, but Sun has a long standing issue where fopen will fail if the # of open fds is greater than 0xff. The underlying reason is that they never updated their FILE struct to change the UNIX fd from an unsigned char. Only if you build your app as _LP64 does it finally use an int for the fd. In order to work around this bug we've maintained our own imitation f* API for reading/writing that does not have this 256 fd limit. Is there any benefit to providing a full GLib fopen/fread/fwrite/etc API which provides its own implementation if the system implementation has an fd limitation? The configure script could detect this and enable it if necessary. Just wondering if anyone else had run into this problem... Thanks, Andrew Paprocki Bloomberg LP ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
GtkNotebook signals
Can someone fill me in if there is proper documentation for the signals on GtkNotebook? Specifically, these: change-current-page focus-tab select-page switch-page If an application wishes to prevent the notebook from switching pages if some type of validation fails on the current existing page, is select-page the proper signal to use with a return of FALSE? If someone can explain these in a bit more detail, we could update the function comments so the docs are more clear. Thanks, Andrew Bloomberg LP ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
gtk_container_real_check_resize
A bit of code in this function is confusing me:
if (requisition.width widget-allocation.width ||
requisition.height widget-allocation.height)
{
if (GTK_IS_RESIZE_CONTAINER (container))
gtk_widget_size_allocate (GTK_WIDGET (container),
GTK_WIDGET (container)-allocation);
else
gtk_widget_queue_resize (widget);
}
I'm trying to understand the logic behind the GTK_IS_RESIZE_CONTAINER case. If
it is known that the requisition is greater than the allocation, why is the
widget allocated with insufficient space? Are container implementations supposed
to do something special to handle this case?
Andrew Paprocki
Bloomberg LP
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
