hi,
On Tue, Mar 31, 2015, at 03:48, Alexander Larsson wrote:
In general, setting O_CLOEXEC is a nice thing to do, but doing so does
not change the fundamental fact that you can't rely on it being set.
This is pretty much the entire point of this thread. I now consider
O_CLOEXEC as a 'nice to
hi,
On Sat, Mar 28, 2015, at 02:22, Jasper St. Pierre wrote:
Thanks. I have refactored this code to use GSubprocess:
https://git.gnome.org/browse/mutter/commit/?id=d4e8d97e58f9c931a14ea9b6484890d7a66e65e7
Glad to see this getting some more use.
It looks like you leak the launcher, though.
hi Chris,
On Sun, Mar 22, 2015, at 09:12, Chris Vine wrote:
The implementation borrows from g_spawn* which does not look quite right
to me. I have submitted a bug
( https://bugzilla.gnome.org/show_bug.cgi?id=746604 ).
I believe this bug report is based on a common misunderstanding. The
code
On Sat, Mar 21, 2015, at 12:04, Matthias Clasen wrote:
'Not part of POSIX' has never stopped us from using something in glib:
atomics, futexes, inotify, pipe2, libelf, to name just a few...
...and in each of these cases, we pay the price with some sort of
abstraction layer, #ifdef, fallback
On Sat, Mar 21, 2015, at 12:09, Matthias Clasen wrote:
Are you actually suggesting that we rip out all code that is currently
doing the right thing, cloexec-wise ?
from my original email:
I'm not going to go and retroactively tear things out where they are
already working, unless it would
hi,
On Sat, Mar 21, 2015, at 01:59, Jürg Billeter wrote:
I would keep using O_CLOEXEC as it's as close as we can get to the
behavior that should have been the default: don't implicitly inherit
file descriptors on exec.
Maybe there are applications out there that rely on correct file
On Fri, Mar 20, 2015, at 20:29, Christian Hergert wrote:
What I would welcome, is a function that says glib, close all FDs you
know about or that you created. If all the libraries did that, at least
it would be possible for applications to maybe, sorta, do the right
thing. (That would push
On Fri, Mar 20, 2015, at 23:33, Matthias Clasen wrote:
So, you found that dup3 doesn't do what you want, and now you want to
throw out the baby with the bathwater and just say I don't care
anymore if we leak fds ?
dup3() was a bit of a straw that broke the camel's back case. I could
point at
hi,
On Sat, Mar 21, 2015, at 01:19, Jasper St. Pierre wrote:
Right now, we use raw fork/exec in mutter where we need to do some tricky
management and explicitly leak an FD into the correct place [0]. Does
this
mean that from now on, glib might leak an FD and we need to be prepared
to
handle
hi,
On Sat, Mar 21, 2015, at 01:27, Jürg Billeter wrote:
Doesn't the following standard POSIX functionality provide what you
want?
fcntl(fd, F_DUPFD_CLOEXEC, 0)
Yes. It does. Thank you very much.
It seems that this is a (slightly) recent addition. It's documented:
karaj,
I just released GLib 2.43.92 and branched. 'glib-2-44' is what will
become 2.44.0 and 'master' is what will become 2.46.
Cheers
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
hi Aleksander,
On Thu, Jan 15, 2015, at 06:28, Aleksander Morgado wrote:
Currently GFileMonitor doesn't have a unique way to know whether a file
got closed. There is the changes-done-hint event, but that covers IIRC 2
things: files getting closed and also a virtual emission which happens
hi,
On Thu, Jan 15, 2015, at 10:49, Morten Welinder wrote:
Great plan, but you cannot get that in a meaningful way. Think
creat
write
mmap
close
# Further writes by way of the mapped region
I don't think you can detect the end of that write.
Quoting inotify(7):
hi Martyn,
On Thu, Jan 15, 2015, at 04:14, Martyn Russell wrote:
Just to add to what you said, the Tracker project extensively uses this
API and has quite some detailed unit tests which are ensuring the
functionality is consistent between releases.
It might be useful to anyone looking to
hi,
On Wed, Jan 14, 2015, at 19:13, Fan Chun-wei wrote:
I think I can also take a look at the Windows backend for this as well,
since we are actually using the same Windows API for monitoring file and
directory changes, ReadDirectoryChangesW(), as I was trying to get file
monitoring to
hi,
I'm making substantial modifications to the file monitoring system in
GIO. I've gotten to the point where I feel comfortable pushing a branch
that contains the main ideas:
https://git.gnome.org/browse/glib/log/?h=wip/mount-watcher
It's not even vaguely tested or stable and will probably
hi,
On Wed, Jan 14, 2015, at 18:14, Christian Hergert wrote:
I quickly read over the relevant commit message. I didn't see anything
alluding to the goal of the patch set. I'm sure there is a goal you have
in mind?
Overhead reduction, performance related I assume?
Thread safety -- file and
hi,
On Wed, Jan 14, 2015, at 20:49, Christian Hergert wrote:
Does anything rely on the delay that happens in the current system? For
example, is it used to coalesce an open(O_CREAT)/rename() into a single
signal emission?
I know I've written some things in the past where I've been a bit
hi Fan Chun-wei,
On Tue, Dec 30, 2014, at 03:26, Fan Chun-wei wrote:
-There are some things that required specialized implementations for XP,
for example, SRWLock in GLib and networking items in GIO, which may or
may not work well.
(for example, by using inet_pton() directly in
hi John,
On Mon, Oct 20, 2014, at 06:28, John Emmas wrote:
Hi - I just updated from git master (about half an hour ago) but MSVC
gives me an 'undeclared identifier' error at line 368 of
'glib/goption.c'. Here's what the line looks like:-
optind = 1;
This is a known issue and will
hi,
On Thu, Sep 25, 2014, at 02:29, Lele MA wrote:
Does it mean the system doesn't define _POSIX_THREADS?
If so, can I still use the glib in the Mini-OS without the support of
_POSIX_THREADS?
Without knowing too much about this MiniOS: GLib has a hard dependency
on POSIX threads. It is not
hi,
On Thu, Feb 20, 2014, at 7:53, Giovanni Campagna wrote:
It's worth pointing out that mozjs will *force* a garbage collect if
you go over the malloc limit (a dynamic value between 30 and 90 MB),
but will garbage collect a lot more often if you call MaybeGC.
My preferred solution to the
hi,
On Tue, Nov 12, 2013, at 11:09, Jonathan S. Shapiro wrote:
As an implementation matter, I understand that this is true. As an API
matter, it's clearly false, because g_thread_self() is explicitly
documented to silently return an invalid GThread* value if the calling
thread was not
hi,
On Sat, Nov 9, 2013, at 10:38, Jonathan S. Shapiro wrote:
but I'm kinda stuck, because GTK relies on GLIB mutexes, which seem to
rely
on GThread.
This is not true. You can make your own threads and use them with our
mutexes.
Cheers
___
On Wed, Oct 23, 2013, at 6:26, Marc-André Lureau wrote:
It would be nice if we can keep XP compatibility for a few more years
(why would we need to drop it now?). XP support could be limited to
mingw64, if it's complicated to keep MSVC support?
The biggest gain here would be to kill the beast
hi
On Tue, Oct 22, 2013, at 6:11, Alexander Larsson wrote:
By Darwin you mean OSX in general I assume?
yes. I guess we need Cocoa here too in order to really be useful.
I think the above list is a good start. But it is not good enough. We
also need to specify which versions of the above
hi,
GLib aims to work on a wide range of operating systems, but we have no
good story for ensuring that this is the case. Mostly we do things for
Linux and, if they are the sort of thing that may cause problems, we
also check that they work on Windows. We read manpages and make sure
that the
hi,
On Tue, Oct 15, 2013, at 15:14, Olivier Brunel wrote:
I do not understand, however, why the entire GtkImageMenuItem widget was
deprecated, and not just what relates to those options - since using
icons in menus remain a very useful thing, and one used by many GTK apps
out there. It makes
hi,
On Wed, Oct 9, 2013, at 10:45, Matthias Clasen wrote:
You are right that the functionality of the gtk-button-images and
gtk-menu-images settings was removed. They are only 'deprecated' insofar
as
programs that were using g_object_set to directly change these settings
on
the GtkSettings
hi
On Wed, Oct 9, 2013, at 14:29, Jasper St. Pierre wrote:
Perhaps we can revert the GtkMenu/GtkButton changes and just remove the
XSettings hookup.
Out of all of the available options, this would be the most pointless
thing to do.
If we're going to have the complexity in the widgets anyway,
hi,
On Wed, Oct 9, 2013, at 18:48, Jasper St. Pierre wrote:
Of course, but do any of these need spell checking? I think it would be
more helpful to solidify an API for spell checking to see if it's viable
to
do without UI concepts like cursor position or GTK+ concepts like
GtkTextBuffer
hi,
On Tue, Oct 8, 2013, at 9:49, Matthew Barnes wrote:
Or perhaps follow the glib-networking pattern where GIO just defines a
spell checking interface and an extension point and the meaty parts with
the extra dependencies are supplied by 3rd party module(s).
+1 from me. This is the only way
hi all,
I just branched off GLib 2.38 as glib-2-38.
'master' is now fully unfrozen and will become 2.40.
Cheers
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
hi John,
On Thu, Sep 19, 2013, at 4:06, John Emmas wrote:
Slightly off topic but how do I find out when the upcoming stable
version gets released?
Although it's not strictly aligned with the GNOME schedule, GLib pretty
much tends to follow it these days.
You can see it here:
hi,
GLib 2.37.92 contained a couple of bugs in the new
g_file_measure_disk_usage() so I did a 2.37.93 to fix them. This should
be the one used in the upcoming release.
Cheers
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
hi,
On Thu, Sep 12, 2013, at 5:17, John Emmas wrote:
Before I add anything to Fan's bug report (and before visiting IRC) let
me just create a record here of what I've found this morning - because
it's definitely a bit baffling and I think it needs some lengthy
consideration
These are
hi John,
On 2013-04-08 04:44, John Emmas wrote:
// glib/gvariant.h
GLIB_AVAILABLE_IN_ALL
const gchar **g_variant_get_bytestring_array (GVariant *value, gsize
*length);
// glib/gvariant.c
static gpointer
g_variant_valist_get_nnp (const gchar **str, GVariant *value)
{
// some stuff
hi list,
On 12-12-02 05:59 PM, Alex Chiang wrote:
diff --git a/gtk/gtkicontheme.c b/gtk/gtkicontheme.c
index 0520686..cd2d765 100644
--- a/gtk/gtkicontheme.c
+++ b/gtk/gtkicontheme.c
@@ -1113,6 +1113,7 @@ insert_theme (GtkIconTheme *icon_theme, const char
*theme_name)
dir_mtime-mtime =
hi,
On 12-11-26 04:05 AM, Timothy Arceri wrote:
I'm looking into adding support for .hidden to the GTK File Chooser see:
https://bugzilla.gnome.org/show_bug.cgi?id=596234 however I'm not 100% sure
where I should be making this change. I'm thinking the change should be made to
Glib in
hi Morton,
On 12-11-16 03:09 PM, Morten Welinder wrote:
The breaking of mouse wheel support in gtk+ 3.4 also comes to mind.
(Bug 675089 and others, I'm sure.)
If I'm not mistaken, this was a different kind of breakage that we
engage in a lot of lately: API-incompatible changes on the
hi,
It seems to me that we've been playing a little bit fast and loose with
what goes into stable branches of GLib (and particularly) Gtk+ of late.
From my point of view I think the only thing suitable for a stable
branch is a bug fix. New features are completely out of the question
and
hi,
On 12-11-11 03:03 PM, Matthias Clasen wrote:
Hard to disagree in the abstract. But also not much of a discussion unless
you cite the specific examples that made you write this mail.
Which changes were problematic ?
There are three specific cases that come to mind:
1) Recently Martin
hi,
On 12-11-11 04:46 PM, Matthias Clasen wrote:
Ah, ok. So, this is not about anything recent, but a 'multi-year
accumulated frustration' mail.
The thing that brought this up recently was a discussion at UDS. Ubuntu
is nervous to take our stable releases because of what has happened in
hi all,
We ended up planning quite a lot of work for GLib during Boston Summit,
a lot of which was considered to be potentially dangerous. Matthias
wrote a good blog post that summarised most of it here:
http://blogs.gnome.org/mclasen/2012/10/08/gnome-summit-sunday/
Point-by-point here's
hi,
One of the big design mistakes I made with GSettings is that this is
really weird:
schema id=org.a11y.atspi path=/org/a11y/atspi/
The requirement to specify a separate path is confusing. It causes
people to think that maybe the path should have a prefix like /apps/.
If you manage to
On 12-10-17 12:17 PM, Matthias Clasen wrote:
to
fixedschema id='a.b.c'
relocatableschema id='x.y.z'
Seb mentioned a variation on this theme focusing on attribute names instead:
schema pathid=... !-- same as fixedschema above --
My problem with these proposals is that schema and
hi,
Thanks for the feedback.
On 12-09-12 05:15 PM, Paul Davis wrote:
On Wed, Sep 12, 2012 at 5:07 PM, Michael Natterer mi...@gimp.org wrote:
I object. Do you really want to disable shortcut editors in
complex applications such as GIMP?
I echo Mitch's objections. Ardour users find it very
hi,
I recently wrote a patch[1] to re-enable accel labels in GtkMenu
generated from GMenuModel. They got lost in the shuffle during some
related recent changes.
Essentially, the new approach means that the accel='' attribute of each
menuitem directly determines what the accel label will be
=
Aurimas Černius
Chao-Hsiung Liao
Chun-wei Fan
Colin Walters
Daniel Mustieles
Dan Winship
David King
Dirgita
Fran Diéguez
Javier Jardón
Krishnababu Krothapalli
Lars Uebernickel
Marc-André Lureau
Matthias Clasen
Nilamdyuti Goswami
Owen W. Taylor
Ryan Lortie
Sandeep Sheshrao Shedmake
=
Aurimas Černius
Chao-Hsiung Liao
Chun-wei Fan
Colin Walters
Daniel Mustieles
Dan Winship
David King
Dirgita
Fran Diéguez
Javier Jardón
Krishnababu Krothapalli
Lars Uebernickel
Marc-André Lureau
Matthias Clasen
Nilamdyuti Goswami
Owen W. Taylor
Ryan Lortie
Sandeep Sheshrao Shedmake
Mustieles
Dan Winship
David Zeuthen
Emmanuele Bassi
Fran Diéguez
Jonh Wendell
Khaled Hosny
Lars Uebernickel
Martin Jansa
Martin Pitt
Matthew Barnes
Matthias Clasen
Murray Cumming
Nilamdyuti Goswami
Paolo Borelli
Phil Clayton
Ryan Lortie
Sasi Bhushan Boddepalli
Stefan Sauer
Stef Walter
GLib 2.33.2 has been released.
This is a point release on the way to what will become 2.34.0. API
additions at this point should be considered unstable.
As usual, you can download from
http://download.gnome.org/sources/glib/2.33
GLib 2.33.2 has been released.
This is a point release on the way to what will become 2.34.0. API
additions at this point should be considered unstable.
As usual, you can download from
http://download.gnome.org/sources/glib/2.33
GLib 2.32.2 is now available for download at:
http://download.gnome.org/sources/glib/2.32
b1764abf00bac96e0e93e29fb9715ce75f3583579acac40648e18771d43d6136
glib-2.32.2.tar.xz
This is a stable point release for the 2.32 series and contains no new
major features. There are some minor new
GLib 2.32.2 is now available for download at:
http://download.gnome.org/sources/glib/2.32
b1764abf00bac96e0e93e29fb9715ce75f3583579acac40648e18771d43d6136
glib-2.32.2.tar.xz
This is a stable point release for the 2.32 series and contains no new
major features. There are some minor new
hi Michael,
On Mon, 2012-03-05 at 12:11 +, Michael Meeks wrote:
Does that mean you're removing gdk_threads_enter and leave and the
semantics around that ? is there some cunning new scheme proposed to
intercept the mainloop and ensure that events / idle / timeout emissions
hooked in
Live from the Czech Republic, it's GLib 2.31.18!
This release is an unstable release on the way to 2.32.0.
http://download.gnome.org/sources/glib/2.31/
1ce3d275189000e1c50e92efcdb6447bc260b1e5c41699b7a1959e3e1928fbaa
glib-2.31.8.tar.xz
This release is aimed at being used as part of GNOME
Live from the Czech Republic, it's GLib 2.31.18!
This release is an unstable release on the way to 2.32.0.
http://download.gnome.org/sources/glib/2.31/
1ce3d275189000e1c50e92efcdb6447bc260b1e5c41699b7a1959e3e1928fbaa
glib-2.31.8.tar.xz
This release is aimed at being used as part of GNOME
It seems like we've been avoiding talking about this particular issue
for a while, but I think it's time we got a bit more serious about it.
https://bugzilla.gnome.org/show_bug.cgi?id=657385
This bug introduced a 'Rename to:' field on gtk_menu_popup_for_device(),
which of course, is an API
On Tue, 2012-01-31 at 14:40 -0500, Ryan Lortie wrote:
existed in Gtk 3.2 and was bound as such. Python applications[1]
Sorry:
[1] https://bugs.launchpad.net/bugs/923171 (Ubuntu software centre)
___
gtk-devel-list mailing list
gtk-devel-list
hi,
I was quite fond of the XML format originally used by GMenu because it
allowed for a relatively concise expression of the menus in your
application. It turned out that this format didn't jive well with the
rest of GtkBuilder and, particularly, the tools that we use to extract
translations
hi Maciej,
Thanks for bringing up this topic. I'm not exactly sure what the proper
way forward is, but you raise some interesting possibilities.
On Thu, 2012-01-05 at 01:32 +0100, Maciej Marcin Piechotka wrote:
I don't think I can fix on libgee side without breaking API/ABI (at
least I don't
GLib 2.31.6 was just released.
This release is an unstable release on the way to 2.32.0. It is
intended for use with the GNOME 3.3.3 release and is needed to build
Gtk+ 3.3.6, which will be released soon.
You can grab it from the usual place:
http://download.gnome.org/sources/glib/2.31/
GLib 2.31.4 is out.
This is a point release on the way to what will become GLib 2.32.0.
http://download.gnome.org/sources/glib/2.31/
627fbffdb0c0a95709778e54ab32620d3e4ae9dfed939bb69ab4a50209ff43fb
glib-2.31.4.tar.xz
Overview of changes from GLib 2.31.2 to 2.31.4
hi,
On Fri, 2011-12-09 at 14:39 +0100, Nacho wrote:
just one thing that I don't have quite clear...
how will the extensibility be managed for the menus?
i.e adding a new menuitem from a plugin.
If the plugin can gain access to the GMenu then it can modify it
(adding/removing items, etc).
In
On Fri, 2011-12-09 at 09:50 +0100, Alexander Larsson wrote:
Windows actually has an application menu thing. If you right-click on
the application on the panel you can get app-specific operations in the
menu. I'm not sure if the normal usecase for these match what the app
menu is typically used
hi Tristan,
Thanks for the questions.
On Fri, 2011-12-09 at 14:56 +0900, Tristan Van Berkom wrote:
I think that the (twice) mentioned solution to this problem sounds
elegant enough, i.e. if you have 2 windows with different menubars
then they can easily be '2 applications' at least in terms
hi Jannis,
On Fri, 2011-12-09 at 15:34 +0100, Jannis Pohlmann wrote:
I guess this is unrelated but I have a question regarding extensions as
well. Will there be functionality similar to GtkUIManager-based merging
with placeholders in the GTK part of GMenu?
We use this heavily in Thunar to
On Fri, 2011-12-09 at 09:56 -0500, Ryan Lortie wrote:
The way this works is with questions.
Uhm. *sections.
Don't write email while trying to have a conversation at the same time,
kids :)
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
the searchable help menu
work I did will be entirely impossible to rebase on this. Although do
note that Mac OS has had that exact functionality for years.
On Fri, 2011-12-09 at 09:14 -0500, Ryan Lortie wrote:
What this base level of functionality is has yet to be written down --
and is not entirely known
hi,
On Fri, 2011-12-09 at 11:12 -0500, Morten Welinder wrote:
Will the new api allow one to write a gui that looks and feels
like it was made with the old api?
Yes.
Simply provide a menubar and no application menu and use
GtkApplicationWindow. You will get the menubar added for you
hi,
On Fri, 2011-12-09 at 16:07 +0100, Steve Frécinaux wrote:
Do you plan on/Would the current Gmenu infrastructure allow something
like the mockups in [1] ? Especially, menus like the Mega-menu mockup
for EoG adding a dropdown menu in the title bar [2] would seem to be
feasible
hi,
Today I landed the GMenuModel work on glib master. A release will be
following shortly.
There is related work in the 'wip/gmenu' branch of Gtk+ that will
hopefully be landing soon. There is a trivial example in
gtk+/examples/bloatpad.c that demonstrates some of the ideas here.
The main
hi,
On Fri, 2011-12-09 at 01:34 +0100, Andrea Bolognani wrote:
Does this mean different windows belonging to the same application will
not be able to have different per–window menubars? I’m thinking about
Empathy here, with its Buddy List and Conversation windows having
different menubars,
hi,
On Thu, 2011-12-08 at 19:24 -0800, John Ralls wrote:
I think that you misunderstand how mac os works.
Yes, a single menu bar is displayed at the top of the screen. This is
correct behavior according to Fit's Law, because you can bang the
pointer to the top of the screen and it can't
On Thu, 2011-12-01 at 19:26 +, Simon McVittie wrote:
Hi,
I've been looking into the details of how GObjects are destroyed,
hoping to solve https://bugzilla.gnome.org/show_bug.cgi?id=665211, in
which disposing a global singleton GDBusConnection in one thread races with
reffing and using it
GLib 2.31.2 is out.
This is a point release on the way to what will become GLib 2.32.0.
http://download.gnome.org/sources/glib/2.31/
19d7921671a487c3c5759a57df7b8508afdbadd7764d62a47a82fff7b399032b
glib-2.31.2.tar.xz
Overview of changes from GLib 2.31.0 to 2.31.2
GLib 2.31.2 is out.
This is a point release on the way to what will become GLib 2.32.0.
http://download.gnome.org/sources/glib/2.31/
19d7921671a487c3c5759a57df7b8508afdbadd7764d62a47a82fff7b399032b
glib-2.31.2.tar.xz
Overview of changes from GLib 2.31.0 to 2.31.2
dconf 0.11.2 is released:
http://download.gnome.org/sources/dconf/0.11/
4625978257cd8c273a4d31ea7a8788326df63267fc0236b6d879e891cd48fad9
dconf-0.11.2.tar.xz
This is a point release leading up to what will become 0.12.0.
Changes in dconf 0.11.2
===
- many bugfixes
On Wed, 2011-11-02 at 14:15 -0400, Matthias Clasen wrote:
E.g. Benjamin might be able to attend both...
This is really the issue. Having the gtk and a11y developers in the
same place is great -- but totally useless unless Benjamin can focus on
a11y while he's there.
For that reason, plus the
hi Pedro,
On Wed, 2011-10-26 at 16:14 -0300, Pedro Ignacio Guridi wrote:
Hello everyone,
I dont know if this list is the right place to post this information,
my apologies if is not.
I built Gtk+ 3.3.2, Glib 2.31, etc. under win32 (mingw32), I wanted to
share the link if somebody is
hi all,
dconf 0.11.0 is released. This is the first unstable release going
toward 0.12.
http://download.gnome.org/sources/dconf/0.11/
cfe99f06f517e51e543266f2b27fd50a480565b2b59aa32996d4841887251b93
dconf-0.11.0.tar.xz
There are some bugfixes:
- don't install a system service file
-
At long last, GLib 2.31.0 has been released.
http://download.gnome.org/sources/glib/2.31/
46fcaec884be7ce1b780feffb0da987b55e23850a870d94ed84356870532fe8c
glib-2.31.0.tar.xz
Most people reading this announcement know that there have been a huge
number of changes in this release. There
At long last, GLib 2.31.0 has been released.
http://download.gnome.org/sources/glib/2.31/
46fcaec884be7ce1b780feffb0da987b55e23850a870d94ed84356870532fe8c
glib-2.31.0.tar.xz
Most people reading this announcement know that there have been a huge
number of changes in this release. There
hi
On Thu, 2011-10-13 at 13:26 +0200, Murray Cumming wrote:
By the way, I also noticed that g_thread_init() is deprecated,
presumably because you must now used g_thread_new(), so you don't need
it, but I don't see a deprecation comment on g_thread_init().
g_thread_init() is deprecated because
hi Murray,
On Thu, 2011-10-13 at 12:48 +0200, Murray Cumming wrote:
This change in glib master does indeed break glibmm:
http://git.gnome.org/browse/glib/commit/?id=d904612100120d12126f1a6623a106d8a5b02fa6
I had a feeling it might break something or other, and I didn't think
about bindings.
hi Markus,
On Tue, 2011-10-11 at 12:12 +0200, Markus Elfring wrote:
If you have a GVariant* variable, you should usually know what type it is
already,
but if not, g_variant_get_type() will tell you.
Is a direct use of a function like g_variant_type_is_maybe recommended?
Yes. It's
On Tue, 2011-10-11 at 19:37 +0200, Markus Elfring wrote:
I stumbled on the detail that the functions g_variant_is_of_type and
g_variant_is_container are provided directly while some predicates can only
be
checked by the others.
g_variant_is_of_type (gv, G_VARIANT_TYPE_MAYBE) will do what
On Fri, 2011-10-07 at 09:24 -0400, Morten Welinder wrote:
what is the purpose of '(void) (0 ? *(atomic) ^ *(atomic) : 0)'?
Poor man's type check. That expression isn't valid for every
possible atomic.
Specifically, it ensures that the destination of the pointer is an
integral type. You
On Wed, 2011-09-28 at 11:03 +0200, Kean Johnston wrote:
So easily solved. Call the damned thing g_statfile() and have the structure
be GFileStat.
So then we would have 'struct stat' and 'GStatBuf' which would work with
g_stat(), g_lstat() and fstat(). Additionally we would add a
'GFileStat'
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
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
hi Stuart,
On Sun, 2011-09-25 at 13:45 -0600, Stuart Ambler wrote:
Apparently pkg-config used to contain within it an old version of
glib, used mostly for strings, lists, hash tables, and a few other
things, that the new version has removed and instead made itself
depend on glib. glib
On Tue, 2011-09-27 at 11:36 +0200, Kean Johnston wrote:
On 9/27/2011 9:08 AM, Steve Frécinaux wrote:
Won't you break ABI if you're changing the layout of the struct on
linux/unixes? As I understand this is not an issue on Windows since
everyone ships the libraries with the binary, but it is
hi Kean,
On Mon, 2011-09-26 at 06:57 +0200, Kean Johnston wrote:
https://bugzilla.gnome.org/show_bug.cgi?id=660095
Its small, it doesn't affect anything except Windows and it fixes an actual
build problem if your environment does have dirent.h. Thank you.
We were hard code frozen at the
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:
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
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
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
1 - 100 of 231 matches
Mail list logo
