3 ms·
These are interesting points (although I don't quite follow some of your explanations). I've been trying to learn more about the history of GUI development, so
by zengid 8y ago
These are interesting points (although I don't quite follow some of your explanations). I've been trying to learn more about the history of GUI development, so I appreciate hearing about how it's been done.
Here's an interesting discussion of Delphi (2013):
https://news.ycombinator.com/item?id=7613543 https://news.ycombinator.com/item?id=7613543
- vintagedave 8y agoSure - it was quick! Here's a short overview of how Delphi's UI design works. First, you have a visual form designer: drop a button, resize it, edit the caption, etc. All objects like buttons, edit boxes etc are classes with properties. They live on a form, another class. The key is object streaming. The form has instance variables: a private MyButton : TButton, for example, where TButton is the type. This list of fields is autogenerated by the IDE. However, those are created and values set not in code or managed by the IDE, but by loading from a human-readable text stream at runtime (stored as a separate file at designtime, and linked as a resource at compiletime), something like, from memory: Form : TForm Button : TButton Left = 100 Top = 50 Width = 70 // etc Caption = 'Hello' OnClick = MyClickHandlerMethod end; end; When the form loads, the object instances and their properties are created and set on the fly. A form will self-initialise it and its owned objects from that stream: it will create a TButton instance, assign it to its own Button field, set the Left and Caption properties for the button etc. That includes hooking up methods to events, which are just properties of a method pointer type. So effectively, you have a human-readable, easily editable format that is a streamed version of a class and instance/property hierarchy, which the class can recreate itself from. That is generated by a visual editor, and of course you can edit it manually. It is a very simple and clean format; as little as possible is stored. It is also very diff-able. Your code then is reduced to things like state changes or events - user clicks a button, you write code to do something. UIs are visual. Writing a complex UI in code is inefficient (manually doing stuff you should not have to do) and with a long modification turnaround time - you can't preview what it looks like, so changes take a long time. The important leap was to design visual elements visually; to stream, so it is OO, diffable, and still human editable if you need to; and to load from a stream via reflection/RTTI. Delphi did all that in 1995. C++Builder does all that too, in C++! It's beautiful compared even to Qt, and certainly compared to code like the original post, which reads like early nineties techniques to someone used to the above.
- vetinari 8y agoThe downside was, that UI design was visual, Delphi used absolute positioned layout and everyone was using pixels (despite VCL supporting pt<->px). Allaire Homesite (one of the early HTML editors), written in Deplhi, was one of the first apps that openly ignored the pt sizing and was broken on computers with Large Fonts setting enabled. After that, everyone started ignoring the DPI, and that is what got us into today's HiDPI mess. Yes, I was pissed of at the time. I was using Large fonts. During a short time, that option became unusable, because nobody bothered with DPI, when drag and drop UI design is so easy.