Live data from Hacker News

Flutter desktop shells

github.com

251–260 of 322 posts

Re: Flutter desktop shells

#251

Earlier quoted context omitted.

> So (3) is hardly better than (2). As someone developing GUIs with Qt bindings for Python daily, and has been for the past 8-9 years, I respectfully disagree. Understanding of the underlying types and memory management is rarely an issue (e.g. once every 3 months), and when it is it's incredibly straightforward (e.g. maintaining reference to a window you've just created else Python garbage collects it for you). Topi…

Putting aside the many resource problems with Electron apps, can you achieve the level of user experience that the Electron folks do? I see Electron devs being asked to match the slickness of an existing website with similar delivery time and productivity. You don't seem to be able to get close to that with native APIs, API frameworks, or higher-level tools without a lot of work. When you remove these UI and delivery…

My argument is that the UI requirements are almost always nonsense. I hate launching a new app and trying to figure out a new interaction model or fighting a themes/fonts that fight my needs (font sizes, contrasting colors, etc). Basic stuff is often broken and there's a long tail, if ever, for them to get fixed. They're also the best candidates to break during an OS or other library update.

The whole reason OSes give you reusable components is so its easy to implement the conventions users are familiar with. Those are the things that are supposed to be fast and easy.

This likely violates the delivery timelines, but Maya, Nuke, and Houdini are all professional, heavily customized apps that were written in their own UI toolkits but were ported years ago to Qt and are cross platform.

Re: Flutter desktop shells

#252

Earlier quoted context omitted.

I know we're talking UI frameworks, but... I think we lost something important with the shift from workgroup to client/server (especially ODBC). I banged out a lot of dBase II, FoxBASE, MS Access (in-house) apps, back in the day. I've not felt as productive since. I miss it dearly.

Software based on that still exists and it’s a hell to maintain.

To which I can reply 'come back in 20 years and tell me about your experience maintaining something based on npm and friends'. At least those old crufty systems had the good grace of not having a best-before date measured in weeks. They might lack many other graces but for maintainability there is something to be said for a modicum of temporal stability when it comes to development environments.

Re: Flutter desktop shells

#253

Earlier quoted context omitted.

Context: I was a Qt developer in a past life. The alternatives for cross-platform GUI are 1. Electron 2. Frameworks like C++/Qt C/Gtk 3. Bindings to (2) Using frameworks like Qt in native C++ sucks because C and C++ are just terrible languages for GUI development, even with the bolted on object systems and language extensions (Qt extends the C++ language). Using bindings to those frameworks is nice in theory because…

FreePascal with Lazarus, the true cross-platform GUI framework is similar to Delphi's VCL or .Net's WinForms, it's been in active development for over a decade, and you compile your program into native machine code to a lot of platforms. https://www.lazarus-ide.org/

Yeah but then you have to write every library you'll need, since the ecosystem is tiny.

Re: Flutter desktop shells

#254
post #219

Earlier quoted context omitted.

Unrelated question, when did you decide not to pursue a career in sales?

I have heard variations of that most of my life. I always wanted to get into the Unix shell business on the coast so that the following would be true: "Chris Sells sells C-shells by the sea shore." Alas, another dream unrealized...

It's never too late :)

Re: Flutter desktop shells

#255
post #145

Every so often for the past several years I'll go evaluate options for cross-platform desktop app development and I always come back with an enormous handful of options and all of which fall short on some measure. I would really think that this "problem" would have a great solution by now. But I think most of the developer attention is on web for obvious reasons (more ease, more conducive to mistakes/novices/etc). Ho…

As I write in https://www.reddit.com/r/rust/comments/9bapwt/thoughts_on_wh... I think the solution is to split in 2: A UI back-end with logic, layout, etc and a UI front-end renders in each UI native toolkit. So when write Button(title="hello") is NOT a widget, but a struct with data. It must be pushed to UI.Coccoa.render(button) to show up. But not only that, is possible to say: Form when(toolkit=UIKit) Field(UILabe…

Sounds like what Scenic's trying to do for Erlang/Elixir GUI programming, albeit at a lower level.

Also sounds like what wxWidgets already does.

Re: Flutter desktop shells

#256
post #236
post #138

Flutter looked great, until I realised that they were re-implementing all the OS controls themselves. For example: https://github.com/flutter/flutter/blob/1db5d66932b873e17c8c... This is the kind of thing that leads to an "uncanny valley" app, where things feel slightly off, or they look good until the OS changes something and Flutter doesn't keep up.

In other hand, when I build something using Flutter I know end use will look at this exact pixel on whatever (android) phone used.

How much does this actually matter, though?

Re: Flutter desktop shells

#257
post #61

Earlier quoted context omitted.

To me Dart is pretty disappointing. Modern languages like Swift and Rust have shown the power of incorporating functional features like sum types and pattern matching. Dart just feels like the same sort of OO language we've been getting since Java became popular. Edit: Also the continued existence of null in new programming languages is a baffling choice to me.

Indeed, Flutter would be much more compelling if I could use it with Rust or Swift instead. Dart really doesn’t interest me.

One nice think about Dart I've found is that compile times are very fast (faster than Go) and when editing in VSCode the code intelligence is instant and 100% accurate in my experience.

Compare that to Rust where compilation speed is almost as bad as C++, RLS is slower than e.g. Qt Creator's clang lints, and has auto-completions so innaccurate that they are almost worse than nothing.

Buuut.... I wanted to make a deep copy of an object (a map of maps) in Dart, and one of the suggestions on Stackoverflow is to serialise it to JSON and then deserialise it. Eek. In C++ you just do `auto a = b;`. In Rust `let a = b.clone();`. How do they leave out such basic functionality?

https://stackoverflow.com/a/26616081/265521

Re: Flutter desktop shells

#258
post #132
post #4

Earlier quoted context omitted.

You could say the same about Objective C, and to a lesser extent Swift. While I respect your opinion, and somewhat agree on it being a weird choice to use Dart, I think there is value in learning it iff it becomes the ubiquitous way to write apps for mobile.

Objective-C and Swift help sell Apple's hardware. Besides Ad Words, there is very little being sold by Dart.

Besides the thing that provides nearly all of Google's income...

Re: Flutter desktop shells

#259
post #236

Earlier quoted context omitted.

In other hand, when I build something using Flutter I know end use will look at this exact pixel on whatever (android) phone used.

How much does this actually matter, though?

matters a lot more than getting inconsistent rendering and behavior that you have to continually test cross platform when trying to wrap native controls behind a leaky abstraction.

Re: Flutter desktop shells

#260
I'm a web developer, but I would like to learn Flutter. However, I haven't found a good resource to get started with. Everything seems to assume that you're a mobile developer already, except for a few very basic tutorials, which only half-assume that.

Does anyone know of something that will take you from zero mobile knowledge to building some simple apps?

Post reply on HN