Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Sugar Labs boot logo #6

Open
quozl opened this issue Mar 23, 2018 · 22 comments

Comments

Projects
None yet
4 participants
@quozl
Copy link
Contributor

commented Mar 23, 2018

@vipulgupta2048

This comment has been minimized.

Copy link

commented Mar 23, 2018

@vipulgupta2048

This comment has been minimized.

Copy link

commented Mar 23, 2018

This actually gives me a cool new idea for contribution to Sugar
Labs. I have been working with Plymouth for a quite some time now. I could
create one for Sugar too (if not implemented already). By first starting
with a custom boot logo then moving up to a custom-made boot screen with
animation using Plymouth. I love tweaking especially with Linux.

Thanks a lot, James, I would be adding this to my proposal for GSoC 2018
under other deliverables too. Love to work on it this ASAP.
Also, here are my dotfiles for Plymouth if anybody needs them -
https://github.com/vipulgupta2048/dotvfiles/tree/master/plymouth/

@vipulgupta2048

This comment has been minimized.

Copy link

commented Mar 23, 2018

@quozl I would like to take this up.

@quozl

This comment has been minimized.

Copy link
Contributor Author

commented Mar 26, 2018

Plymouth is not in the build, so you'll have to add it as well as configure it.

(Also, while it is good you would like to take it up, we do not make reservations. What matters is the pull request. This new practice of asking for permission to work on something, perhaps in the hope of being the one who will win the task, goes against our Sugar Labs culture. If someone else solves the problem before you, in a way that is better than your solution, we'll take it gladly. 😁)

@vipulgupta2048

This comment has been minimized.

Copy link

commented Mar 26, 2018

I am really sorry @quozl, I hope you would chalk these up as beginner's mistakes. I completely understand that this is not a race and also if a solution is better than mine then I too would go for it. This won't happen again, I for one know the importance of open-source culture and would do anything to uphold it.

Plymouth is not in the build, so you'll have to add it as well as configure it.

Oooh... That sounds challenging and equal parts fun. I am down for it. I need some help though on how to go about navigating the directory structure of Sugar when installing in the system.

@vipulgupta2048

This comment has been minimized.

Copy link

commented Mar 26, 2018

How about I dig through the docs of LFS and maybe could find more about adding Plymouth and how to go about configuring it. Seems like a good place to start, right ?.

@quozl

This comment has been minimized.

Copy link
Contributor Author

commented Mar 26, 2018

I feel you are speculating. Clone sugar-live-build, work out how to run it, read the documentation included, and read the documentation for the dependency Debian Live Build. Come back once you've made a build and have read the documentation, because by that stage you should have a better idea of how to proceed.

@vipulgupta2048

This comment has been minimized.

Copy link

commented Apr 3, 2018

So, I cloned sugar-live-build, gave the documentation mentioned a look. I ran the build script which ran without errors and created a build. I do have a better idea then what I had at the start. I think we need to customize the live build, make a default Plymouth theme (considering Plymouth is mentioned in the package list. Which I checked, is there) So all I have to do is to create a Plymouth script (Theme) for Sugar Labs. But add it to where I am still a little unsure. Under chroot, seems the most appropriate place.

@vipulgupta2048

This comment has been minimized.

Copy link

commented Apr 3, 2018

Also, I was thinking of adding something like this
But needed a .png for it, do we have a repo for all the files like these.

@quozl

This comment has been minimized.

Copy link
Contributor Author

commented Apr 4, 2018

Sorry, I thought it was very obvious. Recommended way to change the builder;

  • install a build on a virtual machine,
  • make changes by hand, reboot, and iterate until you have reached a functional goal (a logo during boot),
  • evaluate the changes you made and redesign the changes for use by Debian Live Build,
  • commit changes to the build, make a build, test the same functional goal is met, and iterate until done.

Once you make a pull request, we'll critically review whether you've made the change in the right place. Be prepared to justify your decision. 😁

You can find icons in the various Sugar Labs repositories. Format is SVG so they can be rendered to any size. Look in sugar, sugar-toolkit-gtk3, sugar-artwork. If you have a specific icon in mind, mention that. The one you refer to is not used by Sugar Labs in that form. Instead, Sugar uses icons/scalable/device/computer-xo.svg in sugar-artwork, but only to represent a computer or child. My guess is you should be looking for the Sugar Labs logo as well. See www-sugarlabs.

@vipulgupta2048

This comment has been minimized.

Copy link

commented Apr 4, 2018

test1

Plymouth Script draft 1

  1. The spinner i.e rotating is taken from Xubuntu's splash screen. I can assure you that the spinner is quite smooth, it's just that .gif format is messing it up. [I used this since the script is written to work on all screen sizes with good test cases.]

Any changes, or should I proceed to test it. Thanks for the detailed description. It helps a ton.

@quozl

This comment has been minimized.

Copy link
Contributor Author

commented Apr 4, 2018

Ask sugar-devel@ for design opinions. I think it is unlikely anybody else is following this issue.

@vipulgupta2048

This comment has been minimized.

Copy link

commented Apr 4, 2018

Roger that, sending a message now.

@walterbender

This comment has been minimized.

Copy link
Member

commented Apr 4, 2018

looks good to me...

@samswag

This comment has been minimized.

Copy link
Member

commented Apr 4, 2018

I have a comment, I don't know if it is doable but I think if it is possible the loader (sugarlabs image)should use the same pattern(use different colors, meaning switching different image.) just how logo change on www-sugarlabs along with the spinner.

@quozl

This comment has been minimized.

Copy link
Contributor Author

commented Apr 5, 2018

@vipulgupta2048, likely to take weeks to get feedback, so why not go ahead with what you have? Next step for us to review is a pull request with the implementation details. Content of logo can be changed later, separate issue.

@vipulgupta2048

This comment has been minimized.

Copy link

commented Apr 5, 2018

@samswag I will see what I can do. Thanks for your feedback. 👍
@quozl I agree with you, I will push on with this. If later, some changes need to be done to the Plymouth theme. Then I will make it so that it would be easy to accomplish that without much intervention. 👍

@vipulgupta2048

This comment has been minimized.

Copy link

commented Apr 9, 2018

virtualbox_sugar_09_04_2018_00_16_21

I finally got the build script (5th attempt) running with my config in it 😅 But then after booting the .iso made by the script in VM, this happened. I can't seem to debug this, any suggestions are appreciated. My changes to live-build are here I am still learning as I go. Also, I will straighten all the changes done, once everything is finalized.

@quozl

This comment has been minimized.

Copy link
Contributor Author

commented Apr 9, 2018

Common problem; there's no init process for the kernel. You should bisect your changes to find which one made the problem occur.

Unrelated to the problem; we can't have binaries like those script.so files. Use source code only.

@vipulgupta2048

This comment has been minimized.

Copy link

commented Apr 9, 2018

Common problem; there's no init process for the kernel. You should bisect your changes to find which one made the problem occur.

Roger that, I can fix it.

Unrelated to the problem; we can't have binaries like those script.so files. Use source code only.

That's a module needed for running the Plymouth theme, Debian doesn't have that in the Plymouth folder upon installing Plymouth. I had plans of removing it once, the .iso ran and checking again. Will take care of it. Thanks.

Also, what do you think about the other changes to hooks and package-lists. Going the right way or any further changes that are needed?

@quozl

This comment has been minimized.

Copy link
Contributor Author

commented Apr 9, 2018

Your quoting was broken and looks wrong in GitHub. Reformatting below;

we can't have binaries like those script.so files

That's a module needed for running the Plymouth theme,

Then it should come from the Plymouth packages, right?

After installing plymouth the path is /usr/lib/x86_64-linux-gnu/plymouth/script.so so there's probably no need to have that file in sugar-live-build.

Debian doesn't have that Plymouth folder upon installing.

It does have script.so, see the plymouth package file list.

Perhaps you have used the wrong path to the file?

I had plans of removing it once, the .iso ran. Will take care of it. Thanks.

Also, what do you think about the other changes to hooks and package-lists. Going the right way or any further changes that are needed?

The commits didn't explain what was changing and why, so they were very difficult to follow. There seemed to be redundant changes to multiple directories. You might test to see what changes are required, minimise the changes, and rewrite the commit series by rebasing and adding a detailed commit message. See our guide to commit message writing.

@vipulgupta2048

This comment has been minimized.

Copy link

commented Apr 9, 2018

Fixed the quotes, thanks for mentioning. Will take care of the same.

Perhaps you have used the wrong path to the file?

I will surely look into it, thanks for the reference. I could be wrong there. The final commit won't have it.

The commits didn't explain what was changing and why, so they were very difficult to follow.

As mentioned before, I have done the changes in a more unprofessional manner then I would have liked since I am still testing the build. The final review would include having all commits rebased and amended when I make the PR. I am on it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.