Tuberculosis-resistant cows developed for the first time using CRISPR technology - <AUTHOR> http://sciencebulletin.org/archives/9946.html <comment><USER2> Cows have a protein in their white blood cells helps to make nitric oxide (a molecule very toxic to bacteria, including tuberculosis). It has been shown in other instances that if you have more of the protein (NRAMP1), then you tend to be more resistant to tuberculosis, and less of the protein, then you are less resistant to a tuberculosis infection. The protein itself is a transmembrane iron transporter. It just shuffles iron from one side of the membrane to another.

Cows already have the dna that encodes for NRAMP1, but in order to demonstrate their prowess with CRISPR technology, this group found a dormant location in the cow's genome in order to insert DNA that encodes a second copy of the same protein. The expectation being that by having a duplicate copy of the DNA that encodes for the NRAMP1 protein, more of the protein would be produced, and the cows would be less susceptible to tuberculosis. This seems to have been the case.

So here, adding DNA encoding a protein that already existed in the cow's genome allowed _more_ of the protein (NRAMP1 - an iron transport machine) to be produced, thus conferring some tuberculosis resistance by means of allowing the cows white blood cells to produce nitric oxide more efficiently.

</comment><comment><USER3> Related article:

[http://gizmodo.com/the-fda-is-cracking-down-on-rogue- genetic...](http://gizmodo.com/the-fda-is-cracking-down-on-rogue-genetic- engineers-1791760888)

 _" Ishee was preparing for a project that sought to cure hyperuricemia in Dalmatians—a common liver malfunction that frequently results in kidney stones, bladder stones or gout.

"It should be straight forward," he told Gizmodo. Ishee plans to use the gene- editing technique CRISPR to correct the single errant nucleotide that causes the condition, reversing the mutation to turn a T in the genetic code back into the correct G. Then he'll use a technique called sperm-mediated gene transfer, which will allow him to transfer his engineered Dalmation DNA to a female Dalmation, resulting, he hopes, in a fertilized egg that'll produce hyperuricemia-free pups.

"The animals just get molecular surgery to fix a broken gene that causes their bladders to explode," he said. "Then those animals can become the founders on a healthy generation of Dalmatians and breed the disease away in a few years.""_

<comment><USER4> If it's such a simple genetic flaw, why isn't marker assisted selection breeding used to eradicate the problem? Such a thing could even easily be mandated by law.

<comment><USER5> It might be coincident with desirable traits.

</comment></comment></comment><comment><USER6> Tangent: This is nice popsci reporting. Reasonable, not very hyped, contextualized laymen explanation of a technical paper, with a link at the bottom direct to the source.

</comment><comment><USER7> One interesting thing about what they did was they assayed potential insertion sites with ChIP-seq to see how much off-target effects there are. They used a catalytically inactive cas9 for IP to see the quantity and strength of off- targets.

</comment><comment> guard-of-terra While they're at it, they might also make milk not burn-prone.

I've read there's a single base that makes cow's milk to behave like that.

<comment><USER2> Do you happen to know which protein?

<comment> guard-of-terra β-Lactoglobulin.</comment></comment></comment>


Draft House Language Seeks to Halt Air Force Atlas 5 Launches This Year - <AUTHOR> http://aviationweek.com/blog/draft-house-language-seeks-halt-air-force-atlas-5-launches-year

<comment><USER2> So, the US Government encourages the partnership that resulted in these engines in the Atlas V and now they are worried. I guess we got a good deal on the engines[1] though.

1) [http://www.nycaviation.com/2011/05/russia-accuses-rocket- eng...](http://www.nycaviation.com/2011/05/russia-accuses-rocket-engine- builder-of-selling-to-united-states-below-cost/#.U16Gbl5cI1c)</comment>


Hulu Owners Cancel Plans to Sell Company - <AUTHOR> http://blog.hulu.com/2011/10/13/hulu-equity-owners-announce-decision-to-terminate-the-hulu-sale-process/

<comment><USER2> Not exactly worth of a post on its own so I'll put it here for fellow HNers in Japan:

[http://www.engadget.com/2011/09/01/hulu-launches- streaming-i...](http://www.engadget.com/2011/09/01/hulu-launches-streaming-in- japan-for-about-20-us-monthly/)

I'm taking advantage of the 1-month free trial and enjoying Twin Peaks.

</comment><comment><USER3> Hulu is a well designed and great product. That said, hulu's value is its content not its backend and community. The only reason to buy hulu would be if it came with streaming rights that were more valuable than the purchasing price.</comment>


Reboot – conference for failed startup founders - <AUTHOR> http://www.rebootconf.com <comment><USER2> Failure is bad. No one really works to fail, but if you're an entrepreneur slogging away at your business, there is a high chance that you've encountered the dreaded F-word. In India, its even worse because failure is looked down upon and even the closest ones begin doubting you.

Failure is hard. Failure is tough. But its also an essential part of what makes you an entrepreneur. It make you learn from your mistakes and move on.

At RebootConf, we're not just embracing failure, we're celebrating it. We're inviting 30 entrepreneurs across our chosen themes for a one day event, to talk about their mistakes & failures.

Come join us and see the difference!

</comment><comment><USER3> On behalf of the regular HN reader community, I apologize that you haven't received any warmer welcome. I know how tough it is to have your startup fail and to even just open up and talk about it with people you don't know. I see the beauty of how Reboot can create an avenue of shared learning to help entrepreneurs move forward. Best of luck to you guys and kudos for the idea!

<comment><AUTHOR> Thanks! Your kind words would inspire others to have a look and make them think.

Our intention is to celebrate the attempts, without them the winners cannot exist!

Please do help share the idea with others.

</comment></comment><comment><USER4> > Just, hard lessons.

This is rather bad grammar. :(

Perhaps you might mean "Just hard lessons."

Good luck with the conference!

<comment><USER5> Jesus really?

<comment><AUTHOR> Appreciate the support sir!

No offence taken here. We all have our pet peeves :).

</comment></comment></comment><comment><USER6> This conference will....

<comment><USER7> FAIL :)

<comment><AUTHOR> LOL, as will most startups ;).

Thanks for having a look!</comment></comment></comment>


Show HN: RESTfender – Connect and secure your IoT devices - <AUTHOR> Hi HN,
I'm Jay and my cofounder and I have been working on RESTfender to help connect and secure IoT devices.  Would love to hear feedback.  While there are some IoT platforms out there, we're focusing primarily on the problem of botnets and managing devices. We use machine learning to track and automatically categorize bots.
The app: https://app.restfender.com Website: https://restfender.com
IoT Camera example: https://iot-cam.restfender.com (the goal is to find a place to attract more attention like a bird nest, hamster on a wheel, hummingbird feeder, etc.) <comment><USER2> Jay, sorry to say this, but I don't get your product. I'm coming from the IoT space myself and I'm having trouble understanding what your offering is. Is it a reverse proxy for my home IoT devices so I don't have to expose them via PortForwards? If yes, how does that work?

<comment><AUTHOR> Thanks for the question. Slowly adding details on the website and how it works. Yes it is a reverse proxy. We have a python sdk that you use to connect your device to our platform.</comment></comment>


'Trustjacking' Could Expose iPhones to Attack - <AUTHOR> https://www.wired.com/story/trustjacking-ios-itunes-wi-fi-sync-attack/ <comment><USER2> Wow</comment>


Making Advanced GUI Applications with Godot - <AUTHOR> https://medium.com/swlh/what-makes-godot-engine-great-for-advance-gui-applications-b1cfb941df3b <comment><USER4> If you want to use this in a business, either for an internal tool or for an application you sell, this is a horrible idea.

Godot doesn't display native widgets, so it has no support for accessibility, for example to screen readers and blind users. Some people think blind people bring too little profit to care, but this is wrong for one single reason. There are some laws mandating accessibility, and more laws are being passed, for example in the EU. Even if you don't really focus on accessibility at this point, you always want to keep your options open, in case the law forces you to. If you choose Electron, WX or even QT, some minor tweaks will usually be enough to make it right. If you choose Godot, you will need to rewrite the whole thing from the ground, which might kill your business, or risk fines and litigation, which might also kill your business. This is even true about internal tools, as there are laws mandating accessibility of the tools used at the workplace, and you never know when a blind person gets hired for a job they theoretically should be able to perform.

This might sound very harsh, but it's important to get this right early, as one bad decision here is usually irreversible. Of course, this applies not just to Godot, but to any GUI tool which doesn't implement accessibility properly (including those that theoretically work on the web, but use canvas instead of DOM rendering).

<comment><USER5> Are you speaking out of professional experience? Do you _know_ of cases where not implementing accessibility really did become a big financial hazard?

Imagine the headline "company goes bust due to regulatory violations after hiring blind person". That would basically be sending the message "never hire a blind person", because no company can ever be sure to be in compliance.

