Tristan Van Berkom wrote:
- Is there any kind of plan of enhancing GObject introspection ?
(ofcourse including its internals such as pspecs etc).
- Is it speced anywhere ?
- Is there anyone working on it ?
gobject-introspection module in GNOME CVS
-- Dan
Damon Chaplin wrote:
Maybe a better idea would be for bindings to grab all the gtk-doc
documentation, and then just override the docs for particular functions
if they need to.
Yeah, I didn't mean to suggest that the bindings docs could be generated
completely automatically from the C docs,
ANDREW PAPROCKI, BLOOMBERG/ 731 LEXIN wrote:
within compound statements. As an extension, GCC also allows this in
C89 mode. For example, you could do:
IMO, this is a GCC bug... from the man page:
(-std=)
c89
iso9899:1990
ISO C90 (same as -ansi).
Not a
Johan Dahlin wrote:
Over the last couple of weeks Henrique Romano and I have been working on
GtkBuilder, a UI constructor intended for inclusion in GTK+.
I'd like to discuss the API and some of the decisions before making the
code available for public review.
I went ahead and attached the
Cool.
Alexander Larsson wrote:
At some point in time gnome_vfs_uri_is_local() started detecting and
returning TRUE for NFS mounts and other type of local network
mounts. This is both slow and unexpected, and has led to problems and
unnecessary changes in many places.
s/TRUE/FALSE/, I think.
Alexander Larsson wrote:
Do many apps really require creating launchers
from arbitrary desktop files? What is the typical usecase of that?
Well, the panel in multiple places (main menu, panel launchers, run
dialog). The various panel add-ons/replacements (the Novell main menu
and app launcher,
OK, I've written a GInputStream subclass using libsoup to download HTTP
responses. It's not beautiful (because it has to convert between
libsoup's push API and gio's pull API), but it shows that it can work
for gvfs. The biggest problem with it right now is that there's no way
to make libsoup use
Felipe Contreras wrote:
How should applications use sockets with GIO?
I'm interested in hostname resolution, and socket handling. If
possible also proxy handling.
There isn't yet a good story here. See
http://bugzilla.gnome.org/show_bug.cgi?id=515973 and
Maciej Katafiasz wrote:
Den Tue, 07 Oct 2008 16:55:29 -0400 skrev Behdad Esfahbod:
Ugh. Why is that? Who knows? Matthias suggested that because a string
claiming to be length bytes long but terminating prematurely is not
valid. However, that statement assumes that string is nul-terminated.
Behdad Esfahbod wrote:
Sure, but then there's memcpy, memcmp, memdup, etc for the other behavior.
And they take void *, not char *, to indicate this fact.
I'm not arguing that a validate UTF-8 bytes possibly including NULs
function wouldn't be useful to some people, I'm just arguing that
Stefan Kost wrote:
I prefer there's an official documentation with no comments, and the
online documentation with the possibility to add comments. Just like
in www.php.net/docs.php where you have the online documentation with
comments, and if you choose to download the documentation (eg. to
David Zeuthen wrote:
This mail is already too long but there's one more thing.
Yeah. Still digesting. But...
I have not done all that much with D-Bus, but one thing I noticed while
doing the libsoup 2.4 API rewrite was that, at a very high level, D-Bus
and XML-RPC are fairly similar, and so it
David Zeuthen wrote:
Yeah. I think XML-RPC types can largely be considered a subset of the
D-Bus types. For the datetime we could add an extra ISO8601 data type or
something (don't think GTimeVal is enough; need to preserve the TZ I
think).
Nope, XML-RPC dateTimes are (unfortunately)
Ryan Lortie wrote:
The type system, of course, is that of DBus.
I love your feedback. Please give it all to me.
I took at a look at GVariant from the perspective of could I make
libsoup's XML-RPC (and future JSON) code use GVariant instead of
GValue. (For more background, see the thread
Ryan Lortie wrote:
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
(I still haven't read all of gnio, so I'm mostly only commenting on
Alex's comments, plus GSocket, since I have read that.)
Alexander Larsson wrote:
Every time I've done socket code I've enabled SO_REUSEADDR
Yeah, Ryan and I had this exact conversation (including the same link)
on IRC
Alexander Larsson wrote:
On Mon, 2009-04-27 at 13:22 -0400, Dan Winship wrote:
g_socket_finalize closes socket even if g_socket_close() is already
closed, need to add an is_closed variable. We should also check this in
all operations so that we don't accidentally call stuff on an fd that
may
Alexander Larsson wrote:
No GSocket methods are virtual, so its not possible to subclass GSocket
and override methods to e.g. create a TLS/SSL socket. The current TLS
code in gnio works on the higher level stream objects rather than the
socket object, but it would possibly be interesting to
I feel like, as much as possible, GSocket should behave the same on
Linux and Windows. So I'm dubious about a few things...
blocking/non-blocking: on Windows it is not possible to read the
non-blocking property of a socket so it won't be reliably detected, and
on windows any call to
Alexander Larsson wrote:
The not-possible-to-read-non-blocking thing only affects
g_socket_new_from_fd(), so Its not a horrible problem. Although I agree
that its kinda weird. Its clearly possible to implement blocking mode on
win32 purely on the gsocket.c side, which would make GSocket behave
Alexander Larsson wrote:
I was going to say we could make g_socket_listen() set it but
actually, you need to do it before calling bind(). I'm not really
familiar with the use cases of bind() on client sockets, but it seems
like probably if the application is trying to bind to a specific local
On 05/11/2009 03:47 AM, Alexander Larsson wrote:
On Sun, 2009-05-10 at 10:53 -0400, Dan Winship wrote:
But if you bind() and then connect() (eg, like the rcmd/rsh/rlogin
suite) then maybe you don't want SO_REUSEADDR. (And looking at the glibc
source for rresvport(), it doesn't use SO_REUSEADDR
On 05/11/2009 10:30 AM, Stefan Kost wrote:
Alexander Larsson schrieb:
GResolver is already in gio, yes. NameResolver isn't really less generic
than GResolver though. What else would it resolve but names? Could be
GDNSResolver though.
That sounds good. I was just wondering as there are
On 05/12/2009 05:22 AM, Paul LeoNerd Evans wrote:
Speaking of GResolver, in the API (which I'm currently staring at here:
http://git.gnome.org/cgit/glib/diff/gio/gresolver.h?h=gresolverid=05507dce1f540581028e8be0e220e68c44fade2f
) I don't see any attempt at the gai()-style hostname +
more comments, now that it's all committed... :-}
g_socket_new()'s documentation and implementation don't match wrt
protocol. (In particular, the docs refer to the protocol_id argument
as protocol, and talk about %NULL instead of 0.) Also, is there some
reason this is an int rather than another
On 05/25/2009 04:14 PM, Brian J. Tarricone wrote:
On 05/25/2009 02:04 AM, Nemes Sorin wrote:
With widescreens even on a mac globalmenu loose it's sense.
Kinda funny you specifically mention a mac -- do people in the mac
community complain about having a global menu? You'd think you would
On 11/09/2009 07:53 AM, Bastien Nocera wrote:
Could this be used by libsoup for websites that zlib-compress their
data?
It could (and eventually would), but passing data to zlib isn't the
hard part of the problem there. (And this will actually be working in
libsoup in 2.28.2.)
-- Dan
On 11/12/2009 11:36 AM, Michael Meeks wrote:
The 'real' fix, is to recognise that:
a) interposing (excluding LD_PRELOAD) is a horrible expensive
feature, that more often than not causes problems
Well, you're talking about the specific thing that (presumably) is
causing
On 11/13/2009 08:50 AM, 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.
Maybe we can do something like:
Add g_data_input_stream_read_until2() which doesn't consume
On 11/17/2009 04:54 AM, Alexander Larsson wrote:
On Fri, 2009-11-13 at 10:11 -0500, Dan Winship wrote:
On 11/13/2009 08:50 AM, Alexander Larsson wrote:
Maybe we can do something like:
Add g_data_input_stream_read_until2() which doesn't consume the input.
#define g_data_input_stream_read_until
On 11/18/2009 11:17 AM, Tristan Van Berkom wrote:
While the GSlice allocator storing some per-thread data and getting messed
up across g_thread_init() might be a fixable bug
it was fixed a very long time ago. The problem, as you note, is with
everything above libglib in the stack, not with
On 11/20/2009 01:49 PM, Alexander Larsson wrote:
What about making g_slice able to handle late initialization of threads,
but everything else that uses g_thread apis to protect something would
just get threads auto-initialized. Then super-simple apps using just
glist and ghashtable would not
On 12/01/2009 08:29 AM, Alexander Larsson wrote:
In addition to enabling threads (if complied in) in g_type_init() it
adds a G_THREADS_MANDATORY define that if set causes all the
g_thread_supported() calls to be removed in the g_thread_* macros.
Should probably add that to Cflags in
On 12/01/2009 03:36 PM, Alexander Larsson wrote:
I don't think that is quite right. Its only safe to set this define if
you can guarantee there is no calls to your code before g_type_init (or
g_thread_init directly) is called.
Hrmph. Could potentially add a define which would cause a
On 12/06/2009 10:05 AM, Adam Goode wrote:
I guess what I really would like is a way that I can use GLib privately
from my library and have it be thread-safe without requiring users of my
library have to link against gthread and call g_thread_init. I think it
is primarily just GSlice that is
On 03/14/2010 10:52 PM, Ryan Lortie wrote:
- replace G_BEGIN_DECLS/G_END_DECLS with protected visibility
pragmas. This means that any symbol declared in a header file
will end up with protected visibility.
which means what exactly? The gcc docs only say that `protected' and
On 03/17/2010 07:40 PM, Emmanuele Bassi wrote:
a stop gap solution is to avoid doing crazy stuff
like:
static void
my_blah_widget_init (MyBlahWidget *widget)
{
gtk_widget_set_foo (GTK_WIDGET (widget), TRUE);
gtk_widget_set_bar (GTK_WIDGET (widget), FALSE);
On 08/03/2010 04:50 AM, Emmanuele Bassi wrote:
Did outstanding work for GLib 2.26 get discussed ? I am only aware of
the datetime work, anything else ?
I'm reviewing the datetime API; we also discussed the TLS support in GIO
and it's pending a final review.
Proxy support, not TLS support.
Hey, there is code on the tls branch of glib (and glib-networking) for
implementing TLS (aka SSL) connections now. I would like to get this
into glib before the next release, which will presumably be shortly
before the next GNOME 2.91 release, on November 29 (and then I'd like to
NOT have API
On 11/18/2010 12:32 PM, laborer2008 laborer wrote:
Hello All
It is possible?
I build glib for embedded(with uClibc and disabled ipv6 support) and
found the following errors. Option to disable ipv6 in glib configure
script i did not find.
Right. You should build uClibc with IPv6 support.
On 11/19/2010 04:50 AM, Tor Lillqvist wrote:
Have you heard the phrase patches welcome?
I'm not sure that's true in this case. We're generally not big on being
able to select bits of API to include or not at compile time. People who
only want part of glib for some special purpose can just patch
On 11/30/2010 12:12 PM, Achuta wrote:
Hi,
GLib/GIO cannot listen on IPv6 link local address. This bug is because
GSocketAddress does not have a field for sin6_scope_id to fill in
interface
index (as stated in `man 7 ipv6`).
I would like to make the changes. Is there some
On 01/31/2011 01:13 AM, Benjamin Otte wrote:
Google codesearch didn't find any users
Note that Google code search doesn't index git.gnome.org (or most other
git repos besides github). It does find release tarballs, but that may
not catch new modules, minor projects, etc.
(qv
On 01/29/2011 08:03 AM, Antono Vasiljev wrote:
Something as good as in previous implementations missing in glib.
http://library.gnome.org/devel/glib/unstable/glib-URI-Functions.html
Most generic implementation I found in GNet but is deprecated.
Should I port this to GLib?
I started some
On 02/17/2011 11:22 AM, Piñeiro wrote:
You are proposing to forget this proxy approach on the accessibility
support. As far as I understand you are proposing to implement the ATK
interfaces directly on GTK, so instead of having a GTK widget and his
accessible equivalent, just having a GTK
On 05/31/2011 03:12 PM, Owen Taylor wrote:
So, let's add alternate API that allows for failure without going boom
and blowing up the world, and let's figure out how to get that hooked
up to languages with exceptions automatically. Yes, this is made harder
by the fact that it's a constructor,
On 06/19/2011 04:25 PM, Dmitry Matveev wrote:
My project includes writing a kqueue file monitoring backend for GIO, in
order to provide fast file monitoring to Glib/GIO-powered applications
on BSD systems.
Cool. I took a quick look. It mostly looks good. (Or at least, as good
as the inotify
On 08/12/2011 10:15 AM, Matthew Bucknall wrote:
Any better suggestions would be much appreciated. I'm hoping the
answer won't be that it doesn't matter if user data doesn't get
cleaned up because if the main loop stops the program is usually
terminating anyway - I know this is the attitude
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 there are only 2 exported symbols (g_thread_init and
g_thread_init_with_errorcheck_mutexes), I
On 08/31/2011 03:31 PM, Kevin Fox wrote:
Maybe the time to discuss pulling in an api something like Grand Central
Dispatch has arrived? :)
I was thinking it would be nice to integrate with GThreadPool somehow,
but I didn't have any specific idea of how that would work...
-- Dan
On 09/26/2011 10:54 AM, Ayo wrote:
...at least, I thought the API supported that. Browsing through the
code of the gnutls implementation in glib-networking, I see a single
internal state being used for both the read and write functions, with
apparently no synchronisation whatsoever. Am I
On 12/02/2011 07:55 AM, Tristan Van Berkom wrote:
o References to other GObjects are broken in dispose, and since
dispose can run multiple times, care must be taken, i.e.:
if (priv-reffed_object != NULL) {
g_object_unref (priv-reffed_object);
priv-reffed_object
I've pushed the GTask code to glib master.
For those who weren't watching the bug, this is a replacement for
GSimpleAsyncResult and GIOScheduler with some additional functionality
and simplifications. The docs
(http://git.gnome.org/browse/glib/tree/gio/gtask.c#n28) cover the use
cases in detail
On 11/02/2012 10:15 AM, Tal Hadad wrote:
First, there were an old project called GTask[0]
Yes, but people building on top of glib shouldn't use a plain G prefix
in their names... we can't just let everyone with an ftp server be able
to steal potential names from us.
But the real problem is not
On 11/05/2012 01:42 PM, Ryan Lortie wrote:
The upshot of this is that, as of a few moments ago, building glib from
git without also building git versions of pygobject and libsoup has the
potential to result in things being broken.
Old libsoup is fine; as noted in the libsoup commit, the
On 01/17/2013 12:17 PM, Ken Bass wrote:
ch-main_context = g_main_context_default ();
g_main_context_unref(context);
g_main_context_default() does not give you a ref on the default context,
so your code here is destroying an object internal to glib. If you call
this more than once (or,
On 01/17/2013 02:48 PM, Ken Bass wrote:
On 01/17/2013 01:58 PM, Dan Winship wrote:
g_main_context_default() does not give you a ref on the default context,
so your code here is destroying an object internal to glib. If you call
this more than once (or, if you do *anything* involving
On 05/19/2013 08:23 AM, John Emmas wrote:
Just updated from Git and tried to build libglib using MSVC. The build
fails because a couple of files are now referencing 'STDOUT_FILENO'
and/or 'STDERR_FILENO'.
Oops. It builds under mingw...
Let's see what Matthias says, but I'd say probably just
On 05/20/2013 02:50 PM, John Emmas wrote:
notice that 'total += nwrote' occurs twice during each loop iteration.
Was that the intended behaviour?
nope. fixed now, along with using stdio instead of write(), so it should
compile again on Windows now.
-- Dan
On 05/31/2013 05:55 AM, John Emmas wrote:
On 31 May 2013, at 09:15, John Emmas wrote:
what would cause the appearance that some files have been removed when
(apparently) they're still present and needed. Maybe they did get added
back later but I just can't find it?
Ah, I think maybe
On 09/24/2013 07:40 AM, Przemyslaw Kedzierski wrote:
Hello
Currently we work on an experimental feature for libgio,
we try to adapt it to use kdbus.
We consider some concepts, one of it is adding a new transport
for dbus.
There are three interesting files in glib/gio subdirectory:
On 10/03/2013 04:18 PM, John Ralls wrote:
In
https://git.gnome.org/browse/glib/commit/?id=d2bb019533bbcbd1cee3891822ac7ba6ff55ad3d
, Colin removed the call to gl_GLIBC21 from configure.ac, which breaks the
installation of charset.alias because clause in glib/libcharset/Makefile.am
which
On 10/08/2013 12:36 AM, A. Walton wrote:
My only question is why GIO and not GDK? This kind of per-platform API
would happily reside in GDK and prevent us from adding even more
extension points to GIO. There's really nothing I/Oish about this API
(despite GIO already being the home for lost
On 10/08/2013 11:25 AM, Jasper St. Pierre wrote:
glib-networking exists for political reasons. I don't think we want to
repeat that with something we can just import in-tree.
No, glib-networking exists for the same reasons as gvfs; to avoid having
circular dependencies (libproxy depends on
On 10/22/2013 11:45 AM, fanc...@yahoo.com.tw wrote:
Unforunately I
can't say anything about anything at or before Visual Studio 2005, as I
don't have access to them
Since you are (as far as I can remember) the only person who has
submitted any Visual Studio build fixes in the last several
On 11/14/2013 03:53 PM, Bernhard Schuster wrote:
Is this possible (read: implemented with gio modules)? I need this for
gtlsbackend to be statically put into my binary (which uses
glib-networking).
The --enable-static --disable configure flags does not change that
behaviour (still got the
On 03/03/2014 09:40 AM, Colin Walters wrote:
1) Split off some of the core settings like org.gnome.system.proxy into
gsettings-core-settings or something
The current proxy settings (and maybe some of the others in
gsettings-desktop-schemas) cause warnings every time you install a new
schema,
On 12/22/2017 06:09 AM, Benjamin Berg wrote:
> Hi,
>
> I ran into an issue the other day where abrtd was polling an invalid
> file descriptor. Obviously, there must be a bug in abrtd which closed
> the wrong FD even though it was still registered with the mainloop
> using g_io_channel_unix_new
68 matches
Mail list logo
