Test on Fedora 18

[quozl]

Made a bundle using dist_xo and installed on an OLPC XO-4 running OLPC OS 13.2.10.

• "Total Files" is truncated,
• some of the pie chart legends are not visible,
• pie chart data shows activity bundle identifier tails instead of bundle names, (Distance is shown as AcousticMeasure, see activity.info),
• "User Activity" empty blocks are truncated on the right edge of display,
• when "User Activity" coloured blocks are selected, and there is more than one related journal object, the second object is truncated on the bottom edge of display,
• when the journal is changed by starting a new activity, then Dashboard is given focus using alt+tab, the list of journal entries and other data is not updated.

[Hrishi1999]

Thanks! On Ubuntu 18.04 everything looks normal. The white background to the Vboxes and Hboxes doesn't seem to apply in OLPC OS. The font I am using also doesn't seem to be present on the system, I will try to test on a VM running OLPC OS(?) I will try to fix these issues soon.

[Hrishi1999]

To refresh the TreeView, I think it will be good if I add a refresh button. Also, I think the Vboxes and Hboxies didn't have background color because I didn't specify Gdk version?

And what is the resolution of XO-4?
(Screenshot for reference attached)

[quozl]

XO-1 through to XO-4 are 1200x900 pixel resolution. OLPC OS 13.2.10 is latest for these models, but it can't be run in a VM as far as I know. Nearest equivalent is to install Fedora 18 in a VM and then install Sugar. Or find an ISO of Fedora SoaS from about the same year.

My guess is that the GTK default styles have changed since then, and you're using unconventional methods to set background colours. You can find in other activities how to set colours. You can find in sugar-artwork repository some GTK styles for specific versions. It is an unreliable thing for Sugar to do though, as the GTK defaults keep changing. sugarlabs/sugar-artwork#100 is an issue which was caused by this, as illustration.

[Hrishi1999]

Can you test again? I've made a few changes. I tried to test on a Fedora 17 SoaS but didn't activity won't open (can't find sugar3)

[quozl]

I didn't know which version of Fedora acquired the GTK 3 port of sugar-toolkit-gtk3, but from research;

• 0.95.2 was released December 2011,
• Fedora 17 packaged 0.95.2,

Please check that the package is installed? If necessary, install Fedora 17 SoaS to virtual disk and then use "yum install -y sugar-toolkit-gtk3".

Fedora 18 should be better though. Can you try that?

[quozl]

Some change visible, but none of the points in opening comment are fixed yet.

[Hrishi1999]

I will try to fix them soon. Thanks.

[Hrishi1999]

@quozl Tried to install Sugar and some other packages on Fedora 18, but since it has reached the end of support, the mirrors were not available and couldn't install it. Should I use the latest Fedora version?

[quozl]

Fedora 18 has moved from the mirrors and remains available in the archives. Change the configuration of the package manager; here's the archives link; http://archives.fedoraproject.org/pub/archive/fedora/linux/releases/18/Everything/i386/os/ Latest Fedora won't help you test for deployment onto the OLPC XO fleet. Talk to your mentors and the wider community if you need to reduce the scope of your project to avoid the OLPC XO.

[Hrishi1999]

Tested on Fedora 18 running Sugar 0.112. I can see the problem with the Pie chart, but the results are different than yours.

[quozl]

Thanks for testing. You see something different despite running Fedora 18 in a VM using the same version of Sugar and the same resolution as an OLPC XO. Let's look for the cause of different result. What is the value of SUGAR_SCALING environment variable? For me it is 100. Which git hash of your source? For me it was e355758 from 17th June, and although you have two later patches the commit messages don't mention Fedora 18. What version of sugar-artwork is installed? For me it is 0.112.olpc.2 What version of GTK 3? For me it is 3.6.4

[Hrishi1999]

Running echo $SUGAR_SCALING return nothing. There is no SUGAR_SCALING env variable.
My sources hash is 3b30a96 (the last patch). Sugar art-work version sugar-artwork-0.112.olpc.2-0.i686 (same as yours). Gtk3 version: gtk3-3.6.2-1.fc18.i686

[quozl]

You'd better find out why it isn't being set then. You'll find it in /usr/bin/sugar which comes from bin/sugar.in in the source repository.

[Hrishi1999]

