5 ms·

Slint dev here. I'm a bit disappointed to see that Slint is considered a non-starter. In fact, one of our users is currently working on exactly that (a VST plu

Slint dev here. I'm a bit disappointed to see that Slint is considered a non-starter. In fact, one of our users is currently working on exactly that (a VST plugin for an audio application) and they are about to release it very soon. Unfortunately, I can't share a link until it's officially released. The author seems to dismiss declarative UI without explaining why. From my perspective, declarative is the best way to describe UI. Regarding the limited support for custom widgets, I disagree. In Slint, it's incredibly easy to create custom widgets. A widget is simply a component that can be created and utilized. While it's true that our desktop integration is still a work in progress, we have already implemented the core functionalities needed for building such UIs. We are actively developing features based on user needs and prioritize implementing features that our users require immediately. If you're interested in using Slint, please reach out to us, and we'll ensure that we implement what is necessary for your product.

chaosprint 3y ago
Do you have plan for wgpu?
- tronical 3y ago
  We're working on interop, so that when you select Slint's Skia renderer on top of Vulkan or Metal, you can import a wgpu texture if wgpu's Metal or Vulkan adapter was chosen. What kind of feature set do you need?
zerr 3y ago
Declarative UI, even when implemented coherently within the same langauge like in Flutter and MAUI/Xamarin, so there is no need for an ugly bridge between two worlds, still leads to an unreadable nested hell. Surprisingly, an imperative GUI creation code is much more easier to read and modify.
- deleted 3y ago
  [deleted]
- mort96 3y ago
  Hmm? I've written a fair bit of React, which I assume fits the declarative description, and I never got the impression that it leads to an "unreadable nested hell". You split up your big functions into smaller reusable functions, just like in all other forms of programming.
  - akdor1154 3y ago
    By the traditions of desktop ui, React is imperative (or maybe immediate): it's written in a declarative style, but ultimately jsx is just JavaScript. The best analogue to "declarative" in desktop ui terms would be to have your dom templates in separate files that you don't manipulate the structure of in code. I honestly have an overall negative view of react, but its method for letting you declare ui structure is really fantastic.
- ogoffart 3y ago
  I respectfully disagree. In my experience, Declarative UI is more concise, making development and changes easier. It enhances productivity and allows for a clear separation of concerns, which is beneficial. Moreover, Declarative UI enables the development of powerful tooling and visual editors. For instance, in Slint, we have an extension that provides live UI preview and code transformation capabilities. We are also actively working on a visual editor that lets users drag and drop widgets. Such capabilities are difficult or impossible to achieve with imperative APIs.
  - pkphilip 3y ago
    Have you looked at tools such as Delphi, Lazarus etc and the approach used to build GUI components which can be added at build time or at runtime? If you are interested in talking about this, do let me know.
  - lelanthran 3y ago
    > We are also actively working on a visual editor that lets users drag and drop widgets. Such capabilities are difficult or impossible to achieve with imperative APIs I don't think you have ever used an imperative API, have you? I used VB, then Delphi, then C++ builder and now use Lazarus, and there's no declarative equivalent that is easier or faster than those.
    - ogoffart 3y ago
      In the examples you mentioned, the UI is typically described in XML or form files (.dfm), which is essentially a declarative approach, and clearly not described in imperative code. Although they may not be intended to be edited by hand, the underlying representation is still declarative in nature.
      - lelanthran 3y ago
        Agreed, but they were easily achieved with imperative APIs. This is the statement I was contending: > We are also actively working on a visual editor that lets users drag and drop widgets. Such capabilities are difficult or impossible to achieve with imperative APIs Maybe I should have said "there's no declarative-only equivalents that's easier or faster". As someone else pointed out elsethread, declarative is a subset of imperative, so it's easy to produce an imperative API that consumes machine-generated declarations, but not so easy to use a declarative-only framework to reproduce the ease and speed of Delphi, Lazarus, etc.
- pkphilip 3y ago
  Absolutely. I actually prefer a combination of declarative + imperative code similar to how it is in Delphi/Lazarus. The overall layout of the GUI is designed using a GUI designer and this gets saved as a "form" in a resource file which is loaded at run time and so the actual code does not have a lot of declaration of the GUI but it is read in as a stream from a separate resource file. However, to this GUI, you can add event handlers, add or remove components at run time etc. All of this is quite clumsily done (IMHO) in frameworks such as flutter.
