On 04/13/2009 05:00 AM, Butrus Damaskus wrote:
Hi!
This page: http://bjoern.hoehrmann.de/utf-8/decoder/dfa/ claims to
have better (quicker and smaller?) utf8 decoder. Maybe it would be
worth to look at it?
Funny how he claims "reduced complexity". That's definitely the most complex
UTF-8 dec
Havoc Pennington wrote:
Hi,
On Mon, Apr 13, 2009 at 4:32 PM, Simon McVittie
wrote:
On Mon, 13 Apr 2009 at 15:56:36 -0400, Havoc Pennington wrote:
It looked like you might allow non-string dict keys, was one I noticed.
Er, so does D-Bus... Telepathy uses a{uu} in at least one place.
I person
Hi,
On Mon, Apr 13, 2009 at 4:32 PM, Simon McVittie
wrote:
> On Mon, 13 Apr 2009 at 15:56:36 -0400, Havoc Pennington wrote:
>> It looked like you might allow non-string dict keys, was one I noticed.
>
> Er, so does D-Bus... Telepathy uses a{uu} in at least one place.
>
> I personally think D-Bus
On Mon, 13 Apr 2009 at 15:56:36 -0400, Havoc Pennington wrote:
> It looked like you might allow non-string dict keys, was one I noticed.
Er, so does D-Bus... Telepathy uses a{uu} in at least one place.
I personally think D-Bus has about the right balance for what to allow as a
key in a dict (any
Hi,
On Mon, Apr 13, 2009 at 3:00 PM, Ryan Lortie wrote:
> - dictionary entries in GVariant can stand freely (ie: they are not
> restricted to being contained in an array).
What does it mean if you have a free-floating dict entry? Are you
supposed to treat as a dict with one entry? Or treat a
Hi,
On Mon, Apr 13, 2009 at 3:00 PM, Ryan Lortie wrote:
> GVariant has nullable ("maybe") types which were a proposed extension to
> DBus some time ago but never materialised. iirc, Havoc, you had a
> favourable opinion of this extension but wasn't sure exactly how we'd handle
> the compatibilit
Mikkel Kamstrup Erlandsen wrote:
I have been silently anticipating GVariant for a while now and I am
very happy to see it coming forth now. I am bit in the same camp as
Dan here... My primary interest is not necessarily passing GVariants
over DBus (although I would also love to do that), but more
Havoc Pennington wrote:
Reading the gvariant and gbus source btw, this would be somewhat
misleading at the moment; gvariant's type system is a dbus superset,
and its serialization format is a proposed "dbus v2" format that may
or may not ever get used by dbus. (One of the main barriers being that
From: "Mikkel Kamstrup Erlandsen", Date: 13/04/2009 21:45, Wrote:
> How about dropping GVariant data in a human readable form to a
> file? I often find myself in the following scenario: I have data that
> is really not well suited for GConf and can't fit in a GKeyFile, and I
> also want to allow e
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Grzegorz Kuczyński a écrit :
> Colomban Wendling pisze:
>> Simply because access to window->title will not be possible any
>> more, as I explained in another mail.
>>
>> - another mail: No, AFAIK, GSEAL_ENABLE is not meant to be
>> put in any GTK+
Colomban Wendling pisze:
Simply because access to window->title will not be possible any more,
as I explained in another mail.
- another mail:
No, AFAIK, GSEAL_ENABLE is not meant to be put in any GTK+ header,
only to be added by hand to your programs' compiling options (e.g.
- -DGSEAL_ENABL
Hi,
On Mon, Apr 13, 2009 at 7:45 AM, Mikkel Kamstrup Erlandsen
wrote:
>
> * I really hope there is room in GVariant for NULL values in some way
> or other. Without a NULL it is hard to map stuff from an SQL DB
> directly to the serialization format without nasty hacks. This has
> bitten me sever
Hello. I am writin to tou to ask a few questions.
The first problem is how to disable icons on GtkButton? There is description
how to change spacing bewtween label nad the icon, but I can't find a solution
to disable icons at all.
The second question is how to change spacing between scroll and t
I am learning gtk+ version 2.12. Currently I am trying to implement icon
view, showing thumbnails with text labels. The code I used is as follows:
const char* list[] =
{
"1",
"2" ,
"3",
"4",
NULL
};
filename = gtk_file_chooser_get_filename (
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Grzegorz Kuczyński a écrit :
> A. Walton pisze:
>> 2009/4/12 A. Walton : ...
>>
>> gtk_window_set_title() is inside of gtk+ and won't need to
>> change. The macro is to prevent external applications from doing
>> window->title = whatever; and instead a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Grzegorz Kuczyński a écrit :
> Colomban Wendling pisze:
>>> Ok I understand the idea, but... how work it? for example:
>>> --- struct _GtkWindow { GtkBin bin;
>>>
>>> gchar *GSEAL (title); --- void gtk_window_set_title
>>> (GtkW
2009/4/9 Dan Winship :
> Ryan Lortie wrote:
>> The type system, of course, is that of DBus.
>>
>> I love your feedback. Please give it all to me.
>
> I took at a look at GVariant from the perspective of "could I make
> libsoup's XML-RPC (and future JSON) code use GVariant instead of
> GValue". (Fo
Tor Lillqvist pisze:
So to protection is enable - must include gdkconfig.h.win32 in my
aplications?
Eek, no. Include gdkconfig.h. Including the normal GTK+ headers
already does that for you.
When building GTK+ for Windows with MSVC, gdkconfig.h.win32 is copied
to gdkconfig.h.
If building
Hi!
This page: http://bjoern.hoehrmann.de/utf-8/decoder/dfa/ claims to
have better (quicker and smaller?) utf8 decoder. Maybe it would be
worth to look at it?
BBD
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/lis
> So to protection is enable - must include gdkconfig.h.win32 in my
> aplications?
Eek, no. Include gdkconfig.h. Including the normal GTK+ headers
already does that for you.
When building GTK+ for Windows with MSVC, gdkconfig.h.win32 is copied
to gdkconfig.h.
If building GTK+ for Windows using m
A. Walton pisze:
2009/4/12 A. Walton :
...
gtk_window_set_title() is inside of gtk+ and won't need to change. The
macro is to prevent external applications from doing window->title =
whatever; and instead applications should (and will be forced to use)
gtk_window_set_title().
"will be fo
21 matches
Mail list logo
