91–100 of 152 posts
>Attribution to Slint Mmmm no thanks, I'll pass. While I'm looking for a Flutter alternative, this seems like a trap.
> 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 st…
> why would anyone choose the potentially expensive commercial option
The paid option is for those using Slint in embedded devices (which is not permitted by the royalty-free license) or for those who prefer not to include attribution to Slint in their program.
I just spent the last two weeks choosing an embedded ui framework and then building out a little demo to test out its capabilities. I settled on Slint and have been very impressed with the design of the domain specific language they came up with. It’s small, simple, powerful and easy to learn IMO. The vs code extension for real time gui feedback is amazing. I’ve used swift ui before and Slint is as much of a joy to u…
I assume you're already doing this since you're on a microcontroller, but have you set [profile.release] codegen-units = 1 lto = true
[profile.release]
opt-level = "z"
lto = true
overflow-checks = false
codegen-units = 1
debug = false
You must then implement panic handling yourself:
pub mod std {
#[lang = "eh_personality"]
#[no_mangle]
pub unsafe extern "C" fn rust_eh_personality() -> () {}
// panic can be replaced by abort with the panic_immediate_abort feature.
// -Z build-std-features=panic_immediate_abort
// This saves space by getting rid of the unwinding.
#[panic_handler]
pub unsafe fn panic_impl(_info: &::core::panic::PanicInfo) -> ! {
loop {}
}
#[no_mangle]
pub unsafe extern "C" fn abort() {
// blink led
loop {}
}
}
You can also experiment with the inlining threshold:
export RUSTFLAGS+=-C inline-threshold=0There is often a criticism of Javascript, that new frameworks seem to appear every week. But it honestly feels like every week on HN there is a new Rust UI project showing up. Whether it is some new HTML/web thing, a native app thing, a TUI thing, etc. Don't get me wrong, I think that is the sign of a very healthy ecosystem. I am just curious how the Rust evangelists will spin this. Somehow this constant churn on the…
I used it for a cross compiled Windows app (did 99% of the development on macOS) and it was quite nice. It was a little limited as far as widget customization went (without getting down and writing your own widgets from scratch) but app ended up looking nice and behaving decently. It also lacked a few features I'd say were essential for any non-small desktop app (multiple top level windows weren't a thing a year ago, not sure if they've been added yet).
I quite liked their DSL for the UI scripting. It was even typechecked a bit and interfaced with Rust in a fairly clean way. It's one of the nicer UI libraries I've used in a while.
The toolkit still seems quite incomplete for desktop use (as opposed to embedded/appliance UIs), as it doesn't support menu bars in an issue open since 2020: https://github.com/slint-ui/slint/issues/38
I just spent the last two weeks choosing an embedded ui framework and then building out a little demo to test out its capabilities. I settled on Slint and have been very impressed with the design of the domain specific language they came up with. It’s small, simple, powerful and easy to learn IMO. The vs code extension for real time gui feedback is amazing. I’ve used swift ui before and Slint is as much of a joy to u…
I wish that there was some GUI lib dedicated to small embedded systems, I just want to draw some buttons and sliders without eating hundreds of flash/ram...
>Attribution to Slint Mmmm no thanks, I'll pass. While I'm looking for a Flutter alternative, this seems like a trap.
We are not a charity and aim to operate on a sustainable development model. While we offer paid and GPL licensing options, we also provide a free-of-charge license that only requires attribution. If you are unwilling to provide even attribution, then Slint may not be the right choice for you.
Yet, it's curious that you compare Slint to LVGL/Flutter/Electron (I don't know about Qt) when none of them have this intrusive requirement.
--- >What's intrusive about it?
(a) Display the AboutSlint widget in an "About" screen or dialog that is accessible from the top level menu of the Application.
(b) Display the Slint attribution badge on a public webpage, where the binaries of your Application can be downloaded from, in such a way that it can be easily found by any visitor to that page.
(c) You may not remove or alter any license notices (including copyright notices, disclaimers of warranty, or limitations of liability) contained within the source code form of the Software.
(d) You allow SixtyFPS to use your Application on the website and in advertising materials of SixtyFPS as a reference and to display your logo and trademark for this purpose.
---
Please don't pretend like a/b/d aren't big asks by saying "you wont even provide attribution?"
Correct and complete text handling is hard. Does Slint handle (did a cursory search in the docs but couldn't find anything that hints at an answer): * multi-line text * languages that use non-Latin characters, as well as mixing them in the same control * RTL and maybe vertical layout
Slint does handle multi-line text and languages that use non-Latin characters. However, we currently do not support vertical layouts.
Also, I just realized I had checked out this project before when it was still called SixtyFPS, https://slint.dev/blog/sixtyfps-becomes-slint . Maybe it would make sense to mention the name change in your post.
It really is not difficult to just call functions to set values. Laying out GUI components is also rarely what takes time when doing GUI programming.
A brand new custom domain specific language has almost no benefits but has huge downsides like having to learn brand new syntax, complete with error messages and debugging. Then you probably have to change GUI values dynamically anyway inside your program. All of this is on top of the added bloat, which itself is strange for a 'embedded usage'.
I think a lot of newer GUI libraries would be better off porting FLTK to work on their platform, it is very simple and easy to understand underneath.