larschdk 3y ago
I find Slint's font rendering odd and somewhat off-putting. It doesn't look sharp, especially on classic 96 DPI displays. Big text look inconsistently both fuzzy and aliased, and small text has inconsistent intensity. Lack of subpixel rendering and hinting? Rounded corners look sharp in comparison.
- rob74 3y ago
  That's unfortunately an issue I have seen with several new GUI frameworks over the last years: with High-DPI displays getting more widespread, they tend to push subpixel rendering support down the road.
  - mort96 3y ago
    And understandably so. Du pixel rendering only works on some kinds of displays (many modern displays don't have 3 vertical subpixels per pixel), makes the text look kinda bad due to the wonky colors, really doesn't mesh well with any sort of transparency or even coloured text, it requires that you keep 3 images of each glyph in memory to account for the 3 different sub pixel offsets. It also deeply entangles detailed knowledge of the monitor into your font rendering. You need to re-render everything and update all text any time orientation changes or the window is dragged between monitors. And how the hell do you handle a window stretching across 2 different monitors? That's not to dismiss subpixel rendering, there is arguably a legibility improvement to trading off color accuracy for horizontal resolution, but it's really no wonder that new frameworks don't bother and that old frameworks are losing the ability to do subpixel rendering. Apple, for example, ripped out subpixel rendering from their frameworks a long time ago (before Retina displays, IIRC).
    - rob74 3y ago
      > Apple, for example, ripped out subpixel rendering from their frameworks a long time ago (before Retina displays, IIRC). ...or at least when Retina displays were still rare and expensive, probably to encourage their adoption.
andyjohnson0 3y ago
> From my perspective, declarative is the best way to describe UI I agree. It seems like we have some good solutions for declaratively describing the structure and static appearance of UIs - but beyond things like transition animations, we don't have anything that satisfactorily describes their behaviour. Its a hard problem nut I sometimes wonder why this aspect is under-served by the technologies we have.
rendaw 3y ago
While it's not super clear, I think TFA's issue with Slint is the markup file (new syntax, not rust, special tooling/dev environment?), not the declarative bit. After all, they didn't say anything about Iced which is also declarative.
- ogoffart 3y ago
  Good point. I don't see the issue with a new syntax either. GUI libraries always come with their own set of large APIs and conventions, so learning a new syntax isn't a big deal. The special tooling and dev environment in Slint are optional. But if you do use them, the Language Server Protocol (LSP) allow to integrate them everywhere and provides handy features like code completion, navigation, and even a live preview.
wokwokwok 3y ago
> The author seems to dismiss declarative UI without explaining why. From my perspective, declarative is the best way to describe UI. …but I mean, that’s an opinion that is not falsifiable. If the author disagrees, that’s up to them right? I agree with the author too; after using xaml, my taste for declarative UIs is limited. Here’s something that is falsifiable: what is possible using declarative UIs is a strict subset of what is possible using imperative code. If your declarative config is Turing complete, it’s a DSL; ie. a programming language, not declarative and you’re in “not invented here” land. If not, the possibilities for it are a subset. That’s provable; so, if you’re worried that your UI is too complex to easily represent with the existing declarative structure, go for code. What if you need dynamic layouts? What if your layouts are determined at runtime by dynamically loaded plug-ins? What if your layout needs to generated differently based on themes, or screen sizes? Who knows? It seems entirely reasonable. The same goes for other declarative solutions and projects. Eg. Terraform. I mean, the author literally says a) it’s a trade off for velocity, b) they’re more concerned with performance, c) the implementation in slint is not complete and d) they’re considering writing a very very low level UI library to get what they want. …maybe, they just want different things to what you’re offering? It doesn’t mean they’re “wrong”.
- rat9988 3y ago
  I'm not sure where you read "wrong". Did the message get edited?
  - TheMaskedCoder 3y ago
    Those are scare quotes around the word. It's not quoting the parent comment.
  - wokwokwok 3y ago
    No, sorry if my "'s made it appear I was quoting a literal text. What I mean is: > The author seems to dismiss declarative UI without explaining why. > From my perspective, declarative is the best way to describe UI. I think it's pretty clear that the writer here believes that the OP is wrong about slint and declarative UIs. My point is that OP is not wrong; declarative UI is not the best way of doing UI for all use cases. It is simply one way of doing UI.
duped 3y ago
Most plugin UIs are extremely simple compared to a DAW, and have the nice property that most of the time they aren't visible.
- ninepoints 3y ago
  This is absolutely not the case for many DAW plugins
  - duped 3y ago
    Which part isn't the case?
    - ninepoints 3y ago
      Plugins in DAWs are graphically complex, animate, and exhibit plenty of the issues described about DAWs themselves
      - duped 3y ago
        Yes, but a DAW must do that dozens/hundreds of times more and is on screen for the entire lifetime of the program. I stand by what I said: most plugins have nowhere near the complexity of a DAW. Some do! (Kontakt/Reakt, and so on) but the vast majority only have a small subset of what the DAW needs to display, and only need to do it for a limited number of channels, and only need to do it rarely.
