[no subject]
Happy new year! Happiness is your life. http://www.odenvoyage.ironie.org/sites.m.php?ligoogleId=06fi5 ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Announce: glib-jsonrpc
On Tue, 2012-01-03 at 16:38 -0800, Christian Hergert wrote:
Hi,
On Tue, 2011-12-27 at 06:52 +0200, Dov Grobgeld wrote:
I created jsonrpc client/server (http://json-rpc.org/) library through
glib/gio for remote controlling my application. It is available at:
https://github.com/dov/glib-jsonrpc
Comments and contributions are welcome.
Just got back from holiday and thought I'd post a few comments.
First off, I think this sort of thing is useful. Especially when you
consider the possibilities of automatically discovering applications
running near you using avahi. (A remote control application becomes
trivial).
I'm not a fan of the approach to hand-writing the HTTP responses. There
are so many quirks in HTTP clients. SoupSessionAsync suits the job well
and scales more than well enough for this use-case. I imagine it would
also make it easier to handle multiple async commands concurrently.
The JSON-RPC doesn't define a transport agent because it can be
transported over any protocol it fits in. It shouldn't be tied to HTTP
when for example xbmc (which is the reason I wrote my library) provides
JSON-RPC over standard TCP.
GIOStream is a good choice for transport but it does need some help in
HTTP department.
As for the API, I'm not a huge fan of registering commands with a
generic callback scheme. It requires lots of boilerplate code which we
used to deal with in the early DBUS days (well, if you support
parameters, not sure this does yet). I would like to see a design where
you register a GObject at a path, like GDBUS, and GObject Introspection
is used to route the given method. Parameters would be passed in as the
POST body with a Content-Type of application/json. Then, a single,
generic marshaller could be written to convert the argument parameters.
I actually wanted to do this with my library but the problem is that you
probably don't want to take an exclusive approach to it. I imagine that
there's at least a few JSON-RPC implementations out there that uses
weird notation like notify_func[something] and another using
do_stuff::abc whereby they can mean a whole host of implementation
specific things. That's why initially I just have an interface with a
single function `find' that takes a name and returns a delegate.
Regardless of what you plug on top of this, that particular interface is
necessary in order to allow *any* kind of implementation to work.
Additionally, this would allow for discovery of a given methods
parameters with a GET request to the given method by describing them in
a JSON response. Or a list of methods available with a GET to the
objects path.
Of course introspection is desired but as the spec doesn't define any
introspection methods, this should be an elective per instance.
And at this point, I expect flames about re-implementing DBUS. However,
I still find it useful in cases where DBUS clients aren't viable (JSON
API server, application controllable by iOS/Android, etc).
No flames, just reminding you that there is a specification and we
should adhere to it 100%, or in some cases maybe even be liberal (see my
json_rpc_bridge_{request,notify}_verbatim, which I put in both for
performance and non-conforming 3rd party reasons)
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Function completion for GVariant maybe types?
On Sat, 31 Dec 2011 at 17:22:57 +0100, Markus Elfring wrote: - if the maybe contains a value, return the NULL of the same type Would you like to give the clarification of this open issue another try? How do you think about extensions for the support of nullable data types around the function g_variant_new_maybe? It seems that the open issue is: you think a new function is needed; Ryan thinks the current API is sufficient and there is no problem. This seems to be basically a matter of taste so without a compelling reason to add more API, the maintainer's opinion (i.e. Ryan's) will tend to win. I'm inclined to agree with Ryan, tbh - I don't see that there's any need for more functions here. In a well-designed D-Bus API (or any of the other common uses I see for GVariant, like serialization) you already know at compile-time what type you're using, so you can just mention the type signature (or GVariantType in GLib jargon) in your source code. S ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Announce: glib-jsonrpc
On Tue, 03 Jan 2012 at 16:38:35 -0800, Christian Hergert wrote: And at this point, I expect flames about re-implementing DBUS. However, I still find it useful in cases where DBUS clients aren't viable (JSON API server, application controllable by iOS/Android, etc). I think JSON and D-Bus both have their place. There's a continuum between natural language and raw binary, and no right answer for where you want to be on that continuum; JSON and XML are closer to the human-readable/inefficient end than, say, D-Bus or Google protocol buffers, but that's not a bad thing for some uses. Another important difference to think about when deciding which one to use is that JSON-RPC is 1-1/peer-to-peer, whereas D-Bus usually isn't (the star topology and broadcasts/subscriptions are optional, but very useful, and in practice nearly always used). S ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Announce: glib-jsonrpc
On Wed, 2012-01-04 at 11:40 +0100, Joakim Sindholt wrote:
No flames, just reminding you that there is a specification and we
should adhere to it 100%, or in some cases maybe even be liberal (see
my
json_rpc_bridge_{request,notify}_verbatim, which I put in both for
performance and non-conforming 3rd party reasons)
My mistake, I didn't realize there was a spec for this. In that case, it
is not what I'm looking for.
-- Christian
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Function completion for GVariant maybe types?
This seems to be basically a matter of taste so without a compelling reason to add more API, the maintainer's opinion (i.e. Ryan's) will tend to win. Thanks for your feedback. Would you like to answer any more details from my issue summary? http://mail.gnome.org/archives/gtk-devel-list/2011-December/msg00021.html I'm inclined to agree with Ryan, tbh - I don't see that there's any need for more functions here. Please tell me then which function(s) I should use to reset a GVariant object to an instance of nothing while the previous data type information will be kept. In a well-designed D-Bus API (or any of the other common uses I see for GVariant, like serialization) you already know at compile-time what type you're using, so you can just mention the type signature (or GVariantType in GLib jargon) in your source code. I imagine uses cases outside the D-Bus application context. Regards, Markus ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Announce: glib-jsonrpc
Thanks for your comments. Though I am agreeing with most of them, I am
unlikely to implement them on my own, as I am mostly interested in
remote controlling my own applications in situations where I am in
control of both the server and the client.
(I have just implemented such control in my image viewer giv
(https://github.com/dov/giv), which also gives an example of an
asynchronous call, pick_coordinate, that waits for the user to click
somewhere in the image and returns the chosen coordinate.)
On the other hand I have fixed some thread bugs in the asynchronous
callbacks, and now it seems to work, both under posix and Windows.
So feel to pick apart, clone, or ignore any of my code.
Regards,
Dov
On Wed, Jan 4, 2012 at 19:42, Christian Hergert ch...@dronelabs.com wrote:
On Wed, 2012-01-04 at 11:40 +0100, Joakim Sindholt wrote:
No flames, just reminding you that there is a specification and we
should adhere to it 100%, or in some cases maybe even be liberal (see
my
json_rpc_bridge_{request,notify}_verbatim, which I put in both for
performance and non-conforming 3rd party reasons)
My mistake, I didn't realize there was a spec for this. In that case, it
is not what I'm looking for.
-- Christian
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Bug 666728 - critical warning in libgee
Sorry for spamming but it seems that it's a bug without clear product which is fully responsible for the problem (see Ryan's comment[1]). On the other hand it affects all libgee newer then 0.4.0 release and hence it is probably blocker on Gnome 3.4. In summary the glib master become more restrictive when overriding properties. The problem is diamond inheritance: Gee.Collection --- Gee.List ^ ^ | | | | Gee.AbstractCollection --- Gee.AbstractList which results in following errors: /ArrayList/[Collection] type correctness: GLib-GObject-CRITICAL **: Read-only property 'read-only-view' on class 'GeeAbstractList' has type 'GeeCollection' which is not equal to or more restrictive than the type 'GeeList' of the property on the interface 'GeeList' I don't think I can fix on libgee side without breaking API/ABI (at least I don't see it). I believe that because currently various GNOME applications depends on libgee it means that bug effectively breaks GNOME (by breaking for example gnome-shell or empathy). As far as I understand possible fixes include: - Treating g_object_interface_install_property as override property if interface have prerequisite - Change Vala to use g_object_class_install_property(s) instead of g_object_class_override_property. - Change error into warning, remove it from libgee 0.7/0.8 and change back into error when the old software die. Regards [1] https://bugzilla.gnome.org/show_bug.cgi?id=666728#c1 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Bug 666728 - critical warning in libgee
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 see it). I believe that because currently various GNOME applications depends on libgee it means that bug effectively breaks GNOME (by breaking for example gnome-shell or empathy). I talked to Jürg a bit about this problem and I think he decided that the appropriate thing to do would be to modify Vala to prevent Gee from doing this in the first place. - Treating g_object_interface_install_property as override property if interface have prerequisite I think this wouldn't help. The problem comes from the fact that two separate interfaces are defining a property with the same name and different types (so far so good) and then a class tries to implement both interfaces (one directly and one by inheritance). Boom. What we could do is to try to step up the intelligence in GObject about *which* property to override to pick the more-compatible type. I resist this because it's not simple and because in the event that you have two properties with the same name, why should we arbitrarily pick one over the other at all? Even if the types are compatible, we still have (admittedly small) questions about things like which description string we want to end up with. That might be a small practical concern, but it gives me a distinct feeling of this is icky I think we should possibly consider being *more* strict in this area: if there are two possible properties of the same name that you could be overriding then g_object_class_override_property() should probably fail. - Change Vala to use g_object_class_install_property(s) instead of g_object_class_override_property. I think this would be pretty reasonable. Vala has enough information to be able to pick the correct information to register the property with, from scratch. It could also give a meaningful compile time error if it's not possible to reconcile the types in a way that works with the access flags of each of the properties. - Change error into warning, remove it from libgee 0.7/0.8 and change back into error when the old software die. It's just a critical now, so nothing should die. I suppose we could downgrade that to a warning if you're worried about people running with fatal criticals. Cheers ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Bug 666728 - critical warning in libgee
On Thu, Jan 5, 2012 at 10:40 AM, Ryan Lortie de...@desrt.ca wrote: 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 see it). I believe that because currently various GNOME applications depends on libgee it means that bug effectively breaks GNOME (by breaking for example gnome-shell or empathy). I talked to Jürg a bit about this problem and I think he decided that the appropriate thing to do would be to modify Vala to prevent Gee from doing this in the first place. - Treating g_object_interface_install_property as override property if interface have prerequisite I think this wouldn't help. The problem comes from the fact that two separate interfaces are defining a property with the same name and different types (so far so good) and then a class tries to implement both interfaces (one directly and one by inheritance). Boom. What we could do is to try to step up the intelligence in GObject about *which* property to override to pick the more-compatible type. I resist this because it's not simple and because in the event that you have two properties with the same name, why should we arbitrarily pick one over the other at all? Even if the types are compatible, we still have (admittedly small) questions about things like which description string we want to end up with. That might be a small practical concern, but it gives me a distinct feeling of this is icky Strongly agree with Ryan here, lets please refrain from allowing subclasses to implement interfaces with conflicting property names at all. Critical warnings should be fired, perhaps g_object_class_add_interface() should simply fail in the case that a property name clashes with a class property or another interface property (is this not already the case anyway ?). Otherwise it becomes very easy to introduce undefined/random behavior from apis like g_object_set/get() (or g_object_class_list_properties()... etc) Cheers, -Tristan I think we should possibly consider being *more* strict in this area: if there are two possible properties of the same name that you could be overriding then g_object_class_override_property() should probably fail. - Change Vala to use g_object_class_install_property(s) instead of g_object_class_override_property. I think this would be pretty reasonable. Vala has enough information to be able to pick the correct information to register the property with, from scratch. It could also give a meaningful compile time error if it's not possible to reconcile the types in a way that works with the access flags of each of the properties. - Change error into warning, remove it from libgee 0.7/0.8 and change back into error when the old software die. It's just a critical now, so nothing should die. I suppose we could downgrade that to a warning if you're worried about people running with fatal criticals. Cheers ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk3 replacement for gdk_pixmap_foreign_new
Hello, I have asked this 3 times now, but have not received any response. It is very simple gdk_pixmap_foreign_new() is going away in gtk 3. I would like to know what code can be used to replace it. I am getting tired of posting this. PLEASE CAN SOMEBODY RESPOND TO THIS. I NEED TO KNOW THE ANSWER URGENTLY ! Regards, Salsaman http://lives.sourceforge.net https://www.ohloh.net/accounts/salsaman Hi, sorry if this question has been asked already, but I understand that in gtk3 gdkpixmap is being replaced by cairo and all gkdpixmap functions are being replaced by cairo surface functions. I would like to know what cairo function is the equivalent of gdk_pixmap_foreign_new(). I cannot seem to find any reference to this anywhere. TIA, salsaman. http://lives.sourceforge.net https://www.ohloh.net/accounts/salsaman ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: gtk3 replacement for gdk_pixmap_foreign_new
On Wed, Jan 04, 2012 at 10:31:30AM -0300, salsaman wrote: I am getting tired of posting this. PLEASE CAN SOMEBODY RESPOND TO THIS. I NEED TO KNOW THE ANSWER URGENTLY ! Seems you depend on this for some business? Suggest asking one of those Gtk+ companies. E.g. (first thing after a Google search): http://www.lanedo.com/gtk+.html -- Regards, Olav ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: gtk3 replacement for gdk_pixmap_foreign_new
On 01/04/2012 05:40 PM, Michael Torrie wrote: On 12/30/2011 02:56 PM, salsaman wrote: I would like to know what cairo function is the equivalent of gdk_pixmap_foreign_new(). I cannot seem to find any reference to this anywhere. Actually does this function replace it? cairo_xlib_surface_create_for_bitmap() http://cairographics.org/manual/cairo-XLib-Surfaces.html Thought it requires more information than the gdk call, it does create a Cairo surface for a native X11 pixmap, which if I read the GDK manually correctly, that is what the deprecated call does. I found this function by searching Google for cairo surface native X11 pixmap ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: gtk3 replacement for gdk_pixmap_foreign_new
Hi Michael, thanks for your replies. Yes I was wondering why my posts were not showing up in gmail. The function you mention is not really a replacement. The original function is used by LiVES to capture and record external windows from the desktop. Its not really a show-stopper not having it but its a useful feature (you just click on a window and its output is recorded as a clip) and I will need to find a replacement function before I can implement GTK+ 3.completely in LiVES. Regards, Salsaman. http://lives.sourceforge.net https://www.ohloh.net/accounts/salsaman On Wed, Jan 4, 2012 at 21:46, Michael Torrie torr...@gmail.com wrote: On 01/04/2012 05:40 PM, Michael Torrie wrote: On 12/30/2011 02:56 PM, salsaman wrote: I would like to know what cairo function is the equivalent of gdk_pixmap_foreign_new(). I cannot seem to find any reference to this anywhere. Actually does this function replace it? cairo_xlib_surface_create_for_bitmap() http://cairographics.org/manual/cairo-XLib-Surfaces.html Thought it requires more information than the gdk call, it does create a Cairo surface for a native X11 pixmap, which if I read the GDK manually correctly, that is what the deprecated call does. I found this function by searching Google for cairo surface native X11 pixmap ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: gtk3 replacement for gdk_pixmap_foreign_new
Somewhat OT, but still applicable. Gmail is a PITA to use on most lists. (At work i have no choice but to use the web UI) But at home i use a dedicated email client with filters. So when i reply to a list using gmail web ui i don't see anything, but when i check my email at home I see my outbound messages to lists as well as inbound replies which eliminates those nasty thoughts of wtf happened to my sent mail... Basically i avoid the web ui when possible. A good client will permit threaded view which works fine with gmail as a basic mail server. Steve On Wed, Jan 4, 2012 at 10:15 PM, salsaman salsa...@gmail.com wrote: Hi Michael, thanks for your replies. Yes I was wondering why my posts were not showing up in gmail. The function you mention is not really a replacement. The original function is used by LiVES to capture and record external windows from the desktop. Its not really a show-stopper not having it but its a useful feature (you just click on a window and its output is recorded as a clip) and I will need to find a replacement function before I can implement GTK+ 3.completely in LiVES. Regards, Salsaman. http://lives.sourceforge.net https://www.ohloh.net/accounts/salsaman On Wed, Jan 4, 2012 at 21:46, Michael Torrie torr...@gmail.com wrote: On 01/04/2012 05:40 PM, Michael Torrie wrote: On 12/30/2011 02:56 PM, salsaman wrote: I would like to know what cairo function is the equivalent of gdk_pixmap_foreign_new(). I cannot seem to find any reference to this anywhere. Actually does this function replace it? cairo_xlib_surface_create_for_bitmap() http://cairographics.org/manual/cairo-XLib-Surfaces.html Thought it requires more information than the gdk call, it does create a Cairo surface for a native X11 pixmap, which if I read the GDK manually correctly, that is what the deprecated call does. I found this function by searching Google for cairo surface native X11 pixmap ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: gtk3 replacement for gdk_pixmap_foreign_new
Can't you use gdk_pixbuf_get_from_window() if you want to capture the contents of external windows? More details can be found here: http://developer.gnome.org/gtk3/stable/ch25s02.html#id1616337 Regards Mario - Ursprüngliche Mail - Von: salsaman salsa...@gmail.com An: Michael Torrie torr...@gmail.com CC: gtk-list@gnome.org Gesendet: Donnerstag, 5. Januar 2012 04:15:13 Betreff: Re: gtk3 replacement for gdk_pixmap_foreign_new Hi Michael, thanks for your replies. Yes I was wondering why my posts were not showing up in gmail. The function you mention is not really a replacement. The original function is used by LiVES to capture and record external windows from the desktop. Its not really a show-stopper not having it but its a useful feature (you just click on a window and its output is recorded as a clip) and I will need to find a replacement function before I can implement GTK+ 3.completely in LiVES. Regards, Salsaman. http://lives.sourceforge.net https://www.ohloh.net/accounts/salsaman On Wed, Jan 4, 2012 at 21:46, Michael Torrie torr...@gmail.com wrote: On 01/04/2012 05:40 PM, Michael Torrie wrote: On 12/30/2011 02:56 PM, salsaman wrote: I would like to know what cairo function is the equivalent of gdk_pixmap_foreign_new(). I cannot seem to find any reference to this anywhere. Actually does this function replace it? cairo_xlib_surface_create_for_bitmap() http://cairographics.org/manual/cairo-XLib-Surfaces.html Thought it requires more information than the gdk call, it does create a Cairo surface for a native X11 pixmap, which if I read the GDK manually correctly, that is what the deprecated call does. I found this function by searching Google for cairo surface native X11 pixmap ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
