Re: GInterfaces and API Stability

On Wed, 2007-11-07 at 22:42 -0500, Owen Taylor wrote: > > > I'm hoping this is just one of those "oops, never thought of that" kinds > > > of issues and the gtk+ and atk maintainers will avoid extending these > > > stable interfaces going forward. It's a significant binding support > > > issue.

Re: GInterfaces and API Stability

On Wed, 2007-11-07 at 20:47 -0500, Matthias Clasen wrote: > On Nov 7, 2007 4:58 PM, Mike Kestner <[EMAIL PROTECTED]> wrote: > > I have been working on the 2.12 bindings for Gtk# and have noticed a > > stability issue for us related to GInterfaces. In Atk and Gtk, it seems > > there is no restrict

Re: [PATCH]: Fix SIGBUS in JPEG handling on RISC

From: Owen Taylor <[EMAIL PROTECTED]> Date: Sat, 03 Nov 2007 21:16:38 -0400 > On Sat, 2007-11-03 at 15:50 -0700, David Miller wrote: > > Alternatively, we can say that GTK+ knows better and simply > > block out such dumb platforms at the top-level configure :-) > > Plus you don't want to trap

GLib branched for 2.14

I have just created a glib-2-14 branch which will continue to receive bugfixes and produce 2.14.x releases. The work that we expect to land in trunk soon is the gio work that Alex' has been working on for a while. He sent out a mail outlining our merge plans earlier today. Matthias __

Re: GInterfaces and API Stability

On Nov 7, 2007 4:58 PM, Mike Kestner <[EMAIL PROTECTED]> wrote: > I have been working on the 2.12 bindings for Gtk# and have noticed a > stability issue for us related to GInterfaces. In Atk and Gtk, it seems > there is no restriction against adding methods to stable GInterfaces. > There have been

GInterfaces and API Stability

I have been working on the 2.12 bindings for Gtk# and have noticed a stability issue for us related to GInterfaces. In Atk and Gtk, it seems there is no restriction against adding methods to stable GInterfaces. There have been numerous additions to the Atk interfaces while in "stable" mode. A Get

Re: Merging gio into glib

On Wed, 2007-11-07 at 22:30 +0100, Alexander Larsson wrote: > > > It will mean that applications linking to libglib will suddenly pull in > more dependencies however. Thats not something that really happens with > e.g. gobject, and for gmodule the extra library is from glibc. > > For instance, i

Re: Merging gio into glib

On Wed, 2007-11-07 at 21:46 +0100, Alexander Larsson wrote: > On Wed, 2007-11-07 at 13:32 -0500, Behdad Esfahbod wrote: > > On Wed, 2007-11-07 at 11:06 -0500, Ryan Lortie wrote: > > > > > > One library, one .so file, one pkg-config file. > > > > I'd say do a hybrid: separate pkg-config files, si

Re: Merging gio into glib

