Re: Gtk, Python, and Threading.

[Robert Park <rbpark exolucere ca>]

On Tue, Dec 14, 2010 at 10:36 AM, Robert Park <rbpark exolucere ca> wrote:
> On Tue, Dec 14, 2010 at 1:28 AM, Tomeu Vizoso <tomeu tomeuvizoso net> wrote:
>> Interfaces cannot be instantiated, use something like instead:
>>
>> http://library.gnome.org/devel/gio/2.25/GFile.html#g-file-new-for-path
>
> Thanks, I will try this when I get home tonight.

What am I missing here?

    def request_geoname(self):
        """Use the GeoNames.org webservice to name coordinates."""
        if not self.valid_coords(): return
        self.gfile = Gio.file_new_for_uri(
            'http://ws.geonames.org/findNearbyPlaceNameJSON?lat=%s&lng=%s'
            % (self.latitude, self.longitude))
        self.gfile.read_async(0, None, self.receive_geoname, None)

    def receive_geoname(self, gfile, result, alwaysnone):
        """This callback method is executed when geoname download completes."""
        print "Hello from the callback!", gfile, result, alwaysnone
        print gfile.read_finish(result)

Output:

Hello from the callback! <__main__.GDaemonFile object at 0x1a8ef00
(GDaemonFile at 0x1847990)> <SimpleAsyncResult object at 0x1a8efa0
(GSimpleAsyncResult at 0x1b11240)> None
<__main__.GDaemonFileInputStream object at 0x1aae140
(GDaemonFileInputStream at 0x1a7c520)>

So the callback is called successfully, and I can use read_finish() to
get this GDaemonFileInputStream object, but what the hell do i do with
that? The documentation is *remarkably* obtuse here. The example that
I've been loosely following from online (I pasted it in a previous
email) suggests that I then call .read() with no arguments on the
result of .read_finish(result), but if I try to actually do that, it
demands that I give it 4 arguments instead of 1. Not knowing what
arguments it could possibly want, I tried passing it 3 Nones. Then it
told me argument 2 has to be a number, so I tried calling it as
.read(None, 0, None), and then it returned (True, 0L). If I passed it
1, it would return (True, 1L). I tried it with 100 and it gave me 100L
back. It seems I've stumbled onto an incredibly convoluted method of
converting integers into long integers.

I referred to Gio-2.0.gir and found this:

      <method name="read" c:identifier="g_input_stream_read" throws="1">
        <return-value transfer-ownership="none">
          <type name="gssize" c:type="gssize"/>
        </return-value>
        <parameters>
          <parameter name="buffer" transfer-ownership="none">
            <type name="any" c:type="void*"/>
          </parameter>
          <parameter name="count" transfer-ownership="none">
            <type name="gsize" c:type="gsize"/>
          </parameter>
          <parameter name="cancellable"
                     transfer-ownership="none"
                     allow-none="1">
            <type name="Cancellable" c:type="GCancellable*"/>
          </parameter>
        </parameters>
      </method>

This suggests that I need a buffer, a count (of what?), and a
cancellable. So now I'm thinking that perhaps Gio is going to modify
this buffer argument in-place with the data I need. So I decide maybe
I'll pass it an empty string there. Seems strange to me because I know
python strings are immutable, but what the hell, I decide to try it.
The result is that instead of returning (True, 100L), it now returns
simply 100 and then immediately segfaults. For shits and giggles I
also try passing an int and a list as the buffer argument and they all
produce the same results.

So anyway, I could really use a prod in the right direction here
because this technique has the potential to be brilliantly simple
without any threading nightmares, except that I can't actually get the
necessary data out of this object. All available documentation I've
been able to find has been nothing short of totally wrong, and I've
largely exhausted my usual attempts at calling dir() on the objects in
question and referring directly to the .gir file.

Thanks.

-- 
http://exolucere.ca