ninepoints 3y ago
As a previous Qt user, I never got on the qml train and stayed firmly in widgets land. Declarative uis work well, until they don't because of custom requirements, and then they simply get in the way. They are harder to debug and understand from a code perspective. Not everyone writes apps that target both desktop and mobile.

chaosprint 3y ago

Do you have plan for wgpu?

tronical 3y ago
We're working on interop, so that when you select Slint's Skia renderer on top of Vulkan or Metal, you can import a wgpu texture if wgpu's Metal or Vulkan adapter was chosen. What kind of feature set do you need?

zerr 3y ago

Declarative UI, even when implemented coherently within the same langauge like in Flutter and MAUI/Xamarin, so there is no need for an ugly bridge between two worlds, still leads to an unreadable nested hell. Surprisingly, an imperative GUI creation code is much more easier to read and modify.

deleted 3y ago
[deleted]
mort96 3y ago
Hmm? I've written a fair bit of React, which I assume fits the declarative description, and I never got the impression that it leads to an "unreadable nested hell". You split up your big functions into smaller reusable functions, just like in all other forms of programming.
- akdor1154 3y ago
  By the traditions of desktop ui, React is imperative (or maybe immediate): it's written in a declarative style, but ultimately jsx is just JavaScript. The best analogue to "declarative" in desktop ui terms would be to have your dom templates in separate files that you don't manipulate the structure of in code. I honestly have an overall negative view of react, but its method for letting you declare ui structure is really fantastic.
ogoffart 3y ago
I respectfully disagree. In my experience, Declarative UI is more concise, making development and changes easier. It enhances productivity and allows for a clear separation of concerns, which is beneficial. Moreover, Declarative UI enables the development of powerful tooling and visual editors. For instance, in Slint, we have an extension that provides live UI preview and code transformation capabilities. We are also actively working on a visual editor that lets users drag and drop widgets. Such capabilities are difficult or impossible to achieve with imperative APIs.
- pkphilip 3y ago
  Have you looked at tools such as Delphi, Lazarus etc and the approach used to build GUI components which can be added at build time or at runtime? If you are interested in talking about this, do let me know.
- lelanthran 3y ago
  > We are also actively working on a visual editor that lets users drag and drop widgets. Such capabilities are difficult or impossible to achieve with imperative APIs I don't think you have ever used an imperative API, have you? I used VB, then Delphi, then C++ builder and now use Lazarus, and there's no declarative equivalent that is easier or faster than those.
  - ogoffart 3y ago
    In the examples you mentioned, the UI is typically described in XML or form files (.dfm), which is essentially a declarative approach, and clearly not described in imperative code. Although they may not be intended to be edited by hand, the underlying representation is still declarative in nature.
    - lelanthran 3y ago
      Agreed, but they were easily achieved with imperative APIs. This is the statement I was contending: > We are also actively working on a visual editor that lets users drag and drop widgets. Such capabilities are difficult or impossible to achieve with imperative APIs Maybe I should have said "there's no declarative-only equivalents that's easier or faster". As someone else pointed out elsethread, declarative is a subset of imperative, so it's easy to produce an imperative API that consumes machine-generated declarations, but not so easy to use a declarative-only framework to reproduce the ease and speed of Delphi, Lazarus, etc.
pkphilip 3y ago
Absolutely. I actually prefer a combination of declarative + imperative code similar to how it is in Delphi/Lazarus. The overall layout of the GUI is designed using a GUI designer and this gets saved as a "form" in a resource file which is loaded at run time and so the actual code does not have a lot of declaration of the GUI but it is read in as a stream from a separate resource file. However, to this GUI, you can add event handlers, add or remove components at run time etc. All of this is quite clumsily done (IMHO) in frameworks such as flutter.

larschdk 3y ago

I find Slint's font rendering odd and somewhat off-putting. It doesn't look sharp, especially on classic 96 DPI displays. Big text look inconsistently both fuzzy and aliased, and small text has inconsistent intensity. Lack of subpixel rendering and hinting? Rounded corners look sharp in comparison.

