[Feature] Tamagtochi Widget

[Hrishi1999]

Adds Tamagotchi widget. The XO icon responds/changes according to changes in the number of journal entries, battery status, and disk status.
Please use https://github.com/Hrishi1999/sugar-artwork/tree/tamagotchi-widget to test this feature since the artwork for Tamagotchi widget is not complete.

[aperezbios]

I hate to be "that guy" but the word Tamagotchi is trademarked, and actively in force. It would be in our best interest to not use it in this, or any other, context. See https://trademarks.justia.com/752/47/tamagotchi-75247559.html

Please consider changing the name to a more generic term prior to release.

[Hrishi1999]

Thanks, we discussed this topic in the GSoC Weekly meeting (http://meeting.sugarlabs.org/sugar-meeting/2019-08-12). I will change it.

[Hrishi1999]

@quozl Review?

[quozl]

I've lost track of your plan. I can't find a feature page on the Wiki. You're asking for a merge to master branch, so that means you are targeting future release of Sugar, not OLPC XO laptops. But you were careful to get the Dashboard tested on Fedora 18. I'm confused as to what you want to do. Tell me more?

[Hrishi1999]

This feature is not a dashboard. This is a widget, which replaces the XO icon on the Sugar desktop. I've also opened a pull request for Dashboard integration. My GSoC project includes two projects 1) This widget (to be renamed) 2) Dashboard.
Dashboard (integration) can be merged with the master branch for a future release but the Dashboard activity will work on XOs too.

[quozl]

Thanks. You are intending Tamagtochi for master. Please fill out the feature template. If you don't have a Wiki account, then either get one or add the answers to the pull request.

I've briefly reviewed the change;

• make it optional; add a GSettings schema key org.sugarlabs.tamagtochi and test it before changing how the icon is displayed,
• make it opt-in; have the key default to False, and this will relax review criteria,
• rather than a datastore.find every 60 seconds, connect to the datastore Created and Deleted signals, and maintain a count,
• rather than copy and paste of code from extensions/deviceicon/battery.py, add a way to obtain the data from the extension,
• the number of different states is very low, and the number of icons very high; rather than use icons and badges, use Cairo to draw elements. See my feedback on 6th July.

[Hrishi1999]

I will try to fix these issues this week. Thanks.

[Hrishi1999]

@quozl Added gsettings key in 740eea4
I've found a way to import extensions.deviceicon.battery but I think I will be required to make modifications to extensions/deviceicon/battery or still use an existing modification of setup() method (like I am using right now). I am still figuring it out.
For the Cairo part, we will need to replace CanvasIcon with a Gtk.DrawingArea and I think that will affect how buddyicon's signals are used (notify::present and notify::color).

[quozl]

@quozl Added gsettings key in 740eea4
I've found a way to import extensions.deviceicon.battery but I think I will be required to make modifications to extensions/deviceicon/battery

That's expected. Modularity has several advantages in software development. If a module has a clear purpose (interface to battery), and callers don't need 100% of the functionality, it's normal.

or still use an existing modification of setup() method (like I am using right now). I am still figuring it out.
For the Cairo part, we will need to replace CanvasIcon with a Gtk.DrawingArea and I think that will affect how buddyicon's signals are used (notify::present and notify::color).

Yes, I expect so. You can create signals if you need them.

[Hrishi1999]

@quozl I tried to connect with Created and Deleted signals. I initially do a datastore query and then use the signals to maintain a count, but instead of Created signal I am using Updated signal. The count won't be incremented when I use Created, but it does decrement when I use Deleted signal. Using Update signal would sometimes increment the counter multiple times.

[quozl]

Yes, that's right. As you can see from the datastore source, updated signal occurs when a journal object is changed by an activity or Sugar, and that won't change the number of objects unless the find is given search criteria.

Is there a feature page yet?

[quozl]

Your change here to use self.has_battery means the keyword argument is not needed?

[Hrishi1999]

I will create a feature page this week. The has_battery change was unintentional. I will try to do a datastore query with some search criteria and then try to use Created signal. Thanks

[Hrishi1999]

Feature page: https://wiki.sugarlabs.org/go/Features/Variable-Appearance-of-Buddy-Icon

[quozl]

Thanks.

[quozl]

It's been almost a month and there hasn't been;

• a post to sugar-devel@ mentioning the feature page, or any discussion since the feature page was made,
• any edits to the feature page by affected people.

I don't think anyone else has seen it. Do what you can to get input?

[srevinsaju]

@Hrishi1999 I have created a small update on your repo. I am not getting any visible changes to the XO icon on the Home page, I have built sugar-artwork from Hrishi1999/sugar-artwork:master