search

martpie / museeks

🎵 A simple, clean and cross-platform music player
https://museeks.io
MIT License
1.66k stars 198 forks source link

Package system discussion #260

Open dkniffin opened 7 years ago

dkniffin commented 7 years ago

This topic has come up a few times, so I think it'd be good to have a formal discussion about it. It is not something that we would do anytime soon, but rather a post-1.0 feature.

The basic idea would be to implement something similar to Atom's package system. So, users would go to settings, and find a list of add-on packages (and possibly themes), which could extend museeks with non-core functionality.

Some example packages:

If we model this after atom, we also might want to break out each feature into it's own package. So, for example, playlists would be a package, the player would be a package, the library would be a package, etc, and we'd have a default set of packages that come with the install, but users could uninstall parts of it if they want.

The intention of this issue is simply to have a place to discuss this idea, and whether we want to support it at all. If we decide in the future that it's something we want to do, I think we should make a separate issue (or maybe a label, with a bunch of issues) for how to implement it.

dkniffin commented 7 years ago

One concern I've been thinking about is where the list of packages will be kept. ie: the museeks version of https://atom.io/packages

The obvious choice is to build a backend server system for this, but I think that's overkill. What I'm thinking is each package is a github repo, and we have a "plugins.json" file in the repo (or perhaps another repo, if it gets too big), which just has a list of all those github repos. Then anyone who wants to develop a new package/plugin/addon creates their repo, and submits a PR to add it to the list.

martpie commented 7 years ago

reserverd post

OutsourcedGuru commented 7 years ago

Don't know if you're interested in packing up the resources/app folder with asar but I've successfully done so with the following workflow on Windows:

  1. npm install -g asar
  2. cd d:\sits\mplayer\mplayer-win32-x64\resources

Just wanted to make sure that electron doesn't try to use the original folder...

  1. ren app app.dev
  2. asar pack app.dev app.asar
  3. dir
 Directory of D:\sites\mplayer\mplayer-win32-x64\resoures

02/27/2017  12:50 PM    <DIR>          .
02/27/2017  12:50 PM    <DIR>          ..
02/27/2017  12:51 PM        88,985,197 app.asar
02/27/2017  12:42 PM    <DIR>          app.dev
01/19/2017  08:59 AM           145,261 default_app.asar
01/19/2017  08:58 AM           223,247 electron.asar
               3 File(s)     89,353,705 bytes
               3 Dir(s)  408,856,977,408 bytes free
  1. cd ..
  2. electron

I suppose this would be a production/distribution sort of build idea.

mainrs commented 6 years ago

Hey ^_^

I am currently writing a music player myself. I started some weeks ago before I even found museeks. The idea behind it was to make it highly customizable. Meaning that everything except the plugin loading mechanism is build as an extension. I am currently at the fifth iteration of the plugin loading mechanism and wanted to share some problems that I have found with you!

1. Depending on your state management, registering new UI components can be hard. This was one of my very first problems. Since I am using Redux as my state library, adding new components through actions into the state is seen as highly 'invasive' I guess. It does not follow the idea of Redux where the state is considered pure and can be serialized. Since I wanted to make the registration loosely coupled, actions and reducers seemed the way to go. To be honest, I am ok with having a 'soft poluted' state where a sub-tree can't be serialized.

The same problem occured when I tried to make reducer, router and middleware registration possible. Same deal, functions stored within the state.

I am currently thinking about building a hybrid type of state where UI components (React), reducers, routes and middlewares are added using a flux architecture, separating those parts of the application from the core state, the Redux part. This would make a lot of stuff cleaner and wouldn't polute the logical state (Redux) of the application. Since plugins would then just interact once with the flux stores at startup to register any functions or components, this would not be that much of a hassle to use I guess.

2. Package manager - Hosting @dkniffin suggested to build a 'small' backend, similar to atom.io. To bes honest, I think that is pretty overkill. I decided to use npm as my backend of choice. Publishing plugins over there makes it easy to fetch and update them too. The only problem that might occur is when plugins use native node modules that target specific platforms.

3. Dependencies This is by far the hardest part I guess. I kind of solved it by making each plugin declare it's dependencies as externals and the application provides all its runtime libraries to those plugins. I am still debating on whether I should run each plugin within an own instance or run all within a separate instance. This would make the core application less error prone since errors in another thread won't effect the core functionality. I think vscode does something similar but oh boy, there source code is ugly as hell. So many sub-packages without any proper documentation on what part is doing what. No idea how they keep track of it 😄

Just wanted to give some small inside ^^ Did you guys internally discussed something similar? Or have an idea on how to implement stuff? I would love to not polute the redux state and I am honest, I pretty much like the idea of mixing flux and redux for this particular use case. It seems like museeks used flux in it's earlier stages (or something similar) sine not all of the code complies to pure redux.

I will probably just keep tinkering around with the player. I might come up with something useful ^^ Maybe we'Ll integrate it at some point into museeks. ^^

YurySolovyov commented 6 years ago

Did you guys internally discussed something similar? Or have an idea on how to implement stuff?

We don't have anything more internal/closed than GitHub and Gitter (that is - everything is open)

I personally very much against (unbounded) extension points, I like museeks for that minimal(istic) approach:

I like that museeks treats me as owner of the music I have, and it just allows me to play it - that's the most essential part that should never be sacrificed.

Next comes library management part - it is not perfect yet, but that's because it is actually pretty complex and requires a lot of thought. But again, that part should have great UX out of the box.

Then comes the category of features that is kinda to hard to talk about - features (to be) implemented as/via plugins. It is hard to talk about because it is double-sided - I can see the these features being useful, but I can also live without them - hence, they are not essential.

Can a player be a good one without being able to play local stuff? No. Do you need to be able to search/organize stuff by basic metadata like albums/artists/folders? Yes. Are lastfm/visualizations/custom themes really essential? I don't think so.

^ all of that just an IMO, I hope it at least somewhat matches initial project vision.

Btw, if you look at the https://github.com/KeitIG/museeks/issues/220, you'll see how much essential stuff needs to be done, even before we can say basics are done and we can think about extensions.

Besides that, there are lot of stuff you can contribute to, e.g. themes are not frozen and if you have ideas on how to make them better - that's great, also: lots of under-the-hood changes are waiting to happen, different in scale and impact, that might be interesting too.