rob74 3y ago
That's unfortunately an issue I have seen with several new GUI frameworks over the last years: with High-DPI displays getting more widespread, they tend to push subpixel rendering support down the road.
- mort96 3y ago
  And understandably so. Du pixel rendering only works on some kinds of displays (many modern displays don't have 3 vertical subpixels per pixel), makes the text look kinda bad due to the wonky colors, really doesn't mesh well with any sort of transparency or even coloured text, it requires that you keep 3 images of each glyph in memory to account for the 3 different sub pixel offsets. It also deeply entangles detailed knowledge of the monitor into your font rendering. You need to re-render everything and update all text any time orientation changes or the window is dragged between monitors. And how the hell do you handle a window stretching across 2 different monitors? That's not to dismiss subpixel rendering, there is arguably a legibility improvement to trading off color accuracy for horizontal resolution, but it's really no wonder that new frameworks don't bother and that old frameworks are losing the ability to do subpixel rendering. Apple, for example, ripped out subpixel rendering from their frameworks a long time ago (before Retina displays, IIRC).
  - rob74 3y ago
    > Apple, for example, ripped out subpixel rendering from their frameworks a long time ago (before Retina displays, IIRC). ...or at least when Retina displays were still rare and expensive, probably to encourage their adoption.

andyjohnson0 3y ago

> From my perspective, declarative is the best way to describe UI I agree. It seems like we have some good solutions for declaratively describing the structure and static appearance of UIs - but beyond things like transition animations, we don't have anything that satisfactorily describes their behaviour. Its a hard problem nut I sometimes wonder why this aspect is under-served by the technologies we have.

rendaw 3y ago

While it's not super clear, I think TFA's issue with Slint is the markup file (new syntax, not rust, special tooling/dev environment?), not the declarative bit. After all, they didn't say anything about Iced which is also declarative.

ogoffart 3y ago
Good point. I don't see the issue with a new syntax either. GUI libraries always come with their own set of large APIs and conventions, so learning a new syntax isn't a big deal. The special tooling and dev environment in Slint are optional. But if you do use them, the Language Server Protocol (LSP) allow to integrate them everywhere and provides handy features like code completion, navigation, and even a live preview.

wokwokwok 3y ago

> The author seems to dismiss declarative UI without explaining why. From my perspective, declarative is the best way to describe UI. …but I mean, that’s an opinion that is not falsifiable. If the author disagrees, that’s up to them right? I agree with the author too; after using xaml, my taste for declarative UIs is limited. Here’s something that is falsifiable: what is possible using declarative UIs is a strict subset of what is possible using imperative code. If your declarative config is Turing complete, it’s a DSL; ie. a programming language, not declarative and you’re in “not invented here” land. If not, the possibilities for it are a subset. That’s provable; so, if you’re worried that your UI is too complex to easily represent with the existing declarative structure, go for code. What if you need dynamic layouts? What if your layouts are determined at runtime by dynamically loaded plug-ins? What if your layout needs to generated differently based on themes, or screen sizes? Who knows? It seems entirely reasonable. The same goes for other declarative solutions and projects. Eg. Terraform. I mean, the author literally says a) it’s a trade off for velocity, b) they’re more concerned with performance, c) the implementation in slint is not complete and d) they’re considering writing a very very low level UI library to get what they want. …maybe, they just want different things to what you’re offering? It doesn’t mean they’re “wrong”.

rat9988 3y ago
I'm not sure where you read "wrong". Did the message get edited?
- TheMaskedCoder 3y ago
  Those are scare quotes around the word. It's not quoting the parent comment.
- wokwokwok 3y ago
  No, sorry if my "'s made it appear I was quoting a literal text. What I mean is: > The author seems to dismiss declarative UI without explaining why. > From my perspective, declarative is the best way to describe UI. I think it's pretty clear that the writer here believes that the OP is wrong about slint and declarative UIs. My point is that OP is not wrong; declarative UI is not the best way of doing UI for all use cases. It is simply one way of doing UI.

duped 3y ago

Most plugin UIs are extremely simple compared to a DAW, and have the nice property that most of the time they aren't visible.

ninepoints 3y ago
This is absolutely not the case for many DAW plugins
- duped 3y ago
  Which part isn't the case?
  - ninepoints 3y ago
    Plugins in DAWs are graphically complex, animate, and exhibit plenty of the issues described about DAWs themselves
    - duped 3y ago
      Yes, but a DAW must do that dozens/hundreds of times more and is on screen for the entire lifetime of the program. I stand by what I said: most plugins have nowhere near the complexity of a DAW. Some do! (Kontakt/Reakt, and so on) but the vast majority only have a small subset of what the DAW needs to display, and only need to do it for a limited number of channels, and only need to do it rarely.

ninepoints 3y ago

As a previous Qt user, I never got on the qml train and stayed firmly in widgets land. Declarative uis work well, until they don't because of custom requirements, and then they simply get in the way. They are harder to debug and understand from a code perspective. Not everyone writes apps that target both desktop and mobile.