01walid

How does this compare to Tauri ?

Edit: it looks like it leverages its own Webkit for the frontend, but then how is this more efficient than Electron ?

Windows XP Delta Edition

Windows XP Delta Edition

Windows XP Delta Edition

Windows XP Delta Edition

Windows XP Delta Edition

Windows XP Delta Edition

Windows XP Delta Edition

How does Krita compare to Gimp at this point?

(Since someone on the comments here said it can be a Photoshop drop-in replacement)

Can it talk to a GraphQL backend ?

For a second I thought this is a WebAssembly app :)

Nice job!

No. Explicit is better than implicit.

Would you get the merge conflict if you mark the *.png extension as 'binary' in .gitattributes?

How does this compare to CockroachDB?

I'm wondering what's the position of Amazon Lightsail in all of this ?

Is it exempted?

Interesting, but -from the repo description- why this is limited to Go source code files?

That is why I do not use Slack for Desktop, and just keep a pinned tab of Slack open almost all the time. I also tend to reduce my usage of any Electron-based app because I want to better make use of my laptop resources in my development workflow requirements.

I feel like I agree with most what's said there, the same would apply to NW.js and the likes.

This should be a heads up for GUI developers to [re]consider Qt and QML. It made real progress in the last few months. and there are some nice bindings to it.

Oh right, almost forgot that..

dumb question: will qtdeploy produce a single static binary for the whole app or is about some other sort of shared libraries deployment ?

That's why I posted this, too many people would be affected by such regression. And would prefer sticking to Go 1.7.x

Please see my comment above...

I really disagree, RTL should be defined in Markdown,.. as the ZEN of Python says:

"Explicit is better than implicit."

this is a case where indicating RTL should be done explicitly, letting the parser/browser or whatever do the work still won't help. Why?

think about a mixed text of one sentence/line where there's only one word in Arabic at the beginning and the rest of it is Latin... the browser/parser or whatever will think of it like LTR text because the sum of latin words > sum of Arabic words. which is False.

A live example of this is Facebook. it does actually a Layout detection based on the content's language in comments. but it sucks in many cases. try to write a comment in Arabic with a mention of someone's name (the name in Latin) to see what I mean.

so IMO, neither dir='auto' nor the parser can detect this implicitly, we still don't have the AI for smarter detection, even if we have, there are cases where you want RTL regardless of the content. thus it SHOULD be defined in Markdown.

Since when Markdown was just about ASCII text ? then we can't write French, Arabic, Chinese using markdown ?

my whole point is to define a syntax indication in the specs on how RTL elements should be identified when converted to say HTML. when converted, THAT element (or the whole document) would contains dir="RTL" attribute in its tag.

for example, something like this:

<-rtl--

Foo

Bar

would convert to:

<p dir="rtl">Foo

Bar

</p>

Prettifying won't help... RTL elements/document should be indicated in markdown

No. It won't just work, it's even shown on your comment how awful it is.

To understand what I mean, try to inspect your comment, add `dir="rtl"` to the <p> tag of the Arabic text...

How a group (of whoever they are) claim they're the standard about something in nowadays without even caring about localization ?

2 years of 'complete specs' without a mention for RTL and how it should be supported/written in markdown....

A bit disappointed tbh... even though it's a nice initiative...

There's a typo in the about page: "you're application"...

also there are no contact information (email?)

Simple idea, nice hack, I think some people will find this very useful!