Feedback on Measure (was Re: Another pass through some basic Activity test results)

[Tomeu Vizoso]

2008/9/29 Erik Blankinship <erikb at mediamods.com>:
>
>> On Sun, Sep 28, 2008 at 6:02 AM, Gary C Martin <gary at garycmartin.com>
>> wrote:
>> > On 26 Sep 2008, at 19:31, Arjun Sarwal wrote:
>> >
>> >> 2008/9/26 Gary C Martin <gary at garycmartin.com>:
>> >>>
>> >>> Here's a set of basic Activity test results for build 8.2-763, hope
>> >>> the
>> >>> ASCI
>> >>> art doesn't get too mangled by the list server (need to view with a
>> >>> fixed
>> >>>      Measure-20 . . - . x x x . x Doesn't sleep when Activity is in
>> >>> the
>> >>>                                   background (eats 75% cpu). Can't
>> >>> seem
>> >>> to
>> >>>                                   record anything. Keep error when
>> >>
>> >> -- When Measure is in background and some other Activity comes in
>> >> foreground, then Measure releases sound device - you can record sound
>> >> using any other program/application. In this state Measure also
>> >> doesn't hog CPU.
>> >
>> > Just testing with Measure-21 and 8.2-765, yes I see this now. However
>> > switching to any of the Neighborhood/Group/Home views does not seem
>> > count as
>> > putting Measure into the background, it still consumes the cpu and
>> > claims
>> > the sound input device. I'm guessing this is a Sugar behaviour? Is this
>> > a
>> > bug or a feature (feels like a Sugar bug that would make the UI sluggish
>> > for
>> > no go reason)?
>>
>> See #7856. Seems like a Sugar related issue to me. I had borrowed the
>> code and concept from Record activity, which now apparently uses some
>> other method to determine switch of view/context/activity.( I think
>> they detect whether one of the main gtk widgets is the topmost or not
>> etc. not sure) I should try exploring that. Any help on this would be
>> great.
>
> Record listens for "visibility-notify-event":
>
> self.playOggWindow.add_events(gtk.gdk.VISIBILITY_NOTIFY_MASK)
> self.playOggWindow.connect("visibility-notify-event", self._visibleNotifyCb)
>
> Because Record has many different windows, we listen on each window and run
> through a series of checks on the callback to determine if it is the active
> activity anymore.

Oops, just replied with similar information to the old thread, sorry.

Do you need to do that for each window? Why don't you just listen for
that signal in just the main activity window and stop everything when
gtk.gdk.VISIBILITY_FULLY_OBSCURED and resume when otherwise?

Regards,

Tomeu