On Mon, 2009-11-30 at 08:30 -0500, Matthias Clasen wrote:
> I'd just drop that kind of thing; I did study lattice theory and know
> what a bounded join-semilattice is, but I doubt this information will
> help anybody to use GVariant...
OTOH, just this morning I woke up to:
07:35 -!- Irssi: Start
Hi everyone,
FWIW, the patch has been merged now.
Cheers
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
On Thu, 2009-11-12 at 19:49 +0100, Alexander Larsson wrote:
> On Thu, 2009-11-12 at 16:45 +0100, Stanislav Brabec wrote:
>
> > I think that gmodule-2.0.pc is the best place to add needed fix, as
> > loading of threaded modules is the main originator of all these
> > problems.
>
> I agree, this se
On Tue, 2009-11-17 at 15:03 +0100, Alexander Larsson wrote:
> I guess we should bit the bullet and just do this correctly, deprecating
> the old function and creating a new one. Not sure what to best name it
> though.
>
> g_data_input_stream_read_until_found maybe?
>
If we're going to do this, I
On Thu, 2009-11-12 at 19:49 +0100, Alexander Larsson wrote:
> On Thu, 2009-11-12 at 16:45 +0100, Stanislav Brabec wrote:
>
> > I think that gmodule-2.0.pc is the best place to add needed fix, as
> > loading of threaded modules is the main originator of all these
> > problems.
>
> I agree, this se
On Fri, 2009-11-13 at 14:50 +0100, Alexander Larsson wrote:
> I don't like breaking API like this. Especially since I think its the
> sync call that is really broken, and we should not also break the async
> one.
Ok. Some questions from when I went to do the patch:
What happens in the case that
Hi
On Fri, 2009-11-13 at 14:50 +0100, Alexander Larsson wrote:
> I don't like breaking API like this. Especially since I think its the
> sync call that is really broken, and we should not also break the async
> one.
The solution you propose is actually closer to the one that I ultimately
like. I
Hi
I want to make a small break to the API of GDataInputStream.
The details are in bug #584284.
https://bugzilla.gnome.org/show_bug.cgi?id=584284
The summary:
When I implemented the async versions of read_line() and read_until() I
got the semantics of the read_until_async() function very slig
On Thu, 2009-11-12 at 14:57 +0100, Alexander Larsson wrote:
> One issue with this change is that it sort of breaks the whole reason
> for having libgthread in a separate library.
Ben has indicated that he thinks that by 3.0 threading should be
non-optional in all glib applications on the premise t
On Thu, 2009-11-12 at 14:04 +0100, Stanislav Brabec wrote:
> Other possibilities:
> - Cleanly say, that dynamic loading of modules linked with libpthread is
> not recommended.
This would definitely be the nicest solution, but I doubt that it is
possible.
Cheers
_
On Thu, 2009-11-12 at 00:27 -0500, Behdad Esfahbod wrote:
> > libdbus links against libpthread.
>
> My only question is: can't this be fixed instead? I don't immediately see
> why not..
dbus has a threading abstraction layer just like glib does. The
difference between dbus and glib is that db
Hi
Since there has been so much love on the list lately for linking GIO to
some extra libs, I want to do one more.
I have it on good authority[1] that it's a no-no to dlopen() libpthread
into an executable that is not, itself, linked against libpthread. The
rationale for why this is bad is somet
On Wed, 2009-11-11 at 09:31 -0500, David Zeuthen wrote:
> Should probably define an abstract GDBusHandleSet interface and then
> have a concrete GDBusUnixFdSet class (and possibly a GDBusWin32HandleSet
> too) implement it.
I'm not totally sure that this makes sense. The support that exists in
DBu
On Mon, 2009-11-09 at 08:21 -0500, David Zeuthen wrote:
> Sorry for the lag,
No problems :)
> Hmm, I don't like this approach. It means you'd have to pass this
> GDBusFDSet object around in code you use to build/parse the GVariant. In
> particular, your proposed GTypeSerializer would need suppor
On Tue, 2009-10-20 at 11:17 -0400, David Zeuthen wrote:
> So how about something like 1. and 2. below? We'd put
>
> g_dbus_connection_get_handle_for_unix_fd()
> g_dbus_connection_set_handle_for_unix_fd()
I was actually thinking that we could introduce a GDBusFDSet:
gint g_dbus_fd_set_add_fd (g
On Tue, 2009-10-27 at 21:03 -0400, Matthias Clasen wrote:
> Just to run down the concepts you meet while reading this chapter,
> mostly without introduction or explanation:
> - type classes
> - basic types, maybe types, container types
> - 'any' types
> - generic types
> - variant types and type st
On Thu, 2009-10-15 at 12:24 -0400, David Zeuthen wrote:
> Yeah, hmm, while this is theoretically nice and everything, I'm not sure
> it's worth the effort to do just yet. I think it's better to just ensure
> that libdbus-1 is available (and working) on all platforms where we care
> about GLib (e.g.
On Thu, 2009-10-15 at 12:38 -0400, David Zeuthen wrote:
> Yeah, I think we need to support this from the get-go.
>
> Anyway, at the end of the day, UNIX fds are just integers so if you
> require that users (such as GDBus itself and apps using GDBus) keep the
> fds alive until the method/signal ha
Hi everyone,
On Wed, 2009-10-14 at 21:34 -0400, David Zeuthen wrote:
> There was an amazing amount of consensus; here's a brief list
I am in complete agreement with any point in the list that I am not
directly addressing. Other comments below:
> - Ideally make insane things impossible to do
>
Matthias Clasen wrote:
On Tue, May 12, 2009 at 9:50 AM, Ryan Lortie wrote:
Since GtkTreeModel also has no
reason to depend on (the rest of) GTK, it seems logical to move it into
glib.
It is not that GtkTreeModel depends on the rest of GTK+, it is more
that GtkTreeModel is designed for being
Thomas Wood wrote:
I think the Clutter project has it's own model implementation only
because there isn't one in glib. There isn't actually a consumer in
Clutter for ClutterModel, but other libraries built on top of Clutter
use it.
Yes. It's exactly about libraries.
I have a similar situation
Szilárd Pfeiffer wrote:
What do you want to do with that? What about GNode? Isn't it good for you?
I should have been slightly more clear: I am interested in being able
to provide a GtkTreeModel for those people who wish to use it without
having to link to libgtk myself.
So the problem wit
are there any 3ish plans for GtkTreeModel -> GTreeModel?
cheers
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Alexander Larsson wrote:
GIOStream.c:
This is currently an interface, while the related GInputStream and
GOutputStreams are base classes. This isn't necessarily wrong by itself,
but looks a bit weird. There are also other reasons (see below) why it
would be nice if it was a class, so
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
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
Dan Winship wrote:
(Alternate possibility: add a way to include type tags, so that callers
and callees can agree that a particular "x" is to be treated as a time_t
and not a generic int64. Eg, a signature of ":x" would mean a (string)
type tag followed by an int64, but it would be distinct from "
Hi David
Thanks for your reply.
David Zeuthen wrote:
- GVariant brings in a completely new type system
That's not entirely true. The DBus type system is being used and loved
by many people already and GVariant is using that type system. GVariant
merely brings this type system into glib.
Hello Everyone!
I'm proposing GVariant for inclusion in glib this cycle.
I've created a 'gvariant' branch of glib and pushed it to the official
repository.
For those who don't know what GVariant is, please see the announcement
email here:
http://mail.gnome.org/archives/gnome-announce-list/
Gustavo Noronha wrote:
On Wed, 2009-02-11 at 01:07 -0500, Matthias Clasen wrote:
- What do we do about the added 16bit integer types that are supported
by the DBus protocol, but don't have corresponding fundamental types in
GObject ? EggDbus currently has fundamental types for them.
It just st
like this isn't something that has really
been flamed on as much as maybe it should be. Havoc tried to bring
this topic up in another thread and as far as I can tell it didn't
get a whole lot of play there.
There is also some work by Ryan Lortie on a Glib-compatible Dbus api
calle
On Thu, 2008-07-31 at 13:39 -0400, Havoc Pennington wrote:
> At the point that all compilers anyone cares about support a
> _particular_ C99 feature, that particular feature would presumably not
> require #ifdefs, but the fact that the feature is in C99 doesn't
> matter - what matters is whether al
Hello.
void print (va_list *ap)
{
printf ("%d\n", va_arg (*ap, int));
}
void test (int num, ...)
{
va_list ap;
int i;
va_start (ap, num);
for (i = 0; i < num; i++)
print (&ap);
va_end (ap);
}
int main (void)
{
test (3, 1, 2, 3);
return 0;
}
ISO C99 (footnote 215, §7.15) say
On Mon, 2008-03-17 at 14:16 +0400, Alexander Shaduri wrote:
> Hi all,
>
> Having studied the FSF licenses and their restrictions, I think
> it would be reasonable to re-license GTK+ under the LGPLv3
> (or later) + GPLv2 linking exception (or, alternatively, simply
> multi-license it under LGPLv3 /
Hello.
After some talk at the Hackfest about it, I'm writing the list to
officially request that glib and GTK be moved to LGPL "version 3 or
later".
The reasons for this are the increased clarity in the language of the
license plus the ability to accept LGPL3 code into glib/gtk ((since it
seems l
I should have known better than this. 'collected' used to be a 32bit
integer so I forgot to make the change when I switched it to 64.
Please tell me that you weren't actually bitten by this bug... If you
were, then I have a good deal of sympathy for your parser :)
Note that we have G_GUINT64_CO
sorry for the long delay in replying. it's been a hectic week with
family events and friends back from school to visit.
the problem is pretty simple. i'm not sure it is explicitly documented
as such, but i've mentioned before that the redirection is currently
only supported for 1:1 mappings. th
On Tue, 2007-11-20 at 17:13 +0100, Mathias Hasselmann wrote:
> For supporting your feature there should be a separate call:
>
> void (*get_supported_sizes) (GtkOrientation orientation,
> GtkRequisition **sizes,
>guint
On Wed, 2007-11-07 at 17:45 +0200, Xan wrote:
> On Nov 7, 2007 5:35 PM, Alexander Larsson <[EMAIL PROTECTED]> wrote:
> > The idea is that this library would contain non-ui stuff that
> > applications want but that requires GObject, so they can't be in glib.
> > Various names for this library has be
201 - 240 of 240 matches
Mail list logo
