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 is
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 y
Philip Withnall escribió:
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
Peter Clifton wrote:
> Turns out about 20% of our source files don't compile with
> -DGSEAL_ENABLE anyway, so looks like we've got some work to do before
> GTK3.0 comes out ;). Oh.. and a fair number of these bugs were in my
> "stolen and modified from GTK sources" GtkAction and GtkAccelLabel
> su
"Martin (OPENGeoMap)" writes:
> Maciej Piechotka escribió:
>> On Mon, 2009-01-26 at 23:48 +0100, Martin (OPENGeoMap) wrote:
>>
>>> I believe que a C compiler is the right place to this kind of
>>> unsafe code.
>>>
>>
>> What do you mean by 'unsafe'? If the 'unsafe' code is unsafe there is
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 othe
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 thoun
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.
> 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 understan
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:
>>> ht
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:
http://library.gnome.org/devel/glib/unstable/glib-Unicode-Manipulation.h
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?
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 ha
>>> 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
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
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 pr
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 GT
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
Martín Vales writes:
> Colin Walters escribió:
>> On Mon, Jan 26, 2009 at 9:12 AM, Behdad Esfahbod 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
To be honest -
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'
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 wrote:
> >
> >> Lets just say that
> >> UTF-16 is at best implementation details of Firefox.
> >>
> >
> > Well, JavaScript is notably UTF-16. Given that th
Colin Walters escribió:
On Mon, Jan 26, 2009 at 9:12 AM, Behdad Esfahbod 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 li
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 o
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 fac
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 yo
On Mon, Jan 26, 2009 at 9:12 AM, Behdad Esfahbod 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 us for quite a w
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
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 fal
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 wrote:
> >
> >
> >> Other overhead i see is the open dir/file funtions, where in windows we
> >> need do the utf8 to utf16 everytime in windows. I
Paul LeoNerd Evans escribió:
On Sun, 18 Jan 2009 17:43:57 +0100
Martín Vales 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?.
On Mon, 19 Jan 2009 20:07:09 -0600
Federico Mena Quintero 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 them glaringly missin
On Sun, 18 Jan 2009 17:43:57 +0100
Martín Vales 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 one of the biggest
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 t
33 matches
Mail list logo
