Re: g_malloc overhead

2009-01-26 Thread Martín Vales
Paul LeoNerd Evans escribió: On Sun, 18 Jan 2009 17:43:57 +0100 Martín Vales mar...@opengeomap.org wrote: Other overhead i see is the open dir/file funtions, where in windows we need do the utf8 to utf16 everytime in windows. If JAVA,.NET and Qt use utf16 by default why in gnome world we

Re: g_malloc overhead

2009-01-26 Thread Behdad Esfahbod
Martín Vales wrote: I can see the advantages of use utf8 but the true it´s most of people use utf16. I know gnome/linux/cairo/freedesktop promote utf8 but most people use utf16: http://unicode.org/notes/tn12/#Software_16 This is a very baseless claim. One that actually turns out to be false.

Re: g_malloc overhead

2009-01-26 Thread Colin Walters
On Mon, Jan 26, 2009 at 9:12 AM, Behdad Esfahbod beh...@behdad.org wrote: Lets just say that UTF-16 is at best implementation details of Firefox. Well, JavaScript is notably UTF-16. Given that the Web, Java and .NET (i.e. all the most important platforms) are all UTF-16 it's likely to be with

GtkTreeModel / GtkTreeStore for big models

2009-01-26 Thread Christoph Schmeding
Hi I am currently developping a model browser for a car crash application. I am using GTK2.12 to populate all the objects that are in my car crash model. For this I used the standard GtkTreeModel / GtkTreeStore design pattern. When the model is becoming really big (more than 250 000 objets

Re: g_malloc overhead

2009-01-26 Thread Martín Vales
Colin Walters escribió: On Mon, Jan 26, 2009 at 9:12 AM, Behdad Esfahbod beh...@behdad.org wrote: Lets just say that UTF-16 is at best implementation details of Firefox. Well, JavaScript is notably UTF-16. Given that the Web, Java and .NET (i.e. all the most important platforms) are

Re: g_malloc overhead

2009-01-26 Thread Owen Taylor
On Mon, 2009-01-26 at 18:30 +0100, Martín Vales wrote: Colin Walters escribió: On Mon, Jan 26, 2009 at 9:12 AM, Behdad Esfahbod beh...@behdad.org wrote: Lets just say that UTF-16 is at best implementation details of Firefox. Well, JavaScript is notably UTF-16. Given that

Re: g_malloc overhead

2009-01-26 Thread Maciej Piechotka
Martín Vales mar...@opengeomap.org writes: Colin Walters escribió: On Mon, Jan 26, 2009 at 9:12 AM, Behdad Esfahbod beh...@behdad.org wrote: Lets just say that UTF-16 is at best implementation details of Firefox. Well, JavaScript is notably UTF-16. Given that the Web, Java and

Re: g_malloc overhead

2009-01-26 Thread Martin (OPENGeoMap)
hi: Well - what do you mean? Having 2 functions - one reciving utf-16 and one utf-8? To be honest - it doesn't make any sense to me (it would create much mess, double the code, make programming errors easier...). Converting? What's wrong with g_utf16_to_utf8? I was talking about a full

Re: g_malloc overhead

2009-01-26 Thread Martin (OPENGeoMap)
Maciej Piechotka escribió: On Mon, 2009-01-26 at 22:30 +0100, Martin (OPENGeoMap) wrote: hi: Well - what do you mean? Having 2 functions - one reciving utf-16 and one utf-8? To be honest - it doesn't make any sense to me (it would create much mess, double the code, make

Re: utf-16 and glib

2009-01-26 Thread Martin (OPENGeoMap)
Maciej Piechotka escribió: On Mon, 2009-01-26 at 22:49 +0100, Martin (OPENGeoMap) wrote: Maciej Piechotka escribió: On Mon, 2009-01-26 at 22:30 +0100, Martin (OPENGeoMap) wrote: hi: Well - what do you mean? Having 2 functions - one

Re: utf-16 and glib

2009-01-26 Thread Martin (OPENGeoMap)
Dominic Lachowicz escribió: What is wrong with: gchar* g_utf8_strncpy (gchar *dest,const gchar *src,gsize n); That's one not needed as strncpy should work. hehe i know but that function it really exist:

Re: utf-16 and glib

2009-01-26 Thread Behdad Esfahbod
Martin (OPENGeoMap) wrote: Dominic Lachowicz escribió: What is wrong with: gchar* g_utf8_strncpy (gchar *dest,const gchar *src,gsize n); That's one not needed as strncpy should work. hehe i know but that function it really exist:

GTK+ 2.15.2 released

2009-01-26 Thread Matthias Clasen
GTK+ 2.15.2 is now available for download at: http://download.gnome.org/sources/gtk+/2.15/ gtk+-2.15.2.tar.bz2 md5sum: 1c230eeb1bf24b69b480d0a35da34794 gtk+-2.15.2.tar.gz md5sum: 1e9d42fb6bdfb6752a82f6c3afc3b3e7 This is another development release leading up to GTK+ 2.16. Notes: * This

Re: GSeal bugs in GtkAccelLabel hampering flexibility

2009-01-26 Thread Mathias Hasselmann
Am Montag, den 26.01.2009, 04:03 + schrieb Peter Clifton: Hi, I'm trying to write a subclass of GtkAccelLabel in order to override its source for the accelerator string. gEDA (GPL Electronic CAD) uses multi-key-press keyboard shortcuts which are unfortunately incompatible with the

Re: g_malloc overhead

2009-01-26 Thread Paul LeoNerd Evans
On Sun, 18 Jan 2009 17:43:57 +0100 Martín Vales mar...@opengeomap.org wrote: Other overhead i see is the open dir/file funtions, where in windows we need do the utf8 to utf16 everytime in windows. If JAVA,.NET and Qt use utf16 by default why in gnome world we use utf8 by default?. Probably

Re: Bikeshedding the invisible-char

2009-01-26 Thread Paul LeoNerd Evans
On Mon, 19 Jan 2009 20:07:09 -0600 Federico Mena Quintero feder...@novell.com wrote: I'm arguing for committing openSUSE's patch based on the following unquestionable criteria: Do you have any numbers on the glyph coverage of these two characters in a variety of common fonts? Are either of

Re: g_malloc overhead

2009-01-26 Thread Martín Vales
Paul LeoNerd Evans escribió: On Sun, 18 Jan 2009 17:43:57 +0100 Martín Vales mar...@opengeomap.org wrote: Other overhead i see is the open dir/file funtions, where in windows we need do the utf8 to utf16 everytime in windows. If JAVA,.NET and Qt use utf16 by default why in gnome world we

Re: g_malloc overhead

2009-01-26 Thread Mathias Hasselmann
Am Montag, den 26.01.2009, 12:40 +0100 schrieb Martín Vales: Paul LeoNerd Evans escribió: On Sun, 18 Jan 2009 17:43:57 +0100 Martín Vales mar...@opengeomap.org wrote: Other overhead i see is the open dir/file funtions, where in windows we need do the utf8 to utf16 everytime in

Re: g_malloc overhead

2009-01-26 Thread Behdad Esfahbod
Martín Vales wrote: I can see the advantages of use utf8 but the true it´s most of people use utf16. I know gnome/linux/cairo/freedesktop promote utf8 but most people use utf16: http://unicode.org/notes/tn12/#Software_16 This is a very baseless claim. One that actually turns out to be false.

Re: GSeal bugs in GtkAccelLabel hampering flexibility

2009-01-26 Thread Peter Clifton
On Mon, 2009-01-26 at 10:15 +0100, Mathias Hasselmann wrote: Am Montag, den 26.01.2009, 04:03 + schrieb Peter Clifton: Hi, I'm trying to write a subclass of GtkAccelLabel in order to override its source for the accelerator string. gEDA (GPL Electronic CAD) uses multi-key-press

Re: g_malloc overhead

2009-01-26 Thread Colin Walters
On Mon, Jan 26, 2009 at 9:12 AM, Behdad Esfahbod beh...@behdad.org wrote: Lets just say that UTF-16 is at best implementation details of Firefox. Well, JavaScript is notably UTF-16. Given that the Web, Java and .NET (i.e. all the most important platforms) are all UTF-16 it's likely to be with

Re: GSeal bugs in GtkAccelLabel hampering flexibility

2009-01-26 Thread Behdad Esfahbod
Peter Clifton wrote: The way GTK seems to have worked (from my past experience), is I / others write patches, then they sit in Bugzilla and get ignored. I won't pollute this reply with the list of examples, but I can think of several. (Ok - only one patch was mine). Peter, I understand your

Re: GSeal bugs in GtkAccelLabel hampering flexibility

2009-01-26 Thread Peter Clifton
On Mon, 2009-01-26 at 00:59 -0500, Yu Feng wrote: Hi Peter, I agree with you to seal accel_string without any getter/setter sucks. But some of my code may interest you. Look for class MenuLabel in the following file to see its public interface: Thanks for the suggestion. I did in fact do

Re: GSeal bugs in GtkAccelLabel hampering flexibility

2009-01-26 Thread Peter Clifton
On Mon, 2009-01-26 at 09:59 -0500, Behdad Esfahbod wrote: Peter Clifton wrote: The way GTK seems to have worked (from my past experience), is I / others write patches, then they sit in Bugzilla and get ignored. I won't pollute this reply with the list of examples, but I can think of

Re: g_malloc overhead

2009-01-26 Thread Martín Vales
Colin Walters escribió: On Mon, Jan 26, 2009 at 9:12 AM, Behdad Esfahbod beh...@behdad.org wrote: Lets just say that UTF-16 is at best implementation details of Firefox. Well, JavaScript is notably UTF-16. Given that the Web, Java and .NET (i.e. all the most important platforms) are

Re: g_malloc overhead

2009-01-26 Thread Owen Taylor
On Mon, 2009-01-26 at 18:30 +0100, Martín Vales wrote: Colin Walters escribió: On Mon, Jan 26, 2009 at 9:12 AM, Behdad Esfahbod beh...@behdad.org wrote: Lets just say that UTF-16 is at best implementation details of Firefox. Well, JavaScript is notably UTF-16. Given that

Re: g_malloc overhead

2009-01-26 Thread Paul LeoNerd Evans
On Mon, Jan 26, 2009 at 12:57:28PM -0500, Owen Taylor wrote: On Mon, 2009-01-26 at 18:30 +0100, Martín Vales wrote: Yes, i only talked about the overhead with utf8 outside of glib, only that. Perhaps the only solution is add more suport to utf16 in glib with more methods. There's zero

Re: g_malloc overhead

2009-01-26 Thread Maciej Piechotka
Martín Vales mar...@opengeomap.org writes: Colin Walters escribió: On Mon, Jan 26, 2009 at 9:12 AM, Behdad Esfahbod beh...@behdad.org wrote: Lets just say that UTF-16 is at best implementation details of Firefox. Well, JavaScript is notably UTF-16. Given that the Web, Java and

Re: g_malloc overhead

2009-01-26 Thread Martin (OPENGeoMap)
hi: Well - what do you mean? Having 2 functions - one reciving utf-16 and one utf-8? To be honest - it doesn't make any sense to me (it would create much mess, double the code, make programming errors easier...). Converting? What's wrong with g_utf16_to_utf8? I was talking about a full

Re: GSeal bugs in GtkAccelLabel hampering flexibility

2009-01-26 Thread Behdad Esfahbod
Peter Clifton wrote: If you want a workaround for now, just access the member as GSEAL(member_name). I told them the GSEAL macro should use __line__, they didn't listen :P. Ok - didn't know I could do that. I had presumed the sealed members we not available for prodding outside GTK's

Re: g_malloc overhead

2009-01-26 Thread Martin (OPENGeoMap)
Maciej Piechotka escribió: On Mon, 2009-01-26 at 22:30 +0100, Martin (OPENGeoMap) wrote: hi: Well - what do you mean? Having 2 functions - one reciving utf-16 and one utf-8? To be honest - it doesn't make any sense to me (it would create much mess, double the code, make

Re: utf-16 and glib

2009-01-26 Thread Martin (OPENGeoMap)
Maciej Piechotka escribió: On Mon, 2009-01-26 at 22:49 +0100, Martin (OPENGeoMap) wrote: Maciej Piechotka escribió: On Mon, 2009-01-26 at 22:30 +0100, Martin (OPENGeoMap) wrote: hi: Well - what do you mean? Having 2 functions - one

Re: utf-16 and glib

2009-01-26 Thread Dominic Lachowicz
What is wrong with: gchar* g_utf8_strncpy (gchar *dest,const gchar *src,gsize n); That's one not needed as strncpy should work. hehe i know but that function it really exist: http://library.gnome.org/devel/glib/unstable/glib-Unicode-Manipulation.html#g-utf8-strncpy It does make sense.

Re: GSeal bugs in GtkAccelLabel hampering flexibility

2009-01-26 Thread Peter Clifton
On Mon, 2009-01-26 at 16:34 -0500, Behdad Esfahbod wrote: Peter Clifton wrote: If you want a workaround for now, just access the member as GSEAL(member_name). I told them the GSEAL macro should use __line__, they didn't listen :P. Ok - didn't know I could do that. I had presumed the

Re: GSeal bugs in GtkAccelLabel hampering flexibility

2009-01-26 Thread Peter Clifton
On Mon, 2009-01-26 at 22:09 +, Peter Clifton wrote: I can't grep a single reference defining the GSEAL macro in /usr/include, nor _g_seal__. Yet magically -DGSEAL_ENABLE makes the code compilation break by hiding those members. Am I being dumb...? What black magic is going on here?

Re: utf-16 and glib

2009-01-26 Thread Martin (OPENGeoMap)
Dominic Lachowicz escribió: What is wrong with: gchar* g_utf8_strncpy (gchar *dest,const gchar *src,gsize n); That's one not needed as strncpy should work. hehe i know but that function it really exist:

Re: utf-16 and glib

2009-01-26 Thread Behdad Esfahbod
Martin (OPENGeoMap) wrote: Dominic Lachowicz escribió: What is wrong with: gchar* g_utf8_strncpy (gchar *dest,const gchar *src,gsize n); That's one not needed as strncpy should work. hehe i know but that function it really exist:

Re: utf-16 and glib

2009-01-26 Thread Dominic Lachowicz
Glib/gtk is full of macros. I believe que a C compiler is the right place to this kind of unsafe code. If i want create safe code i have c#,c++, JAVA, D or VALA. Using macros is the only way to ensure intermediate APIs don´t have any overhead. Besides modern GUIs have support to understand

Re: utf-16 and glib

2009-01-26 Thread Martin (OPENGeoMap)
Maciej Piechotka escribió: On Mon, 2009-01-26 at 23:48 +0100, Martin (OPENGeoMap) wrote: Dominic Lachowicz escribió: What is wrong with: gchar* g_utf8_strncpy (gchar *dest,const gchar *src,gsize n); That's one not needed as strncpy should work.

Re: utf-16 and glib

2009-01-26 Thread Behdad Esfahbod
Martin (OPENGeoMap) wrote: hummm. Example: If we have for example a DWG binary file we have for example 15000 utf16 strings. If i use glib i need make 15000 translations utf16/utf8 to use the utf8 glib api. When i need save the file i need make other 15000 translations. There are thounsand

Re: utf-16 and glib

2009-01-26 Thread Philip Withnall
On Tue, 2009-01-27 at 00:19 +0100, Martin (OPENGeoMap) wrote: hummm. Example: If we have for example a DWG binary file we have for example 15000 utf16 strings. If i use glib i need make 15000 translations utf16/utf8 to use the utf8 glib api. When i need save the file i need make other

Re: utf-16 and glib

2009-01-26 Thread Behdad Esfahbod
Martin (OPENGeoMap) wrote: I don´t want say we MUST add more support to glib. I only say most software developers works with utf16 text and many of that people are not fan of that encoding but they must use it in the 100% of the source code. Other than making a lot of noise, what are you

GTK+ 2.15.2 released

2009-01-26 Thread Matthias Clasen
GTK+ 2.15.2 is now available for download at: http://download.gnome.org/sources/gtk+/2.15/ gtk+-2.15.2.tar.bz2 md5sum: 1c230eeb1bf24b69b480d0a35da34794 gtk+-2.15.2.tar.gz md5sum: 1e9d42fb6bdfb6752a82f6c3afc3b3e7 This is another development release leading up to GTK+ 2.16. Notes: * This