4 ms·

As an alternative for Electron it's not as important, so I cheer the effort. But... For me that means it's not really "native". Native as in CPU native is jus

by hawski 8y ago

As an alternative for Electron it's not as important, so I cheer the effort. But... For me that means it's not really "native". Native as in CPU native is just to say it's reasonably fast and efficient. It's nice, but I'm looking for platform native. When your application is native in the first sense, you are competing with almost everyone. Games, even applications written with SDL are native in this sense. And almost every cross-perform widget toolkit out there - Qt, GTK+, FLTK, Fox Toolkit, IUP, Juce... I think that then you also need to state if you handle accessibility. If you don't handle it _yet_ you better have a plan to do so. With accessibility you could cross out most of the toolkits I mentioned. That's how you stand out. Now I'm wondering is there a toolkit that started as a crossplatform accessibility library and then gained rendering capabilities? I think accessibility is harder, so when it's bolted on later it's even harder.

saagarjha 8y ago
Qt is "semi-native" in the sense that it uses native components, but does so in a hackish, "lowest common denominator" way. It's better than the other alternatives you've mentioned.
- ptx 8y ago
  Qt renders its own widgets, just like this library, although it does use the native theming APIs to make them look native. You might be thinking of wxWidgets.
  - saagarjha 8y ago
    Thanks, I combined the two in my head :(
yourapostasy 8y ago
> With accessibility you could cross out most of the toolkits I mentioned. That's how you stand out. I'd like to see accessibility baked-in because that would be my preferred path to a fully-addressable/programmable UI, and UI-QA-as-code. The way we QA UI's today is way too hack'ish. I want to be able to write unit tests for the UI within the development flow of writing the UI itself, not in some external, bolted-on fashion. Part of what seems missing is I can call the UI to perform some action on my behalf, but querying the compositor upon the final results sitting on the display output seems to be haphazardly available; I can query for some elements, but not all, or I can query for pixels but not what UI element those pixels belong to.

by hawski 8y ago

saagarjha 8y ago

Qt is "semi-native" in the sense that it uses native components, but does so in a hackish, "lowest common denominator" way. It's better than the other alternatives you've mentioned.

ptx 8y ago
Qt renders its own widgets, just like this library, although it does use the native theming APIs to make them look native. You might be thinking of wxWidgets.
- saagarjha 8y ago
  Thanks, I combined the two in my head :(

yourapostasy 8y ago

> With accessibility you could cross out most of the toolkits I mentioned. That's how you stand out. I'd like to see accessibility baked-in because that would be my preferred path to a fully-addressable/programmable UI, and UI-QA-as-code. The way we QA UI's today is way too hack'ish. I want to be able to write unit tests for the UI within the development flow of writing the UI itself, not in some external, bolted-on fashion. Part of what seems missing is I can call the UI to perform some action on my behalf, but querying the compositor upon the final results sitting on the display output seems to be haphazardly available; I can query for some elements, but not all, or I can query for pixels but not what UI element those pixels belong to.