rhardih's comments

https://sheety.co (No pricing)

I jest of course. This is really cool and nice to see something like this, make the front page of HN for once!

When you say 'correspond to device pixel ratio', do you mean 50% scale when on retina e.g.?

That is, of-course, until they decided to up the price on my tier by almost 60% with very short notice. Same box I'd been running for years, no upgrades or nothing aside from a shiny new price tag...

For screen recordings, Quicktime works great, but only provides a fullscreen or area based capturing option.

With Window Recorder, I've tried to mimic the behaviour of the screenshot tool, but for screen recordings.

It's currently free, but my intention is to take the freemium route, with an upcoming version including a premium upgrade, with a few more knobs and dials to tweak the recording, as well as recording directly to .gif.

So simple, yet so effective.

I'm running OpenCV on Android for an app project, and gauging pipeline costs at different steps is a pain. Right now I'm resorting to a "timing" build, with basic printouts of elapsed times at each step. Archaic.

Do you guys plan to add e.g. Snapdragon etc. as a measure at some point?

Also are the benchmarks based off of real device numbers, or are they fuzzed estimates somehow?

You seem to target businesses, understandably, but I signed up for a beta in any case.

https://venturebeat.com/2019/01/07/pingdom-will-kill-its-fre...

I can totally understand the move, and if my personal needs were greater, I'd gladly have converted to a paid account. Basically I just want an email if one of my hobby projects goes down. Nothing much more.

I already pay for a server, so I decided to put together a minimal Rails app that gets me 95% of the way instead of hunting for another free provider.

For now there's no auth etc. It's bare bones, but batteries included. All you need to run your own instance, is a host running docker.

Tim Sneath linked to the official plugins list in another comment, https://github.com/flutter/plugins, and both camera, sensors and connectivity, would be akin to the kind of ownership I'd expect. It's definitely a good start.

Obviously I don't know how you've structured responsibilities internally, but what I've seen before is, that the quality of individual components, or plugins if you will, live and die by the interest of the teams and people behind them.

Qt has this very same problem, often leading to some bugs ageing unacceptably long, or features never properly maturing, simply because there's little to no inside interest. NPM has a variant of the same problem as well. I'd venture a guess that a large percentage of packages on NPM right now, is downright abandonware.

I will be keeping a interested eye out for the developments of Flutter and I'm hopeful you succeed in this space. There's definitely room for it.

With regards to the native stuff, I'm mainly coming from a performance perspective on GPGPU and computer vision applications. I think going forward, there's going to be a huge increase in AR/MR apps, that will need easy access to do heavy lifting on metal. Coincidentally, I was lucky enough to catch a quick chat with Michael Thomsen, after his talk at Coldfront recently and he mentioned that, that was indeed on the roadmap. If you guys manage to provide the easiest cross platform way to do Vulkan/Metal or whatever the next-gen iOS and Android HAL is going to be, you're definitely going to come out on top.

The thing is that most things coming from Web just moves faster, and there's so many more resources available for the 95% app. For all of that JS kinda makes sense. It just comes with a bad upbringing and poor manners, when seen through the glasses of considering a phone as an "embedded" device with resource restrictions. Performance is always seems an afterthought in most things web. And that's understandable, because even the baseline resource usage, as fast and small as you can get on a Javascript runtime, is still above what I'd consider acceptable. It just isn't for most apps out there and people have sort of gotten used to charging their phones mid-way through the day.

Qt definitely isn't perfect, and it can be a bit of a pain to work with. QtCreator is just... and there's no live reloading.

The good thing is that runs really fast on the machine you're already working on, so most of the time you just work on the Desktop windowed version anyway.

I wish there's was a bigger selection of UI frameworks available though. For mobile there's Qt Quick Controls 2, which is quite good, but not at all as expansive as what you have available on the web for instance.

I do think though, that if Qt doesn't do something about their tooling and ecosystem, that they'll get run into the ground when some of these other frameworks bridges the gap to some of the features that Qt is still unique in having.

I agree that a truly solid package system, is inherently a good thing for any framework. But it has to be just that. Qt is severely lacking in that aspect; qpm isn't even close IMO.

Counter to your point though, just take a look at the ecosystem around NPM for instance. What a mess...

For a cross platform development framework, to truly shine, I need to be able to "trust", that my majority use case is covered within the framework itself, so I don't have to go package shopping and spend a lot of time on quality controlling vendored code.

For a mobile app framework, I want the most ubiquitous device capabilities covered. That means various hardware specific things, such as networking, gps, bluetooth and yes, the camera. Whatever is to be expected present on most devices.

So yeah, I guess it boils down to dependability and trust. Something which is implicit in the framework and core library for the most part.

But, that's almost the same as not having support at all. JNI isn't really a poster-child of usability.

With Qt, since you're already on the right side of the fence, it's just a matter of "#include "whatever.h" and linking it at compile time.

I mean, even just getting a camera feed on Flutter isn't a built-in: https://pub.dartlang.org/packages/camera