3 ms·

I went pretty deep on swift mac UI development at some point but I was left disappointed. I've realized that building your own gui toolkit isn't that hard. Righ

I went pretty deep on swift mac UI development at some point but I was left disappointed. I've realized that building your own gui toolkit isn't that hard. Right now, I'm building my own toolkit in Rust with this Rust nanovg clone called gpucanvas https://github.com/cytecbg/gpucanvas https://github.com/cytecbg/gpucanvas. Here's another nanovg based gui toolkit in cpp https://github.com/wjakob/nanogui https://github.com/wjakob/nanogui Thanks to Rust macros, you can shape the language to be essentially whatever you want. I think that ECS (entity component system https://en.wikipedia.org/wiki/Entity_component_system https://en.wikipedia.org/wiki/Entity_component_system) is the way go with GUIs.

doteka 6y ago
Could you elaborate on what you found easy about writing a GUI toolkit? Not being snarky, but easy is the last word I would use to describe it.
- adamnemecek 6y ago
  I didn't say easy, I said it's not too bad. Look at this toolkit for example https://github.com/yushroom/Fishgui https://github.com/yushroom/Fishgui. Once you have rendering (which nanovg handles), you just need some hierarchy, event handling, windowing and layout and you have a basic toolkit. I like the control a lot, with Cocoa, I felt really constrained sometimes.
  - PaulDavisThe1st 6y ago
    text input (right to left, left to right, compose chars) ? tree views (with non-textual cells)? nested menus? file selection dialog?
    - adamnemecek 6y ago
      You should wrap native file dialogs. Text input direction isn't that big of a deal if your rendering supports it. Tree views are somewhat tricky but not that much harder than list views.
  - millstone 6y ago
    Now draw the rest of the owl! A key point of a shared UI toolkit is that users can bring their knowledge from one app to another. A standard Cocoa table view or text view has tons of advanced behaviors: type select, keyboard shortcuts, etc. It's worth the user's time to learn these because they work in every app. But apps where these don't work feel discordant and frustrating.
    - adamnemecek 6y ago
      You can mimic native behaviors. But these are different between say browser and native cocoa apps anyway.
      - saagarjha 6y ago
        This is why many people are frustrated by web applications that do not mimic features they expect from native Cocoa apps.
      - kergonath 6y ago
        You won’t ever produce a perfect imitation. UIs based on third-party toolkits are always a pain, stuck in the uncanny valley. They look somewhat like they should, but have all sorts of quirks that break useability: text fields that don’t support standard shortcuts, weird layouts, wrong fonts, buttons that cannot be selected with the keyboard, etc. It is much, much better to use Apple’s toolkits.
        adamnemecek 6y ago
        How many shortcuts are there realistically? 50?
        kergonath 6y ago
        Probably around that by default, maybe a bit more: https://jblevins.org/log/kbd https://jblevins.org/log/kbd https://www.howtogeek.com/681662/35-mac-text-editing-keyboard-shortcuts-to-speed-up-typing/ https://www.howtogeek.com/681662/35-mac-text-editing-keyboar... But all of them need to work, along with system-wide custom ones. Text substitution is also an issue.
  - coldtea 6y ago
    >you just need some hierarchy, event handling, windowing and layout and you have a basic toolkit. Yeah. Once you add hierarchy, event handling, windowing, and layout to a rendering engine you pretty much have a basic toolkit. Kind of like once you've hand built a cpu, gpu, logic board, hard drive, and so on, on top of 3d-printing a case, you have a basic PC.
    - adamnemecek 6y ago
      This is a basic toolkit in like 3000 loc https://github.com/yushroom/Fishgui https://github.com/yushroom/Fishgui. It uses nanovg.
  - doteka 6y ago
    That sounds like an insane amount of work to me to end up with something objectively worse from a usability standpoint. But to each their own.
    - adamnemecek 6y ago
      It's debatable how much worse usability is.
  - nikki93 6y ago
    A certain genre of apps, especially eg. digital audio workstations, manage to do this and also have a sizeable userbase. Ableton Live is an example here. It seems especially sensible if your design does actually have a bunch of controls you need custom rendering for. Honestly, don't let these comments get you down. It's important to act strategically of course, so it doesn't make sense to over-invest in an idea succeeding. But it makes sense to do scoped experiments / proof-of-concepts. I don't think we're "done" with UI framework architecture design, people need to keep trying new things in the space. And I also don't think only Apple (eg. SwiftUI) and Google (eg. Flutter) are allowed to work on these things and we need to accept their gifts from above. Some times, a good quality here is almost not believing that something is too hard to do (while obviously also informing oneself about as much existing work there has been as possible to incorporate it into the experiments).
  - filleduchaos 6y ago
    And what of accessibility?
- jitl 6y ago
  UI programming - and GUI toolkit programming - is all about breadth. There’s a ton of things a UI needs to do, but most of those things are straightforward to implement, and there’s usually a plethora of lower-level libraries to compose in any given area. So, it does take a lot of work to implement a UI (toolkit) but not much of it is a stumper. And, many areas of UI toolkit functionality can be ignored or have low-quality implementation for a long time. For example, a hobbyist writing their own UI toolkit can ignore accessibility, but still end up with something usable by the hobbyist. Or, the initial implementation can use only absolute layout. Or, the initial implementation can use only a single fixed-width bitmap ASCII font.
readarticle 6y ago
Does the lack of arthritic, farsighted Arabic speaking users factor into it not being too hard or is that whole mess already built into the underlying libraries? UI platforms as a rule are always terrible, but there’s inevitably a whole lot of baby in the bath water.
- adamnemecek 6y ago
  It depends. How does Cocoa handle arthritic users? It's not baby with the bathwater, the second you want something cross platform, your choices are electron or qt? Neither is that great of an option.
  - readarticle 6y ago
    Common, customizable keyboard shortcuts & behaviors across the entire OS are huge for people with arthritis that can’t use a mouse, Automator workflows that hook in and take care of repetitive tasks are common and eventually Siri Shortcuts will be available on macOS like iOS. Last year Voice Control: https://www.apple.com/macos/catalina/docs/Voice_Control_Tech_Brief_Sept_2019.pdf https://www.apple.com/macos/catalina/docs/Voice_Control_Tech... came out and is absolutely stunning and free with accessibility labels. A custom UI would force them into “grid mode” on page 6 off the bat while it’s almost too easy if you just stay native, UI tests interact with the app through accessibility labels for example, and obviously we’re all testing, right? Simply riding closely on the back of the behemoth that’s weirdly good about accessibility gets one very far, very fast.
    - adamnemecek 6y ago
      Too bad this behemoth doesn't care about cross-platform.
      - readarticle 6y ago
        Too bad disabled users don’t either. Cross platform wasn’t even mentioned or implied in your original comment by the way, it was edited into the second one where you narrowed an “arthritic, farsighted Arabic speaking user” into “arthritic”.
pjmlp 6y ago
How well does it actually implement each platform L&F (specially the feel part), does data virtualization, UI designers, support for disabled people and respective assistive technologies? Drawing buttons and windows is easy, the problem is the rest.

doteka 6y ago

Could you elaborate on what you found easy about writing a GUI toolkit? Not being snarky, but easy is the last word I would use to describe it.

adamnemecek 6y ago
I didn't say easy, I said it's not too bad. Look at this toolkit for example https://github.com/yushroom/Fishgui https://github.com/yushroom/Fishgui. Once you have rendering (which nanovg handles), you just need some hierarchy, event handling, windowing and layout and you have a basic toolkit. I like the control a lot, with Cocoa, I felt really constrained sometimes.
- PaulDavisThe1st 6y ago
  text input (right to left, left to right, compose chars) ? tree views (with non-textual cells)? nested menus? file selection dialog?
  - adamnemecek 6y ago
    You should wrap native file dialogs. Text input direction isn't that big of a deal if your rendering supports it. Tree views are somewhat tricky but not that much harder than list views.
- millstone 6y ago
  Now draw the rest of the owl! A key point of a shared UI toolkit is that users can bring their knowledge from one app to another. A standard Cocoa table view or text view has tons of advanced behaviors: type select, keyboard shortcuts, etc. It's worth the user's time to learn these because they work in every app. But apps where these don't work feel discordant and frustrating.
  - adamnemecek 6y ago
    You can mimic native behaviors. But these are different between say browser and native cocoa apps anyway.
    - saagarjha 6y ago
      This is why many people are frustrated by web applications that do not mimic features they expect from native Cocoa apps.
    - kergonath 6y ago
      You won’t ever produce a perfect imitation. UIs based on third-party toolkits are always a pain, stuck in the uncanny valley. They look somewhat like they should, but have all sorts of quirks that break useability: text fields that don’t support standard shortcuts, weird layouts, wrong fonts, buttons that cannot be selected with the keyboard, etc. It is much, much better to use Apple’s toolkits.
      - adamnemecek 6y ago
        How many shortcuts are there realistically? 50?
        kergonath 6y ago
        Probably around that by default, maybe a bit more: https://jblevins.org/log/kbd https://jblevins.org/log/kbd https://www.howtogeek.com/681662/35-mac-text-editing-keyboard-shortcuts-to-speed-up-typing/ https://www.howtogeek.com/681662/35-mac-text-editing-keyboar... But all of them need to work, along with system-wide custom ones. Text substitution is also an issue.
