Test on Fedora 18 - Githubissues

quozl commented 5 years ago

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

Screenshot of _Dashboard Activity_

[x] "Total Files" is truncated,
[x] 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),
[x] "User Activity" empty blocks are truncated on the right edge of display,
[x] 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,
[x] 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 commented 5 years ago

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 commented 5 years ago

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) issue2

quozl commented 5 years ago

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. https://github.com/sugarlabs/sugar-artwork/issues/100 is an issue which was caused by this, as illustration.

Hrishi1999 commented 5 years ago

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 commented 5 years ago

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

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 commented 5 years ago

Screenshot of _Dashboard Activity__1

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

Hrishi1999 commented 5 years ago

I will try to fix them soon. Thanks.

Hrishi1999 commented 5 years ago

@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 commented 5 years ago

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 commented 5 years ago

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

quozl commented 5 years ago

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 e355758098208b1c0f51bf85881c91e70420baf4 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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

It is being set. The SUGAR_SCALINGwill 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 commented 5 years ago

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.

https://github.com/Hrishi1999/Dashboard.activity/commit/3b30a967e9829bda1b55be2ed561ebe2cb20cacc tested on Fedora 18 based OLPC OS 13.2.10 on an OLPC XO-4 looks like this now;

Screenshot of _Dashboard Activity__2

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 commented 5 years ago

Sorry forgot to mention that I also tested with SUGAR_SCALING=100. Here is the screenshot. f18_XO 0 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 commented 5 years ago

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 commented 5 years ago

"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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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.

Screenshot of _Dashboard Activity__3

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 commented 5 years ago

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 commented 5 years ago

Experimented with source code as at c9b8e1cc.

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 commented 5 years ago

@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 commented 5 years ago

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 commented 5 years ago

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

quozl commented 5 years ago

Tested ef3f6b0 and updated all checkboxes in opening comment.

Trying to scroll with arrow keys launched several bundles.

Hrishi1999 commented 5 years ago

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 commented 5 years ago

Connect to the notify::active signal on the Activity. For an example that demonstrates, see the Clock activity.

Hrishi1999 / Dashboard.activity

Test on Fedora 18 #2