displaying a number on screen

Hi, I am sorry if this is not the right mailing list. For given x and y co-ordinates is it possible to display a particular number at that position? or in other words, is it possible to paint a number or character on the screen at a given point? Thanks in advance. -- regards, Nischal E Rao

GLib 2.24.0 released

GLib 2.24.0 is now available for download at: ftp://ftp.gtk.org/pub/glib/2.24 http://download.gnome.org/sources/glib/2.24 sha256 sums: 7b6aa2cf21e734a6092a711bf196b8d2ddc589b971f93337610c10fa4f23400d glib-2.24.0.tar.bz2 579a668cef12e1db63ee15bbaccc2c9067aee095d85a5eafe4b9d8d4499febfc

Re: glib's role in the units policy game

On Sat, 2010-03-27 at 02:44 +0100, Benjamin Drung wrote: Hi, I am sending this mail to gtk-devel list to catch as many ideas and opinions as possible, if you not already following bug #554172 [1]. Ubuntu has now a units policy [2] and I want to implement it, but I am still not sure what

Re: Faster UTF-8 decoding in GLib

On 03/26/2010 05:43 PM, Daniel Elstner wrote: Hi Behdad, Am Freitag, den 26.03.2010, 13:25 -0400 schrieb Behdad Esfahbod: * The construct borrowed from glibmm, as beautiful as it is, is WRONG for 6-byte-long UTF-8. It just doesn't work. We historically support those sequences.

Re: Faster UTF-8 decoding in GLib

Hi, Am Samstag, den 27.03.2010, 16:12 -0400 schrieb Behdad Esfahbod: Err, you're right. My bad. It's still broken though since it doesn't check that the fragment bytes all start with the bits 10. Missing error checking. It is not meant to check for errors. I think it is totally arbitrary

Re: Faster UTF-8 decoding in GLib

On 03/27/2010 04:27 PM, Daniel Elstner wrote: Hi, Am Samstag, den 27.03.2010, 16:12 -0400 schrieb Behdad Esfahbod: Err, you're right. My bad. It's still broken though since it doesn't check that the fragment bytes all start with the bits 10. Missing error checking. Looking at:

Re: Faster UTF-8 decoding in GLib

Hi, Am Samstag, den 27.03.2010, 16:51 -0400 schrieb Behdad Esfahbod: On 03/27/2010 04:27 PM, Daniel Elstner wrote: It is not meant to check for errors. Good point. I think it is totally arbitrary to handle some potential errors but not others. And I think the current implementation

Re: Faster UTF-8 decoding in GLib

On 03/27/2010 05:21 PM, Daniel Elstner wrote: Well, I assume that ints are at least 32 bit wide on any platform supported by GLib. But if you meant to say that it would break with larger ints, I don't see why. As long as the type is unsigned, it should be fine. If the utf8 byte has more

Re: Faster UTF-8 decoding in GLib

Hi, Am Samstag, den 27.03.2010, 17:40 -0400 schrieb Behdad Esfahbod: On 03/27/2010 05:21 PM, Daniel Elstner wrote: Well, I assume that ints are at least 32 bit wide on any platform supported by GLib. But if you meant to say that it would break with larger ints, I don't see why. As long

Re: Faster UTF-8 decoding in GLib

On 03/27/2010 05:49 PM, Daniel Elstner wrote: Hi, Am Samstag, den 27.03.2010, 17:40 -0400 schrieb Behdad Esfahbod: On 03/27/2010 05:21 PM, Daniel Elstner wrote: Well, I assume that ints are at least 32 bit wide on any platform supported by GLib. But if you meant to say that it would break

Re: Faster UTF-8 decoding in GLib

Hi, Am Samstag, den 27.03.2010, 18:04 -0400 schrieb Behdad Esfahbod: Sure, I wasn't referring to valid data. In valid UTF-8, there is no 5byte or 6byte sequences either. True, but that was a post-hoc restriction imposed afterwards, when Unicode was redefined as a 21-bit character set,

GLib 2.24.0 released

GLib 2.24.0 is now available for download at: ftp://ftp.gtk.org/pub/glib/2.24 http://download.gnome.org/sources/glib/2.24 sha256 sums: 7b6aa2cf21e734a6092a711bf196b8d2ddc589b971f93337610c10fa4f23400d glib-2.24.0.tar.bz2 579a668cef12e1db63ee15bbaccc2c9067aee095d85a5eafe4b9d8d4499febfc