7 ms·

How many of those actually look and behave like native and support accessibility correctly?

by jbk 4y ago

nicoburns 4y ago
None yet, but that is being worked on.
Strom 4y ago
What even is "native" on Windows? Is it Win32? WinForms? WPF? UWP? WinUI? Windows App SDK? There's so many to choose from and they all look and behave differently.
- 323 4y ago
  These days the native GUI for Windows is Electron.
  - pjmlp 4y ago
    Not quite, WebView2, which has the benefit of not dragging Chrome with every single application.
- izacus 4y ago
  Any of those will do as long as you don't drag in javascript crap.
- pjmlp 4y ago
  Win32, WinForms, WPF are as good as it gets, and really the only ones that matter. UWP is deprecated, althought it keeps being the one mostly used on Windows 11, as WinUI still isn't up to its game and keeps collecting issues across all their repos. Windows App SDK is not a GUI framework, rather the new marketing name for Project Reunion, the porting of UWP runtime infrastructure on top of standard COM without sandoxing and application identity.
  - chronogram 4y ago
    Do you know which of those toolkits is used for the new Windows 11 Notepad? It's quite a bit more "laggy" to scroll in than the old Notepad that's still on the Server edition.
    - pjmlp 4y ago
      The old notepad was Win32, the new one is WinUI, there you have it, how good WinUI is in its current state. https://www.thurrott.com/windows/windows-11/260092/hands-on-with-the-redesigned-notepad-for-windows-11 https://www.thurrott.com/windows/windows-11/260092/hands-on-...
- jbk 4y ago
  Many of those are native enough, meaning they inherit the style from the desktop (and not just emulate it), do they support accessibility and so on. For example, QtWidgets is native and qml is not. WxWidgets is, electron is not.
