Thoughts on an Electron version?

[abritinthebay]

Would work rather nicely on the desktop then :)

[captbaritone]

I'd love to see someone take a serious stab at it. Hopefully the internal API shouldn't require too much hacking to get it to work. I'd be happy to move stuff around to allow the Electron version to live in this repo. Maybe it could live in the experiments/ directory and import code directly?

I foresee a few things as being difficult:

1. Window management. You'll want to bypass the WindowManager component for sure, but I don't know how/if you can have multiple windows that talk to each other without some hefty hacks.
2. Getting square corner windows working on MacOS.

I think the web version will always come first for me, but if we can get a sensible Electron version working (maybe even just the main window) I'd be happy to own maintaining compatibility as the project progresses.

Let me know how I can help! I can setup a chat room if you have more detailed questions.

[abritinthebay]

The Electron stuff isn't too bad. Square windows is easy - just make the electron windows frameless and you have full control of the contents.

Multiple windows aren't too bad (you create multiple BrowserWindow's in Electron, there are some nice plugins to help with management). It's just not that common as most are just web-app wrappers.

[abritinthebay]

I'll do a quick fork/branch for getting it working - just the basics - maybe this weekend 😄

[thesnups]

+1

[captbaritone]

Hey @abritinthebay! Have you gotten a chance to take a look at this yet? Curious to see if you've hit any roadblocks.

[abritinthebay]

Sadly work + real life has meant no-free time >_<

[captbaritone]

If anyone wants to pick this up, feel free to.

[Matnard]

+1

[ajaykarwal]

+1

[nicovanzyl]

+1

[maliur]

+1

I don't know if it's already there or it will make it into Electron as well but react 16 Portals would be really great for handling multiple windows

[Ell]

Gonna try to see what I can do with this idea this weekend, thanks for all the great work!

+1

[captbaritone]

@Ell You are going to make so many people happy. Please let me know how it goes. I'm curious to learn what is easy/hard about this.

It looks like a few people have done some early investigations but have not opened any PRs:

• master...jbeatteay:jbeatteay-electron-mod
• rmoura-92@a4c5d7b

Any lessons learned or advice? @jbeatteay @ricardomoura

[durasj]

Hi @captbaritone,

I would like to take a look at this the upcoming week. What I would like to achieve:

