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

how to build this project locally #66

Open
meodai opened this issue Jan 28, 2020 · 3 comments
Open

how to build this project locally #66

meodai opened this issue Jan 28, 2020 · 3 comments

Comments

@meodai
Copy link

meodai commented Jan 28, 2020

Nice project.

trying to improve a few things on the frontend side. (Mainly css and JS)
But I fail to build the project locally. A few instructions on how to work on it would be greatly appreciated.

There are some things I would like to work on;

  • Improve accessibility. no aria tags are use and almost no accessibility guidelines were considered. I think this is quite important on a project aiming towards audio. Its nearly impossible to use the UI for the visually impaired.
  • package.json files should contain the needed node version. (BeocreateConnect can only be build using node 8 because of an electron issue, Beocare works fine with current node version)
  • is it possible to work on the frontend alone, without having the whole node app running. If not, this is something I would like to work on.
  • Its not clear how dependencies are handled, sometimes they are in the package.json file sometimes they are just in some folder, like jQuery, fastclick, etc... Also something I could work on.
  • The beo-ui.js code is total spaghetti and not documented at all.
  • Getting rid of jQuery & jQuery UI in favour of vue.js for example to make the UI code more maintainable. Would greatly help for the modularity of the UI components.
  • Separate node js logic from frontend logic
@tuomashamalainen
Copy link
Collaborator

Thanks for the comments. It's a lot of food for thought, which is good!

Running this project locally hasn't been something we've put attention to, because we have Raspberry Pi test systems with the relevant sound cards at our disposal to run the code when working on it. Out of interest I tried running this on Mac OS X 10.14.6 and Node 8.12.0. It will start but will be very limited because the system ties into a lot of stuff that's part of HiFiBerryOS and I'm not installing/controlling. This was the process:

  • Put beo-system, beo-product-identities, beo-product-images, beo-extensions and beocreate_essentials in a folder together.
  • Run npm install in beo-system and beocreate_essentials.
  • You'll have to throw away a lot of extensions in beo-extensions because of the aforementioned reason. The server will start with at least the following extensions and should allow you to navigate around but they may give errors:
volume-limit
ui-settings
tone-controls
sound
software-update
product-information
now-playing
hifiberry-debug
hifiberry-audiocontrol
general-settings
feedback
equaliser
dsp-programs
daisy-chain
choose-country
channels
  • npm install should be run for any extensions that have dependencies.
  • etc/system.json should be put into /etc/beocreate on your system. You can change the port in the system.json, otherwise the server will want to run with sudo because it defaults to port 80. If you won't run with sudo, give this folder write access for your user.
  • Finally, you should be able to start node beo-system/beo-server.js vvv dev (vvv enables maximum logging and dev will rebuild the UI from stored HTML files whever you refresh your browser (localhost:port).

The process is so convoluted because the Buildroot system for HiFiBerryOS takes care of putting stuff into place and installing dependencies for us. Making independent installation easier could be something to look into, but in my view this is primarily interesting for other Raspberry Pi Linux distros that can be used with the HiFiBerry sound cards and not necessarily for PC/Mac (as the functionality will be very limited).

Now to some of the other points you made:

  • Accessibility definitely has not been considered but I would be more than happy to support any work towards this. It's in our interests not just from enabling the UI for the visually impaired – maybe it'll mean we can enable navigation with a 4-way remote control, for example.
  • Noted on the Node version declaration, thank you. I was unaware of this.
  • Currently running just the client-side UI is not (at least easily) possible, because the server-side code takes the menu.html files that make the UI for each extension and embeds them into the main index.html before it's served. On client-side the infamous beo-ui.js then builds the navigation structure based on how the menus are organised.
  • Dependencies: for Node on the server side I've tried to make sure they're always in package.json. For client side there isn't a system.
  • Making the UI more modular gets a thumbs-up from here 👍 I'll look into Vue. JQuery I've been using out of old habit but otherwise I'm not at all attached to it.

No denying that there's a lot of code that's dreadfully messy and not documented. Some of that I'll attribute to my inexperience and building this solo. I've been throwing stuff on the wall and seeing what sticks to achieve a system that can work, with the intention of hopefully improving and documenting it later. I sincerely appreciate the criticism and help from more experienced individuals (such as yourself). Helps me learn and do stuff more "by the book".

I'm totally open to tearing down anything in favour of replacing it with something better and more robust – but would like to hold on to the concept of being able to drop extensions into a folder and have them magically integrate with the UI and backend with no further action.

@meodai
Copy link
Author

meodai commented Jan 29, 2020

Oh wow thanks for the very complete answer and feedback.

So the best way would be to actually run it on the pyi and work on it via ssh?
I can totally do this.
I think it would be much more practicable on the long therm to be able to run the frontend on its own. So people could contribute more easily.

To the other points: Sorry I hope this did not came over as a critique, those are only things I would love to work on. But my motivation often expects my ability so don't be too excited yet :D

I will open issues for the other topics and try to work on them myself, I think this will be more efficient then discussing them all in this thread.

  • I worked on some projects were accessibility was very important, so I think I will be able to do something very quickly. Since most of the time it's only a matter of using the semantically correct HTML element or adding some aria-props. Some swiss colleagues just put out this super helpful guide: https://www.accessibility-developer-guide.com/

  • Node version: Cool. Took me a while to figure out what node version to use: https://docs.npmjs.com/files/package.json#engines This is how you can indicate it.

  • Client / Server code separation: I think vue will help a lot there. I could supery easily give you a quick intro to vue. We can set up a shared desktop session or something if you want.

  • Dependencies: we could separate them in dependencies and devDependencies (npm install --save-dev / npm install --save) to differentiate between backend and frontend dependencies. So you would not have to actually include client libraries into the project, but only track the code that actually belongs to the project.

I totally also have my fair share of ugly code projects out there. But since I would love to work on that one, I hoped we could clean it up a bit in order for me and other to be able to help efficiently. It would make me happy to help with this as well.

Thanks for your open minded and positive answer.

@tuomashamalainen
Copy link
Collaborator

So the best way would be to actually run it on the pyi and work on it via ssh?

This is precisely how I do it. I tend to run the latest HiFiBerryOS build and I've set up my editor to auto-upload files to the Pi whenever I save. This means for client-side changes I can just reload the page and for server-side changes I'll restart the server. In terms of workflow it's equally simple as running it locally.

To the other points: Sorry I hope this did not came over as a critique, those are only things I would love to work on. But my motivation often expects my ability so don't be too excited yet :D

All good man ☺️ My background is industrial design so I'm used to taking critique and feedback.

I will open issues for the other topics and try to work on them myself, I think this will be more efficient then discussing them all in this thread.

Totally cool. I can chime in when and wherever you need assistance.

Client / Server code separation: I think vue will help a lot there. I could supery easily give you a quick intro to vue. We can set up a shared desktop session or something if you want.

This would be super awesome, I in turn can give you a tour of the inner workings of the system if you want, then we can both get a better idea on how to attack this. You can reach me privately at exttpt at bang-olufsen dot dk.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants