Re: g_io_channel_win32_new_messages() WaitForSingleObject()
Man, I'm almost there. First, just ignore everything having to do with
win32 services. I was misreading the msdn service example. The
WaitFor*() is really done on an event. So here is a stripped down demo
of the progress so far. It does what I want, but then crashes before
ending the event loop gracefully, which means something needs to be
different. I'm sure it has something to do with the size arg to
g_source_new() call, since GSource is simply:
typedef struct {
} GSource;
Clearly I have no idea what I even want to pass to it.
=== glib_win32_event_test.c =
#include glib.h
#include windows.h
HANDLE windows_event = NULL;
GPollFD g_poll_fd;
GSourceFuncs g_source_funcs;
int global_int = 0;
gboolean my_source_prepare(GSource *source, gint *timeout_)
{
g_print(1) my_source_prepare()\n);
*timeout_ = -1;
return FALSE;
}
gboolean my_source_check(GSource *source)
{
g_print(1) my_source_check()\n);
if(global_int)
{
g_print(1) bam!\n);
return TRUE;
}
return FALSE;
}
gboolean timeout_callback(gpointer opaq)
{
g_print(1) still here...\n);
return TRUE;
}
DWORD WINAPI thread_entry(LPVOID lpParameter)
{
g_print(2) I'm thread #%d\n, GetCurrentThreadId());
Sleep(4000);
g_print(2) stuff is going to happen now..\n);
global_int = 1;
SetEvent(windows_event);
g_print(2) I'm done\n);
return 0;
}
int main(int argc, char **argv)
{
DWORD error_code;
gchar *error_string;
GMainLoop *main_loop;
GSource *g_source;
g_print(1) I'm thread #%d\n, GetCurrentThreadId());
if((windows_event = CreateEvent(NULL, TRUE, FALSE, NULL)) == NULL)
{
error_code = GetLastError();
error_string = g_win32_error_message(error_code);
g_print(1) CreateEvent() failed, \%s\\n, error_string);
g_free(error_string);
return 1;
}
main_loop = g_main_loop_new(NULL, FALSE);
g_timeout_add(1000, timeout_callback, NULL);
g_poll_fd.events = 0;
g_poll_fd.revents = G_IO_IN;
g_poll_fd.fd = windows_event;
memset(g_source_funcs, 0, sizeof(GSourceFuncs));
g_source_funcs.prepare = my_source_prepare;
g_source_funcs.check = my_source_check;
g_source = g_source_new(g_source_funcs, sizeof(GSource));
g_source_attach(g_source, NULL);
g_source_add_poll(g_source, g_poll_fd);
if(CreateThread(NULL, 0, thread_entry, NULL, 0, NULL) == NULL)
{
error_code = GetLastError();
error_string = g_win32_error_message(error_code);
g_print(1) CreateThread() failed, \%s\\n, error_string);
g_free(error_string);
return 1;
}
g_main_loop_run(main_loop);
return 0;
}
cmd.exe session output:
1) I'm thread #3444
1) my_source_prepare()
2) I'm thread #5064
1) my_source_check()
1) still here...
1) my_source_prepare()
1) my_source_check()
1) still here...
1) my_source_prepare()
1) my_source_check()
1) still here...
1) my_source_prepare()
2) stuff is going to happen now..
2) I'm done
1) my_source_check()
1) bam!
1) still here...
[crash and burn]
=
Thoughts?
Tor Lillqvist wrote:
It's best to experiment, as I said I don't recall the details by
heart... and too busy to actually check now.
--tml
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: g_io_channel_win32_new_messages() WaitForSingleObject()
Well if any lone googlers ever find this, and want to know what
happened. I did fix it with this, but I still think the right way is to
some how create a new structure that is inherits the GSourceFuncs and
adds a place to store the event handle and the protected data (in this
case global_int). If there was an example of how to create a source, or
some doc on a source life cycle, that would be helpful. I did look at
the source, but was quickly lost. I'm guessing the main loop
architecture involves multiple sources, fds, and realization
callbacks all being able to exist without extras. So for instance 1
fd could trigger 5 sources, which each result in glib calling a variable
number of callbacks. If only there was more time to spend on these
things
#include glib.h
#include windows.h
HANDLE windows_event = NULL;
GPollFD g_poll_fd;
GSourceFuncs g_source_funcs;
int global_int = 0;
GMainLoop *main_loop;
gboolean my_source_prepare(GSource *source, gint *timeout_)
{
g_print(1) my_source_prepare()\n);
*timeout_ = -1;
return FALSE;
}
gboolean my_source_check(GSource *source)
{
g_print(1) my_source_check()\n);
if(global_int)
{
g_print(1) bam!\n);
// g_source_remove_poll(source, g_poll_fd);
return TRUE;
}
return FALSE;
}
gboolean my_source_dispatch(GSource *source, GSourceFunc callback,
gpointer user_data)
{
g_print(1) my_source_dispatch()\n);
if(callback == NULL)
return FALSE;
return callback(user_data);
}
gboolean my_source_callback(gpointer data)
{
g_print(1) my_source_callback()\n);
g_main_loop_quit(main_loop);
return FALSE;
}
gboolean timeout_callback(gpointer opaq)
{
g_print(1) still here...\n);
return TRUE;
}
DWORD WINAPI thread_entry(LPVOID lpParameter)
{
g_print(2) I'm thread #%d\n, GetCurrentThreadId());
Sleep(4000);
g_print(2) stuff is going to happen now..\n);
global_int = 1;
SetEvent(windows_event);
g_print(2) I'm done\n);
return 0;
}
int main(int argc, char **argv)
{
DWORD error_code;
gchar *error_string;
GSource *g_source;
g_print(1) I'm thread #%d\n, GetCurrentThreadId());
if((windows_event = CreateEvent(NULL, TRUE, FALSE, NULL)) == NULL)
{
error_code = GetLastError();
error_string = g_win32_error_message(error_code);
g_print(1) CreateEvent() failed, \%s\\n, error_string);
g_free(error_string);
return 1;
}
main_loop = g_main_loop_new(NULL, FALSE);
g_timeout_add(1000, timeout_callback, NULL);
g_poll_fd.events = 0;
g_poll_fd.revents = G_IO_IN;
g_poll_fd.fd = windows_event;
memset(g_source_funcs, 0, sizeof(GSourceFuncs));
g_source_funcs.prepare = my_source_prepare;
g_source_funcs.check = my_source_check;
g_source_funcs.dispatch = my_source_dispatch;
g_source = g_source_new(g_source_funcs, sizeof(GSource));
g_source_attach(g_source, NULL);
g_source_add_poll(g_source, g_poll_fd);
g_source_set_callback(g_source, my_source_callback, NULL, NULL);
if(CreateThread(NULL, 0, thread_entry, NULL, 0, NULL) == NULL)
{
error_code = GetLastError();
error_string = g_win32_error_message(error_code);
g_print(1) CreateThread() failed, \%s\\n, error_string);
g_free(error_string);
return 1;
}
g_main_loop_run(main_loop);
return 0;
}
Thomas Stover wrote:
Man, I'm almost there. First, just ignore everything having to do with
win32 services. I was misreading the msdn service example. The
WaitFor*() is really done on an event. So here is a stripped down
demo of the progress so far. It does what I want, but then crashes
before ending the event loop gracefully, which means something needs
to be different. I'm sure it has something to do with the size arg to
g_source_new() call, since GSource is simply:
typedef struct {
} GSource;
Clearly I have no idea what I even want to pass to it.
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: g_io_channel_win32_new_messages() WaitForSingleObject()
On Thu, 02 Apr 2009 16:53:11 -0500
Thomas Stover tho...@wsinnovations.com wrote:
Well if any lone googlers ever find this, and want to know what
happened. I did fix it with this, but I still think the right way is
to some how create a new structure that is inherits the
GSourceFuncs and adds a place to store the event handle and the
protected data (in this case global_int). If there was an example of
how to create a source, or some doc on a source life cycle, that
would be helpful. I did look at the source, but was quickly lost. I'm
guessing the main loop architecture involves multiple sources,
fds, and realization callbacks all being able to exist without
extras. So for instance 1 fd could trigger 5 sources, which each
result in glib calling a variable number of callbacks. If only there
was more time to spend on these things
I may be missing your point (I would have to read through the
back-posts to make sense of it), but if you want to create your own
source object to hold its own protected/private data, it is just this:
struct MySource {
GSource source;
/* my data, such as a gpointer but it could be anything and as much member data
as you want */
gpointer data;
};
It is created with:
MySource *my_source = (MySource*) g_source_new(source_funcs, sizeof(MySource));
/* initialise data */
my_source-data = my_object;
For more information see this, in particular the section Creating new
sources types:
http://library.gnome.org/devel/glib/stable/glib-The-Main-Event-Loop.html
An idle object may already do much of what you want. With windows, I think
it uses a window event object under the hood.
Chris
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: g_io_channel_win32_new_messages() WaitForSingleObject()
Chris Vine wrote:
I may be missing your point (I would have to read through the
back-posts to make sense of it), but if you want to create your own
source object to hold its own protected/private data, it is just this:
struct MySource {
GSource source;
/* my data, such as a gpointer but it could be anything and as much member data as you want */
gpointer data;
};
It is created with:
MySource *my_source = (MySource*) g_source_new(source_funcs, sizeof(MySource));
/* initialise data */
my_source-data = my_object;
For more information see this, in particular the section Creating new
sources types:
http://library.gnome.org/devel/glib/stable/glib-The-Main-Event-Loop.html
An idle object may already do much of what you want. With windows, I think
it uses a window event object under the hood.
Chris
Dude! Yes! Your example above needs to be in that section you reference,
which I missed even though I've been looking at that page all day. Now
if I could just figure out how to make the g_main_loop_quit() work with
out first calling g_main_loop_new(). Which would make sense to me except
g_main_loop_quit() is apparently the only function that needs the
g_main_loop_new() call. Even g_main_loop_run() will work with a NULL.
The relationship between main loops, main contexts, defaults, and
manually created ones is ambiguous at best. Anyway thanks Tor and Chris.
Some notes for anyone else who is just figuring out several things like
myself:
-a real new source would have a constructor that would do the
allocation and setup
-it would also have its own functions for setting up callbacks to source
specific events
-I think g_source_remove_poll() would be called in related destructor,
so I suppose the GPollFD structure needs to be stored in MySource as well
-I guess the destructor would be the closer_callback of the
GSourceFuncs parameter
-the GSourceFuncs and GPollFD variables are just copied by glib when
they given as parameters, so they don't need to dynamic (or
global/static like my last examples)
=== updated conversational source (yes! no globals) ===
#include glib.h
#include windows.h
typedef struct {
GSource source;
HANDLE windows_event_handle;
int integer;
} MySource;
gboolean my_source_prepare(GSource *source, gint *timeout_)
{
MySource *my_source = (MySource *) source;
g_print(1) my_source_prepare()\n);
*timeout_ = -1;
return FALSE;
}
gboolean my_source_check(GSource *source)
{
MySource *my_source = (MySource *) source;
g_print(1) my_source_check()\n);
if(my_source-integer)
{
g_print(1) bam!\n);
return TRUE;
}
return FALSE;
}
gboolean my_source_dispatch(GSource *source, GSourceFunc callback,
gpointer user_data)
{
MySource *my_source = (MySource *) source;
g_print(1) my_source_dispatch()\n);
if(callback == NULL)
return FALSE;
return callback(user_data);
}
gboolean my_source_callback(gpointer data)
{
GMainLoop *main_loop = (GMainLoop *) data;
g_print(1) my_source_callback()\n);
g_main_loop_quit(main_loop);
return FALSE;
}
gboolean timeout_callback(gpointer opaq)
{
g_print(1) still here...\n);
return TRUE;
}
DWORD WINAPI thread_entry(LPVOID lpParameter)
{
MySource *my_source = (MySource *) lpParameter;
g_print(2) I'm thread #%d\n, GetCurrentThreadId());
Sleep(4000);
g_print(2) stuff is going to happen now..\n);
my_source-integer = 1;
SetEvent(my_source-windows_event_handle);
g_print(2) I'm done\n);
return 0;
}
int main(int argc, char **argv)
{
DWORD error_code;
gchar *error_string;
GPollFD g_poll_fd;
GSourceFuncs g_source_funcs;
GMainLoop *main_loop;
MySource *my_source;
g_print(1) I'm thread #%d\n, GetCurrentThreadId());
memset(g_source_funcs, 0, sizeof(GSourceFuncs));
g_source_funcs.prepare = my_source_prepare;
g_source_funcs.check = my_source_check;
g_source_funcs.dispatch = my_source_dispatch;
my_source = g_source_new(g_source_funcs, sizeof(MySource));
g_source_attach(my_source, NULL);
main_loop = g_main_loop_new(NULL, FALSE);
g_source_set_callback(my_source, my_source_callback, main_loop, NULL);
if((my_source-windows_event_handle = CreateEvent(NULL, TRUE, FALSE,
NULL)) == NULL)
{
error_code = GetLastError();
error_string = g_win32_error_message(error_code);
g_print(1) CreateEvent() failed, \%s\\n, error_string);
g_free(error_string);
return 1;
}
my_source-integer = 0;
g_poll_fd.events = 0;
g_poll_fd.revents = G_IO_IN;
g_poll_fd.fd = my_source-windows_event_handle;
g_source_add_poll(my_source, g_poll_fd);
g_timeout_add(1000, timeout_callback, NULL);
if(CreateThread(NULL, 0, thread_entry, (LPVOID) my_source, 0, NULL) ==
NULL)
{
error_code = GetLastError();
error_string = g_win32_error_message(error_code);
g_print(1) CreateThread() failed, \%s\\n, error_string);
g_free(error_string);
return 1;
}
g_main_loop_run(main_loop);
return 0;
}
===
--
www.thomasstover.com
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
Re: Moving GLib and GTK+ to git
On Mon, 2009-03-30 at 12:47 -0400, Matthias Clasen wrote: Last week, I said that I'd like to get this done by the end of March, which is almost upon us now. I've got a local branch with the rebased client-side-windows work. However, I am unable to push it to git.gnome.org due to the pre-commit hooks: The following translation (.po) file appears to be invalid. (When updating branch 'client-side-windows'.) po/af.po The results of the validation follow. Please correct the errors on the line numbers mentioned and try to push again. stdin:90: keyword msgctxt unknown stdin:90:8: parse error . Checking http://git.gnome.org/cgit/gitadmin-bin/tree/pre-receive-check-po we have: # gettext-0.14.6 on git.gnome.org isn't new enough to handle # features such as msgctx # dash_c=-c dash_c= This means whats currently in gtk+ master branch does not pass the commit checks, so we can't branch master even if no changes are made to the pofiles. Also, it means we can't do updates to the pofiles in master that uses msgctxt. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Upgrade of gettext on git.gnome.org (was Re: Moving GLib and GTK+ to git)
On Thu, Apr 02, 2009 at 12:07:30PM +0200, Alexander Larsson wrote: I've got a local branch with the rebased client-side-windows work. However, I am unable to push it to git.gnome.org due to the pre-commit hooks: The following translation (.po) file appears to be invalid. (When updating branch 'client-side-windows'.) po/af.po The results of the validation follow. Please correct the errors on the line numbers mentioned and try to push again. stdin:90: keyword msgctxt unknown stdin:90:8: parse error . Checking http://git.gnome.org/cgit/gitadmin-bin/tree/pre-receive-check-po we have: # gettext-0.14.6 on git.gnome.org isn't new enough to handle # features such as msgctx # dash_c=-c dash_c= So a gettext update should be done. CC'ed gnome-sysadmin. -- Regards, Olav ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Upgrade of gettext on git.gnome.org (was Re: Moving GLib and GTK+ to git)
On Thu, 2009-04-02 at 22:45 +0200, Olav Vitters wrote: On Thu, Apr 02, 2009 at 12:07:30PM +0200, Alexander Larsson wrote: I've got a local branch with the rebased client-side-windows work. However, I am unable to push it to git.gnome.org due to the pre-commit hooks: The following translation (.po) file appears to be invalid. (When updating branch 'client-side-windows'.) po/af.po The results of the validation follow. Please correct the errors on the line numbers mentioned and try to push again. stdin:90: keyword msgctxt unknown stdin:90:8: parse error . Checking http://git.gnome.org/cgit/gitadmin-bin/tree/pre-receive-check-po we have: # gettext-0.14.6 on git.gnome.org isn't new enough to handle # features such as msgctx # dash_c=-c dash_c= So a gettext update should be done. CC'ed gnome-sysadmin. Upgrading the system gettext to a radically different version isn't something that I want to do. My plan here is to create an RPM with just the gettext utilities that installs in /usr/lib/gettext17 or something. (BTW, I temporarily disabled the hooks so Alex could push his branch.) - Owen ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GLib plans for the next cycle
Hi Matthias Clasen wrote: One thing that has been tossed around for a long time is that it would be really good to have DBus support on the Glib level. Agree strongly, but I'm not sure of the timing. A couple of people have raised a few questions with me recently (in light of the noise I've been making about GVariant and GBus) about how this could be happening yet. A few of the concerns that were raised: - How will compatibility between EggDBus and GBus be? I think this is not a very big concern, actually. These two things are currently aimed in very different directions. GBus is very low-level at the moment, mostly only implementing things that EggDBus currently uses libdbus-1 to do. - Why is there EggDBusVariant instead of GVariant? How will these map? See below. - Do we want glib depending on libdbus? It is my understanding that the intention is that glib is at the bottom of the stack. I felt like the reason that the GIO/gvfs split occured the way it did was in a large part because the gvfs client would not be able to use libdbus if it was in glib. - What of the license issues? GLib is LGPL. libdbus-1 is not. The recent attempt to relicense libdbus-1 failed spectacularly due to copyright in a large chunk of it having been acquired by a bank (or something?) when CodeFactory AB folded. - How does it fit with gobject-introspection? It seems like there could be a lot of advantage here in terms of easily exporting objects on the service side without need for large tables, if/elseif/elseif statements or code generation. - Do we need code generation? Somewhat related to the last question, clearly: maybe we can avoid having generated code. There is precedent for generated code in glib, certainly (enums, marshalers, etc.) but adding more is still a significant decision -- particularly when alternatives are available. This is a huge ideological debate, of course: I'm not going to suggest that this approach is wrong, but I guess my preference would lie on the other side, and it seems 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 called gbus. It is lower-level than EggDbus, and might be suitable as a replacement for libdbus. While I have no clear idea yet how EggDbus and gbus will eventually relate, it is worth pointing out that EggDbus' use of libdbus is an implementation detail that is not exposed in the api, so it would be possible to replace it by something like gbus later on. GBus is in a completely different problem space than EggDBus, so there's not much toe-stepping going on here. I'm not certain GBus is stable enough that I'd feel comfortable encouraging its uptake during this cycle. In the meantime, that means that we'd have to deal with the license and external dependency problems that come with using libdbus-1. It also means that we might be in trouble later if we find out that the abstraction was a tiny bit leaky. I do intend to propose GVariant for glib this cycle -- I'm going to be creating a branch of the newly-converted glib git repository and merging GVariant into it soon. Assuming all goes well, EggDBus could be using it at this point. This would make future transition to GBus extremely easy and would avoid converting between two different value types that do essentially the same thing. Once we release EggDBus with one variant type or the other appearing on the public API, we're more or less stuck that way forever. - What do we do about collections ? EggDbus adds typesafe GObject wrappers around GHashTable and GArray. Other people have grandiose plans to force java/.net style collection interfaces into GObject. My proposal: Dodge the issue by just adding the minimal necessities to GObject: a type for GArray (GHashTable already has one), and an api to associate element type information to arrays and hash tables. I suspect that this will be insufficient. In general, the GType system isn't powerful enough to express DBus types properly. This is what lead to the creation of GVariant. Even if we have support for querying the element type of an array, for example, we can get into situations where we can still have type errors. Consider the case of an array of arrays of strings (which is a fairly simple DBus type: aas). In this case, if you have a GArray, and query its type you will see the answer is G_TYPE_ARRAY. This doesn't help you very much. You have to grab one of the inside arrays and query its type. If the top array happens to be the empty array then you're really in trouble because now you have no way of determining the (complete) type of this empty array. It's also not reasonable to (dynamically?) create a new GType for the exact type
Re: GLib plans for the next cycle
Hi, On Thu, Apr 2, 2009 at 7:05 PM, Ryan Lortie de...@desrt.ca wrote: - How does it fit with gobject-introspection? - Do we need code generation? I'm on the same page with you here, but I think the fix is to split the object mapping from the other pieces (as outlined in my long manifesto previously). Then go ahead and get the other pieces stable and usable, and give the various object mapping ideas and codebases some more time to settle. - What of the license issues? GLib is LGPL. libdbus-1 is not. The recent attempt to relicense libdbus-1 failed spectacularly due to copyright in a large chunk of it having been acquired by a bank (or something?) when CodeFactory AB folded. Just for the record, my comment on this has always been that the license issues were not earth-shattering to begin with, and the relicensing was just throwing a bone to people who cared. Not sure large chunk is super accurate, either. As a practical matter this topic is highly overblown. Nobody has yet explained (to my satisfaction anyway) how the libdbus license has an issue the LGPL does not have. Perhaps we should get Luis or SFLC on the case, but I'm not sure it's worth their time. http://log.ometer.com/2007-07.html#17.2 3 points here. 1. AFL+GPL is the same as LGPL+GPL in the case people are complaining about. LGPL is a dual-license - the part that's the LGPL itself, OR you can choose GPL. The part that's the LGPL itself is not GPL-compatible - it's a totally different license. That's why it gives you the choice of GPL instead. libdbus is the same way, but it's choice of AFL (much less restrictive than LGPL) or GPL. Remember, when you link a GPL program to an LGPL library you are using the library under GPL. Same if you link a GPL program to dbus. The difference between dbus and an LGPL library arises only if your program is *not* GPL. You have to choose whether you want LGPL or GPL when using GTK, and AFL or GPL when using libdbus. You can't say your program is using both choices. You have to choose. If a program is GPL+Exception, I don't think you can choose GPL for an LGPL library. You have to use the LGPL terms. This means, however, that your program must, in its exception, allow linking to the LGPL library. It could also allow linking to an AFL library, if so. If your exception doesn't allow this, then your program's GPL terms require that the library be distributed under GPL... but if the library is GPL, you can't have the exception. So GPL+exception is not compatible with an LGPL library unless the exception includes LGPL libraries. 2. It's unclear that the AFL2.1 is GPL-incompatible. GPLv2 is hard to understand on this topic, so it's hard to know. GPLv3 may be clearer. But as generally understood, if you distributed libdbus under either GPL version, you'd be licensing your patents under GPL. All AFL2.1 requires is that if you sue *with respect to libdbus* claiming libdbus infringes your patents, you can't distribute libdbus. But distributing libdbus under GPL requires you not to sue with respect to libdbus. So in practice, there is no situation AFL adds further restrictions over GPL. The GPL already prevents you from suing for infringement claiming that libdbus infringes your patents, *while distributing libdbus yourself*, because distributing libdbus yourself necessarily licenses your patents. There is no way, under either GPL or AFL, to distribute libdbus while simultaneously suing users of libdbus saying libdbus infringes your patents. The licenses agree on this. As does LGPL for that matter. So the situation where 1) AFL keeps you from doing something and 2) GPL allowed you to do that same thing, does not ever exist. As a result, I don't think there's a further restriction. To me further restriction means prevents something the GPL allowed me to do and the AFL does not do so. AFL is pretty much an MIT/X11 license and an extremely liberal and toothless patent clause (compared to the GPL's patent requirements). 3. There's no practical issue, even if there's a theoretical one (which I don't think there is) _Even_ if I'm wrong on the theory (IANAL), the case where it even _matters_ is that some non-software company who owns the assets of a small business (codefactory) that went bankrupt years ago, somehow opens a musty old file, cross-references it with open source forums on the Internet, realizes they could disrupt the distribution of something called Rhythmbox, goes to lots of legal time and expense to do so... and then we either rewrite the Anders-written code in libdbus, or add an exception to the GPL in Rhythmbox, or relicense Rhythmbox to GPLv3, or some other solution, and we solve the problem. There are many things to worry about in life, but this is not one of them. btw, I believe we were going to add a notice to COPYING in libdbus to the effect of all new code is also MIT/X11, and most code is MIT/X11, but a few bits are GPL/AFL so that new contributions are MIT/X11 and we don't
Re: GLib plans for the next cycle
On Thu, 2009-04-02 at 19:05 -0400, Ryan Lortie wrote: Hi Matthias Clasen wrote: One thing that has been tossed around for a long time is that it would be really good to have DBus support on the Glib level. Agree strongly, but I'm not sure of the timing. A couple of people have raised a few questions with me recently (in light of the noise I've been making about GVariant and GBus) about how this could be happening yet. A few of the concerns that were raised: - How will compatibility between EggDBus and GBus be? I think this is not a very big concern, actually. These two things are currently aimed in very different directions. GBus is very low-level at the moment, mostly only implementing things that EggDBus currently uses libdbus-1 to do. Right, the point of the EggDBus effort is really just to provide a reasonable object mapping for C programmers using GObject, e.g. the focus is really the C object binding. Yes, this involves code generation (and way too much code at the moment but that is fixable) since we care about things like type safety and other crap. Anyway, so Havoc made a good point that we should also making things easy for non-C language bindings on top of GLib so he wrote a big laundry list of things that I largely agree with (that won't affect the C object binding that EggDBus gives you) and I'm planning to implement. Presumably if EggDBus is using GBus instead of libdbus-1 this would have to come from GBus ;-) Some relevant threads http://mail.gnome.org/archives/gtk-devel-list/2009-February/msg00121.html http://mail.gnome.org/archives/gtk-devel-list/2009-February/msg00123.html http://mail.gnome.org/archives/gtk-devel-list/2009-March/msg00026.html http://mail.gnome.org/archives/gtk-devel-list/2009-March/msg00030.html So, yeah, from a 50,000 feet perspective you are right that it's not important for the EggDBus C object binding whether libdbus-1 or gbus or whatever is used. The important point, however, is that the non C object binding stuff is reasonably efficient so it's usable by non-C object mappings without having to copy a lot of values around and allocate memory to free it again nano-seconds later. License issues aside, I'm not exactly sure why we'd want to avoid using libdbus-1. My view has always been that application programmers should not even have to know that libdbus exist because they should be using a language specific object mapping that hides libdbus-1... using either generated code or varargs-ish functions depending on your taste and the size and complexity of the D-Bus service you are providing and/or using. - What do we do about collections ? EggDbus adds typesafe GObject wrappers around GHashTable and GArray. Other people have grandiose plans to force java/.net style collection interfaces into GObject. My proposal: Dodge the issue by just adding the minimal necessities to GObject: a type for GArray (GHashTable already has one), and an api to associate element type information to arrays and hash tables. I suspect that this will be insufficient. In general, the GType system isn't powerful enough to express DBus types properly. This is what lead to the creation of GVariant. Even if we have support for querying the element type of an array, for example, we can get into situations where we can still have type errors. Consider the case of an array of arrays of strings (which is a fairly simple DBus type: aas). In this case, if you have a GArray, and query its type you will see the answer is G_TYPE_ARRAY. This doesn't help you very much. You have to grab one of the inside arrays and query its type. If the top array happens to be the empty array then you're really in trouble because now you have no way of determining the (complete) type of this empty array. If you are not using a D-Bus variant this information is explicitly available as part of the interface contract and it is also in the the introspection data http://people.freedesktop.org/~david/eggdbus-HEAD/eggdbus-eggdbusinterface.html#EggDBusInterfaceInfo as a D-Bus signature. For d-feet D-Bus debugging / introspection style apps you can also get a EggDBusInterfaceInfo struct by introspecting objects at run-time (again as a D-Bus signature) using egg_dbus_object_proxy_introspect(). If you are using a D-Bus variant the signature is available on EggDBusVariant. The point is that you can always get to the D-Bus signature and from that you can infer the complete type. So, you are right that the G type system _alone_ isn't powerful enough if we do it this way. E.g. you will need to augment the type with the D-Bus signature and then you have all the information you need. I'm not sure that's a big deal. (Note that in for most real-life apps this is not a big deal. People normally code their applications against a known interface contract (e.g. they know the D-Bus API at coding time) so they know exactly what a value will
Re: A model/buffer for GtkEntry
Matthias Clasen wrote: On Thu, Mar 26, 2009 at 5:38 PM, Stef Walter stef- That may be the case, and I thought about this myself. One thing in favor of doing the conversion of 'real text' - 'display text' in the model is that it allows subclassed models to do some quite interesting stuff in the conversion. Once you talk about moving this kind of templated input into the model, you also need to move cursor movement and selection handling to the model, and then the model gets a lot more complicated. Okay, well then I should probably follow Tristan's suggestion [1] and keep the conversion to 'display text' in the view. This would mean that all the invisibility would continue to live in GtkEntry. I'll work on abstracting it out a bit better, instead of 'if(entry-visible)' everywhere. Cheers, Stef [1] http://mail.gnome.org/archives/gtk-devel-list/2009-March/msg00173.html ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
