Add get_bundle method to activity.py

[godiard]

When a programmer need open one activity from other [1]
usually need display in the user interface information about the activity
to open, like the name or the icon.
This method allow get this information, previously only available on jarabe.

[1] http://wiki.sugarlabs.org/go/Features/Start_activity_from_another_activity

[samdroid-apps]

Why are we adding the dbus overhead? The get_bundle method is designed
to be runnable outside the jarabe process.

Could we just make this a wrapper without dbus?

On Fri, 3 Jul 2015 5:17 am Gonzalo Odiard notifications@github.com wrote:

When a programmer need open one activity from other [1]
usually need display in the user interface information about the activity
to open, like the name or the icon.
This method allow get this information, previously only available on
jarabe.

[1]

http://wiki.sugarlabs.org/go/Features/Start_activity_from_another_activity

You can view, comment on, or merge this pull request online at:

#236
Commit Summary

• Add get_bundle method to activity.py

File Changes

• M src/sugar3/activity/activity.py
  https://github.com/sugarlabs/sugar-toolkit-gtk3/pull/236/files#diff-0
  (13)

Patch Links:

• https://github.com/sugarlabs/sugar-toolkit-gtk3/pull/236.patch
• https://github.com/sugarlabs/sugar-toolkit-gtk3/pull/236.diff

—
Reply to this email directly or view it on GitHub
#236.

[godiard]

@samdroid-apps, we need ask to sugar for the bundle installed.

[samdroid-apps]

Huh?

On Fri, 3 Jul 2015 7:21 am Gonzalo Odiard notifications@github.com wrote:

Closed #236 #236.

—
Reply to this email directly or view it on GitHub
#236 (comment)
.

[godiard]

@samdroid-apps, all the logic used to read the bundles is in the toolkit, but Sugar (and the code is in jarabe) have a registry of the activities installed in sugar. If we don't use dbus, need move all that logic to the toolkit, and the worst part is every activity process need store the registry information.

[samdroid-apps]

But it works perfectly fine from outside of the jarabe process right now?

Is there any reason to increase the surface area of the change so late in
the cycle?

On Fri, 3 Jul 2015 7:29 am Gonzalo Odiard notifications@github.com wrote:

@samdroid-apps https://github.com/samdroid-apps, all the logic used to
read the bundles is in the toolkit, but Sugar (and the code is in jarabe)
have a registry of the activities installed in sugar. If we don't use dbus,
need move all that logic to the toolkit, and the worst part is every
activity process need store the registry information.

—
Reply to this email directly or view it on GitHub
#236 (comment)
.

[quozl]

Yes, good reasons. Don't want dependency between an activity and sugar. Hurts everybody in future as sugar changes. The point of isolation must be the toolkit. And performance too, I think.

[godiard]

@samdroid-apps, I explained the reason in my email to sugar-devel. Use jarabe in the activities is forbidden, because is a internal API and we don't warranty stability.
I know is very late, but in my experience, every time we change the APIs our users have more problems than we expect. Then, I think we need do the release with a usable API.

[quozl]

+1