<comment><USER6> You don't need to hire a blind person to be compliant with regulations. What if you are building consumer facing products? Can you pick who your consumer will be? What stops a blind person from using your product? And what if the user is suffering from another physical disability which doesn't let the user operate a keyboard/mouse? What if the employee were a medically fit person but met with an unfortunate accident and lost his/her eyesight/limb and have to now continue job after recovery? How can s/he continue their job? Will you fire the person? You never hired a physically challenged person but s/he can always become physically challenged due to some accident later.

> Do you know of cases where not implementing accessibility really did become > a big financial hazard?

"Jason Camacho, a blind resident of Brooklyn, N.Y., is suing 50 colleges over the accessibility of their websites.

The 50 lawsuits, filed in November, say the colleges are in violation of the Americans With Disabilities Act, as their websites are not accessible to people with disabilities. Camacho uses a screen reader and said he experienced barriers when trying to access the colleges' websites."

Source: [https://www.insidehighered.com/news/2018/12/10/fifty- college...](https://www.insidehighered.com/news/2018/12/10/fifty-colleges- sued-barrage-ada-lawsuits-over-web-accessibility)

<comment><USER5> > What if...

What if tomorrow some change of parameters makes my business impossible? I'll go out of business. That's always an option.

Dealing with _every possible risk_ ahead of time generally isn't an option.

> "Jason Camacho, a blind resident of Brooklyn, N.Y., is suing 50 colleges > over the accessibility of their websites.

This is referring to public websites, which arguably are covered by the ADA.

I'm looking more of a story like "We wrote all our software without regards to accessibility. Then we got sued. It bankrupted us."

If this was a real problem for software in general, why is there no cottage industry of shady lawyers using people with disabilities to sue software vendors in particular? There's obviously lots of software that is not accessible, or not accessible enough.

<comment><USER6> > What if tomorrow some change of parameters makes my business impossible? > I'll go out of business. That's always an option.

Yes and no one can sue you for going out of business. But you can be sued for violating a law while your business is in operation.

> Dealing with every possible risk ahead of time generally isn't an option.

No you need not if you use standard software development tools that do it for you. You would need to worry about it if you plan to implement everything on your own.

> If this was a real problem for software in general, why is there no cottage > industry of shady lawyers using people with disabilities to sue software > vendors in particular? There's obviously lots of software that is not > accessible, or not accessible enough.

When there is a clear law that states that you have to make your software accessible you have no choice but to implement accessibility. For personal use you need not. For open source projects, the implementation rests on the shoulders of those using the project for end-user facing software. You can get away with it for a while, just like you can get away with using pirated software. But then law will catch up anyways. Just because there is no precedent set doesn't mean that it is legally allowed. Would you want to be the first test case? A scapegoat? I bet not!

As far as why there are no cottage industry of shady lawyers: Maybe those shady lawyers have bigger fish to catch. Maybe there isn't much awareness about it in the legal circles. Could be variety of reasons why.

<comment><USER5> > No you need not if you use standard software development tools that do it > for you.

The belief that you just need to use "standard toolkits" and accessibility "just works" is wrong.

> When there is a clear law that states that you have to make your software > accessible you have no choice but to implement accessibility.

There is no law that mandates implementing accessibility for all commercial software.

> As far as why there are no cottage industry of shady lawyers: Maybe those > shady lawyers have bigger fish to catch. Maybe there isn't much awareness > about it in the legal circles. Could be variety of reasons why.

...or maybe the law doesn't actually say what you think it says.

<comment><USER6> > The belief that you just need to use "standard toolkits" and accessibility > "just works" is wrong.

Toolkits provide you the tools to do accessibility right. Toolkits don't do your accessibility for you. That is the biggest difference. You just misunderstood what I said.

> There is no law that mandates implementing accessibility for all commercial > software.

Wrong! It applies to all software. Period.

"The Department of Justice (DOJ) published the Americans with Disabilities Act (ADA) Standards for Accessible Design in September 2010. These standards state that all electronic and information technology must be accessible to people with disabilities.

The ADA differs from Section 508 regulations, which are an amendment to the Rehabilitation Act of 1973 and apply to all information technology, including computer hardware, software and documentation."

In fact, the DOJ clarifies it further that accessibility is paramount and that even though the regulatory process isn't complete on paper doesn't mean that the software should remain inaccessible in the meantime.

'"The Department is currently developing regulations specifically addressing the accessibility of goods and services offered via the web by entities covered by the ADA. The fact that the regulatory process is not yet complete in no way indicates that web services are not already covered by title III."'

Source: [https://www.interactiveaccessibility.com/services/ada- compli...](https://www.interactiveaccessibility.com/services/ada-compliance)

> ...or maybe the law doesn't actually say what you think it says.

It does. Read it.

</comment></comment></comment></comment></comment></comment></comment><comment><USER7> I did an Ask HN [1] about this topic a little while ago.

Most relevant comment [2], from gunibert is here:

The problem in a framework like GoDot is, that it is meant for Games. A game renders screens in 30/60 fps. A Desktop application like a Gtk application does exactly nothing if you dont interact with the application. If you click a button only the button gets re-rendered. This is more efficient then using something like a game engine which has no concept about damaged regions and so on.

Also, people like to have something like "native" look and feel. This would be possible with Java-SWT as it abstracts away the toolkit. This is possible but in the case of SWT it is just broken (think about margins, text, scroll behaviour).

The other option is to use electron as it is just plain simple, works even in the web (you can basically make a webapp and repackage that as an electron app)

Or you package a toolkit with your application and avoid native libraries. This happens in the world of Qt for example. Gtk is cross-platform too but not statically linkable.

[1] [https://news.ycombinator.com/item?id=23580213](https://news.ycombinator.com/item?id=23580213) [2] [https://news.ycombinator.com/item?id=23584258](https://news.ycombinator.com/item?id=23584258)

<comment><USER8> As mentioned in the article Godot has a low processor usage mode:

> If true, the engine optimizes for low processor usage by only refreshing the > screen if needed

[https://docs.godotengine.org/en/stable/classes/class_os.html...](https://docs.godotengine.org/en/stable/classes/class_os.html?#class- os-property-low-processor-usage-mode)

<comment><USER9> Why would any engine re-render if it's not needed? It will still have benefits even on desktops.

<comment><USER10> I think mostly because having scads of clever conditionals all over the place _greatly_ increases the risk of subtle and hard-to-reproduce bugs. From a 2007 Carmack email [1] :

> _The way we have traditionally measured performance and optimized our games > encouraged a lot of conditional operations -- recognizing that a particular > operation doesn 't need to be done in some subset of the operating states, > and skipping it. This gives better demo timing numbers, but a huge amount of > bugs are generated because skipping the expensive operation also usually > skips some other state updating that turns out to be needed elsewhere._

> _We definitely still have tasks that are performance intensive enough to > need optimization, but the style gets applied as a matter of course in many > cases where a performance benefit is negligible, but we still eat the bugs. > Now that we are firmly decided on a 60hz game, worst case performance is > more important than average case performance, so highly variable performance > should be looked down on even more._

There was fascinating breakdown [2] of a single GTA V frame about five years back. It was a real eye-opener for me - whole full-screen rendering passes for things like water reflection and refraction when there isn't even any water visible in the scene.

[1] [http://number- none.com/blow/john_carmack_on_inlined_code.htm...](http://number- none.com/blow/john_carmack_on_inlined_code.html)

[2] [http://www.adriancourreges.com/blog/2015/11/02/gta-v- graphic...](http://www.adriancourreges.com/blog/2015/11/02/gta-v-graphics- study/)

<comment><USER11> Also, modern processors might run the code anyway and trow away the path not taken. Its better to optimize by generating a function that does not have branches.

<comment><USER10> I don't think that applies to conditional rendering, does it? You can't speculatively execute a graphics API command buffer submission and then dash after it shouting "wait, come back, I didn't mean it". Same with any kind of I/O, I'd think.

<comment><USER11> You are correct. But the same strategy can be used for optimization. Eg. get rid of the whole if block, and preferably dependencies to make it pure so that it can be further optimized by caching the output. Although cpu can be faster then cache so always measure.

</comment></comment></comment></comment></comment></comment></comment><comment><USER12> QtWidgets works really hard to try and remain native (both by reusing the platform window pointers, and mimicking style and functionality). That for me is worth it. While the article constantly complains about dev tooling size, a reasonable complaint, my DLLs I ship w/ my Qt program are just 20MB (so I'd suspect a similar size increase to a single binary were I to statically link). If I didn't care about native look and feel I might have gone GTK3 (absent from the comparison here).

Having said that, the other issues concerning Qt may be valid, but for a code- only set of widgets, they work for me. For these kinds of comparisons to have value, you have to list the pros and cons of all things, not just the pros of what you like and cons of what you don't.

<comment><USER13> It's odd to see the "just 20MB" phrasing. I guess even native applications have expanded to the point where 20MB seems small, but in absolute terms I still consider that quite large --- to put things into perspective, _a full installation of Windows 3.11_ , the OS with all of its included applications, is less than 20MB.

I wonder if, in another 20 years, we may see people speaking of "just 20GB"...

<comment><USER14> I think this is in comparison with 200M+ Electron executable, which is nowadays bundled with almost every 'native' app.

Do you want to flash image to USB drive? There is Electron app (balenaEtcher) for that.

Do you want to control your mouse/keyboard? There is Electron app for that (Logitech GHub), which also includes many Qt libraries.

Do you want a terminal emulator? There is an Electron based app for that.

...

<comment><USER15> It's unfortunate that traditional desktop GUI frameworks are such an abysmal developer experience that everything from FOSS made by 1 person in their spare time to the cornerstone of multi-billion dollar companies choose to embed a web browser into their desktop app instead.

Qt is the best I've seen, but it has the normal c++ FUD plus the infamous licensing FUD.

And honestly, I'll have to admit that how react models GUIs is a really attractive.

<comment><USER16> > Qt is the best I've seen, but it has the normal c++ FUD

Not sure what you mean exactly; C++ is complex, but why the fear and doubt?

Also - Qt is based on veeery old C++ - a 22-year-old standard. The language has changed significantly since then, while Qt's fundamental design (in terms of programming) - not really, or not much. So, Qt is not "normal C++" these days.

<comment><USER17> Simply add [https://github.com/woboq/verdigris](https://github.com/woboq/verdigris) so you can use C++ ≥ 14.

<comment><USER18> The moc is not the issue. The biggest design problem with Qt is that it predates move semantics. That history affects the design of almost every class.

It feels like a beautiful old walking path that detours around a wall that's long since been torn out. It's still fine... but... it's not how you'd design it if you were to start from scratch.

</comment></comment></comment></comment></comment></comment></comment><comment><USER19> I did a lot of tutorials on my YouTube channel on how to start making GUI applications with Godot. The visual scripting is really bad for now, so I would stick with GDScript (a Python like language) or C#. It is really a great piece of software to make something quick for non-technical people. I really recommend anyone to explore and play with it a bit and I'm sure you'll find a use for this amazing engine.

<comment><USER20> > visual scripting is really bad for now

Are there any visual scripting languages that aren't terrible? The system in unreal works but every time I use it I find myself wanting a text editor (I have spent years learning to program well, be that C++ or shaders, just let me do that!).

<comment><USER21> If it's general purpose, then I agree that visual languages always seem to be an annoyance. If it's domain-specific, that's another story, since many domains are all about connecting blocks together. The most common use case is audio/video signal processing, where it works well if you're working above a certain level of abstraction.

<comment><USER22> Indeed, I've had mostly positive experiences with Isadora in the audio/video signal processing visual scripting space.

</comment></comment></comment></comment><comment><USER23> No mention of overdraw, pixel perfect rendering, layout performance, power consumption, view recycling/scrolling, or render caching (caching the composition result).

Does Godot handle this stuff well? I have no idea. I wish the post did a better deep dive. I know Unity doesn't compare well to the native APIs in these regards.

</comment><comment> yoz-y In part criticizing SwiftUI:

> While you get a GUI inspector panel for your GUI components you are still > forced to largely write the GUI in code.

Well yes. The time and experience (at least for me) has shown that designing UIs anywhere outside the code will eventually bite you. Not to mention that from the very moment a second person joins your team you can practically throw your version control system out of the window for UI files. Thanks but no thanks.

<comment><USER24> Interface Builder is all fun and games until you have a merge conflict in a storyboard. It's all XML files so you'd think it'd be solveable, but SwiftUI makes the code representation so much more readable.

And really, you can drag and drop elements into the live previews and it writes the code for you, including automatically wrapping existing components in horizontal/vertical stacks as needed to arrange the layout. So SwiftUI still has some of the visual UI editor benefits, just broken into smaller pieces with a much more useful text representation.

<comment> yoz-y Exactly. For maintainable code I think this is the way forward.

</comment></comment></comment><comment><USER25> I like the concept, but you're starting your development by throwing out the native UI components, along with all the accessibility features, keyboard shortcuts, and other features that go with them.

A search about accessibility immediately popped up github issues acknowledging the difficulty making screen readers work: [https://github.com/godotengine/godot/issues/29736](https://github.com/godotengine/godot/issues/29736)

There are some applications that mimic all those friendly native behaviors, but it tends to take a lot of work, and sometimes pushing updates when the OS behaviors change.

</comment><comment><USER26> Yeah no kidding, choosing a GUI framework is pretty difficult task... all of them suck for a different reason :-).

I'm using cljfx these days and really enjoying it. For desktop apps I think it is a great choice [1].

The approach described using Godot could work well depending on the type of app, I think. For instance, this commercial app [2] is built using Kivy [3], which basically draws the controls using sdl+openGL, so a similar kind of setup as the Godot one described in the OP.

1: [https://github.com/cljfx/cljfx](https://github.com/cljfx/cljfx)

2: [http://www.yeco.io/](http://www.yeco.io/)

3: [https://kivy.org/#gallery](https://kivy.org/#gallery)

</comment><comment><USER27> Several years ago using Unity3d to make an advanced cross platform (half business half industrial) GUI was an excellent experience and result. So yes, I readily believe modern game engines are good for cross platform GUIs and may conquer a niche here.

</comment><comment><USER28> This is such a bad idea. Try adding a line editor. Now try typing anything that is not ASCII or an emoji. Suddenly you'l see why you generally do not want to use a game engine for a tools.

Even the Godot editor itself is not non-English friendly. It's got a horrible experience for any language that uses an IME. If you try to insert an emoji on Mac the IME won't even appear.

<comment><USER29> Assuming that is true, it is an oversight. There is no actual technical limitation.

I am confident if Godot sees usage as a GUI/app framework, they will take care of that.

<comment><USER30> Surprisingly, they won't.

Text input and manipulation is so incredibly ugly and hard, that basically nobody cares it enough to to it really well.

Unicode to start is complicated. Then you have things like bidirectional text.

Line breaking is complicated.

There are no accepted practices for a lot of use cases.

Hyperlinks. Embedded content like images.

Copying/inserting html and other formats.

Styling content.

Rendering 100 000 lines of styled content without screwing up user input.

Line-heights. Tabs. Font definitions that are ambiguous an inconsistent (a lot of font tables today still don't provide enough space for accents on capital letters, think Swedish - so you have broken looking text or have to 'fake it'). Screwed up Kerning tables.

No established standard for real pixelation and rendering - zoom in and you'll see font's can be rendered a variety of ways.

Emojis, fat finger cursor navigation on mobile devcies, input managers.

It's hard to describe how messy it gets because none of it is academic, it's not some scary-hard algorithm - it's just an incredibly ugly pile of cross- cutting code with a zillion little bits and pieces of corner cases.

And a big one for gaming engines: they don't render text 'natively'. You basically have to create textures. Every big of text, it's own texture. How big is the texture for 100 000 lines of code? Big.

This is actually one are where Qt falls flat. In the 'new and improved' Qt, they do everything in the GPU, if you try to load 100 000 lines of something the app will use up 1G of memory and puke. So then you have to magically code your way around it.

All for what? Why would you want to render text in a _gaming_ engine in the first place ...

Then you discover that 'apps' and 'games' are really different things, and they use different tech for good reason. It only gets ugly when they really have cross paths.

<comment><USER29> Nobody is saying Godot should implement their own text engine. There are several available ones they can use, or just pick whatever the platform offers.

> Why would you want to render text in a gaming engine in the first place ...

Just about _every_ game needs text, including Unicode text. Every proper engine handles it.

<comment><USER30> " just pick whatever the platform offers."

The platform does not offer anything.

"Just about every game needs text, including Unicode text. Every proper engine handles it"

No, what they do is paste a few characters on screen, handling a more common subset of Unicode. They don't come close to handling most of the things I described above.

Not even Qt handles text well - Qt allows you to do some fun 3D things with text, but not you can't open 100K lines of formatted code like VSCode.

Webkit is just as bad - MS had to invent 'Monaco' a huge layer on top to be able to manage text properly and it's kind of a hack.

Simply put nobody does it well out of the box.

<comment><USER29> > The platform does not offer anything.

All major platforms offer advanced text rendering support.

How do you think Windows or macOS render their UI?

> what they do is paste a few characters on screen, handling a more common > subset of Unicode.

 _Some_ games do that, in particular old ones or indies. Most games do actual text rendering properly.

> you can't open 100K lines of formatted code

You definitely can, but not naively. VS Code doesn't render all the text at once either and neither does any serious text editor.

<comment><USER30> "All major platforms offer advanced text rendering support."

No, they don't realy.

I think you're missing a few pieces in your understanding of what the platform does in these contexts

The platform does not support text rendering for Qt and such platforms. They are rendered 'from scratch'.

Some platforms offer some built in components, but even they are quite limited.

No platform offers the ability, out of the box, to do for example, a 'coded editor' with properly highlighted syntax. Not even close.

"Most games do actual text rendering properly."

They are 'rendering text properly' for the extremely limited subset of text that they put on the screen.

Have you ever used even a basic 'text editor' in a game? No? Because they don't even do that.

" you can't open 100K lines of formatted code"

"You definitely can, but not naively."

'Natively' means nothing on the context of 'browser'. If you mean to say 'the browser doesn't do it out of the box' \- then ok, yes, we agree. And why not, because it's extremely hard?

There are 0 comprehensive text APIs that are built upon gaming or even 3D engines today. Most of the barely handle basic text formatting. They put a few lines of text on the screen in a limited number of languages, and that's it.

There are very, very few platforms that offer comprehensive text rendering, including Qt, GTK, and native platform components - they're basic.

Providing comprehensive text API is not only something that has to be layered on top of those things - they also have to 'hack' those platforms to work around inherent bugs and limitations.

</comment></comment></comment></comment></comment></comment></comment><comment><USER31> Nice post. I look forward also to a future where Godot helps facilitate VR (office) applications as well.

We have developed SimulaVR ([https://github.com/SimulaVR/Simula](https://github.com/SimulaVR/Simula) \-- a Linux VR Desktop) on top of Godot, and I think there's a lot of potential for this in Linux.

</comment><comment><USER32> Godot is an incredibly good piece of technology, made by fantastic people.

But I'm not sure that I can echo the sentiment here exactly. I took the time to read the entire article.

This is what it boils down to for me:

IF you are going to build a native desktop app with a drag-and-drop WYSIWYG editor, I think it's arguably a solid choice over QT or whatever else you might do it with.

But the latter part of the article focuses on the argument against using web technologies:

      > My discussion of Web technologies needs some disclaimers. I have little experience with web technologies, and I am not very fond of web technology. I am an old school GUI toolkit guy, who did his first GUI stuff using the Intuition toolkit on an old Amiga 1000.

      There are a couple of really big problems I see however:

      2. It was made for web pages not applications. When trying to make a GUI for an application I found that I so often hit on the limitations imposed by the assumption that we are in some scrollable webpage.

      3. It is not made for reusable components, like real GUI toolkits.

From time to time, I hear this argument about how because web applications are run on the web, they're somehow fundamentally different from an application that might run on your phone or desktop natively in terms of appearance or UI capabilities.

It's all pixels on a screen. Any design asset you can whip up, with whatever animations and effects, can be rendered identically on a web, or native mobile/desktop app.

And modern web applications are entirely made of reusable components and the principles behind them.

I like to think I don't say without some perspective -- some of the first applications I ever wrote were VB.NET apps in Visual Studio 2007 using Windows Forms.

But today the idea of saying "An app made with web technologies cannot look or function quite like a native desktop app, and it lacks reusable components" is a bit wild.

Can you imagine trying to build <insert omnipresent application>'s desktop client with a WYSIWYG.

Finally, will conclude the rant here -- author talks about how Godot's 30MB compressed/70MB uncompressed size is fantastic, but with Tauri you can build native desktop apps using HTML/JS in 1-2MB.

[https://tauri.studio](https://tauri.studio)

<comment><USER33> > It's all pixels on a screen. Any design asset you can whip up, with whatever > animations and effects, can be rendered identically on a web, or native > mobile/desktop app.

The issue is that no one bothers to do all the OS integrations you get for free when you make a native app.

Also, every web app I've used that pretends to be a desktop app has issues that make it feel off. Using Discord as an example; I have to focus the title bar before I can use the minimize/maximize window buttons - unlike every native macOS app. I run into this almost every day.

I'm not denying that web applications are useful, but if you want something really high quality, native is the only solution in my opinion.

I was hopeful that web applications could offer a really great way to make cross-platform applications. After trying some frameworks out, and following the web standards more closely, I'm pretty pessimistic. The complexity of web browsers is out of control and I don't think they'll ever be comparable to native apps.

<comment><USER34> The funny thing is, I often prefer Web/Electron apps for the simple reason that zoom always works and it always works the same way. It's hit and miss with desktop/mobile apps.

</comment></comment></comment><comment><USER35> This just reads like a godot advertisement...it only has good things to say about godot and only bad things to say about any other library. It's really hard to take the article seriously with so much blatant bias. It also seems to leave out any technical information that a developer using the engine would want to know, like how well it integrates with existing code, what paradigms it uses compared to other UI engines, or whether it uses lazy rendering or if it constantly runs at 60fps, etc.

<comment><USER36> I made this comment when someone was talking about using GLFW and IMGUI to make an application with a openGL window and I think it applies here too, because it is easy to overlook the things that you will eventually need that are not trivial to add once you go down the road of using tools made for only very basic UIs.

"I would bet that the easiest thing would be FLTK. You can use system colors and make an openGL window while having everything else you would expect in a UI library. Executables with no dependencies start at a few hundred KB and it is very fast. There is even a single big pdf for documentation and dozens of examples that show off every widget. FLTK is very underrated these days because no one is out there marketing it.

GLFW and IMGUI are great libraries, but once you start wanting a program with various modal and non-modal windows, menus, widget layout, a native look, file dialogs, fonts, drag and drop, copy and paste, unicode, spreadsheet tables, physical printing, custom widgets, functions to hide OS specific system stuff (like stat, directory listing etc.) you might wish you had started with something made for what you are trying to do. "

<comment><USER37> Unfortunately, FLTK falls short in at least one important way: it doesn't implement accessibility, e.g. for blind users with screen readers. Godot and immediate-mode GUIs have the same problem.

If I'm not mistaken, the most lightweight cross-platform UI toolkit that draws its own widgets (unlike wx or SWT) and implements accessibility is sciter [1]. It's a good thing the antivirus vendors (who seem to be sciter's biggest customers) want to sell to governments.

[1]: [https://sciter.com/](https://sciter.com/)

<comment><USER38> > it doesn't implement accessibility, e.g. for blind users with screen > readers. Godot [has] the same problem.

Yeah, this is currently a valid criticism--it's an aspect I'm hoping will see more development attention in the future.

I did recently discover this project which is working on improving the situation: [https://github.com/lightsoutgames/godot- accessibility/](https://github.com/lightsoutgames/godot-accessibility/)

</comment></comment></comment></comment><comment><USER39> MaterialMaker [https://github.com/RodZill4/material- maker](https://github.com/RodZill4/material-maker) is also made in Godot :)

</comment><comment><USER40> It's not the world's best WYSWYG editor but it sure is a WYSWYG editor, with cross platform exports. You can even write your apps in C# if you want.

<comment><USER41> And using C# gives you the added benefit of the rest of the C# ecosystem. You can use Nuget right in the VS solution file Godot generates to import whatever you like.

</comment></comment><comment><USER42> I think Lazarus is a much better environment for creating desktop apps which are small, cross-platform and very fast. The component architecture is much more advanced than Godot and you have access to a huge number of components. Extending these components or creating new components is also very easy.

<comment><USER43> Don't you have to use Pascal for that, though?

I'm sure the tooling is better by now, but I remember being pretty happy not to need to touch Pascal anymore by the late '90s. The APIs that expected Pascal conventions were often pretty miserable to use.

<comment><USER42> Yes, you do need to use Object / Free Pascal but it is actually quite a nice language and you can interface with C libraries quite easily

<comment><USER43> That's good. Converting between pascal and C calling conventions is one part of the 1980/1990s that I have absolutely zero desire to revisit.

I do recall that some of the Object Pascal class hierarchies that got developed were quite nice, and I am glad to hear there's more development continuing that direction.

</comment></comment></comment></comment><comment><USER44> How would this work on 2 or 3 monitors. Asking this, since any serious content creator tool end up using windows across monitors, and there you need good docking support.

Qt has some, but not all the way there, like Visual Studio has (but there are some good alternatives for Qt).

The other two pain points (for DCC): \- HDR support (again across monitors) \- Hi-DPI support (and again across monitors)

Once you start hitting issues above (among many small others), you realize how much there is to add (wacom tablet support? What next?)

<comment><USER45> I'm not too up to date with Godot news, but I remember that a recent update (maybe devlog?) added good multi monitor support to the editor, and therefore the gui toolkit of the engine, since the editor uses the engine.

</comment></comment><comment><USER46> My question - what happened to microsoft in this space?

The get up and go speed of the super old windows forms approach was fantastic.

Now I'm supposed to use - XAML? UWP? WPF? Do these have great windows form designer still?

I'm talking speed between download and go with an GUI, a button, a text box (maybe data bound) etc.

This will age me, but for all the decades of "improvements" this tooling has, every time I've tried to do the little widget apps thing I used to be able to do trivially I end up wondering in the woods.

<comment><USER47> You can do the "WinForms approach" with WPF/XAML still, but once you got the ideas and concepts behind MVVN, observables, bindings, converters, collection controls and so on, there is absolutely no turning back and you start to miss that stuff on WinForms.

<comment><USER46> Is WPF/XAML the right way now to do quick get going windows app development?

<comment><USER48> Yes, although the future is WinUI.

[https://microsoft.github.io/microsoft-ui- xaml/about.html](https://microsoft.github.io/microsoft-ui-xaml/about.html)

</comment></comment></comment></comment><comment><USER49> I'm trying doing this with Unity.

My main issue is the amount of learning necessary for doing "simple" stuff - <USER2> think onboarding of new people will be a challenge.

But I guess time will tell :-)

That said i do enjoy the experience - and some of the "game" features do give an amazing opportunity to make a nice interface.

I you go this route, do prepare yourself to spend your hours very different - making an animation takes no time - making a simple tab sequence takes time :-)

</comment><comment><USER50> A great app made using Godot is heavypaint[1]. He explains that in his Blender everyday talk[2]

[1] [http://www.heavypoly.com/heavypaint](http://www.heavypoly.com/heavypaint)

[2] [https://youtu.be/3jZLTZnIiKU?t=2318](https://youtu.be/3jZLTZnIiKU?t=2318)

<comment><USER51> Wow, that's really cool! There has been so much new painting software on linux which makes me really regret selling off my drawing pad.

Here's a good illustration of the program in usage: [https://www.youtube.com/watch?v=JCY4dfVNq9Q](https://www.youtube.com/watch?v=JCY4dfVNq9Q)

</comment></comment><comment><USER52> I have been playing around with Godot (to help my kids) and, to be honest, I had largely the same idea. For personal apps that have simple GUIs and have no formal spec, it might be just the ticket.

(I've been thinking of building an app to do photo triage, and Godot can certainly load up a bucketload of image assets and render them...)

</comment><comment><USER53> That article is very flawed and also misses a critical point about UI in general, the reason why Windows feels like Windows in the last 20 years is because of UI/UX, I used Windows all my life and when I have to open a new app eventough I never used it before I can naviguate easily, everything makes sense, I click it does what it's supposed to, pop messages are all the same, menu looks the same, they all follow the same standard.

It's like driving a car, you can have thousand of different models and yet you get inside one you can drive it right away. You don't have that kind of usability if everyone was doing custom GUI running with a game engine.

Same reason why there is a learning curve with UI in games, every games are different so every UI are also different, it takes time to naviguate properly in a new game.

Consistance is key.

</comment><comment><USER54> If you're going to do something like this, just use Flutter. It's the same principle, draw pixels to a screen, but it has a lot of advantages over Godot for application development, such as accessibility and only rerendering components when they change.

</comment><comment><USER55> Not familiar with godot, but the GUI reminds me a lot of the blender GUI. I always wondered if the devs would ever spin out that GUI so that it became a library, because it always felt blazingly fast compared to e.g. Qt or GTK

<comment><USER56> there's this project

[https://github.com/julianeisel/bWidgets](https://github.com/julianeisel/bWidgets)

</comment></comment><comment><USER57> An underlying tone of this article which most people in this thread have missed, was the impact of hitting the ground running. Godot quickly gets something on the screen for someone to build on. Qt is difficult to get something running. The impact of this makes technical benefits one way or the other moot. After all, if it works, who cares what technology is better?

I found the hassle of setting up Qt painful, but it didn't scare me away. The final nail the coffin was their prioritization of Qt Creator over SDK integration. juggling two IDEs just didn't seem right with an existing codebase.

<comment><USER58> > _The final nail the coffin was their prioritization of Qt Creator over SDK > integration. juggling two IDEs just didn 't seem right with an existing > codebase._

Curious what you mean by that? What did you need Qt Creator for that you couldn't do otherwise?

</comment></comment><comment><USER59> When I came here I was hoping to hear all about godot making minority report type futuristic GUIs... I was surprised to see it was all about a game engine making regular every day 2020 UIs!

</comment><comment><USER60> Reminds me how in 2015 I built a web server in Godot. It's very limited, uses busy polling to listen for new connections, but nothing else was available at the time (IDK about current Godot). [https://github.com/KOBUGE-Games/godot- httpd/blob/master/http...](https://github.com/KOBUGE-Games/godot- httpd/blob/master/httpd.gd)

Where there's a will, there's a way :).

</comment><comment><USER61> I am a big fan of the MOAI toolkit, which is similar to Godot in some ways - inasmuch as its a game engine toolkit with a Lua front-end - and with which I have created a number of 'non-game' GUI apps.

It was easily one of the nicest projects I've ever done - no web stuff to deal with, only MOAI for the core layer, with Hanappe doing the regular work of providing the GUI controls and abstractions I need - scroller views, buttons, sliders, etc.

And since that experience, I really yearn for a similar kind of framework on the better-supported engines out there (MOAI has gotten a bit long in the tooth in the last few years).

Its really quite a neat feeling to ship an app that uses highly optimised game code for its lower interface abstractions, with a mid-layer framework on top of it - which then can be packaged and run on any platform: iOS, Android, Windows, Linux, MacOS - and looks the same, functions the same, on every platform.

It does take some courage however. You do have to make a great UI experience for the end user - if its half-assed or buggy, the whole thing falls down. But, when it works, it works very well and blows away the whole Web framework. I really don't like doing apps any other way these days ..

</comment><comment><USER62> I feel strongly that OP should check out Google's Flutter project. It has many of the benefits he sees in Godot, with a more general focus rather than the singular focus on games.

Flutter is very "game-like" in the way it does its UI. It does not use the native graphics elements. Everything is a component that is rendered by Flutter's own rendering engine ... AND even the inputs (like touch) are handled directly in Flutter.

</comment><comment><USER63> JUCE is another option one could explore for cross platform non-web UI.

It's generally used to make audio apps and plugins, but these require UIs are after all. I'm fairly certain the first versions of Ableton Live were made with JUCE, I'm not so sure about the later ones. MaxMSP is also made with JUCE.

[https://juce.com/](https://juce.com/)

<comment><USER38> I looked into JUCE a while back when I was keen to find a good cross-platform UI solution but was put off by the licensing aspects that seemed more complex/onerous than even Qt's. YMMV.

</comment></comment><comment><USER64> There is so much bullshit and lies about Qt5, I won't bother finishing that piece of crap:

Erik Engheim: Qt5 is 5GB Actual fact (on arch linux): qt5-base = 64.07 MiB, qt5-declarative = 24.72 MiB, qt5-quickcontrols2 = 8.56 MiB

> Try having somebody look at a Qt design you made. "Oops sorry you need a 5 > GB download to do that. Oh and btw you need to register an account on a > website, login and search really hard to find the free version."

...blatant lie, etc. I won't bother, this guy is nuts. Thanks god for Qt, it has its quirks but on the desktop it's the best we can do to dev cross- platform

Erik Engheim: Consider Qt Creator IDE which is quite minimalist, without Qt which it requires to run, requires over 200 MB Actual fact: 108.03 MiB

<comment><USER65> There might be some confusion about Qt the runtime (ie: compiled binaries) and the Qt SDK for development. Last I remember (admitedly, >8 years ago) the Qt SDK certainly was a multigigabyte download.

In this case, you need the SDK to develop a UI with Qt, so I think the author's comparison is fair.

> Consider Qt Creator IDE which is quite minimalist, without Qt which it > requires to run, requires over 200 MB Actual fact: 108.03 MiB

Probably depends on the platform, I wouldn't be surprised if it was > 200 MB on OS X. But either way, 100 vs 200, same order of magnitude

<comment><USER66> > Probably depends on the platform, I wouldn't be surprised if it was > 200 MB > on OS X. But either way, 100 vs 200, same order of magnitude

keep in mind that Qt Creator comes with a full clang for its C++ code model which is already 40-50 megabytes at least ; no decent C++ IDE can skip that.

Regarding the Qt SDK size, what can take gigabytes is installing it for all android & iOS ... ABIs / versions.

for a fast SDK installation experience, I recommend aqtinstall:

        $ pip install aqtinstall
        $ time python -m aqt install 5.15.0 linux desktop -O ~/Qt/
        10,43s user 2,14s system 153% cpu 8,213 total
        $ du -csh ~/Qt/5.15.0
        592M 5.15.0

(but really, just install e.g. qtbase5-dev on Debian systems has 99.9% of what is needed for most GUI desktop apps and is ~13 megabytes: [https://packages.debian.org/sid/qtbase5-dev](https://packages.debian.org/sid/qtbase5-dev) what takes space is 3D engines, webviews, multimedia apis, etc... but an awful amount of apps don't need those)

</comment></comment></comment><comment><USER67> I use Godot on a daily basis, full time. Don't try that at home.

<comment><USER68> Why?

</comment></comment><comment><USER69> Interesting Article and also conversation here.

I think the future of interactive immersive VR work environments is looking very strong so using it for GUI apps seems like a good first step.

The author of this article said that he is not a web developer and he has a pro-application perspective. I think he misses the huge opportunity for web properties to also render into Virtual Reality.

Out of curiosity I looked at some of the examples in the Oculus Quest SDK. Basically Android+3D, effective but there is lots of room for improvement.

</comment><comment><USER70> The section on "Electron, HTML5, CSS and JavaScript" is worth a read. We might have taken a few wrong turns when it comes to web technologies for applications.

</comment><comment><USER71> The author has a point that game engines may be suitable for some applications. In arquitecture I've used Twinmotion, based on unreal and Lumion, not sure about the engine on that one, probably unreal too. It may be obvious in this field, where game like visualization is directly usable, but I can see other areas where It may work. Anything regarding 3d objects will find in a game engine state of the art, real time, visualization tools.

</comment><comment><USER72> Regarding sizes for Xcode, etc.: While I think they're bloated downloads, they include things like dozens of OS simulators, far more than the app/IDE itself.

</comment><comment><USER73> I personally got so used to the look of Gnome3 + GTK that I want all my applications to either use GTK or at least try to attempt to use a similar theme. The most important factor, as petty as it may sound, is the size of the control elements. If there is a generic dark theme it's usually okay but if the standard controls look off it usually doesn't appeal to me.

</comment><comment><USER74> How well does godot support dynamic/programmatic layout (w.r.t odd aspect ratios and resizing), localization, and accessibility?

I'd also take issue with the notion that 2D UI frameworks based on game engines are more performant than their alternatives, because game engines are optimized for 3D graphics and often struggle with performance once your UI state becomes reasonable large.

<comment> irq-1 > How well does godot support dynamic/programmatic layout (w.r.t odd aspect > ratios and resizing),

Very well (it's a game engine)

> localization, and accessibility?

Poorly and not at all. Godot has a student adding PO files:

[https://godotengine.org/article/gsoc-2020-progress- report-1#...](https://godotengine.org/article/gsoc-2020-progress- report-1#i18n-improvements)

<comment><USER38> I'm not sure that "poorly" is an _entirely_ accurate description of Godot's localization abilities.

The GSOC project you linked to is about _enhancing_ the existing .po based feature: "In Godot, we [already] have two ways of importing translation - <USER3> using CSV or PO files."

Here's a blog post about someone's experience doing a translation for a Godot game: [https://sites.miis.edu/vprolow/2019/12/15/godot-game- localiz...](https://sites.miis.edu/vprolow/2019/12/15/godot-game- localization/)

And here's an official tutorial: [https://docs.godotengine.org/en/stable/tutorials/i18n/intern...](https://docs.godotengine.org/en/stable/tutorials/i18n/internationalizing_games.html)

</comment></comment></comment><comment><USER75> > Game development faces some rather brutal conditions to survive.

Which begs the question how do other areas of development get such easy conditions?

<comment><USER76> Competition. When I was in high school some 15 years ago many of my classmates wanted to make games. It was seen as fun and because it was seen as you had to be smart to do it (parents had no clue) it was in my classmates eyes the perfect combination.

Fifteen years later and the competition is huge, and the demand in overtime and the stress followed.

As you start to make even more "programming is fun" classes, what they don't see is the other end, and then queue in the FAANG salaries as if that is indicative of what programmers salaries are.

If I get kids, I'll tell them to do some soul digging to find out what they find fun that the majority instead finds boring or something that has a clear path through a moat.

</comment></comment><comment><USER77> Why is Hacker News not interested in JavaFX at all? Seriously.

<comment><USER78> I know right! I watched a scene builder demo and was floored at how easy things were.

Java went with webapps thinking it'd be easier to manage distribution of the application if a browser did it for you. Or at least that's how the trends played out. It kind of works, but the real missed opportunity was all the client side processing and storage that desktop apps bring to the table.

</comment></comment><comment><USER79> Anyone interesting in using this to create a code-editor / IDE? I'm dying to try my hands at a next gen IDE created using a game engine :D

<comment> Alex----- Check out Glass Editor [https://glasseditor.com/](https://glasseditor.com/) it's made using an unreleased game engine.

<comment><USER79> ...god, my eyes, they hurt, that design, they're bleeding now ...you almost made me change my mind of whether this would be a good idea :)

(Hint: I'm interested in mostly using this for creating a graphically rich but minimalistic distraction-free ADHD-friendly experience ...that could also be usable in VR for even more distraction free coding - I mean since most pro devs touch type anyway, using a keyboard in VR would just work for us, without any extra stuff.)

</comment></comment></comment><comment><USER80> Need a hello world, then something extra like a form, a solitaire etc to see how the rabbit goes.

</comment><comment><USER81> Does anyone know if Godot can play a live video stream with graphics drawn on top?

<comment><USER38> I _think_ that's possible.

From a quick search there's this: [https://docs.godotengine.org/en/stable/classes/class_videopl...](https://docs.godotengine.org/en/stable/classes/class_videoplayer.html)

(But that may not be a _live_ stream, necessarily, I guess.)

Also there's this that may be relevant: [https://docs.godotengine.org/en/stable/classes/class_spatial...](https://docs.godotengine.org/en/stable/classes/class_spatialmaterial.html#class- spatialmaterial-property-flags-use-shadow-to-opacity)

The latter is documented as:

"""

[...] enables the "shadow to opacity" render mode where lighting modifies the alpha so shadowed areas are opaque and non-shadowed areas are transparent. Useful for overlaying shadows onto a camera feed in AR.

"""

</comment></comment><comment><USER38> This is an area I've been actively exploring and think has real potential.

For context, my interest is in:

* Cross-platform support.

* Ease of distribution.

* Ease of construction.

* Platform stability.

* "Licensing"/business issues.

* Accessibility.

In the past I've used Qt w/ C++, Qt w/ Python, web w/Python backend, Python w/embedded web server and dabbled/looked into things like wx etc. (Oh, and, MS Access with VBA. :D )

# Platform Native UI

If you want/need Platform Native UI, then Godot is not going to work for you, period. But neither are most of the other cross-platform options because if they're only 95% they're not native. My impression is that if you want platform native _and_ cross-platform then per-platform clients w/shared backend implementation is pretty much required.

But I also think that platform native (as much as I might like it) is not necessarily mandatory for successful product, see, e.g. Slack.

I think the key around this is once you've chosen to not _be_ platform native don't _pretend_ to be platform native. Lean into making the UI tailored for your application.

And with a game engine there's a whole lot of space to lean into in this regard--particularly in relation to visualisation.

If you're happy with 95% and don't care about any other aspect then likely Qt will be a contender for you.

# Ease of Distribution

 _Trying_ to distribute a Qt + Python app as a single binary (within the last 2 years) was how I ended up ditching Qt & using an embedded web server instead. Despite all the effort & projects trying to make this work, IMO it still doesn't.

With the small initial Godot download and, a (admittedly half gig) "templates" download containing the cross-platform app "shells", it's possible to export to Windows, Mac, Linux, iOS, Android & HTML5. Depending on the platform the output might be a single binary, a disk image, zip file or binary + support files but where required traditional packaging tools can also be used.

This is really powerful for me (as both a developer & user) when the platforms I use (primarily Mac/Linux) are not in the majority & frequently get left out of releases.

# Ease of Construction

In relation to games, the highest praise I have for Godot is:

* Since I downloaded Godot I've actually made and released games.

I've found the integrated nature of the IDE really supports iterative development.

Game-making is often a very collaborative effort and because Godot has been developed (in part) to enable non-developers to not have developers be the bottle-neck it has visual-based tools & a node/component based architecture which also can make it a powerful tool for other technical but "non-developer" people.

# Why not use web technologies?

If your project makes sense as a web site then, make it a web site.

If you want to have a standalone app, you have experience with web technologies and memory/performance aspects aren't an issue, then, sure build it on Electron.

But if you can do those things, you can almost certainly use GDScript and gain the benefit of an integrated IDE and comparatively tiny downloads. (And still export it to HTML5/WebAssembly--admittedly currently probably with a slower initial page load time--but it's still an option.)

Additionally, currently Godot runs on older OS (e.g. even back as far as Mac OS 10.9) than Electron does which keeps getting dragged along to newer versions by Chrome's requirements which seem to place little emphasis on supporting older machines/OS.

# Why not Qt?

Ah, Qt, I really want to like you.

If Qt works for you, then use it.

But my experience with Qt has been one of a business that continually seems to struggle with how to survive; tries to stretch their license compliance in terms of LGPL & contract with KDE to breaking pointing (because, really, they wish they didn't have that constraint at all); and, a continual churn of the underlying technology that results in apps that only support newer & newer OS/Qt versions even if they don't require anything more than, say, Qt 5.2.

If you're a big corporate and/or if a 95% cross-platform solution is enough, then I think there's still situations where Qt probably makes sense but in terms of my niche desktop application development needs it's just too much hassle.

# Is Godot ready for applications now?

Somewhat. Obviously if your application is a game & the required feature set matches Godot's, then yes. :)

Based on my own experience using Godot to develop non-game applications tends to run into some areas of its feature-set which have seen less attention & so have bugs, lack features and/or lack documentation. (e.g. complex Tree controls, more sophisticated font rendering (e.g. kerning), very complex layouts.)

Overall, I think Godot is at a stage where a bunch of people (including OP) have realised it has potential around non-game application development but also has some rough edges in that regard that still needs to be improved.

Given the size & focus of the development team up to this point that's not surprising but I'm excited to see where it may go in future.

# A Note on Accessibility

As mentioned elsewhere in the comments, Godot also unfortunately doesn't currently have a great accessibility story.

There is at least at least one project that I know of that is working on improving that: [https://github.com/lightsoutgames/godot- accessibility/](https://github.com/lightsoutgames/godot-accessibility/)

In addition, Godot's node-based UI system in particular I think lends itself to retro-fitting better accessibility support more than a different architecture might.

But if you need your app to be accessible today then Godot probably won't meet your needs.

# Bonus: Are InfoSec tools a potential niche for Godot-based apps?

I think that's a strong...maybe. :)

To explore the potential of Godot for non-game apps I've been working on developing a Godot-based hex viewer/editor with a focus on binary/format reverse-engineering & visualisation motivated in part by a talk where someone complained that hex editors hadn't done much new for years.

Early in development I realised that InfoSec has a combination of aspects that might make it particularly well suited for Godot-based apps:

* Many people who are technically skilled but consider themselves "non-developers".

* Has problems to solve that benefit from new forms of visualisation (often with large amounts of data) not met by standard UI.

* Has an affinity for flashy visuals. :)

* Need tools that don't only run in the cloud.

(In InfoSec and want to make this happen? I'm available for hire. ;) )

</comment><comment><USER68> Godot has only OpenGL renderers. Do they plan to add DirectX and Metal?

<comment><USER38> For Godot 4.0 the rendering system is being re-worked to use Vulkan.

</comment></comment><comment><USER82> Are there examples of such advanced GUIs? (links to github)

<comment><USER41> Godot's own editor is one obvious example.

Also I saw this Kanban board posted on Reddit earlier: [https://github.com/alfredbaudisch/Godello](https://github.com/alfredbaudisch/Godello)

Heavypaint, mentioned elsewhere here: [https://news.ycombinator.com/item?id=24046431](https://news.ycombinator.com/item?id=24046431)

</comment></comment><comment><USER83> UIs in game engines are pretty different from the look-and-feel you get using native components or QT. Even with Electron apps, the text fields and buttons that you start with are at least native to the platform.

<comment><USER84> That's definitely true. OTOH it does seem that fewer and fewer applications are designed to match the native look-and-feel. A game engine would not be a good choice if that was a goal of your project, but I don't think most projects these days are too bothered about that.

</comment></comment><comment><USER85> flutter is the best. period.

</comment><comment><USER86> I've often wondered why more desktop software and data analysis stuff isn't written in something like Unreal.

\- optimized across platforms \- optimized net code libs \- modal collaboration tool: build in blueprints or code (basically web components before web components) \- advanced visualization \- source control integration \- the frontend can be backend language agnostic, swap C++ for Rust over time \- no web assembly needed - heavily polished ergonomics and UX \- custom input map support is robust, tools can have their own keymap (we aren't secretaries!)

The tech world at large is really addicted to the toolkits of the wrong companies, IMO

Apples "pro" dev tool in Xcode feels like a boring business tool.

Once closed desktop tools are now free for development with a market for making money now. Godot is just as open as Visual Studio or Firefox, minus the DOM, JavaScript, etc.

Cloud infra and micro services can still be what they are, all the usual safety features.

Web/mobile development landscape just feels bloated and insane compared to building once in Unreal or Godot and outputting to multiple platforms like the game engines are doing.

<comment><USER53> Because the overhead and complexity is huge and useless. Unreal is not optimized to make GUI application, it's used to make games. Engines don't have anything useful to make modern app on the desktop.

<comment><USER86> The overhead and complexity of a dozen different IDEs, JS frameworks, 4 browsers, 2 mobile phone platforms, etc etc is less complex?

In a day to day engineering perspective it's all a mess of abstraction and indirection anyway?

If we're going to optimize ONE stack, I'd prefer the one with all the optimized rendering and input mapping, rather than hacking that all into a bloated document parser like we're hacking into a browser?

IMO that is textbook functional fixedness.

<comment> yoz-y For one applications need familiarity and uniformity. Games don't. For example games have exactly zero accessibility support, system actually knowing about what is being rendered is quite useful for it to provide tools like voice over. What about IME?

> If we're going to optimize ONE stack

Why would we though? There are different classes of applications and there are multiple platforms with different conventions. Different use cases require different tools. Every time something "to rule them all" was tried, multiple niche tools grown around.

<comment><USER29> > For example games have exactly zero accessibility support, system actually > knowing about what is being rendered is quite useful for it to provide tools > like voice over.

Some engines do have accessibility support. Most games don't do accessibility because it costs money. Same as web apps, by the way. It is not a technical limitation.

> What about IME?

What about it? It works just fine in any proper engine. There are a lot of non-Latin-charset speakers in the world...</comment></comment></comment></comment></comment>


Dirvish: a fast, disk-based, rotating network backup system - <AUTHOR> http://dirvish.org/ <comment><USER2> Used it for a very long time, however there is one caveat; since it uses the filesystem directly to mirror all kinds of file attributes, your destination filesystem has to support them all (acls, fattrs, caps) and always be mounted with the proper options. Hard links are being used for deduplication. Same kind of caution is appropriate when moving a dirvish vault to a new disk or mount point. Make sure to have a suitable destination filesystem, all the proper mount options, and don't just use cp to copy it over.

These kind of problems are avoided by using tools like Borg backup, which store the backups in archive files which are independent of the underlying filesystem. On the other hand, if one such archive gets damaged, recovery from it is much harder than with a system like dirvish.

Make your choice :)

</comment><comment><USER3> It looks like the project is looking for an administrator.

[http://dirvish.org/pipermail/dirvish/2018-January/thread.htm...](http://dirvish.org/pipermail/dirvish/2018-January/thread.html)

<comment><USER4> Unfortunately it's largely unmaintained nowadays. Also it's written in rather esoteric Perl.

</comment></comment><comment><USER5> Looks very similar to rsnapshot: [http://rsnapshot.org/](http://rsnapshot.org/)

Both use rsync, hardlinking, are written in perl, and seem to have been around for ages. I've depended on rsnapshot for many years and have been really happy with it.

<comment><USER6> Having just recently dipped my toe into ranapshot I will chime in that it's also very easy to configure, and has already saved my client's bacon once avoiding a cloud restore process.

</comment></comment><comment><USER7> At a previous company we used this to shuttle Tbs of data about</comment>


Simjacker: SIM card flaw lets hackers hijack any phone by sending SMS - <AUTHOR> https://simjacker.com <comment><USER2> This is for the exploit release is probably more helpful: [https://news.ycombinator.com/item?id=20951578](https://news.ycombinator.com/item?id=20951578)

<comment><USER3> Ah, that's the same submission, which makes this one a dupe. Thanks!

<comment><AUTHOR> I tried to search for it beforehand and didn't find anything.

<comment><USER3> Not to worry. That happens sometimes.

</comment></comment></comment></comment><comment><USER4> Does anyone have additional information or leads about the private company they suspect being behind it?

<comment><USER5> Five bucks says it's an Israeli company. The IDF's Unit 8200 is basically a Y Combinator for spyware start-ups at this point.

</comment></comment><comment> java-man Previous [lack of] discussion:

[https://news.ycombinator.com/item?id=20959313](https://news.ycombinator.com/item?id=20959313)

</comment><comment><USER6> It looks like most phones on US carriers are safe from this.

According to T-Mobile and Sprint, their SIMs do not contain the S@T Browser. AT&T says the same for their US SIMs. Verizon doesn't seem to have issued a definitive statement, but say that they believe their SIMs are not affected. See [1], [2].

[1] [https://arstechnica.com/information- technology/2019/09/hacke...](https://arstechnica.com/information- technology/2019/09/hackers-are-exploiting-a-platform-agnostic-flaw-to-track- mobile-phone-locations/)

[2] [https://www.pcmag.com/news/370736/sim-card-flaw-poses- spying...](https://www.pcmag.com/news/370736/sim-card-flaw-poses-spying- threat-but-us-users-appear-to-be)

</comment><comment><USER7> This article is effectively claiming that SIM card hardware has a back door built in.

<comment><USER8> i believe it is and it may well be right for the most part although likely with a caveat or two, id wager it cant do much else than report certain info back and it would rely on the sms app having location data permissions (admittedly most will have agreed to this)

ive been hearing rumours of something like this coming out of russia where its referred to as "pelengator" (searching will reveal little other than a vehicle tracking app, ive heard about it from various gsm forums and chats etc but wasnt convinced it was real)

</comment></comment><comment><USER9> Does this affect Apple's eSIMs?

</comment><comment><USER3> Url changed from [https://thehackernews.com/2019/09/simjacker-mobile- hacking.h...](https://thehackernews.com/2019/09/simjacker-mobile- hacking.html), which points to this.

</comment><comment><USER10> This is scary attack.

</comment><comment><USER11> But they've got an awesome animated logo, so it must be serious.</comment>


The Oil Price Is Now Controlled by Just Three Men - <AUTHOR> https://www.bloomberg.com/opinion/articles/2018-11-18/bin-salman-trump-and-putin-control-the-oil-price-now <comment><USER2> Am I the only one that finds the title of this article a little bit misleading? These three men represent giant organizations, are responsible to several interests and do not really "control" oil prices in the sense of "fixing" the price.

<comment><USER3> Putin is in almost absolute control of Russia. Sure, an oligarch or a powerful faction may rebel but Putin has other ways of making them whole.

Do we even doubt that Salman is the absolute ruler of SA?

<comment><USER4> That's not what the previous poster was referring to. "Controlled by Just Three Men" sounds like there's a smoky back room where Joe, Bob and Fred meet weekly to collude on oil pricing. Instead the three men are heads of nation states, each of whom can certainly _influence_ the oil price, but they're not cooperating to fix it.

<comment><USER3> We're going back and forth, but yeah, Trump can increase production with a phone call. Maybe threaten or promise a favor to SA. A $500 per bbl is not good for OPEC long term, so there's a lot more than let's just increase the price.

Even in USA with the three branches, the US President has a LOT of power and if he promises to pass a bill, he has a lot of lever$ he can use to assure the votes are there.

So, yeah, these three men can control the oil price if their interests align.

</comment></comment></comment></comment><comment><USER5> I have a hard time comprehending this article. The three people in charge of Saudia Arabia, Russia and US produce more oil than OPEC the author says. But then SA is in OPEC, and the three don't produce a significant amount more than OPEC combined. What is the entire gist of writing this article other than there's an unproven conspiracy.

<comment><USER6> I think the author is saying: "OPEC can no longer set high oil prices, because US, Russia and SA produce more oil than OPEC combined." But on the other hand the year 2008 has shown that it is not the US president who is setting the oil price, but the oil company executives [1].

[1] [https://money.cnn.com/2008/05/21/news/economy/oil_hearing/in...](https://money.cnn.com/2008/05/21/news/economy/oil_hearing/index.htm?cnn=yes)

</comment></comment><comment><USER7> Saudi Arabia is in OPEC so the gist of the article is moot.

<comment><USER4> OPEC is notorious for having members agree to various things on paper and then doing something else entirely.

<comment><USER8> Then it needs to be replaced.

<comment><USER9> If we apply ideas from game theory, you will find out that cartels are naturally unstable. I don't think you would be able to replace OPEC with another cartel even if you wanted to . (No one outside the newly formed cartel would welcome a new cartel.)

<comment><USER8> You replace a cartel by a free trade organisation, not by another cartel.

<comment><USER10> Free trade is what causes cartels. The is no "you" who gets to control the world economy</comment></comment></comment></comment></comment></comment>


ExFAT in the Linux Kernel? Yes - <AUTHOR> https://cloudblogs.microsoft.com/opensource/2019/08/28/exfat-linux-kernel/?WT.mc_id=social-hackernews-shboyer <comment><USER2> dupe of [https://news.ycombinator.com/item?id=20821064](https://news.ycombinator.com/item?id=20821064)

</comment><comment><USER3> Why didn't they do this a decade ago?

Where's the apology for threatening the community with patent lawsuits?</comment>


The Job Market for C++ Developers (March 2012) - <AUTHOR> http://markcunningham91.blogspot.com/2012/03/job-market-for-c-developers.html <comment><USER2> This is a perfect example of buzzword driven technology recruiting. Imagine this person writing this essay in early 2008, objective-C has all these negatives against it -- ranked about 50 in the popular language index, funky syntax that people can't wrap their heads around, manual memory management, can only write Mac applications (< 5% of devices). Even iPhone is moving to the Web. All Objective-C programmers should give up and move to web technologies. However, about four years later Objective-C is in the top three technologies to learn.

I don't think there is a single C++ programmer (sitting under a rock) that doesn't know that C++ is not cool. It hasn't been cool for over a decade. This "essay" has some sort of anti-lesson in learning about technologies that have peaked. I can understand someone writing this essay in 2005; but if you have been writing C++ all this time, now is probably the best time (relatively speaking). Resource constrained devices are going to be norm in this decade (smart phone, smart sensors etc.). C++ will be one language that will be supported across all these. At the high end, servers will move from python/Java to C++ to squeeze even more operational savings.

Also, becoming a sysadmin (RHCE) in addition to learning about python and RoR and Objective-C. I mean, it doesn't even make sense ...

<comment><USER3> Where on earth do you get these predictions from?

 _Resource constrained devices are going to be norm in this decade (smart phone, smart sensors etc.)_

 _...At the high end, servers will move from python/Java to C++ to squeeze even more operational savings._

You just made assertions about like 5 different markets with precisely zero justification.

</comment></comment><comment><USER4> Being "pigeon-holed" as a C++ developer...that's hilarious. Yesterday, I discovered that not one, nor two, but at least a half dozen different "Ruby programmers" have created Gems to generate placeholder text by making a _web request_ to lipsum.com. So maybe we should be having a conversation about what we mean when we talk about someone being "experienced".

Say what you will about C++, I'll take a good C++ developer with no knowledge of Ruby over many of the "experienced" Ruby developers I'm seeing, any day of the week. Language proficiency is a detail, and Ruby is not a particularly difficult language to learn.

</comment><comment><USER5> I'm a C/C++ programmer with 15+ years experience. I recently was looking in the job market, and I didn't feel any problems trying to find a C++ job. Most jobs weren't C++, but there were still jobs that I could have applied for that would have interested me. But I chose instead to go with a job doing PHP (having no practical experience in PHP), because of the opportunities presented by the company, not because I felt PHP was superior in any way.

C++ opportunities are definitely decreasing, but there is still a lot of life left in it for performance-critical applications. And most kids these days coming out of school don't really learn C++ as much as they used to. I find most of the kids that I interview have experience in Java and Python, so it means that those old dinosaurs like me that have significant C++ experience still have a decent shot, unlike the COBOL programmers of Y2K.

</comment><comment><USER6> It isn't really news that people basically "wrote all the low level code they needed" and moved on from there. There was a market for C++ in the 90's because the hardware demanded it and because there was no foundation to build the myriad of technologies we have today off of. Now we have those technologies and as long as the going rate for a programmer is so high, their time is more valuable than the efficiency of native code.

I prefer C++, and I'm 21. It is the kitchen sink, but that is what I want in a bare native language. If I write something higher level and need efficiency, I can switch into C++ gear and expect the language to be complete enough to quickly implement whatever is missing and inter-opt the functionality.

If my time is more valuable, I'll just jump at Python. If it needs a web presence, I'd sub python for Javascript. If my time _isn't_ the most valuable thing, C++ (maybe one day D) becomes comes to the front of the pack. But that is the way I tackle the problem.

I still wonder about a different perspective. If I am going to write something that is going to see millions of hours of execution on machines, as opposed to the hundreds a normal script will or the thousands a business app might, I'd not want to imagine the amount of electricity and processor power being wasted on interpreters and JIT compilers. I wonder how bad it is for Android phones running most of the non-system software on Dalvik.

Oh, and I'm unemployed, so lf work in C/C++/Java/C#/Python/Javascript (woohoo shameless plug. It is why I read this story after all, even if it is about the job market 9 months ago...)

</comment><comment><USER7> Unfortunately this just confirms that recruiters are terrible at finding decent people. The trick is to look for companies that do not look at buzz words and pigonhole candidates based on tools they have used. Those developers might be one trick ponies and are generally not a very good hire.

</comment><comment><USER8> The game industry still runs on C++.

<comment><USER3> Quant finance too

<comment><USER9> Or at least, the part of quantitative finance that doesn't run Haskell.

</comment></comment></comment><comment><USER10> I'm curious to hear from recruiters about the job market for things like Node.js and CoffeeScript, because those are my favorite technologies at the moment.

</comment><comment><USER11> It may be "buzzword driven recruiting" but it probably reflects what employers are asking for. Look at it as the data point it is.

</comment><comment><USER12> I was going to write a few things, but then I saw this is from a recruiter, so it is actually very good :)

<comment><USER13> Yeah, and he's not wrong about the oil and gas biz. My company is doing a bunch of work with .NET/WPF and what-not, but to some large degree C++ code, literally millions of lines of it, pays the bills. And as someone who's always enjoyed debugging large complex code-bases, I'm really happy with my 80% support / 20% development type role.

But as he says, it's always good to have a varied skill-set, so I've dedicated at least 40 hours over the vacation-time to reading the SegY specification and building a Javascript loader/visualizer. Not much code, and it runs reasonably fast, but making lots of asynchronous calls to load, convert from IBM floats, and visualize data, is the kind of stuff that sharpens up the Javascript skills pretty quick.

The neat thing about something like this, is that everything you need is online. The SegY spec, plenty of available seismic data courtesy of the US government, and incredibly fast Javascript compilers with Firebug as a REPL.</comment></comment>