1. Use the NPM module (IMHO better to keep it separated with clear goals) you created to create a new project
2. Verify basic stuff like dropping the files works
3. Try to hack my way around some stuff like closing and minimizing the window till you can implement the API for that (if they are not already there, I haven't checked that :))
4. Wire it up with the Travis for executables for all three platforms (I can test all of them)

If you don't mind, I will let you know how it went and what would help me.

[captbaritone]

@durasj I think using the NPM module is absolutely the right approach. That said, the current API is very far from what you will need. You might be better off starting with a fork of this library and working to push the necessary piece up to the API layer.

For example, I think the way window management is handed (dragging windows around, closing, minimizing) should be exposed at the API level. We could either have the current behavior be the default, or let it live outside of the API. It's not at all clear yet what these abstractions will need to look like, so I think we need to start with a working Electron version (more or less) before we know exactly what the API should be.

If we want the three windows to actually be three different Electron windows, I think they will need to communicate with each-other via some kind of RPC. Luckily, the Redux actions are serializable, so it should be possible to do. I have no idea how hard it will be, or what kind of API changes will be required, but I'm looking forward to hearing what you learn.

[durasj]

@captbaritone I would like to ignore the window management for now. I personally don't care much about the ability to control the individual windows so I would go with the "disabling"/"simplifying".

The way I would imagine the API (but as we've mentioned I will see how it will go) would be to have the ability to define custom callbacks for all window controls and option to disable/hide them. This can even be the same property (if type function then enabled and call the function; if falsy disable - don't render) whatever you fancy more.

So the most I would do next with the window management (after steps I mentioned in the previous comment) would be to use the API (which should be easy to implement IMHO, I can probably make a PR if needed) to take the control of some main window controls and disable some like playlist resizing, eq,pl moving (detaching) and think about it as a one window.

I imagine the ability to disable that would be useful also for others using the npm module as you usually have restricted place and/or space for something. If there would be enough interest I would eventually maybe look at implementing those as separate windows. Or hopefully, someone would care enough to do a PR. But let's not get ahead of ourselves :)

[captbaritone]

Sounds good to me. I'll do an updated publish to NPM and you can see how far you can get. Feel free to open PRs here as needed.

[captbaritone]

Just published 0.0.2: https://www.npmjs.com/package/winamp2-js

[sgnn7]

@captbaritone https://github.com/sgnn7/winamp2-js-flatpak

Elecron-ified and able to be built as a Flatpak

Window management needs to be done for sure but it's about as simple as it can get.

@captbaritone Let me know if you want this spliced into the current repo in some way or leave it as an independent project.

Edit#2: It's pretty junktastic stuff right now and app events don't propagate to Electron but hopefully it can serve as a springboard for others.

[durasj]

@sgnn7 looks good! The only thing I am really missing is the frameless window.

I finished all 4 first steps from the previous comment. It has some quirks like the cursors not working properly or that dragging is still enabled on the individual windows, but I will solve that when I will implement a real API - right now it's kinda hacky but moving the window across the screen and minimizing/closing works.

See winamp2-js-desktop repo.

[sgnn7]

@durasj I'll check it out when I get a chance but whatever the path forward is, it should probably end up with code getting pushed back to this repo rather than having these splinter ones.

[captbaritone]

Wow, looks awesome @durasj! I was able to build it myself and it seems to be more or less working!! My thought would be to use a mono-repo approach where both projects are distinct NPM modules, with Winamp2-js being a dependency of winamp2-js-desktop, but they live in the same repo. That would enable us to do things like refactor to expose clicks on the close button in winamp2-js and consume that callback in Electron land all in one commit. I think this would dramatically improve the speed at which we could move. What do you think? Assuming you are interested in continuing to work on improving winamp2-js-desktop, I'd be happy to give you committer rights to the repo.

[captbaritone]

I’m working on trying to decide what kind of API Winamp2-js should expose in order to give the desktop app the control it needs while staying environment agnostic. I’ll let you know as I get closer.

[durasj]

Thanks, @captbaritone! I am definitely for anything that will speed up development! But I'm not quite sure how we would pull it off. Could you please explain how we would set up the repositories? Do you mean creating a third repo which will contain both or including winamp2-js in winamp2-js-desktop or vice versa?

I would like to continue with the project for sure. I have many ideas (some of which are in the README), but, at the very least, I would like to rewrite it using a proper API. So it's a great news you are working on that. Please let me know if I can be of any help!

[captbaritone]

@durasj My thought would be that we could add the contents of your repo to somewhere in this repo. For example, experiments/desktop/.

However, as I look into what kind of API we would need, I'm getting nervous that it may be nearly impossible to get the multiple windows working properly. I've created a separate issue to discuss this, but until we feel like we have a feasible way forward on this, I'm hesitant to make any large additions to the API. I'd love to hear your thoughts on them here: #494

[durasj]

Hey everybody, I've been working on the webamp-desktop for some time now. You can check it also at desktop.webamp.org with download buttons for all 3 platforms. It's far from perfect, but it's somewhat usable. My goal is to keep it as a lightweight wrapper around the webamp with a minimum (if any) changes to how the web part of the webamp works. Some things are missing, like multiple display support or the new milkdrop, but everything else should work.

I would appreciate any feedback. You are also more than welcome to contribute.

[quassy]

Amazing! Any chance for an update including Milkdrop?

[durasj]

Hi @quassy, yes, it's definitely coming! You can follow the durasj/webamp-desktop#13. There is one blocker that needs to get resolved after which it'll be released.

[captbaritone]

Closing this since I think we learned what we wanted to learn with https://github.com/durasj/webamp-desktop Thanks again @durasj