Thank You!

[iamlayer8]

@dmarmor , I want to thank you for the work you've put into Epichrome. It is a great tool, I've been extensively using over the last (>5) years.

[dmarmor]

Thank you! I really appreciate the kind thoughts.

[jlongman]

I was just thinking the end of the year is coming and it made me appreciate it and you even the more.

Cheers @dmarmor, I was happy to be part of the Patreon and sad to hear of the end!

[dmarmor]

Thank you, @jlongman! I'm glad Epichrome has been useful, and am also sad I've had to wind it down...

[MalEbenSo]

Dear @dmarmor, thank you for all the work you have put into Epichrome. It has been such a useful tool for a long time.

Sad to see it go. Your work has been appreciated world-wide.

Greetings from Germany and all the best for you and your future.

[dmarmor]

Thank you, @MalEbenSo! I'm sad to see it go too, but glad to know it's been useful. Happy New Year, and all the best to you as well!

[henderea]

@dmarmor: out of curiosity, what would it take for me to maintain an Epichrome version for personal use? Is everything in the repo? Do you have any information I would need for updating certain components of the app when they release new versions? Are any special build tools or knowledge required?

I have an apple developer account, so I would be able to code-sign stuff. I'd definitely like to keep using Epichrome (specifically the Chrome part) into the future, and it would be nice if I could keep things up to date for my own use. I would fork the repo and keep it public if people wanted to use my copy, though I would probably strip out or ignore parts I don't use like Brave.

To be clear, I would be working on it for personal use and keeping it in a public repo with uploaded builds if anyone wants to use it. As it would be for personal use, I would not be taking any money for it and anyone using it would be on their own if they have issues (though I might consider feature requests if they seem like something I might want to use).

Epichrome has been a great tool, and I really don't want to give up on it. As a software developer myself, I'm very much open to maintaining a copy for my own use. If I keep my own copy, anyone else maintaining a copy would of course be free to make use of any code I put into my copy, and I wouldn't mind passing along information I get or things I learn to other maintainers. There are definitely some improvements I've been considering, and I may eventually re-write a fair portion of it in something else like Swift, NodeJS, and/or Electron. Any changes I make would be pushed to my public repo for everyone else to see.

As long as I have all of the parts I need, I don't mind adjusting any parts hardcoded to your developer account or your system or whatever, so I'm definitely not asking you to generalize your code or change it beyond what you need to do to avoid sharing info you don't want to share. I'm fine with handle any generalizing or reworking myself.

Thank you for any information you can provide, and thank you for such a great tool!

[ylluminate]

@henderea you might like / be interested in https://vlang.io/ (https://github.com/vlang/v). @ylluminarious and I are considering rewriting Epichrome in this so we can have a compiled C-speed level app. I think the universality of the language + the UI that's coming along nicely could be a huge asset for building something that can take Epichrome to all dominant operating systems.

[talleux]

Wow! Is this serious? Would be amazing! I'm still looking for an alternative for my 30+ Apps...
I would help as a tester, if you need.

PS: finally Epichrome had a status where it was working very well and in the few cases of a bug it was now easy to recover broken apps. Would be a shame not to have that project continue living and growing ;-)
PPS: i didn't have the chance to test it on a Silicon Mac with Monterey but this is coming very soon...

[ylluminate]

We're in the same boat as you - too much commitment to the wonderful compartmentalization / sandboxing and organization that Epichrome brings to the workspace to just let it go.

So far Apple Silicon with Epichrome+Chrome works quite fine and native, but Brave doesn't; see: #293 (comment)

I'm trying to allocate some time within the next couple days to figure out how to build it as per Dave's notes.

After that it will be somewhat of a slog to first extract out a stepwise reproduction of the logic he follows for creation of Epichrome apps + updating and then, probably, more or less convert this to another language (like I said, I think V is quite promising due to its cross platform compiled nature and C-like compiled speed and size). I think a compiled 3.x would be a reasonable target that works on macOS and perhaps also Linux and then maybe Windows could be roped into this down the road in a 4.x expansion/further rework of logic...

From what Dave has been saying I'm HOPING that taking the compiled approach will eliminate the architectural problems that Apple has been heaping upon everyone that has stopped Epichrome for the time being, but heaven only knows what Google will do... You can't trust that company with a trip to the bathroom (https://killedbygoogle.com/).

[MalEbenSo]

I totally get the cross-platform advantage (if the end result indeed still feels native).

Sincere question: Where in the case of Epichrome does the speed advantage come in? Isn’t the app‘s speed primarily the embedded browser‘s speed?
App launch?

[ylluminate]

After working with Ruby for a long time, I've come to really appreciate speed. Launch speed and even memory efficiency can be very beneficial in many ways. What if, at some point, we want a "terminate and stay resident" approach similar to Chromeless (which I don't trust will stay alive and it is pretty "fat" as far as memory consumption goes due to its platform) - or something different?

We live in a world that has lost its way when it comes to memory and instruction count. I'd love to see a web browser built with V using Ultralight. It's sad to see Chromium taking over the world with no real options contra it's megabloat.

Anyway, could go down some other lines of thought here, but I just think it's a sound principle to try to keep things efficient, isomorphic and maintainable (more quickly picked up for would-be contribs, readable / expressive language vs pure C or, lol, asm) where possible and that sums up my interest in V and using V for even this.

[dmarmor]

Hi @henderea, I fully support you keeping it maintained for your use and even posting packages for others if you want. (If you wanted to keep posting them through the auto-update channel, I think it would be best to leave Brave in it, as many other users rely on that and I wouldn't want someone to accidentally auto-update to a version that breaks their apps.)

As far as building it yourself, I think almost everything you need should be in the repo, except for Platypus, which I have as a module, so I believe it should come down properly if you do a pull (but I haven't tested this), and codesigning ID info, which you will need to create for your developer account in the app/private subdir. In there you'd need to create two files:

1. codesign_identity.txt: This should contain nothing but your codesigning identity. I used my 10-digit alphanumeric code rather than my name, but I think you could use either.

2. notarize_credentials.txt: This contains some command-line flags for the notarization process, which you might not need if not distributing. But if you want your package notarized, this file would need to exist, and look like the following:

--username '<YOUR-APPLE-ID-EMAIL-ADDRESS>' --password '@keychain:AppleID altool notarize'

As I say, I think it should build once you have those files, but there may be dependencies I'm not thinking of. I'd say go ahead and give it a spin, and if you run into a problem and can't figure out how to get it to build, ping me here and I'll try to figure out what's going on. Good luck!