Macha 4y ago
The native toolkits, and Qt. Gtk if you're on Linux
tpush 4y ago
Native doesn't really exist on desktops except macOS, but accessibility is a good question.
ogoffart 4y ago
With Slint [https://slint-ui.com https://slint-ui.com], our aim is to achieve native look and feel, and accessibility.
zackbrown 4y ago
This is a core design goal for Pax. https://www.pax-lang.org https://www.pax-lang.org Pax composites a layer of native text and form elements on top of a canvas drawing layer. This solves accessibility across platforms, as well SEO on the Web. This approach also enables a lean runtime footprint (<100Kb, particularly useful when targeting Web) because the runtime doesn't need to reinvent text rendering, selection, input, etc. Still early days — have made very little noise thus far; it's pre-alpha — but you can see what's cooking at https://docs.pax-lang.org/ https://docs.pax-lang.org/ and https://www.github.com/pax-lang/pax https://www.github.com/pax-lang/pax
- jbk 4y ago
  It does not answer the native styling though…
  - zackbrown 4y ago
    Pax does solve this, but we're now discussing a different problem than element-level look-and-feel or accessibility. Three ways you can slice this with Pax, ft. pseudocode: 1. Conditional templating, like: <SomeLayout> if $is_android { //Only render the back button for Android <BackButton /> } /* ... */ </SomeLayout> 2. Dynamic properties where Rust logic checks for the target platform, like: <SomeElement some_property={self.get_platform_specific_value()} /> 3. Maintain a separate codebase (or different specific components) for each target platform, in the spirit of React Native Or any mix of the above.
    - zamadatix 4y ago
      Does this actually render a native Android back button to the canvas or are you simply saying Pax solves this by not restricting the user from making their own solution to the problem?
      - zackbrown 4y ago
        Pax's Android chassis isn't built yet — but a Pax `<Button>` will render an actual native Android button to a layer on top of a separate canvas layer where vector drawing occurs. That native Android button will be affine-transformed, clipped, and occluded so that the two layers together act as a single coherent screen, and the developer can simply position / transform / layout that `<Button>` alongside, on top of, or underneath virtual / drawn elements as if they were on the same canvas. This "dual layer" approach is already implemented for Pax's `<Text>` element on macOS (native SwiftUI `Text`) and Web (native `<div>` + HTML text) — see: https://docs.pax-lang.org/intro-example.html https://docs.pax-lang.org/intro-example.html
bryanlarsen 4y ago
The native bindings are the first section on the list, and they work well. If you're concerned about looking and behaving native just use those native bindings.

How many of those actually look and behave like native and support accessibility correctly?

by jbk 4y ago

How many of those actually look and behave like native and support accessibility correctly?

nicoburns 4y ago

None yet, but that is being worked on.

Strom 4y ago

What even is "native" on Windows? Is it Win32? WinForms? WPF? UWP? WinUI? Windows App SDK? There's so many to choose from and they all look and behave differently.

323 4y ago
These days the native GUI for Windows is Electron.
- pjmlp 4y ago
  Not quite, WebView2, which has the benefit of not dragging Chrome with every single application.
izacus 4y ago
Any of those will do as long as you don't drag in javascript crap.
pjmlp 4y ago
Win32, WinForms, WPF are as good as it gets, and really the only ones that matter. UWP is deprecated, althought it keeps being the one mostly used on Windows 11, as WinUI still isn't up to its game and keeps collecting issues across all their repos. Windows App SDK is not a GUI framework, rather the new marketing name for Project Reunion, the porting of UWP runtime infrastructure on top of standard COM without sandoxing and application identity.
- chronogram 4y ago
  Do you know which of those toolkits is used for the new Windows 11 Notepad? It's quite a bit more "laggy" to scroll in than the old Notepad that's still on the Server edition.
  - pjmlp 4y ago
    The old notepad was Win32, the new one is WinUI, there you have it, how good WinUI is in its current state. https://www.thurrott.com/windows/windows-11/260092/hands-on-with-the-redesigned-notepad-for-windows-11 https://www.thurrott.com/windows/windows-11/260092/hands-on-...
jbk 4y ago
Many of those are native enough, meaning they inherit the style from the desktop (and not just emulate it), do they support accessibility and so on. For example, QtWidgets is native and qml is not. WxWidgets is, electron is not.

Macha 4y ago

The native toolkits, and Qt. Gtk if you're on Linux

tpush 4y ago

Native doesn't really exist on desktops except macOS, but accessibility is a good question.

ogoffart 4y ago

With Slint [https://slint-ui.com https://slint-ui.com], our aim is to achieve native look and feel, and accessibility.

zackbrown 4y ago

This is a core design goal for Pax. https://www.pax-lang.org https://www.pax-lang.org Pax composites a layer of native text and form elements on top of a canvas drawing layer. This solves accessibility across platforms, as well SEO on the Web. This approach also enables a lean runtime footprint (<100Kb, particularly useful when targeting Web) because the runtime doesn't need to reinvent text rendering, selection, input, etc. Still early days — have made very little noise thus far; it's pre-alpha — but you can see what's cooking at https://docs.pax-lang.org/ https://docs.pax-lang.org/ and https://www.github.com/pax-lang/pax https://www.github.com/pax-lang/pax

jbk 4y ago
It does not answer the native styling though…
- zackbrown 4y ago
  Pax does solve this, but we're now discussing a different problem than element-level look-and-feel or accessibility. Three ways you can slice this with Pax, ft. pseudocode: 1. Conditional templating, like: <SomeLayout> if $is_android { //Only render the back button for Android <BackButton /> } /* ... */ </SomeLayout> 2. Dynamic properties where Rust logic checks for the target platform, like: <SomeElement some_property={self.get_platform_specific_value()} /> 3. Maintain a separate codebase (or different specific components) for each target platform, in the spirit of React Native Or any mix of the above.
  - zamadatix 4y ago
    Does this actually render a native Android back button to the canvas or are you simply saying Pax solves this by not restricting the user from making their own solution to the problem?
    - zackbrown 4y ago
      Pax's Android chassis isn't built yet — but a Pax `<Button>` will render an actual native Android button to a layer on top of a separate canvas layer where vector drawing occurs. That native Android button will be affine-transformed, clipped, and occluded so that the two layers together act as a single coherent screen, and the developer can simply position / transform / layout that `<Button>` alongside, on top of, or underneath virtual / drawn elements as if they were on the same canvas. This "dual layer" approach is already implemented for Pax's `<Text>` element on macOS (native SwiftUI `Text`) and Web (native `<div>` + HTML text) — see: https://docs.pax-lang.org/intro-example.html https://docs.pax-lang.org/intro-example.html

bryanlarsen 4y ago

The native bindings are the first section on the list, and they work well. If you're concerned about looking and behaving native just use those native bindings.