hello everyone.
GLib 2.30.0 has been released.
http://download.gnome.org/sources/glib/2.30/
d64c00b43409eabb89aad78501fcb1a992b002b314a4414a9bd069585cb7cdc1
glib-2.30.0.tar.xz
This major release of GLib represents 1174 commits from 151 individual
authors, including 35 contributors with 5 o
hi,
dconf 0.10.0 was released with no changes at all. It should be packaged
only as a matter of completeness.
http://download.gnome.org/sources/dconf/0.10/
9f744ccfb3da20163a4bb27916c960f6bf56048b3ec1112862c85414fc064ee2
dconf-0.10.0.tar.xz
Cheers
_
hi
dconf 0.9.1 was just released.
I doubt there will be any changes before I release 0.10.0 in time for
the GNOME 3.2 release, but please test this release in case changes do
need to be made.
Download
http://download.gnome.org/sources/dconf/0.9/dconf-0.9.1.tar.xz (169K)
sha256sum: f
hi everyone,
I've torn through a great deal of what I wrote about in "GLib plans for
next cycle" email. Changes are on master.
I'm presently working on the "wip/mutexes" branch. There are two
somewhat-related efforts on this branch:
First, I'm trying to slay bug #70598 by deprecating GStaticMu
hi everyone,
I've been trying to follow the GNOME 3.1 release cycle fairly closely
with GLib 2.29. For that reason, I now consider the glib-2-30 branch to
be hard code frozen. Please do not commit anything without first asking
for an exception.
Cheers
__
hi all,
GLib 2.29.92 has been released. This release is intended to be included
as part of GNOME 3.1.92.
http://download.gnome.org/sources/glib/2.29/
1f68d7990d03a52cf81284f039de94b041c3f5eb3d53663166b31e477557e8b1
glib-2.29.92.tar.xz
2.30.0 will be released on or slightly before Sep
hi all,
I just sent an email to foundation-announce about Boston Summit being in
Montréal. We're not going to attach a Gtk hackfest to that since the
notice is short and we already know that some important participants can
not attend.
The plan for now seems to be to have one early next year.
Ch
hi,
GLib has branched for the stable release ('glib-2-30'). All translation
effort should be focused there (since this is what will appear in GNOME
3.2).
The branch is to be considered frozen for code changes, except by
approval.
Thanks
___
gtk-devel
GLib 2.29.90 is ready.
http://download.gnome.org/sources/glib/2.29/
95af3f46a40ad1a3ecfe75db59b27956b256c4ad02f000be2aa13c7abd32fba3
glib-2.29.90.tar.xz
I consider this to be (almost) a release candidate.
There is probably a bug in GSettings that is causing lots of problems
with gnome
On Tue, 2011-09-06 at 10:14 -0400, Behdad Esfahbod wrote:
> In HarfBuzz I'm using the C++ compiler without linking to libstdc++. I found
> it as very rewarding experience. You get library constructor/destructors for
> free there. I think this approach to library design has serious merit worth
>
hi Colin,
On Thu, 2011-09-01 at 16:13 -0400, Colin Walters wrote:
> There's a huge amount of stuff here - how much of this is really
> dependent? Feature branches are just way easier to review than one
> big "stuff".
All of it except the source API changes is dependent on the libgthread
merge.
An update.
On Wed, 2011-08-31 at 11:50 -0400, Ryan Lortie wrote:
> I'm working on some plans for things I want to do in GLib at the start
> of the next cycle. I'd do them now, but it's getting late.
I created a wip/glib-next branch and started working on a lot of these
On Wed, 2011-08-31 at 19:58 +0200, Jannis Pohlmann wrote:
> TBH, I don't think the name alone will prevent misuse; in particular
> so as the "glib" prefix is no obvious internal-only hint (e.g.
> glib_check_version() is not private either).
>
> Wouldn't a note in the API docs suffice?
We have a f
On Wed, 2011-08-31 at 12:52 -0400, Dan Winship wrote:
> On 08/31/2011 11:50 AM, Ryan Lortie wrote:
> > - merge libgthread into libglib
>
> Getting rid of libgthread or moving any of its symbols into libglib is
> an ABI break on some platforms.
>
> Of course, since t
I'm working on some plans for things I want to do in GLib at the start
of the next cycle. I'd do them now, but it's getting late.
I've tried some aborted attempts at a few of these things in the past,
but they were all made complicated and ugly by one big factor: we don't
have always-on support f
GLib 2.29.16 has been released:
http://download.gnome.org/sources/glib/2.29/
066540465360c37f9d2e9784fa4e1c96b6705ed2028d3b90dc89ea2bf43dee72
glib-2.29.16.tar.xz
Overview of changes from GLib 2.29.14 to 2.29.16
* GTlsDatabase: an abstract
hi Robert,
On Wed, 2011-07-27 at 11:19 +0200, Robert Schwebel wrote:
> Subject: [PATCH] dconf: increase minimum glib version
Thanks for the fix. I've applied it to both the master and dconf-0-8
branches.
Cheers
___
gtk-devel-list mailing list
gtk-dev
hello
I just dropped releases of dconf 0.8.0 and dconf 0.9.0.
http://download.gnome.org/sources/dconf/0.8/dconf-0.8.0.tar.xz (164K)
sha256sum: 05111e973c365696759dd1b37e3f5acc877eff24dd2e4036d742aac5da5dda3b
http://download.gnome.org/sources/dconf/0.9/dconf-0.9.0.tar.xz (169K)
sha256sum: d
hi,
I recently introduced a change into the GLib unstable branch that causes
all applications using Gtk 3.0 to crash:
http://git.gnome.org/browse/glib/commit/?id=d6c30e1766c975dd79e6f252d73c6c0581b64b01
The reason for the crash is this code in gtkthemingengine.c, added a
year ago:
/* FIXME
hi all,
Only a few days after the previous release, GLib 2.29.14 is now out.
You can grab it from the normal place:
http://download.gnome.org/sources/glib/2.29/
The checksums:
2e407742b60c7b6e48527e6f6f5cf1fe8ea7494a55b3a070ebf04cabe044fe5a
glib-2.29.14.tar.xz
d474069c198fb63e0cab401f1b
(replies to gtk-devel-list please)
hello desktop-devel and gtk-devel lists,
On Sat, 2011-03-12 at 22:47 -0500, Ryan Lortie wrote:
> The current plan is
> to remove uses of the macro from glib and gtk+ and add a notice about
> th
On Wed, 2011-05-18 at 09:29 -0400, Shaun McCance wrote:
> With some GApplication work, we could get applications to read
> something from their .desktop file. Then it could be explicit,
> e.g. X-Launchpad-ID= You'd still have to patch applications,
> but with a one-line patch to a data file in
hi
As a quick follow-up to dconf 0.7.4 here is 0.7.5. This release fixes
the major crasher in the last release and attempts to incorporate some
vendor patches that distributions had been carrying.
Robert didn't get the memo about no new feature development before the
0.8 release and added a bunc
Hi.
I recently released dconf 0.7.4 which mixed bug fixes with a pair of
major enhancements. Many distributions were quick to package it due to
the bug fix part.
It turns out that one of the enhancements contained a trivial bug with a
rather extreme result. That's fixed now and I plan to have a
hi everyone
I just released dconf 0.7.4 with two long-awaited feature improvements.
First, the commandline tool no longer sucks.
Second, we have system lockdown support via editing text files and dconf
update (which apparently is how most people want to do it anyway). I'll
update the wiki with
hi Alex,
Thanks for contacting me about this.
On 04/15/11 04:19, Alexander Larsson wrote:
On Mon, 2011-04-04 at 12:34 +0200, Kean Johnston wrote:
Because it doesn't include config.h and since it was code that was sort of
living off to the side and I didn't know if it would be appropriate to
in
I just released dconf 0.7.3.
I consider this release to be more or less 'frozen' for the GNOME 3
release. If emergency changes are needed then we can make those and
release another tarball, but otherwise I will probably just let this one
go out with the release.
In short: please package and
hi Robert,
On 11-02-10 03:51 PM, Robert Schwebel wrote:
what do you think about this patch?
Sorry for the delay. I'm a somewhat casual reader of this list so I
didn't notice your message. The patch has been committed just now.
Thanks
___
gtk-dev
hi Joshua
On 11-02-16 04:09 AM, Joshua Lee wrote:
I can not understand while gvdb_table_is_valid can check the on-disk
gvdb table is valid.
The very first thing that comes in any GVDB file is the string
"GVariant". That's normally why *data should be non-zero, so !!*data
will be 1.
When d
(replies to gtk-devel-list please)
Greetings,
I just opened bug #644611 about deprecating G_CONST_RETURN.
After discussing this with Matthias on IRC, it is our intention to phase
out use of this macro in our platform. The usual way that we would do
that is by removing our own use of it and m
hi everyone;
dconf 0.7.2 is out today.
http://download.gnome.org/sources/dconf/0.7/
SHA256:
35fc51ef893dc3951bfc7abaee6adb8b77e501274b3a5292ed03db4e685ef03c
dconf-0.7.2.tar.bz2
722ec9439d9b54f791dd4b729bf7d6ae4ba52c9dbe096b35ad88e64665e628ac
dconf-0.7.2.tar.gz
Changes in dconf 0.7.2
Hello
The dconf 0.7 release contained a few bugs related to linking. I've
released 0.7.1 to address those issues. If you notice any more
problems, please let me know.
http://download.gnome.org/sources/dconf/0.7/
SHA256:
04b81606131a59362167e50e84b55ac2af49fdfa3ad4b5b0bdb07dc14bf5bd1d
dc
Hello everyone
I just released dconf 0.7. The two main improvements are an improved
dconf-editor and a new library for using dconf with libdbus-1.
http://download.gnome.org/sources/dconf/0.7/
SHA256:
73fe932a2905ea99f7bc51efe7fe240f5ec87caa4959ab0c1ac65571ac14512c
dconf-0.7.tar.bz2
On Fri, 2010-11-12 at 12:37 +0100, Alexander Larsson wrote:
> I'm not inherently against naming the buttons. It would be nice if we
> got a third argument to the group active-changed signal that lets you
> avoid having to compare button instances to see which one is active.
> Although in code it mi
On Wed, 2010-11-10 at 08:23 +0100, Alexander Larsson wrote:
> So, what do you want to do here? How do we land this?
I'm against landing it in its current state because I remember yet
another reason that I think we want to have names for radio buttons
within a group: it's the only sane way to deal
Dear everyone:
please take note :)
On Thu, 2010-11-11 at 15:07 -0500, Dan Winship wrote:
> Discussion should happen mostly in bugzilla I guess? Thanks in advance...
Cheers
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org
hi,
After a lot of travel I've been at home for more than 24 hours. I got a
chance to read through the GPeriodic thread (mostly between Owen and
Havoc).
I've done the following as a first attempt to improve the situation:
GPeriodic now has two GSource priority levels, which it calls "high" and
hi everyone,
I wrote an email yesterday detailing my goals to reduce GLib to having a
single type for time. The work just landed on master.
Of course, there were complications.
Status report:
- GTimeSpec is gone
- g_get_monotonic_time() returns int64 time
- new function g_get_real_time()
hi Alex,
On Tue, 2010-11-02 at 13:42 +0100, Alexander Larsson wrote:
> I'm not sure forcing every radio item to have a name is a good idea.
Maybe true
> Also, I don't think exposing raw widgets as exported actions is a good
> idea. Its probably better to have more highlevel actions, or at le
hi Alex,
I was thinking of doing the same thing, but making the GtkRadioGroup
implement GAction with a state type of string (and each radio button in
the group being identified by a string).
Setting the action to a state equal to the name of a radio item would
activate that item. Easy DBus expor
On Mon, 2010-11-01 at 14:21 -0400, Havoc Pennington wrote:
> Well there's already G_USEC_PER_SEC but I guess it's saving typing of
> more zeroes.
Reading 1000 is very easy. With 100 or 10, you usually have
to stop and count the number of zeros (see also: why 'thousands
separators' exi
On Mon, 2010-11-01 at 10:06 -0700, John Ralls wrote:
> +1
>
> I don't see any reason to have a replacement for GDate. Just add any
> extra functionality it provides to GDateTime -- which, with int64,
> will be good for +/- 290,000 years from whatever its epoch date is,
> with microsecond resolutio
Hello
After an extensive process of dithering and soul-searching, I've come to
the following conclusions about time in GLib:
- we have too many time types
no explanation required.
- microseconds ought to be enough for anybody
A nanosecond is on the scale of individual clock cycl
hi Pavel,
On Mon, 2010-10-25 at 11:24 +0200, Pavel Holejsovsky wrote:
> Just out of curiosity; would you mind trying to specify reasons why you
> don't like it?
My general uneasiness with this idea developed along these lines:
- If we have some API for getting this int64 for the current time t
On Fri, 2010-10-22 at 15:02 -0400, Havoc Pennington wrote:
> Hi,
>
> On Fri, Oct 22, 2010 at 11:06 AM, Ryan Lortie wrote:
> > - We will add GTimeSpec which is GTimeVal using nanoseconds instead of
> >microseconds (same story with struct timeval vs. struct timesp
On Fri, 2010-10-22 at 13:28 -0400, Daniel Macks wrote:
> On Fri, 22 Oct 2010 17:20:45 0200, Ryan Lortie wrote:
> > - we aren't going to bump glib's version number when we release Gtk3
> X constant for Y=3
specifically, X=2 for Y=3
> > - we like glib to have th
On Fri, 2010-10-22 at 16:14 +0100, Bastien Nocera wrote:
> glib 3.0 maybe? We're still discussing changes for glib 2.x, aren't we?
If you accept the following premises:
- we can't break glib API without effectively also breaking Gtk API
- we aren't going to bump glib's version number when we
Hello
We have an agreement at the hackfest that I will do the following things
now:
- Starting immediately, glib will depend on librt (and therefore
libpthread) on systems that have it.
- We will add GTimeSpec which is GTimeVal using nanoseconds instead of
microseconds (same story wi
hi Bastien,
On Thu, 2010-10-21 at 17:44 +0100, Bastien Nocera wrote:
> I'll also note that some apps can't be ported, like gnome-control-center
> or totem because the only way to get arguments is through "open" which
> only deals with files/URIs.
Give G_APPLICATION_HANDLES_COMMAND_LINE in the GAp
Hi Owen,
A few questions, if you don't mind me picking your brain:
On Wed, 2010-10-20 at 14:58 -0400, Owen Taylor wrote:
> The real problem is that the phases of the repaint cycle matter. We
> don't just have a bunch of stuff we need to do every frame, we need to
> do things in the order:
>
> *
hi Havoc,
First I want to note that GPeriodic was only an attempt to get the
timing right. It's just a clock. It is not in any way meant to provide
policy about how a paint cycle is actually run.
That said, I did make a Gtk branch with some crackful experimentation
(currently shoving GPeriodic
Good day!
At long last, the GLib 2.25.x saga has come to an end. You can grab
your 2.26.0 tarballs here:
http://download.gnome.org/sources/glib/2.26/
4c18e3aadb5b20acc7c0f7d3a77da8a2843b85a9fd73fd3aa360a7aea953e3b2
glib-2.26.0.tar.bz2
844bb4612c50898a9a349ab28f
Hi all
A somewhat serious bug was discovered in GLib 2.25.16 as it was released
yesterday -- a complete failure to build against the system-installed
pcre (see bug #629971).
Because of the late date in the cycle leading up to GNOME 2.32, the
inconvenience to our users and distributors is great en
Hello everyone,
I just released GLib 2.25.16 and 2.27.0.
The 'master' branch in git is now tracking the 2.27.x series and the
2.25.x series is on the 'glib-2-26' branch.
'master' is more or less completely open now (except for the normal
restriction that any changes must be backward compatible w
Slovenian
Spanish
Swedish
Swedish
Traditional Chinese
The list of contributors since 2.25.15:
Benjamin Otte
Christian Hergert
Christian Persch
Damien Lespiau
Dan Winship
David Zeuthen
Emmanuele Bassi
Joe Marcus Clarke
Jon Nordby
Kristian Rietveld
Matthias Clasen
Sam Thursf
On Fri, 2010-09-10 at 08:58 -0400, Morten Welinder wrote:
> GDateTime still has API issues.
These are the changes that I mentioned Emmanuele was working on.
Cheers
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/l
Hello everyone
I plan on branching glib-2-26 early next week and removing GApplication
(and related classes) from the branch. At that point, I will consider
the branch to (soft) frozen. Of course, we will allow bug fixes past
that point. Documentation and tests will also be allowed, as will be
hi all,
Just a reminder that we're planning to have a GTK Team Meeting tomorrow,
Tuesday September 7 at the usual time and place.
See the details here:
http://live.gnome.org/GTK+/Meetings
Cheers
___
gtk-devel-list mailing list
gtk-dev
hi Havoc,
On Mon, 2010-08-09 at 12:46 -0400, Havoc Pennington wrote:
> How would we handle widgets that currently have multiple windows and
> draw different things to each one (i.e. the expose handler is looking
> at the window in the expose event).
> For example GtkTextView
I think we should jus
hi Everyone,
Claudio has been in contact with the hotel for the hackfest and has made
a "prebooking". We have received a very discounted rate, but the hotel
needs to know in advance exactly how many people will be coming.
For this reason, we ask that everyone ensure that they are listed on the
w
n
Latvian
Romanian
Spanish
Thanks to all who contributed:
Christian Dywan
Jürg Billeter
Tor Lillqvist
Matthias Clasen
August 8, 2010
Ryan Lortie
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Hello.
Due to a rather serious packaging bug in glib 2.25.12, I'm making a
quick 2.25.13 release. You should not use glib 2.25.12.
I've made some changes to address that problem and hopefully prevent
similar problems from happening again. I looked over the package and it
seems to be fine, but p
On Thu, 2010-08-05 at 19:26 +0200, "Andrés G. Aragoneses" wrote:
> El 04/08/10 19:29, Ryan Lortie escribió:
> >
> > and also more trivial things:
> >
> > - almost doubling the time it takes to configure and build
> > - distributing a(not
hi Robert,
I caught the bug on bugzilla. I'll review it today.
I basically agree, though.
Cheers
On Thu, 2010-08-05 at 09:07 +0200, Robert Schwebel wrote:
> Ryan,
>
> On Tue, Aug 03, 2010 at 09:42:19PM -0400, Ryan Lortie wrote:
> > After a bit of post-GUADEC delay I
hi Kevin,
On Wed, 2010-08-04 at 08:39 -0700, Kevin Fox wrote:
> On Tue, 2010-08-03 at 18:42 -0700, Ryan Lortie wrote:
> > I am experimenting with living a libtool-free
> > existence.
>
> Out of curiosity, why?
Short version:
1) I don't believe that I need it.
2)
hi,
I just released dconf 0.5, containing a dependency on an unreleased
gobject-introspection. Oops. :(
Rumour has it that Colin is still roaming around Europe so I've uploaded
a tarball for gobject-introspection 0.9.3 in order to save vendors the
hassle of coming up with creative solutions to
hi Everyone,
After a bit of post-GUADEC delay I am happy to announce dconf 0.5. This
is the first release of dconf that doesn't completely suck (but it still
has a lot of suck).
There have really been a lot of changes this time around, but one is
really worth mentioning: I am experimenting with
Hello everyone,
I'm very pleased to officially announce the Gtk+ 2010 hackfest.
The hackfest will be during the week of October 18 through 22 in A
Coruña, Galicia. Igalia has stepped up and offered the venue.
For developers actively involved in Gtk+, the foundation has agreed to
pay the full co
On Tue, 2010-08-03 at 01:28 -0400, Matthias Clasen wrote:
> > • Hackfest
> > ∘ Planned for October w22 (18th-22nd)
>
> I will try to make it this time, for a change. Are the dates final yet ?
Set in stone and approved by the foundation. It's fine to start booking
tickets.
> Did outstanding wor
anks to everyone who helped:
Behdad Esfahbod
Benjamin Otte
Colin Walters
David Hoyt
David Zeuthen
Eduardo Lima Mitev
Javier Jardón
Julien Cristau
Matthias Clasen
Murray Cumming
Olivier Crête
Owen Taylor
Stefan Kost
Tomeu Vizoso
July 29, 2010
Ryan Lortie
From the Hague :)
___
I just did a dconf release to go with the new GLib release.
There have been some crasher fixes and the editor has been quite a bit
improved.
Cheers
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-deve
tions
623770 quoting of expand_macro in gdesktopappinfo.c
623772 gdesktopappinfo.c, function child_setup
623780 g_unix_is_mount_path_system_internal
623954 g_settings_finalize
623955 Dubious return values
Updated translations:
Galician
Hebrew
Norwegian bokmål
Spanish
Thanks to the co
On Sat, 2010-06-26 at 19:01 +0200, Tadej Borovšak wrote:
> This is how normal flow looks like:
Quite accurate, and exactly how it will work with dconf.
Thanks for the explanation, Tadej :)
Cheers
___
gtk-devel-list mailing list
gtk-devel-list@gnome.or
hi Robert,
On Sat, 2010-06-26 at 14:43 +0200, Robert Schwebel wrote:
> Is it possible that we make this conditional, like in
>
> --{en,dis}able-dconf-editor
Yes. Of course. I'll do this soon.
The plan is for the dependency on Vala to increase (to be used in the
core parts of dconf, for
hi Everyone,
dconf 0.4.1 is released.
You can download it here:
http://download.gnome.org/sources/dconf/0.4/
Checksums:
02107c9f1cb23b0aa749d49858374246b73786ffa0c14e69ba66d9410d8bfb25
dconf-0.4.1.tar.bz2
6bf25c7c9fe36a6d5c261df0c319877af42faebd78a78c05aa9bb25ff2b4fba8
dconf-0.4.1.tar.gz
utors:
Matthias Clasen
Christian Dywan
Emmanuele Bassi
Milan Bouchet-Valat
David Zeuthen
Dan Winship
Tor Lillqvist
Javier Jardón
Sven Herzberg
Patrick Hulin,
Christian Persch
Johan Dahlin
Christian Persch
Jürg Billeter
June 24, 2010
Ryan Lortie
_
dconf 0.4 is released.
You can download it here:
http://download.gnome.org/sources/dconf/0.4/
SHA256 for your horizonal-scrolling pleasure:
9812a3401ce31a2b083aaf963b6600b528975c61b7292c6d40346f5f4bf76d28
dconf-0.4.tar.bz2
beb33f2aa435ef938bb4d7a2e5066058921504c5ed7b0fd59ab1e5f3bee44431
1:28PM +0200, Robert Schwebel wrote:
> > Ryan,
> >
> > On Mon, May 24, 2010 at 11:09:15PM -0400, Ryan Lortie wrote:
> > > GLib 2.25.7 is now available [...]
> >
> > I've tried to cross compile glib-2.25.7, and it crashes in gio/tests,
> > because compiles g
order to build this dconf.
May 24, 2010
Ryan Lortie
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
/Win32
619142 Build fixes (GDBus)
* Updated translations:
Estonian
Galician
Norwegian bokmål
Thanks to all contributors:
Christian Persch
David Zeuthen
Javier Jardón
Kjartan Maraas
Matthias Clasen
Richard Hughes
Tor Lillqvist
May 24, 2010
Ryan Lortie
, 2010
Ryan Lortie
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Tor Lillqvist
May 19, 2010
Ryan Lortie
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
On Sat, 2010-05-15 at 14:45 -0400, Behdad Esfahbod wrote:
> It would be immensely helpful if GSettingsList can do the cleaning up and
> dup-avoiding part. So, add_item() will in fact get a name *hint*, clean it
> [1] up, avoid dup, and return the key name.
Note that in the interface I gave, add_i
On Sat, 2010-05-15 at 11:16 -0400, Matthias Clasen wrote:
> FD_CLOEXEC ?
There's no exec happening here, far as I know... just a fork.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Hi,
I was just running dconf through the GSettings test suite and I realised
that we have a fairly serious issue that blocks that from working.
The test suite uses this fairly typical gtester pattern of forking off
expected failure cases. Of course, this is wildly incompatible with the
concept o
Hi all,
I've been putting off GSettingsList for a while because of a criticism
that vuntz raised during the hackfest. It's a fairly valid criticism
that I'll describe here, along with my thoughts for a solution. This is
a bit of a request for comments and a hopes that the braindumping
process it
On Fri, 2010-04-23 at 10:32 -0400, Behdad Esfahbod wrote:
> So here's what I suggest:
I'm not really sure we need to go this way at all (with the gigantic
GLIB m4 macro), but if we do..
> - I know gsettings is included in gio, but I suggest providing a separate
> .pc file for it.
This does
ensen
Javier Jardón
Dagobert Michelsen
Behdad Esfahbod
March 21, 2010
Ryan Lortie
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
On Mon, 2010-03-15 at 23:43 +0100, Sven Neumann wrote:
> Feel free to use the implementation in GIMP as a starting point:
>
> http://git.gnome.org/browse/gimp/tree/app/base/base-utils.c#n54
See also:
http://qt.gitorious.org/qt/qt/blobs/4.7/src/corelib/thread/qthread_unix.cpp
http://qt.gitorious
Hi Dan
Thanks for the reply. Hopefully I can clarify some things.
On Mon, 2010-03-15 at 10:54 -0400, Dan Winship wrote:
> On 03/14/2010 10:52 PM, Ryan Lortie wrote:
> > - replace G_BEGIN_DECLS/G_END_DECLS with "protected" visibility
> > pragmas. This means that
On Sun, 2010-03-14 at 22:52 -0400, Ryan Lortie wrote:
> Benefits:
One more thing I forgot to mention here:
The use of the single "glib-compilation.h" included as the first thing
from every file makes for a good starting point from which to consider
header file pre-compilation. Tha
Hi all,
I did a little bit more poking around after my last mail to the list on
the topic of alternatives to galias. I've come up with what I believe
to be a workable solution.
My approach can be summarised as such:
- remove all previous galias stuff
- replace G_BEGIN_DECLS/G_END_DECLS wit
exander Larsson
Priit Laes
Stefan Kost
Fridrich Strba
Behdad Esfahbod
Jonh Wendell
Claudio Saavedra
Christian Dywan
Felix Riemann
Dan Winship
Paolo Borelli
Saleem Abdulrasool
Edward Hervey
Emilio Pozuelo Monfort
March 8, 2010
Ryan Lortie
___
Hi Michael
On Fri, 2010-02-26 at 10:02 +, Michael Meeks wrote:
> This is a similar situation; interning ref-counted strings, whose
> references are held in noddy hand-coded hash-table (to ensure we have a
> unique version):
I was thinking of doing something similar but I took a pass on
Hi Michael
> One of them is from the slightly unfortunate weak-reference /
> hash-table scheme in gvarianttypeinfo.c (patch attached).
Thanks for catching this. This is truly an impressive bug. I'm
surprised you were able to track it down -- I hope it didn't take too
much time. :)
I fixe
Hi
I've been doing some research today on the possibility of dropping the
generation and use of galias.h and galiasdef.c. I've only looked into
libglib so far.
My main beef is that all of glib gets rebuilt every time the symbol
table changes in any way (ie: glib.symbols is modified). My seconda
Hi Matthias
I've started in on the comments in this email.
On Sun, 2009-12-06 at 17:01 -0500, Matthias Clasen wrote:
> First, I didn't see any documentation improvements after my last
> review attempt...are those coming, or are we stuck here ?
I wrote an email in reply to your comments on Octobe
Hi Matthias
Thanks for the further comments.
I'm on holiday until the end of the year at this point. I'll get the
ball rolling again in early January.
Cheers
On Sun, 2009-12-06 at 17:01 -0500, Matthias Clasen wrote:
> Today I had another go at reviewing the gvariant branch, this time
> startin
Hi,
On Mon, 2009-11-30 at 21:08 +0100, Christian Persch wrote:
> schrieb Ryan Lortie :
> > Note that you can do in-place parsing of:
> >
> > "( { 'zero': 0, 'one': 1, 'two': 2 }, '' )"
> >
> > i
Hi Christian
On Mon, 2009-11-30 at 13:27 +0100, Christian Persch wrote:
> Hi;
>
> I've been playing with the gvariant branch of glib a bit, and have a
> few questions / remarks / code comments. I hope they're marginally
> useful :-)
Thanks so much for this feedback. It's extremely valuable.
>
101 - 200 of 240 matches
Mail list logo