I tried to investigate the issue, I couldn't find the cause. Tried adding a $SUGAR_SCALING env variable too, that didn't work. I will keep looking and discuss the issue with mentors. This should be a priority now.

[quozl]

You shouldn't need to add it, as SUGAR_SCALING is automatically set by Sugar. Can you please find out why it isn't being set for you? Are you sure that /usr/bin/sugar is being executed?

[Hrishi1999]

It is being set. The SUGAR_SCALING will be set to 72 (default) every time I run sugar in terminal. The UI elements seem to be a bit large when it is set to 100 (manually by me) but the Dashboard activity still seems normal event with SUGAR_SCALING set to 100

[quozl]

Thanks. I see that SUGAR_SCALING was not set in your earlier comments, but is set now. No matter, as it turned out it doesn't seem to be the main cause of difference, but it should be changed. See below.

3b30a96 tested on Fedora 18 based OLPC OS 13.2.10 on an OLPC XO-4 looks like this now;

In my test, SUGAR_SCALING is set to 100. This is the correct value for the hardware platform, and won't be changing. Yours must be set to 100 in order to reproduce the same environment. I can see from the thickness of the toolbar in your screenshot that yours is set to 72.

In my test, display dimensions are fixed at 1200x900. Your latest screenshot, however, is 1208 x 931. Your display dimensions must be set to 1200x900 in order to reproduce the same environment.

The activity log shows lots of problems that might need fixing.

The activity takes ten seconds to launch. Much of the time is spent iterating through the installed activity bundles. The XO-4 is the fastest of the four models.

You should look for version 3.6.4 of the GTK packages for Fedora 18. This is in the Fedora updates package repository.

While it seems normal for you, that just means you haven't reproduced the same OLPC OS environment as I'm using. Let me know if you have any questions about that environment.

By the way, please don't test by running /usr/bin/sugar in a Terminal. This isn't the way that Sugar is run by target users. Sugar should be run as an xorg session before you report any layout, collaboration, or behavioural problems with activities. Similar situation for running activities; do not run them using /usr/bin/sugar-activity{,3} except as a shortcut to speed the edit test cycle.

[Hrishi1999]

Sorry forgot to mention that I also tested with SUGAR_SCALING=100. Here is the screenshot.

I've also run sugar as a Xorg session before and got similar results. The repository you mentioned only has arm packages but I am running a 32-bit version.
Do you have any other suggestions for getting installed activities?

Edit: Installed GTK version 3.6.4 from http://rpmdropbox.laptop.org/f18/. No changes.

Thanks.

[quozl]

Yes, the repository was straight from an OLPC XO-4, which is ARM, and 32-bit. For Intel 32-bit, the URL may be https://archives.fedoraproject.org/pub/archive/fedora/linux/updates/18/i386/

Do you have any other suggestions for getting installed activities?

I don't know what you mean, sorry.

Installed GTK version 3.6.4 from http://rpmdropbox.laptop.org/f18/. No changes.

That means that GTK changes were not responsible for the difference in behaviour.

Off-hand, I don't know why OLPC OS renders your activity differently to Fedora 18 in a VM. The software stack is quite deep. Areas you might investigate are;

• Sugar font size configuration, org.sugarlabs.font default-size is set to 7 in OLPC OS,
• Xorg dots per inch (DPI) configuration, xdpyinfo says it is 201 on OLPC XO-4, and your system would likely acquire DPI fro the virtualisation software, which in turn would acquire it from your own graphics subsystem, in turn from the EDID query to a monitor or built-in display panel.
• differences in relevant package versions, see OLPC OS for XO-4 package list which is generated by sudo rpm -qa | sort,

[Hrishi1999]

"The activity takes ten seconds to launch. Much of the time is spent iterating through the installed activity bundles. The XO-4 is the fastest of the four models." Any alternative solution? I am using bundleregistry.get_registry() which could cause it?

[quozl]

I've not reviewed your code in detail; can you explain why you use bundleregistry? As far as I can remember, only Sugar uses it, and activities have never been encouraged to use it. I can't find any activities that use it.

[Hrishi1999]

I do not know any other method to get the number of activities installed, please suggest an alternative. I found the use of bundleregistry in Sugar hence I used it (at that time). I still have two uses of jarabe in the activity, one imports bundleregistry and another is misc

