Explain log in with the Sugar desktop selected

[quozl]

"log in with the Sugar desktop selected" is not easy to decode for people who don't know how to use the features of the greeter program, and the desktop selection list. This is made harder because gdm3 does not clearly explain the feature on screen, instead showing a gear logo.

• [x] refer to gdm3 documentation,
• [ ] add script-annotated screenshots of gdm3,
• [ ] maintain for each release of Fedora and Ubuntu,

[shaansubbaiah]

Has this been solved? If not, shall I create a tutorial with images in markdown for the same?

[sanjaymaniam]

Yes, please! I so wished for an illustrated guide a few months back. I suggest instructive GIFs, though you might have to check with the others if it meets Sugarlabs' documentation style.

This is an open issue, so unless otherwise mentioned, you may propose a solution right away😀

[quozl]

Also, gdm3 is not the only greeter program. lightdm and kdm are also encountered. The most time consuming part of this issue is the ongoing maintenance, because the screenshots can change with each release of a Linux distribution. It is why I have not done it myself.

Not planning for ongoing maintenance means we'll just delete what you contribute as soon as it is out of date.

[shaansubbaiah]

@quozl I have come up with something here https://github.com/shaansubbaiah/tutorial-sugar-log-in

[quozl]

Great start, thanks.

It looks like you've referred to the Debian Wiki for documentation. I suggest referring to display manager documentation from the upstream projects. The Arch Wiki is also another good source.

It looks like you've used a record-my-desktop or a screen-casting application and converted to animated gif. There's visual noise. I suggest writing a script to capture the screenshots and assemble them into a coherent view using ImageMagick.

There are a few minor things to change;

• use "display manager" rather than "desktop manager", unless you can find me a source that shows general acceptance for the name change,
• gdm3 is not the default display manager for all those distributions; for some it depends on the flavour or spin of the distribution,
• everywhere you say "default DM" could be just "default",
• best to refer to the display managers consistently using the upstream project name,
• Rasbian on a Raspberry Pi uses lightdm.

[shaansubbaiah]

Thanks, I'll make the necessary changes.

Right, I have mixed up the words display manager and desktop environment in my head :P

I have used Peek to record it as a gif directly. It generally does a good job but causes artifacts when recording a VM.

ImageMagick supports creation of gifs from screenshots, do I use that or just post 2-3 images for each example?

[quozl]

Yes, I figured the artefacts were because of the VM rendering; I've seen something like that before. Could be the type of VM and outer operating system you're using. Some virtualisation software has remote control capability, so you can script something that will pause a VM, take a screenshot, and then resume.

ImageMagick can pretty much do anything with images. Limited to which parts of it you learn how to use. I use ImageMagick rarely, but always from the command line. I'd be happy with a few annotated images, like in a comic panel arrangement. The animated gifs are luxury by comparison.

The key is maintainability. Having to repeat a manual operation for every new release or display manager is a pain.

[shaansubbaiah]

I have found a solution to the artifacting, it was caused by the display driver, turning off 'Allow Flipping' under OpenGL settings fixes it on systems with NVIDIA GPUs. I don't think its an issue on AMD/ integrated GPU systems.

I find that recording it as a gif is much faster, takes only a few seconds for the whole process. It'll be much easier to just record a gif for newer releases.

I've also been able to double the framerate and quality (removed that banding effect) and half the size using the gifski plugin for peek. Old -> https://i.imgur.com/Nkr11mW.gifv New -> https://i.imgur.com/TVLWqnF.gifv

I've updated the readme with the changes (https://github.com/shaansubbaiah/tutorial-sugar-log-in)

[quozl]

Thanks. Where do you think this documentation should be put? Will you document the steps to update the documentation? Will you stop mentioning desktop manager? :grin:

[shaansubbaiah]

Fixed the typo again :P I will write a few steps on recording those gifs. We can put this in the sugar docs repo or just link the words 'login to sugar' in the documentation/ setting up dev environment files to this readme.

[quozl]

Thanks. I've also thought of recording asciinema sessions for installing Sugar on an existing Linux system, or a step by step bringup of a VM under VirtualBox. But we've lacked volunteers to maintain these things.

[quozl]

Merged. https://github.com/sugarlabs/sugar-docs/blob/master/src/sugar-logging-in.md

[shaansubbaiah]

Thanks. I've also thought of recording asciinema sessions for installing Sugar on an existing Linux system, or a step by step bringup of a VM under VirtualBox. But we've lacked volunteers to maintain these things.

The asciinema session recording seems like a really good idea. I think there are enough and more tutorials on how to create a VM using VirtualBox / KVM and the Sugar Live Build installs just like any other Linux distro.

[quozl]

I agree, another tutorial on how to create a VM shouldn't be necessary. Perhaps we just have to link to a good one.

[shaansubbaiah]

According to the Debian wiki,

