Let's write a toy UI library(nakst.gitlab.io)
nakst.gitlab.io
Let's write a toy UI library
https://nakst.gitlab.io/tutorial/ui-part-1.html
29 comments
If you don't keep it as a toy, it can get out of hand quickly. For example, here's the partial implementation of QWidget, almost 500k of code: https://github.com/qt/qtbase/blob/dev/src/widgets/kernel/qwi...
I haven't yet written a UI library so it's not something I can state confidently, but based on adjacent work I've done, I imagine that a significant deal of complexity can be avoided by somewhat paradoxically embracing complexity early on and designing for all the eventualities.
UI frameworks are one place where outside of toy projects, YAGNI doesn't really apply as much, and so things like focus systems and accessibility affordances should be factored in from day one. If you go in with the attitude of writing something "elegant", you're going to end up bolting these things on after the fact and writing contorted code to make it all fit together. It's like finding out that you need a skyscraper after building foundations and framing for a cottage.
UI frameworks are one place where outside of toy projects, YAGNI doesn't really apply as much, and so things like focus systems and accessibility affordances should be factored in from day one. If you go in with the attitude of writing something "elegant", you're going to end up bolting these things on after the fact and writing contorted code to make it all fit together. It's like finding out that you need a skyscraper after building foundations and framing for a cottage.
FWIW it doesn't need to become 500k lines of code... or 13k in QWidget's case :-P. The file is large because it contains the full documentation in addition to the code but also in Qt is a QWidget can also be a (toplevel) window so it needs to support everything a window may want to support, including stuff like setting/getting title, maximize/minimize/etc events, etc.
You can avoid this complexity in the base widget class by placing those elsewhere, e.g. FLTK's base widget class[0] is much smaller at around 500 lines of code (+ documentation comments).
[0] https://github.com/fltk/fltk/blob/master/src/Fl_Widget.cxx
You can avoid this complexity in the base widget class by placing those elsewhere, e.g. FLTK's base widget class[0] is much smaller at around 500 lines of code (+ documentation comments).
[0] https://github.com/fltk/fltk/blob/master/src/Fl_Widget.cxx
Which of these 24 parts cover accessibility?
Ah, this one:
> That said, you could add a description string to the common element header that screen readers could use, but accessibility concerns are out of scope for this toy UI library.
I love it when tutorials teach people to ignore people like me.
Am I being harsh? Well where's the tutorial that teaches people how to do it properly? Where do people actually learn the right way if not here?
Ah, this one:
> That said, you could add a description string to the common element header that screen readers could use, but accessibility concerns are out of scope for this toy UI library.
I love it when tutorials teach people to ignore people like me.
Am I being harsh? Well where's the tutorial that teaches people how to do it properly? Where do people actually learn the right way if not here?
I don't know if you're harsh, but one thing I've thought before I've clicked the link was "oh, another gui toolkit reinvention, I wonder how many times it will reinvent what's already invented and how many already solved problems it will simply ignore".
Well, I guess accessibility is one thing it skipped. It's a huge topic, I admit, so I'm not particularily surprised, but I think a better way for the author of this series would be to promote already existing huge toolkits that do have lots of functionalities built-in, including accessibility, like Qt for example.
That would be good also because already established huge toolkits have already answered a lot of important questions, questions which "modern" GUI toolkits simply ignore. New generations won't even know what we had when we were young.
Well, I guess accessibility is one thing it skipped. It's a huge topic, I admit, so I'm not particularily surprised, but I think a better way for the author of this series would be to promote already existing huge toolkits that do have lots of functionalities built-in, including accessibility, like Qt for example.
That would be good also because already established huge toolkits have already answered a lot of important questions, questions which "modern" GUI toolkits simply ignore. New generations won't even know what we had when we were young.
The point of this isn’t to make another production-ready UI library. The point of it is to learn how UI libraries work by doing it yourself.
Do you walk into a beginner woodworkers class and scoff at them for making yet another birdhouse?
Do you walk into a beginner woodworkers class and scoff at them for making yet another birdhouse?
> oh, another gui toolkit reinvention
Imagine wanting to understand how an existing technology works…
Imagine wanting to understand how an existing technology works…
I think you're being disingenuous. The author could have made this tutorial for the 90% of people that do not have these concerns. Time isn't free and projects people work on in their spare time shouldn't have these snarky comments in response.
> Am I being harsh? Well where's the tutorial that teaches people how to do it properly? Where do people actually learn the right way if not here?
I would love to read your blog post on how to do so! After all, since you seem to imply that time is free for everyone, you shouldn't have any problem making that blog post.
> Am I being harsh? Well where's the tutorial that teaches people how to do it properly? Where do people actually learn the right way if not here?
I would love to read your blog post on how to do so! After all, since you seem to imply that time is free for everyone, you shouldn't have any problem making that blog post.
Leaving accessibility out of an UI library tutorial is like leaving security out of an API tutorial. It’s perfectly possible to build something that’s probably not a problem if you’re building a toy application, but if you haven’t done it right from the start it will absolutely bite you hard, and it’ll broadly be quicker to start over from scratch than try to fix the mess.
The math: There are N tutorials written per year. There are M accessibility experts willing and able to write tutorials. N >> M by orders of magnitude. The ask is for M people to produce N parallel accessible versions of everything, forever, as a prerequisite for being allowed to point out the gap exists.
This doesn't make sense. Why do M people need to write N accessibility tutorials to point out the gap in accessibility support? The same isn't true for localisation for example.
[deleted]
Please can you post a link to your own tutorial on this?
Ah! So it's my responsibility to teach you how to program properly! I must now police every possible new tutorial, framework, library release, and if the author didn't include accessibility I should ... Make my complete alternative version of that thing! With Accessibility included! This is ... super Scalable!
Or, you know, if you say "This is how you make a UI library" maybe you could think about ... what a USER INTERFACE actually is? Because blind people are users? and we need to interface?
Or, you know, if you say "This is how you make a UI library" maybe you could think about ... what a USER INTERFACE actually is? Because blind people are users? and we need to interface?
Do you not see the irony? If it's not your responsibility, why should it be the responsibility of the author of this tutorial?
People write tutorials on what they are interested in, what they have knowledge of, and what they want to share.
Accessibility is an important topic, to be sure, and is clearly of particularly high importance to you. Others might complain that they didn't include how to create a high performance table view, or embed an OpenGL view. I think most people, however, will take it as what it is - a well written, helpful contribution.
Your comment specifically asked if you were being harsh, and the consensus appears to be "yes". Perhaps if you worded things differently you might get a different response.
People write tutorials on what they are interested in, what they have knowledge of, and what they want to share.
Accessibility is an important topic, to be sure, and is clearly of particularly high importance to you. Others might complain that they didn't include how to create a high performance table view, or embed an OpenGL view. I think most people, however, will take it as what it is - a well written, helpful contribution.
Your comment specifically asked if you were being harsh, and the consensus appears to be "yes". Perhaps if you worded things differently you might get a different response.
> is clearly of particularly high importance to you
Tactless.
Tactless.
You could submit your PR to Nakst's Luigi toolkit: https://github.com/nakst/luigi
You don't have to make a complete alternative. You can add calls to ATK (accessibility toolkit) on Linux/Unix platforms. I'm not sure what needs to be done on Win32 platforms though.
You don't have to make a complete alternative. You can add calls to ATK (accessibility toolkit) on Linux/Unix platforms. I'm not sure what needs to be done on Win32 platforms though.
Yes, I would say this is harsh.
Primarily because OP actually did call out accessibility as a concern. That is the opposite of teaching the reader to ignore people who use a11y features. Nor is it OP's responsibility to teach their readers anything they don't care to.
And yeah, where are the tutorials you'd like to see? That could have been a more constructive thing for you to share yourself instead of demanding it from no one in particular.
Primarily because OP actually did call out accessibility as a concern. That is the opposite of teaching the reader to ignore people who use a11y features. Nor is it OP's responsibility to teach their readers anything they don't care to.
And yeah, where are the tutorials you'd like to see? That could have been a more constructive thing for you to share yourself instead of demanding it from no one in particular.
It's unfortunate that accessibility is so often neglected, but at the same time this tutorial seems to be more about the basic concepts of how a UI library works, not a complete overview of every aspect.
They also didn't include text rendering for scripts that are written right-to-left, nor for scripts that are written vertically, and that affects far more people than those who use screen readers.
Clearly they are not intending to provide a complete and comprehensive course on every aspect of the ideal UI library.
They also didn't include text rendering for scripts that are written right-to-left, nor for scripts that are written vertically, and that affects far more people than those who use screen readers.
Clearly they are not intending to provide a complete and comprehensive course on every aspect of the ideal UI library.
[deleted]
You're being unfair and need to get off your high horse or your wheelchair. I'm sure the accessibility can be iterated upon the basics of UI, not have to rewrite the whole thing from scratch; this tutorial only covers the basics, can't blame OP for that.
Rather, why don't you make your comment constructive and tell us about accessibility? I am sure there is an "accessibility for noobs" tutorial out there that the rest of us haven't discovered. I, for one, just recently learned about colour blindness in games and was absolutely mad when I saw what the example game in the book looks like to a colour-blind person. Not that I'm much of a designer, but I'll be sure to choose a universally-good colour palette next time I do any UI. So teach us instead of yelling at us.
Rather, why don't you make your comment constructive and tell us about accessibility? I am sure there is an "accessibility for noobs" tutorial out there that the rest of us haven't discovered. I, for one, just recently learned about colour blindness in games and was absolutely mad when I saw what the example game in the book looks like to a colour-blind person. Not that I'm much of a designer, but I'll be sure to choose a universally-good colour palette next time I do any UI. So teach us instead of yelling at us.
Seems to be exactly what I was looking for. Somehow it's not that easy to find a good explanation of these techniques. I tried old graphic programming books, but their sections on GUI are tiny.
Read the original Inside Macintosh, since that's about as fundamental and basic as it gets. See how they did the API for the Event, Window, and Control Mangers.
Thanks! I didn't think of that.
It looks like WinAPI Window Management via CreateWindow / SetWindowText / SendMessage.
https://gist.github.com/a3f/22d0d2688b56e79865f8
https://gist.github.com/a3f/22d0d2688b56e79865f8
[deleted]
Have not read all of it but it looks great. Also like the minimalistic style of the website.
is it an application builder?