Sugarizer is a free/libre learning platform. The Sugarizer UI use ergonomic principles from Sugar platform, developed for the One Laptop per Child project. It’s published on Snapcraft here.
I recently realized that it can’t works correctly without a classic confinement:
It’s build using Electron and store its context in localStorage. Chromium need filesystem access to save localStorage.
Some activities need Camera access (take picture, read QRCode),
There is a feature to import/export file on the Sugarizer journal so file system access is need.
So I’m requesting classic confinement for Sugarizer.
This shouldn’t be an issue as there are many electron apps in the store. Have your snap ‘plugs: [ browser-support, camera ]’ and optionally ‘home’ and ‘removeable-media’.
I’ve done lot of debugging and testing and you’re right: I don’t need classic confinement. Issues regarding localStorage and import/export file was related to problems in my code.
So I just need to add camera plug. By the way I would like to have the auto-connect active for the camera. Could I do a request for that?
Is camera functionality core to the snap or is it supplementary and otherwise works ok without it? Put another way, what is the expected usage of sugarizer wrt the camera?
Sugarizer is a set of activities that could be use together to create pedagogic activities in the classroom or at home.
Two specific activities need camera:
Record activity: it’s a basic media capture activity. It lets you take pictures then use images into other activities. For example to draw (with Paint activity) or to create amazing comic strip (with Fototoon activity)
QR Code: it’s a QR code scanner and generator that let you associate QR Code with some other content.
If the camera doesn’t work this two activities will be useless but other activities will continue to work. So the user experience will be worse specifically comparing to other platforms supported (Android, iOS, Windows, MacOS).
Thank you for the additional information. I’m slightly conflicted on auto-connecting camera. On the one hand, it is core functionality offered by a standard activity of the application and the user of the application (a child) likely won’t have the permissions to connect the interface on the device (ie, an admin would have to do this). On the other hand, auto-connecting the camera so a child might be recorded without the parent/school teacher/admin necessarily knowing doesn’t sound like a great idea.
Modern browsers typically have some safeguards in place to keep sites/etc from activating the camera without them knowing when people are surfing the web. Does sugarizer have any sort of in-application protections, controls, notifications, etc that mediates the access or makes it clear when the camera is recording?
Thanks to you for this deep analyze on Sugarizer. I perfectly understand your conflict.
The camera must be activated explicitly by user by clicking on an icon in Record and QRCode activities.In both activities the live content of the camera is displayed during the use. So it could not have any confusion regarding the use of the camera for the user. Plus, only Record activity keep the picture taken and it show it immediately to the use (who could remove it). QRCode scan with the camera but just display the QRCode read.
Finally, of course, because it’s a free/libre software under Apache 2 license, the code is fully accessible to check the good usage of camera.
I’m +1 on auto-connecting camera; it seems like sugarizer’s use of the camera is entirely user-driven and won’t inadvertently just start recording. There is always the risk of malicious code making it into the snap and leveraging the camera’s auto-connection, but this risk exists for any other auto-connected snap as well.
The snap declaration is for the snap and not a particular revision. It will therefore apply to any revision that plugs camera (past, present or future).