- coldtea 6y ago
  >you just need some hierarchy, event handling, windowing and layout and you have a basic toolkit. Yeah. Once you add hierarchy, event handling, windowing, and layout to a rendering engine you pretty much have a basic toolkit. Kind of like once you've hand built a cpu, gpu, logic board, hard drive, and so on, on top of 3d-printing a case, you have a basic PC.
  - adamnemecek 6y ago
    This is a basic toolkit in like 3000 loc https://github.com/yushroom/Fishgui https://github.com/yushroom/Fishgui. It uses nanovg.
- doteka 6y ago
  That sounds like an insane amount of work to me to end up with something objectively worse from a usability standpoint. But to each their own.
  - adamnemecek 6y ago
    It's debatable how much worse usability is.
- nikki93 6y ago
  A certain genre of apps, especially eg. digital audio workstations, manage to do this and also have a sizeable userbase. Ableton Live is an example here. It seems especially sensible if your design does actually have a bunch of controls you need custom rendering for. Honestly, don't let these comments get you down. It's important to act strategically of course, so it doesn't make sense to over-invest in an idea succeeding. But it makes sense to do scoped experiments / proof-of-concepts. I don't think we're "done" with UI framework architecture design, people need to keep trying new things in the space. And I also don't think only Apple (eg. SwiftUI) and Google (eg. Flutter) are allowed to work on these things and we need to accept their gifts from above. Some times, a good quality here is almost not believing that something is too hard to do (while obviously also informing oneself about as much existing work there has been as possible to incorporate it into the experiments).
- filleduchaos 6y ago
  And what of accessibility?
jitl 6y ago
UI programming - and GUI toolkit programming - is all about breadth. There’s a ton of things a UI needs to do, but most of those things are straightforward to implement, and there’s usually a plethora of lower-level libraries to compose in any given area. So, it does take a lot of work to implement a UI (toolkit) but not much of it is a stumper. And, many areas of UI toolkit functionality can be ignored or have low-quality implementation for a long time. For example, a hobbyist writing their own UI toolkit can ignore accessibility, but still end up with something usable by the hobbyist. Or, the initial implementation can use only absolute layout. Or, the initial implementation can use only a single fixed-width bitmap ASCII font.

readarticle 6y ago

Does the lack of arthritic, farsighted Arabic speaking users factor into it not being too hard or is that whole mess already built into the underlying libraries? UI platforms as a rule are always terrible, but there’s inevitably a whole lot of baby in the bath water.

adamnemecek 6y ago
It depends. How does Cocoa handle arthritic users? It's not baby with the bathwater, the second you want something cross platform, your choices are electron or qt? Neither is that great of an option.
- readarticle 6y ago
  Common, customizable keyboard shortcuts & behaviors across the entire OS are huge for people with arthritis that can’t use a mouse, Automator workflows that hook in and take care of repetitive tasks are common and eventually Siri Shortcuts will be available on macOS like iOS. Last year Voice Control: https://www.apple.com/macos/catalina/docs/Voice_Control_Tech_Brief_Sept_2019.pdf https://www.apple.com/macos/catalina/docs/Voice_Control_Tech... came out and is absolutely stunning and free with accessibility labels. A custom UI would force them into “grid mode” on page 6 off the bat while it’s almost too easy if you just stay native, UI tests interact with the app through accessibility labels for example, and obviously we’re all testing, right? Simply riding closely on the back of the behemoth that’s weirdly good about accessibility gets one very far, very fast.
  - adamnemecek 6y ago
    Too bad this behemoth doesn't care about cross-platform.
    - readarticle 6y ago
      Too bad disabled users don’t either. Cross platform wasn’t even mentioned or implied in your original comment by the way, it was edited into the second one where you narrowed an “arthritic, farsighted Arabic speaking user” into “arthritic”.

pjmlp 6y ago

How well does it actually implement each platform L&F (specially the feel part), does data virtualization, UI designers, support for disabled people and respective assistive technologies? Drawing buttons and windows is easy, the problem is the rest.