Try out eul:

https://eul.im

It's a native desktop client for Skype, Slack, Facebook, WhatsApp and many others. It's only 4 MB, it has minimal CPU usage, and it can handle hundreds of thousands of messages without lag.

Facebook support is coming tomorrow, WhatsApp is going to be supported next week.

Since Whatsapp is completely proprietary, is this totally based on reverse engineering their protocol?

I see you wrote the program. What did you write it in? What are you using for the UI toolkit? Are you planning to open source it?

1) Go.

2) Nothing. I'm drawing everything directly with OpenGL/ANGLE.

3) Yes, hopefully this year.

I don't know much about OpenGL UI, but how does OS specific font rendering work?

It's using a freetype lib

4) What license do you plan to use?

5) Do you plan to support the Matrix protocol?

6) Do you plan to made income on it? If so, by donation or else (cost, ads, etc.)?

4) I haven't decided yet.

5) Absolutely!

6) Yes, still not certain about that either.

Interesting find. It opens an embedded browser window to OAth with Slack, but after that closes nothing happens to the main window (i.e. the account never gets added).

Incredible how it has a seemingly from-scratch cross-platform UI without framework bloat; but it doesn't seem to work...

It should work. Right now there can be a ~10 second delay for very large Slack teams.

If you still get nothing after 10 seconds, could you please submit a bug report via the built-in '?' form? If it's a public team, please include the URL.

Thanks

I am having the same issue. Once I log in to Slack nothing happens in the main window. My team is very small. I submitted a bug report as advised. Thanks for the nice work!

This has been fixed in v0.22. Can you try again?

There was actually a bug. It was fixed in v0.22. Can you try again?

This looks like it could be really awesome. A feature request if you don't mind: it'd be fantastic if you could allow users to export their previous conversations somewhere. Bonus points if it can be done automatically (real-time and/or on a backup schedule).

Thanks for creating this :)

Good idea. This will be implemented soon along with cloud sync.

Wow, that's something I've been looking for for years, especially including xmpp.

Are you the author? It's hard to trust company logins to a binary blob, coming from a page with no information at all (no about/contact, empty github profile). Looks very fishy at the moment.

I am the author, and there's an /about page :)

https://eul.im/about

Like the home page says, the binaries are going to be signed after September 15. My docs are being verified right now.

Last time I tried Eul it was very rough around the edges, and the fact it’s not using system controls for things like text entry means it’s probably going to take quite a while before it’s mature enough for regular use.

It's a lot more stable now. Controls are closer to system controls, although it's not ideal of course. It's going to be out of beta next month, so it won't take too long.

To be honest, hope you don't mind the criticism, but I think using custom controls was the wrong choice.

I dislike Slack/etc because they are non-native which means they are slow, and behave incorrectly. Eul will address the speed, but without the native controls it's unlikely to behave correctly.

Behaviour I'd be looking for to match system controls: text field editing, including shortcut keys, accessibility of controls using system accessibility attributes (which can be used for screenreaders, productivity apps and OS scripting), pervasive drag and drop support, proxy icons, copy/paste (with rich-text formatting where necessary).

There's a lot to do, much of which comes "for free" or at least "discounted" when using system controls. I really hope you prove me wrong and I wish you all the best with this. I may well end up using Eul anyway because of the speed, but I thought I'd try and provide my motivation for why using system controls is such a key part of my dislike for Electron apps.

Thank you for sharing.

Do these services care that your app lets the user side-step their apps?

+1 to this. I'm worried he'll get shut down with a cease-and-desist letter.

I won't even try this since I'm certain he'll get shut down with a cease-and-desist letter.

Interesting. Trying to pick up where Pidgin left off? Sounds great.

That's the idea. Except eul is going to be a bit easier to use with everything working right out of the box.

>Downloading embedded web browser

Is it used only for authethication? Can a native web view used anyhow (electrino)?

It's only for authentication.

Glad I'm not the only one. For a messaging app it does the whole messaging part pretty poorly. Typing often becomes very laggy. And this is on a fully loaded MBP. I have a feeling it has to do with rich links. Noticed that chats with a lot of them over time become harder to use.

It's unrelated. We're trying to track it down still. Sorry about that

I'm sorry you have such a painful bug, that must be frustrating. Here's hoping you get it soon :)

That’s great to hear, and glad the team is working on it! Thanks!

How can you know something is unrelated and yet still be trying to track it down? Are you running two versions of the code, in production, where this live action comparison is possible? Because if not this response reeks of Google/Microsoft engineers who always shift the blame.

It's not the Reason sections; if you've seen BuckleScript's output you'd know that the JS artifacts are almost like hand-written code. I've checked almost every diff.

Not sure how much I can say, but the leak is somewhere in the subscriptions, which isn't in Reason. Ironically the goal is to convert that section to Reason so that refactoring can finally be done (I've left that part out of the blog post just in case). Messenger produced the grandfather of Flux; it's not the easiest thing to refactor.

Proving that a given error isn't caused by X is a very different matter from working out what does cause it, and even after that, fixing it is another matter again.

What is the last part of your comment in reference to?

Try having an issue with Google or Microsoft services and get back to me on that.

I really wish it didn't have any sort of logic around checking the user agent. I often spoof mine and it's annoying when messenger.com doesn't load because of it.

What do you spoof it to?

All sorts of crap. Since I'm on Desktop I don't select any mobile browsers. Firefox on Linux, etc.

What's your actual browser? The most common cause I can think of would be if we think you have a newer browser than you do and serve you too-new code as a result. If that's the case, using an older version in the string might help.

Is there a reason you guys are doing UA sniffing instead of a Modernizr-esque strategy? Would it have too much of a runtime cost? Or is it just about syntax and serving a transpiled blob would make it bigger? Genuinely curious

We do this both for polyfills and for different compiled code in some cases. Since we need this on the first request (and care about perf on that first request), it's less practical to use JS to decide. User-Agent works well in practice.

Chrome Version 60.0.3112.113 (Official Build) (64-bit)

Windows 10

You're correct. It performs terribly. On my 2016 macbook it takes 20.48 seconds just to load the interface from refresh according to Firefox devtools. Yes, a lot of this is network traffic. It's still terrible for a chat app. I have PS4 games that start in 20 seconds.

This is weird. I was skeptical at first, because I could have swore it wasn't this inefficient, but then I just went there and experienced similar results on a 2016 chromebook; 19.83 seconds.

Could it be all the separate CSS files they're linking?