Re: More changes in path drawing

[Jiří Techet <techet gmail com>]

On Thu, Feb 17, 2011 at 18:51, Robert Park <rbpark exolucere ca> wrote:
> Hey Jiri, as usual I am stuck at work and won't be able to test any of
> this until I get home.
>
> On Thu, Feb 17, 2011 at 8:48 AM, Jiří Techet <techet gmail com> wrote:
>> In python the prefix gets removed so they both become set_position().
>> ChamplainMarker inherits from ClutterActor and also implements
>> ChamplainLocation. So what happens in your code is that
>> clutter_actor_set_position() gets called instead of
>> champlain_location_set_position() because it's found first (interfaces
>> have probably lower priority). I bet if you use the "latitude" and
>> "longitude" properties, everything will work fine.
>>
>> I fear that this would be confusing for every language supporting
>> inheritance. Therefore, I'll rename the set_position() function to
>> set_location() - after all the interface is called ChamplainLocation.
>
> This would also explain that time that I called get_position() with
> the expectation that it was the complement to set_position, and it
> returned (0.0,0.0) instead of raising AttributeError, even before
> set_position stopped working.

Ah, indeed. So it's get_location() now.

>
>> 2. You don't initialize threads. Please do it - libsoup loads tiles on
>> background in separate threads and gobject has to be aware of that. In
>> the old python bindings we would call
>>
>> gobject.threads_init()
>>
>> before clutter initialization. Not sure about how it should be called now.
>
> I guess just GObject.threads_init(). Will try this. Can you elaborate
> on why this kind of thing is necessary? I feel as though there are
> subtle changes going on at very deep levels that are beyond my
> understanding, because this suggestion of yours is highly reminiscent
> of that time that I had to switch from calling Clutter.init([]) to
> GtkClutter.init([]). It always worked before, why do I have to switch
> it now? What changed to make GtkClutter necessary? What changed to
> make threads_init() necessary?

It has always been like that - all our demos have always been calling
these functions. That it worked for you is rather good luck than
anything else. If you have a look here
http://projects.gnome.org/libchamplain/reference.html, you'll see you
should call both g_thread_init() and gtk_clutter_init().

>
> Anyway, I'll try this tonight.
>
>> 3. DON'T use clutter_actor_set_parent() unless you want to make your
>> life hard (clutter documentation says something very similar).
>> ClutterStage implements ClutterContainer interface so use
>> clutter_container_add_actor() instead. I'm pretty sure this will
>> resolve the animation problems of actors inserted into the stage.
>
> Ok, this one is news to me. I'm not sure why I started using
> set_parent. Most likely my widgets weren't appearing and I don't
> really know much about Clutter, so I quickly googled and that was the
> first thing I found that 'worked', and I obviously missed the warning
> (also I never heard of add_actor(), so I should probably review
> Clutter docs).
>
>> 4. Then there's this:
>>
>> self.photo_layer = Champlain.MarkerLayer()
>>
>> This calls the "default constructor" and initializes the selection
>> mode to CHAMPLAIN_SELECTION_NONE. Inside the add_marker method of the
>> layer there's the code
>>
>>  champlain_marker_set_selectable (marker, mode != CHAMPLAIN_SELECTION_NONE);
>>
>> that is, whatever you set before is reset according to the current
>> layer mode. I'm wondering whether your markers are selected correctly
>> because IMO the selection mode is reset once you insert the marker
>> into the layer.
>
> I'm not sure what you're getting at here. When I select photos in my
> GtkListStore, the corresponding ChamplainLabels appear correctly with
> correct selection color, no problems. Even if you ignore the problem
> where the wrong set_position is causing clicked-on markers to
> disappear, the selection color does flash briefly before the Label
> disappears, so that indicates to me that the selection is working
> fine.

Well, what I don't understand is that it works for you. It shouldn't.
The layer you create should be in CHAMPLAIN_SELECTION_NONE mode. Then
you call

label.set_selectable(True)

and finally

self.photo_layer.add_marker(label)

Inside add_marker() there's

champlain_marker_set_selectable (marker, mode != CHAMPLAIN_SELECTION_NONE);

And because it is CHAMPLAIN_SELECTION_NONE, it should set the marker
you previously set as selectable to not selectable and you shouldn't
be able to move markers.

Ah, after writing all this I got it - you make the selection the other
way round - you select something in the list and based on this select
(highlight) the marker, right? The set_selectable() function is
actually not used for this case - it's precise meaning is "is
selectable by mouse" - i.e. when you click the marker, it gets
highlighted (try the launcher-gtk demo). And I bet this doesn't happen
now because it's in the NONE mode.

>
> This might be a good time for me to ask you, does the libchamplain
> concept of a 'selected' marker have any meaning beyond simply
> highlighting that marker with the system theme's selection color? Is
> any other functionality associated with this concept? Because in my
> app I already am using GtkTreeSelection to keep track which photos are
> selected, and in the old API I was simply using get/set_highlighted to
> identify ChamplainMarkers that corresponded to photos that were
> selected in the GtkListStore. When you changed the API and took away
> get/set_highlighted, I literally just did a
> s/et_highlighted/et_selected/g in my source code and didn't think much
> else about it. So to me, the get/set_selected methods are no more than
> simple color highlights, and I already have well-tested code that
> ensures only the correct Labels are set as 'selected'. Is this an
> incorrect usage of "selections" in libchamplain?

selected=highlighted - that's why I renamed highlighted to selected to
have a single name for the same thing. The only extra thing (which was
however present before too) is the selection mode of MarkerLayer -
this mode is valid for mouse clicks only (with the exception of the
single mode which should preserve single marker selection even when
you select it by an API call).

Jiri

>
>> This is about what I've noticed after quickly looking at your code.
>> The image corruption is strange and shouldn't happen - I'm now adding
>> clutter_actor_queue_redraw/relayout where necessary which could help
>> to fix some redrawing problems.
>
> Ok, when I get home I will try out add_actor() instead of set_parent()
> to see if this reduces any problems. Thanks!
>
> --
> http://robru.github.com/GottenGeography/
>