2 ms·

First they have to decide what distribution actually matters for the desktop, out of hundreds that get forked for frivolous reasons. And yes accessibility and

by pjmlp 9mo ago

First they have to decide what distribution actually matters for the desktop, out of hundreds that get forked for frivolous reasons. And yes accessibility and localisation were already a thing in Windows 3.x, classical Mac OS, OS/2,...

Ygg2 9mo ago
I'm talking about accessibility and localization as part of a GUI toolkit. Take localization. Any doofus with CSV and regex can localize a binary. How do you localize dynamic things like "Hi (Sir) PJMLP, you have (0 unread messages)"?[1] In JS I can always Intl.PluralRules. Where are my Plural rules in say C#'s Avalonia (or whatever GUI is hot in C# these days, I can't keep track)? The issue isn't a checklist; it's a quality of availability [2]. The complexity there is essential, because languages are complex beasts, and mitigations for disability are getting better and hence more complex[2]. [1] Why is localizing this a problem? Some languages are language neutral, some have honorific speech, which changes other words, and some have different ways of counting (Hello Welsh. Nice that you have ordinals for zero, one, two, few, many, and more), some have genders, some don't, some have but don't use it in some cases, ad infinitum. [2] There is a huge Mariana Trench in the quality of accessibility for software that offers a magnifying glass and software that offers text-to-speech.
- pjmlp 9mo ago
  And I am talking that was already available in 2000's. Do I have to link to digital copies of documentation to make my point?
  - Ygg2 9mo ago
    Sure. Show me how Windows 3.* supported Unicode, i18n (internationalisation), l10n (localisation), a11y (accessibility), with special focus on CLDR plural rules. Which will be interesting since Unicode 1.0 came around 1991. And CLDR in 2003. And Windows 3.x came in 1990. I'm not saying it is impossible, just highly unlikely MSFT implemented those as early in 3.x. They could have taken part in those early efforts.
    - pjmlp 9mo ago
      If you are so keen in Windows 3.x, remember before standards each OS did its own thing, and I can gladly show you the proprietary APIs used by Windows 3.x. I imagine you never coded for it.
      - Ygg2 9mo ago
        I'm keen on you explaining this part: > And yes accessibility and localisation were already a thing in _Windows 3.x_, Mac, OS/2 (emphasis mine) Because it's the one I used of the things listed, and from my memories, its accessibility was extremely lackluster. I don't care about API as much as you explaining what its a10n features were.
    - speed_spread 9mo ago
      None of the things you mention would have been impossible to integrate in native GUI. They're platform features.
      - Ygg2 9mo ago
        For someone using a GUI toolkit, there is a massive difference between "invent and integrate your own" and "it comes pre-installed". I'm saying the reason modern cross platform GUIs are hard is that the developer and user preferences have changed. Developers want GUIs that come with many bells and whistles. This raises the bar for minimal implementation from - "it will take one guy two weeks to implement" to "it will take a huge group decades of effort to implement." And that's JUST the implementation. At any point, you also face an adoption cliff. Sure, your super layout engine (SLE) might automatically layout stuff, but Josh here doesn't know SLE, he knows CSS.
        speed_spread 9mo ago
        Yeah but whatever the browser provides, the OS can also provide. You don't have to reinvent a browser when you code outside of it. Anyway, this conversation had slipped out of the window. Web app UI programming tools still suck compared to what we had 25 years ago and say what you will, there's NO good reason for that.

by pjmlp 9mo ago

Ygg2 9mo ago

I'm talking about accessibility and localization as part of a GUI toolkit. Take localization. Any doofus with CSV and regex can localize a binary. How do you localize dynamic things like "Hi (Sir) PJMLP, you have (0 unread messages)"?[1] In JS I can always Intl.PluralRules. Where are my Plural rules in say C#'s Avalonia (or whatever GUI is hot in C# these days, I can't keep track)? The issue isn't a checklist; it's a quality of availability [2]. The complexity there is essential, because languages are complex beasts, and mitigations for disability are getting better and hence more complex[2]. [1] Why is localizing this a problem? Some languages are language neutral, some have honorific speech, which changes other words, and some have different ways of counting (Hello Welsh. Nice that you have ordinals for zero, one, two, few, many, and more), some have genders, some don't, some have but don't use it in some cases, ad infinitum. [2] There is a huge Mariana Trench in the quality of accessibility for software that offers a magnifying glass and software that offers text-to-speech.

pjmlp 9mo ago
And I am talking that was already available in 2000's. Do I have to link to digital copies of documentation to make my point?
- Ygg2 9mo ago
  Sure. Show me how Windows 3.* supported Unicode, i18n (internationalisation), l10n (localisation), a11y (accessibility), with special focus on CLDR plural rules. Which will be interesting since Unicode 1.0 came around 1991. And CLDR in 2003. And Windows 3.x came in 1990. I'm not saying it is impossible, just highly unlikely MSFT implemented those as early in 3.x. They could have taken part in those early efforts.
  - pjmlp 9mo ago
    If you are so keen in Windows 3.x, remember before standards each OS did its own thing, and I can gladly show you the proprietary APIs used by Windows 3.x. I imagine you never coded for it.
    - Ygg2 9mo ago
      I'm keen on you explaining this part: > And yes accessibility and localisation were already a thing in _Windows 3.x_, Mac, OS/2 (emphasis mine) Because it's the one I used of the things listed, and from my memories, its accessibility was extremely lackluster. I don't care about API as much as you explaining what its a10n features were.
  - speed_spread 9mo ago
    None of the things you mention would have been impossible to integrate in native GUI. They're platform features.
    - Ygg2 9mo ago
      For someone using a GUI toolkit, there is a massive difference between "invent and integrate your own" and "it comes pre-installed". I'm saying the reason modern cross platform GUIs are hard is that the developer and user preferences have changed. Developers want GUIs that come with many bells and whistles. This raises the bar for minimal implementation from - "it will take one guy two weeks to implement" to "it will take a huge group decades of effort to implement." And that's JUST the implementation. At any point, you also face an adoption cliff. Sure, your super layout engine (SLE) might automatically layout stuff, but Josh here doesn't know SLE, he knows CSS.
      - speed_spread 9mo ago
        Yeah but whatever the browser provides, the OS can also provide. You don't have to reinvent a browser when you code outside of it. Anyway, this conversation had slipped out of the window. Web app UI programming tools still suck compared to what we had 25 years ago and say what you will, there's NO good reason for that.