[quozl]

Thanks. Since Sugar is to be running, it make sense for Dashboard to ask Sugar for the number of activities installed. This will be a fast question and answer because Sugar already has the instance of bundleregistry. You can add a D-Bus service method to the shell, and call the method from Dashboard.

sugar:src/jarabe/view/service.py contains the service methods.

sugar-toolkit-gtk3:src/sugar3/activity/activityfactory.py shows how the NotifyLaunch method is called by an activity via the Toolkit.

Please explain what you use misc for?

[Hrishi1999]

Two uses for misc. 1) To get the icon name 2) To get the date (https://github.com/Hrishi1999/Dashboard.activity/blob/master/activity.py#L263 and https://github.com/Hrishi1999/Dashboard.activity/blob/master/activity.py#L268)

Should I add a dbus service and open a PR? (Also that would mean that Dashboard activity will only run on the latest Sugar which will be released after the PR is merged, so I should keep both the methods withing a try-catch block)

[quozl]

For getting the icon name, this is another use of the bundle registry. Add a service method to the Journal activity? src/jarabe/journal/journalactivity.py

For getting the date, now that Sugar is not the only caller of the function, move it to Toolkit util.py and call it from there. Change from get_date to another name, or move it to src/sugar3/datastore/datastore.py?

I'd expect three pull requests;

• asking the shell for number of activities,
• asking the journal for the icon name for a journal object,
• moving the human readable time conversion to the toolkit.

Be careful of relying on exception handlers; they can hide trivial problems. You might instead check the Sugar version.

Yes, you're right, I'd always expected Dashboard and Tamagotchi projects to require a new version of Sugar. I was also surprised you are creating Dashboard as an activity instead of integrated into Sugar; I don't remember that being discussed.

As for scheduling, I think you should leave the bundleregistry and misc calls in place for the moment, and do that work closer to the end of your project. A ten second startup time is bad, but not too unusual.

[Hrishi1999]

We are gonna decide if the Dashboard is gonna be a core part or an activity in a meeting tomorrow or day after tomorrow. I've pushed a commit which could fix sizing issues (grid cell width sizes provided by @chimosky after testing on a XO)

[quozl]

Tested c9b8e1c Fix XO sizing issues, very little change;

• the user activity grid blocks no longer extend off the screen,

All of the other not yet ticked observations in the opening commit still apply. In addition the refresh data button does not show the new journal object I created.

Thanks for letting me know about the meeting. I'll probably be away. Here's my comments;

Arguments in favour of an implementing as an activity;

• can install or upgrade the dashboard independently of Sugar,
• existing code can be kept; discarding the activity discards a lot of your work,
• less scattered coding; tightly integrating with Sugar requires touching much of the source code.

Arguments in favour of adding to shell;

• efficiency; does not need to rescan activities or communicate across D-Bus with shell,
• less coding; no need for D-Bus, no need to support existing or older versions of Sugar,
• user experience; can be made to be part of the journal,

Also, 0.112 is the last version of Sugar that can be made to work easily on OLPC OS on the XO laptops, because 0.113 and later began using newer APIs that are not available on Fedora 18. I'm maintaining a fork of 0.112 to which I'll backport interesting changes from Sugar master branch. So getting a dashboard into the shell could be a large backporting effort.

[Hrishi1999]

I will ask @chimosky again to test with different cell widths. The refresh button was a placeholder for an upcoming feature (reflecting the last point in the original comment) which will be pushed later today. We could achieve that by GObject.timeout_add() but I don't think it is required when there is a refresh button.
The meeting will be announced today. I will leave the logs in the mailing list.
Thanks!

[quozl]

Experimented with source code as at c9b8e1c.

• tried omitting the set_canvas object Gtk.ScrolledWindow; theory being that it served no purpose, result was no change,
• tried omitting the Gtk.Frame as well; theory being that it had no purpose, result was no change,
• tried omitting each Gtk.Grid child; theory being that one of them is forcing a width greater than display, result was the heatmap child was responsible alone,
• tried reducing grid_heatmap spacing; theory being that the spacing and the fixed count of 365 forces a width greater than display; result was that this was indeed happening and that a column spacing reduced the problem.

Overall result of experiment; the widgets are off-screen because you've given them sizes which push them there.

[Hrishi1999]

@quozl https://github.com/Hrishi1999/Dashboard.activity/tree/pie-chart-test This branch is to fix wrong activity name. The older code was just a complex datastore call, I've simplified it and now I can see "Acoustic Measure" as "Distance" activity. But it has created some problems as I am using titles of objects instead. Any other solution?

[quozl]

Sure to be. You can see in the Distance activity;

name = Distance
bundle_id = org.laptop.AcousticMeasure

Look for how Sugar parses the .info file and stores the data in memory.

[chimosky]

@quozl kindly test again and confirm that as at ef3f6b0, these display issues have been fixed.

[quozl]

Tested ef3f6b0 and updated all checkboxes in opening comment.

Trying to scroll with arrow keys launched several bundles.

[Hrishi1999]

About the pie chart legends not appearing issue, I've added a detailed view feature instead which shows a bigger pie chart.
The fix for wrong activity names is fixed here (https://github.com/Hrishi1999/Dashboard.activity/tree/pie-chart-test) but still it isn't complete and has issues.
I will add a Scrollbar for heatmap's treeview, that would fix the issue.
How can I detect if the activity is in focus? I could refresh data then. I could fix that by using GObject.timeout_add but I think that would be a rough fix.

[quozl]

Connect to the notify::active signal on the Activity. For an example that demonstrates, see the Clock activity. See also sugar-toolkit-gtk3 issue 388.

[Hrishi1999]

a3d9a10 now fixes data not updating on focus issue.
Also, about the heatmap treeview issue (when you click on a block), not sure why you can't see the second. Do you see the main scrollbar? Does scrolling down show other items?
Also, I can't reproduce the issue where navigating by arrow keys launches bundle. Trying.
Thanks!

[quozl]

a3d9a10 is incorrect; it will force an update when focus is lost as well as when focus is gained.

[Hrishi1999]

Added an additional check. Now only updates when it is in foreground.

[quozl]

Much better, but still costly; when using alt-tab to cycle through activities, the Journal activity starts an update, and the Dashboard starts an update. Is there a datastore D-Bus API you can use to be notified of change?

[Hrishi1999]

Is this related to sugarlabs/sugar-toolkit-gtk3#388? I didn't find any dbus API which notifies the change, I will check just to be sure.

[quozl]

Is this related to sugarlabs/sugar-toolkit-gtk3#388?

No.

I didn't find any dbus API which notifies the change, I will check just to be sure.

src/carquinyol/datastore.py provides the D-Bus API, and there are signals Created, Updated, and Deleted. Each signal includes a journal object id as parameter.

src/sugar3/datastore/datastore.py exposes those D-Bus signals as GObject signals, for use by activities.

src/jarabe/journal/model.py shows how the Journal receives and uses these signals directly using the D-Bus API instead of the toolkit.

Your goal could be to avoid asking the datastore to do a Find and updating your widgets if the datastore hasn't sent any Created or Deleted signals since the last time you did it.

[Hrishi1999]

Thanks! I will try fixing it. I saw the src/sugar3/datastore/datastore.py and found updated signal, I will try to use it.

[Hrishi1999]

@quozl 4549211 should fix the issue. The issue is that is caused by this that the timestamps won't be updated unless datastore is modified.
Edit: Also please provide a screenshot so I can look into the pie chart sizing issue.

[Hrishi1999]

969e70d should fix the issue where listview items are cut off.

[quozl]

Tested 969e70d on XO-4

Updated opening comment. New problems;

• when "User Activity" coloured blocks are selected, the only visible thing that happens is the scroll bar shrinks. Moving the scroll bar with the mouse shows journal objects for the date, in about the same way the Journal activity does by default, and the Journal Entries part of the dashboard does.

Perhaps clicking on a coloured block in "User Activity" could restrict and sort the Journal Entries list on the dashboard instead of adding a new list below the "User Activity". Also change the title to show it is a restricted view.

• font size of the pie chart labels is too small; text is blurred on the XO display because of the pixel arrangement.

[Hrishi1999]

1. I will merge "Journal Entries" treeview with the heatmap. Clicking on the block will then update the "Journal Entries" list.
2. I will try to increase the radius for pie chart for XO devices,

[Hrishi1999]

2dd7923 now uses a common treeview.