Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Slint – A declarative UI toolkit for embedded and desktop

slint.dev

Post reply on HN
Print view View original

81–90 of 152 posts

Re: Show HN: Slint – A declarative UI toolkit for embedded and desktop

#81

Post by nologic01 »

timeon wrote: post #75
nologic01 wrote: post #36

Earlier quoted context omitted.

Made a similar comment about the comparison pages, which is a simple and factual statement yet was downvoted immediately by (pressumably) people with a stake in the project. Does not reflect well... Detailed and unbiased comparisons are extremely useful but also are hard (and costly) to do. Don't promise them if you can't deliver.

> (pressumably) Why do you suppose this in particular?

my lack of imagination as to what might be otherwise motivating HN members to "engage" in this way :-)

I mean I can't imagine anybody having an independent interest in the project (like I do) and actually thinking that the comparison provided was adequate.

As said in my original comment, this is an area where a sense of sub-optimal status quo is palpable and people search for some sort of rationalization of the various nascent possibilities and options. Just a few days ago somebody was talking "parallel futures" (in mobile context) [1]

[1] https://news.ycombinator.com/item?id=36340925

Re: Show HN: Slint – A declarative UI toolkit for embedded and desktop

#82

Post by MallocVoidstar »

hyperbrainer wrote: post #63
samstave wrote: post #62

Earlier quoted context omitted.

ELI5 what this does?

The lto setting controls the -C lto flag which controls LLVM’s link time optimizations. LTO can produce better optimized code, using whole-program analysis, at the cost of longer linking time. The valid options are: false: Performs “thin local LTO” which performs “thin” LTO on the local crate only across its codegen units. No LTO is performed if codegen units is 1 or opt-level is 0. true or "fat": Performs “fat” LTO…

Also, codegen-units = 1 disables some compiler parallelization which means it can find more optimizations, including for size: https://nnethercote.github.io/perf-book/build-configuration....

Re: Show HN: Slint – A declarative UI toolkit for embedded and desktop

#83

Post by n8henrie »

> Create your application under MIT, BSD, Apache 2.0 or any of the other GPLv3 compatible licenses, provided that the complete work is made available under the GPLv3.

> Create your application under a license of your choice, open-source or proprietary, provided that the application includes proper attribution to Slint and retains copyright notices. I've listened to at least one (or two?) podcasts on slint, and I'm still not sure that I understand the license options, which makes me hesitate to invest time to learn.

I usually use the MIT license. Is the first license above compatible with MIT, without requiring forks (of my project) to GPL3 their code?

Does the latter license mean I can closed-source and commercialize my app and just include a shout-out to Slint and I'm good? (EDIT: if so, why would anyone choose the potentially expensive commercial option?)

Re: Show HN: Slint – A declarative UI toolkit for embedded and desktop

#85

Post by monroewalker »

nu11ptr wrote: post #42
serial_dev wrote: post #21

The comparison sections are very confusing. It says you will compare your UI toolkit with, for example, Flutter and then there is no comparison there at all. I thought the site is broken on mobile, I tried different browsers, etc, because the comparison was just not there. If you don't have any real content there because you don't want to start a flame war, you could try something like what the Flutter team did, they…

This is what I do: - Write the backend in Rust - Write the UI in Flutter - Tie them together using gRPC. You get an API and ability to run client and server on different machines as well I looked at the flutter to rust bridge and started to play with it, but assuming your UI can withstand the slight overhead of gRPC I found it a simpler way to proceed (although I'm not that far in yet)

I'm looking at something similar with Go as the backend. Why gRPC instead of a pipe? I started with that as well since it was really easy to set up but that comes with the caveat of requiring network permissions even though it's local to local communication.

Re: Show HN: Slint – A declarative UI toolkit for embedded and desktop

#87

Post by nu11ptr »

dist-epoch wrote: post #58
nu11ptr wrote: post #42

Earlier quoted context omitted.

This is what I do: - Write the backend in Rust - Write the UI in Flutter - Tie them together using gRPC. You get an API and ability to run client and server on different machines as well I looked at the flutter to rust bridge and started to play with it, but assuming your UI can withstand the slight overhead of gRPC I found it a simpler way to proceed (although I'm not that far in yet)

> You get an API and ability to run client and server on different machines as well So like a web app.

Yes, nothing to stop you from substituting Flutter for your frontend of choice including a web-based SPA, but then you would need the gRPC-web extension to call gRPC from a browser. The Rust Tonic crate has this available for the server side.

Re: Show HN: Slint – A declarative UI toolkit for embedded and desktop

#90

Post by nu11ptr »

monroewalker wrote: post #85
nu11ptr wrote: post #42

Earlier quoted context omitted.

This is what I do: - Write the backend in Rust - Write the UI in Flutter - Tie them together using gRPC. You get an API and ability to run client and server on different machines as well I looked at the flutter to rust bridge and started to play with it, but assuming your UI can withstand the slight overhead of gRPC I found it a simpler way to proceed (although I'm not that far in yet)

I'm looking at something similar with Go as the backend. Why gRPC instead of a pipe? I started with that as well since it was really easy to set up but that comes with the caveat of requiring network permissions even though it's local to local communication.

Pros and cons: with a pipe it will be up to you to create your own message delimiters and protocol, so a pipe is somewhat lower level. You also limit comm. to just that machine, but that may be a pro if that is what you are looking for (omits need for things like username/password or locking to 'localhost'). Lastly, you do not gain an API for your users to consume (if that makes sense for your app - it doesn't always).
Post reply on HN