On Wed, 2007-11-07 at 16:18 -0500, Behdad Esfahbod wrote: > On Wed, 2007-11-07 at 16:07 -0500, Alexander Larsson wrote: > > > > glib would need dbus as a build requirement for this to work (needs the > > dbus types), and the glib header for the function would have to be > > separate (with a separa

Re: Merging gio into glib

On Wed, 2007-11-07 at 16:07 -0500, Alexander Larsson wrote: > > glib would need dbus as a build requirement for this to work (needs the > dbus types), and the glib header for the function would have to be > separate (with a separate .pc file for it) so that it can include > dbus.h, but it would wo

Re: Merging gio into glib

On Wed, 2007-11-07 at 14:55 -0500, Havoc Pennington wrote: > I think GIO/gvfs are the same, right, where GIO is just interfaces, and > gvfs provides an implementation? Apps would not link to gvfs directly? Its kinda similar. libgio does have an implementation for local files only, so you can use

Re: Merging gio into glib

On Wed, 2007-11-07 at 13:32 -0500, Behdad Esfahbod wrote: > On Wed, 2007-11-07 at 11:06 -0500, Ryan Lortie wrote: > > > > One library, one .so file, one pkg-config file. > > I'd say do a hybrid: separate pkg-config files, single .so. You can > even create .so symlinks, making it a build-time op

Re: RFC: GLib testing framework

On 07/11/2007, Tim Janik <[EMAIL PROTECTED]> wrote: > > On Wed, 7 Nov 2007, Morten Welinder wrote: > > >> nobody has to use this syntax. you can stick to the ever simple: > >>g_assert (foo > bar); > >> > >> however if you want the value of 'foo' and 'bar' be printed out, > instead > >> of just

Re: Merging gio into glib

Hi, It may not be clear to everyone on the list the structure of GIO and GSettings; we had a discussion with Ryan about it on Monday. (I am not 100% sure GIO works the same as GSettings, so I'll talk about GSettings.) Applications use GSettings, which includes an interface for storing preferen

Re: Merging gio into glib

Matthew Barnes wrote: > On Wed, 2007-11-07 at 16:35 +0100, Alexander Larsson 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 been thrown about: >> gfoundation, gb

Re: Merging gio into glib

On Wed, 2007-11-07 at 16:35 +0100, Alexander Larsson 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 been thrown about: > gfoundation, gbase, gplatform > Can you th

Re: Merging gio into glib

On Wed, 2007-11-07 at 11:06 -0500, Ryan Lortie wrote: > > One library, one .so file, one pkg-config file. I'd say do a hybrid: separate pkg-config files, single .so. You can even create .so symlinks, making it a build-time option to include a "feature" in the gwhatever.so or build a separate .s

Re: Merging gio into glib

On Wed, 2007-11-07 at 17:17 +0100, Alexander Larsson wrote: > On Wed, 2007-11-07 at 17:07 +0100, Xavier Bestel wrote: > > > Can you think of a good name for the new unified library? > > > > Stick it in glib. But if you really want to split, please avoid "base" > > or "foundation" or "the-mother-o

Re: RFC: GLib testing framework

On Wed, 7 Nov 2007, Morten Welinder wrote: >> nobody has to use this syntax. you can stick to the ever simple: >>g_assert (foo > bar); >> >> however if you want the value of 'foo' and 'bar' be printed out, instead >> of just the value of (foo > bar) which would be 0 or 1, then there are >> no

Re: Merging gio into glib

On Wed, 2007-11-07 at 11:06 -0500, Ryan Lortie wrote: > 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 th

Re: Merging gio into glib

On Wed, 2007-11-07 at 16:35 +0100, Alexander Larsson wrote: > What do people think about these ideas? Does it make sense? Either people bitch because glib is too big, or they cry because gtk+ has too many dependencies. I prefer less deps => less pain at build- time, less packages in distros, less

Re: Merging gio into glib

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 b

Re: Merging gio into glib

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

Merging gio into glib

I talked a bit with Ryan and Matthias on irc about the possible plans for merging gio into the glib module today. The original plan was to merge gio into glib as a separate library that links to libgobject, then use that from gtk+. The idea behind this is that by shipping it as part of glib we ma

Re: Merging gio into glib

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 been thrown about: > gfoundation, gbase, gplatform Wou

Re: Merging gio into glib

On Wed, 2007-11-07 at 17:07 +0100, Xavier Bestel wrote: > > Can you think of a good name for the new unified library? > > Stick it in glib. But if you really want to split, please avoid "base" > or "foundation" or "the-mother-of-everything", everyone wants its > project to be called like that.

Re: RFC: GLib testing framework

On Wed, 2007-11-07 at 09:15 -0500, Morten Welinder wrote: > Note, that the filter should preserve line numbers, i.e., never remove and > never insert newlines. Otherwise error messages with line numbers would > drive you crazy. It could also just use #line pre-processor directives:

Re: RFC: GLib testing framework

> nobody has to use this syntax. you can stick to the ever simple: >g_assert (foo > bar); > > however if you want the value of 'foo' and 'bar' be printed out, instead > of just the value of (foo > bar) which would be 0 or 1, then there are > no other means than using something simialr to: >

Little documentation patch

Hello, Here is a little patch against gtk+ 2.12.1 documentation : gtknotebook.sgml : corrected some mistakes (noteobook -> notebook) and wrong references (gtk_notebook_enable_popup -> gtk_notebook_popup_enable) gtkradiobutton.sgml : changed @group to @radio_group_member where needed Please let

Re: RFC: GLib testing framework

> > "Matthias Clasen" , Tue, 6 Nov 2007 13:12:02 > -0500 > > On 11/1/07, Tim Janik wrote: > > - we provide an extended set of assertions for strings, ints and floats > >that allow printing of assertion arguments upon failures to reduce > >the need for debugging: > > g_assert_cmpfloat