Packages for VirtualBox are not available in Debian 10 and won't be in buster-backports either. A recommended alternative is Virtual Machine Manager (buster/virt-manager).

Would it be better to link to a tutorial on KVM rather than VirtualBox? This tutorial on the Ubuntu help wiki explains how to install KVM with virt-manager GUI and create a VM very nicely https://help.ubuntu.com/community/KVM/VirtManager

[quozl]

Yes, linking to an open source virtualisation tool set might be better than linking only to VirtualBox. VirtualBox is packaged for Ubuntu. I've not checked Fedora. They all have KVM. However, in my experience there are more plentiful examples for using VirtualBox across more operating system platforms. KVM is rather limited to specific operating systems. Should we document what others are documenting already, only to offer a solution with a limited scope? I'm not sure.

[srevinsaju]

I can confirm that KVM works pretty much very good with almost all manylinux2014 OSes which are built on top of EFI/BIOS. and moreover, KVMs work better than VirtualBox in many aspects other than gaming. I particularly use VirtualBox only and only for non manylinux OSes like Androidx86 and Windows OSes. KVMs work with CentOS6, CentOS7, Fedora 31, Fedora 30, Fedora Rawhide, Ubuntu 18.04, Ubuntu 20.04, Xubuntu 20.04. I have tested these OSes on KVM

PS: I got a new system

---

to my curiosity, is Virtual Box closed source?

[chimosky]

I agree with @quozl.

to my curiosity, is Virtual Box closed source?

Nope it's open source.

[shaansubbaiah]

Should we document what others are documenting already, only to offer a solution with a limited scope? I'm not sure.

@quozl, as we have decided not to create a tutorial on installing a VM, we always have the option to link to tutorials for both KVM and VirtualBox. We may even leave it as is, not provide one at all.

In my opinion, the asciinema session for installing Sugar you had mentioned earlier will be more useful as it is specific to Sugar.

KVMs work better than VirtualBox in many aspects other than gaming.

@srevinsaju I believe KVM supports GPU Passthrough (on devices with GPU + (integrated graphics or another GPU)). Technically it should be better for graphic-intensive tasks like games.

[srevinsaju]

@shaansubbaiah Unfortunately. the jukebox-activity does not work on my KVM version; Maybe I have to do some additional configuration for GPU passthrough.

See https://github.com/sugarlabs/jukebox-activity/issues/28 for what happens on my system with KVM and Sugar

[quozl]

@shaansubbaiah, thanks.

@chimosky, yes most of VirtualBox is open source. Once upon a time it was not. There are proprietary plugins. I've seen this cause confusion.

@srevinsaju, good to hear you 've upgraded. :grin:

[shaansubbaiah]

@quozl shall we close this issue now that the login documentation has been created?

@srevinsaju Have you tried switching to Virtio from QXL in KVM? I could not login to some of the distros without changing this setting, it might help?

[srevinsaju]

@shaansubbaiah no, I have not tried, I will check and let you know. we can then maybe add the possibility to run to the Wiki too. Because the wiki has only VirtualBox as the method of installation afaik

---

as an aside, which desktop environment is yours and which theme? looks cool

[shaansubbaiah]

@srevinsaju Let me know if that works :)

---

Theme:- KDE Plasma on Manjaro with my Candyfloss theme, its a slightly modified fork of EliverLara's Sweet Theme (Available in the Online theme downloader in Settings->Appearance->Get New Plasma Theme)

[srevinsaju]

Nice work on theme; I might use it :smile:

[quozl]

@quozl shall we close this issue now that the login documentation has been created?

Is it linked to yet? How will end-user get to it?

[shaansubbaiah]

I'll link it to all references to 'login with sugar' in the docs. Would it be better to create a single PR or multiple for each doc?

[quozl]

Thanks. You'll find docs in sugar:docs, sugar-docs, wiki.sugarlabs.org and help.sugarlabs.org. Our live build could also benefit. There's also Sugar pages on the Wikis of other projects, but I don't track them; like Debian Wiki, Arch Wiki, and so on.

I don't understand your question regarding single or multiple pull requests. Changes may spread across multiple repositories. Some changes can't be made with pull requests.

[shaansubbaiah]

Thanks for linking the various sources.

To clarify, I was asking whether to create multiple pull requests in the sugar-docs repo for every 'login to sugar' to be linked. It has been mentioned in multiple files within the same repo. Will a single pull request making changes in multiple files be suitable or not?

[quozl]

We would normally use either;

• a new branch, one commit and then one pull request, or;
• a new branch, one commit, and then push to a repository, then add a reference to the commit here to concentrate the discussion, and so that a maintainer can cherry-pick or merge by hand.

In distant past we have also used git send-email for review by sugar-devel@, but that method is unpopular these days. Nobody reviewed properly that way. :grin:

[chimosky]

Fixed in 5b0e880.