I just learned that GNU gettext will soon have official support for
disambiguating context in translations.
This is great. However, Bruno decided to not implement the somewhat
ad-hoc solution which has been recommended for years in the gettext
manual, and implemented in glib using Q_(), which is
Havoc Pennington wrote:
>On Tue, 2005-12-20 at 17:27 +0100, Tim Janik wrote:
>
>
>>GObject:
>>- created with ref_count=1
>>- not initially floating
>>
>>
>
>This is the key I think. The point of my theoretical rant is that I
>think it's really bad if I do:
>
> obj = g_object_new(TYPE_WHATEVE
On Wed, Dec 21, 2005 at 12:07:14AM +, Paul LeoNerd Evans wrote:
> > > void g_string_init(GString *str);
> > > void g_string_fini(GString *str);
Actually, it occurs to me. If we wanted to give certain future
guarantees about GString, we could do something like the following:
#define GSTR
On Wed, Dec 21, 2005 at 01:19:59AM +0100, Øyvind Kolås wrote:
> At least in my sources, and where they draw inspiration from there is
> a larger precedence for the suffix _dup, rather than _clone.
g_string_dup() also works, yes.. I'm not overly attached to the name.
Thoughts anyone?
--
Paul "L
On 12/20/05, Paul LeoNerd Evans <[EMAIL PROTECTED]> wrote:
> * g_string_clone() is a convenient wrapper to take a copy of an
> existing GString;
>
> g_string_clone(s) == g_string_new(s->str)
>
> Except it returns NULL if s == NULL.
At least in my sources, and where they draw inspiration
On Tue, 2005-12-20 at 23:48 +, Paul LeoNerd Evans wrote:
> That said, I don't see why we need a new split function, on reflection.
> Maybe a:
>
> GString** g_string_new_strv(gchar** a);
>
> would be useful; it would return a NULL-terminated array of new
> GString*s, each one wrapping a stri
(Appologies for the pun in the subject; I couldn't help myself.. :) )
On Tue, Dec 20, 2005 at 03:52:28PM -0800, Alan M. Evans wrote:
> > void g_string_init(GString *str);
> > void g_string_fini(GString *str);
> >
> > Which would do most of the work of g_string_new() and g_string_free()
> > re
On Tue, 2005-12-20 at 15:38, Paul LeoNerd Evans wrote:
> This idea would require two new functions:
>
> void g_string_init(GString *str);
> void g_string_fini(GString *str);
>
> Which would do most of the work of g_string_new() and g_string_free()
> respectively, apart from the initial struc
On Tue, Dec 20, 2005 at 06:31:01PM -0500, Owen Taylor wrote:
> At a high-level, I think there is a question of "what GString is" -
> should there be GString versions of everything you want to do
> with a char *?
>
> My opinion is no ... a GString is the equivalent of a Java
> StringBuffer .. it
On Wed, Dec 21, 2005 at 12:33:23AM +0100, Emmanuele Bassi wrote:
> EIther way, you would have another type out: GStringList would be a
> G(S)List of GString; you would have to use:
>
> GSList *iter; /* or GList *iter; */
> for (iter = stringlist; iter != NULL; iter = iter->next)
> do_somet
On Tue, Dec 20, 2005 at 03:26:45PM -0800, Alan M. Evans wrote:
> > Not entirely certain I like this. See below.
> >
> > > GStringList* g_string_split(GString *str, gchar c);
> >
> > Seems to me this should return a gchar** a-la g_strsplit().
>
> I take that back. I can always use g_strsplit()
Hi,
There's no need to Cc: me - I'm subscribed to the list.
On Tue, 2005-12-20 at 23:12 +, Paul LeoNerd Evans wrote:
> > > gint g_string_indexof(GString *str, gchar c);
> >
> > This would be useful with Unicode support, or with a gunichar variant.
>
> I can have a go at a Unicode-awar
At a high-level, I think there is a question of "what GString is" -
should there be GString versions of everything you want to do
with a char *?
My opinion is no ... a GString is the equivalent of a Java
StringBuffer .. it is a useful way to build and work with strings,
but it isn't *a string*.
On Tue, 2005-12-20 at 15:18, Alan M. Evans wrote:
> On Tue, 2005-12-20 at 14:36, Paul LeoNerd Evans wrote:
>
> > typedef GList GStringList;
>
> Not entirely certain I like this. See below.
>
> > GStringList* g_string_split(GString *str, gchar c);
>
> Seems to me this should return a gchar**
On Tue, 2005-12-20 at 14:36, Paul LeoNerd Evans wrote:
> typedef GList GStringList;
Not entirely certain I like this. See below.
> GStringList* g_string_split(GString *str, gchar c);
Seems to me this should return a gchar** a-la g_strsplit(). Whether or
not this is more useful may depend on
On Wed, Dec 21, 2005 at 12:00:52AM +0100, Emmanuele Bassi wrote:
> Can you please open a bug inside http://bugzilla.gnome.org and attach
> the patch there? Tracking patches on Bugzilla makes things easier than
> on a mailing list.
Shall do.
> Apart from g_string_new_lenz() which I don't understan
On Tue, Dec 20, 2005 at 02:43:43PM -0800, Alan M. Evans wrote:
> GStrings are already guaranteed to have a nul terminating byte, aren't
> they?
Ah; yes, in fact, they are. I had thought they weren't, in the case of
calling g_string_new_len(), because I tried it one time and found a bug.
I'd just p
Hi,
On Tue, 2005-12-20 at 22:36 +, Paul LeoNerd Evans wrote:
> As promised earlier, here's a patch with some new functions for GString.
> I'll split them up with related changes, so this is just the first of a
> sequence.
Can you please open a bug inside http://bugzilla.gnome.org and attach
t
On Tue, 2005-12-20 at 14:36, Paul LeoNerd Evans wrote:
> * g_string_new_lenz() is similar to g_string_new_len(), only it appends
> a terminating nul byte to the string buffer, making it safe to
> printf() or use as a normal gchar* string.
GStrings are already guaranteed to have a nul terminati
As promised earlier, here's a patch with some new functions for GString.
I'll split them up with related changes, so this is just the first of a
sequence.
There's 3 functions added here, g_string_clone, g_string_new_lenz, and
g_string_slice. Each is a constructor, to return a new GString object.
GLib defines a function to append data in a GString using a printf-like
call,
void g_string_append_printf(GString *str, const gchar *fmt, ...);
Is there any reason why a va_list-version isn't provided as well for
this? Without that, it is impossible to further wrap va-list or
...-style function
On Tue, Dec 20, 2005 at 02:47:32PM -0500, Tristan Van Berkom wrote:
> CVSROOT=:pserver:[EMAIL PROTECTED]:/cvs/gnome
>
> cvs co glib
Ahh wonderful. And thanks for the speedy reply - most helpful.
I now have a checkout; I'm presuming a standard ./autogen.sh ; make
procedure here. Any special confi
Paul LeoNerd Evans wrote:
[...]
I am however, having difficulty finding a CVS source for GLib. There's
no mention on either the www.gnome.org or www.gtk.org sites about it.
What is the accepted submission method for this? Do you work to some CVS
source, or should I just download latest stable tar
I've been developing a program over the last 2 years that quite heavily
uses GStrings for lots of its work. As a result, I've collected up a
useful set of extra functions I think GLib would benefit from.
My plan was to submit a number of patches, with groups of related
functions added in each pat
On Tue, 2005-12-20 at 09:37 -0800, Dave Benson wrote:
>
> why does one want GFloatingObject?
> it seems like calling g_object_force_floating()
> isn't too hard... and derivation is a somewhat
> inflexible way to set flags (for example, it
> can't be done in a subsubclass of object;
> and to suppo
On Tue, 2005-12-20 at 17:27 +0100, Tim Janik wrote:
> GObject:
> - created with ref_count=1
> - not initially floating
This is the key I think. The point of my theoretical rant is that I
think it's really bad if I do:
obj = g_object_new(TYPE_WHATEVER);
and don't know whether I own a refcount or
> GFloatingObject, derived from GObject:
> - created with ref_count=1
> - initial reference is floating
>
> GtkObject, derived from GFloating object:
> - created with ref_count=1
> - initial reference is floating
> - floating flag is implemented as GtkObject.flags>K_FLOATING
> via a compat hook,
On Sat, 17 Dec 2005, Dave Benson wrote:
On Thu, Dec 15, 2005 at 05:07:34PM +0100, Tim Janik wrote:
On Thu, 15 Dec 2005, Dave Benson wrote:
[long discussion cut]
this thread never really addressed my concern,
which was that this makes it so that container classes
before 2.10 have one style, an
On Tue, 20 Dec 2005, Havoc Pennington wrote:
Hi,
[much theoretical rant that i don't think is worth discussing in detail again]
Full proposal:
- GObject has a floating flag, but it's false by default and
object creator owns a hard reference
- there's a method float() to set the floating f
On Tue, 2005-12-20 at 10:29 -0500, Owen Taylor wrote:
> But the sweet spot for cheap hardware and usable old hardware
> is well above the 8bpp line; GNOME hasn't support 8bpp *well*
> for 5 years, and we've had very few complaints.
Metacity doesn't even properly support all the colormap stuff the
Hi,
The way I've always thought about the floating flag is that when you
create a new object, *you* don't own a reference. Instead, there's a
floating reference with no owner, and anyone is allowed to remove that
floating reference since it's "community property" - the "if floating
exists remove i
On Mon, 2005-12-19 at 17:49 +, Bill Haneman wrote:
> OK, I understand that nobody wants to spend time fixing code that's only
> exercised on obsolete hardware. But it's worth remembering that one of
> the key areas of interest/growth for Gnome is the low-cost and used
> hardware community i
Maybe it would be helpful to have a list of graphics cards that are
known not to work. Maybe in the wiki?
--
Murray Cumming
[EMAIL PROTECTED]
www.murrayc.com
www.openismus.com
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.o
33 matches
Mail list logo
