3 ms·

> Interface Builder is separate, and keeps its view data stored separately, because a WYSIWYG editor can't touch code. (Actually, Delphi showed that it was poss

by porker 12y ago

> Interface Builder is separate, and keeps its view data stored separately, because a WYSIWYG editor can't touch code. (Actually, Delphi showed that it was possible, but that's another story.) Oooh, do tell!

lobster_johnson 12y ago
Delphi automatically synchronized itself with your code. They called this "two-way editing" and it was magical, and worked wonderfully. Let's say you created a form, which in Delphi parlance was a surface that could inhabit controls, typically an actual application window. You would get this empty window: http://www.vwlowen.co.uk/basicdelphi/images/theide.jpg http://www.vwlowen.co.uk/basicdelphi/images/theide.jpg You would also automatically get a source file containing the class definition for that form, roughly corresponding to a window controller class in Cococa. This class would be completely empty, mind; no init code needed or anything: http://136513.jakero00.web.hosting-test.net/wp-content/uploads/2011/10/delphi-7-lite-full-edition.png http://136513.jakero00.web.hosting-test.net/wp-content/uploa... (The GUI layout would live in a separate binary "form file" you never needed to edit directly. This file contained serialized objects that you could read and write in code, similar to OS X bundles, except more easily extensible.) This class would be, by virtue of having the same base file name, automatically linked up with the corresponding form, so you could quickly switch between code and UI. Then if you added a button the form, Delphi would automatically add a private member variable declaration "FButton1: TButton" to your class definition, as glimpsed here: http://www.delphisources.ru/pages/faq/master-delphi-7/content/images/fig05_02_0.jpg http://www.delphisources.ru/pages/faq/master-delphi-7/conten... The framework would know, from the GUI definition, that FButton1 was that button. You could edit it and move it around in your code, and it would still be bound correctly. Same thing with event handlers: If you went into the button's inspector and double-clicked on the "click" handler, it created the method for you, and placed the cursor in the right place so you could immediately fill it out with code. This system made developers insanely productive, because the "boilerplate interactions" were reduced to almost nothing, and all the work was actual work. No "IBOutlet" stuff needed, no manually connecting the variable to the right thing in the GUI builder, and very little setup. A few more brilliant, deceptively minor details made this even more magical. First, the form you edited was truly "live". Delphi actually rendered real controls in the editor. If you created a control that did custom rendering, it would render like that in the GUI editor, live. Interface Builder sort of does this, but not quite, and custom controls are a pain and apparently no longer supported. The second thing was the object inspector: https://www.ibm.com/developerworks/data/library/techarticle/dm-0404swart/figure2.jpg https://www.ibm.com/developerworks/data/library/techarticle/... Interface Builder has a very poor one; Delphi's felt natural. Every property exposed by a control would be visible there through reflection: Delphi would actually parse properties out of your code. It supported structured properties, so if something was a TFont, it expanded into sub-properties for font name, font size and so on. If you created a new class TGradientButton or something, and exposed two properties FromColor and ToColor, they would show up in the object inspector, automatically, and since these properties would be something like TColor, it would know to display an RGB widget for them. You could also register custom object inspector behaviour, so that, instead of FromColor/ToColor, perhaps there was only one property "Gradient" of type TGradient. Your custom object inspector thingy could then render a gradient editor for that property. XCode + Interface Builder is about 10% of what Delphi was. I say "was", it still exists, but I haven't touched it since around 2000-2001. It's insane that Delphi 1.0 in 1995 was more powerful than XCode + Interface Builder today. (I suppose it lives on in the Visual.NET tools; after creating Delphi, Anders Hejlsberg joined Microsoft and created C#. But I haven't used any of it.)

by porker 12y ago

lobster_johnson 12y ago

Delphi automatically synchronized itself with your code. They called this "two-way editing" and it was magical, and worked wonderfully. Let's say you created a form, which in Delphi parlance was a surface that could inhabit controls, typically an actual application window. You would get this empty window: http://www.vwlowen.co.uk/basicdelphi/images/theide.jpg http://www.vwlowen.co.uk/basicdelphi/images/theide.jpg You would also automatically get a source file containing the class definition for that form, roughly corresponding to a window controller class in Cococa. This class would be completely empty, mind; no init code needed or anything: http://136513.jakero00.web.hosting-test.net/wp-content/uploads/2011/10/delphi-7-lite-full-edition.png http://136513.jakero00.web.hosting-test.net/wp-content/uploa... (The GUI layout would live in a separate binary "form file" you never needed to edit directly. This file contained serialized objects that you could read and write in code, similar to OS X bundles, except more easily extensible.) This class would be, by virtue of having the same base file name, automatically linked up with the corresponding form, so you could quickly switch between code and UI. Then if you added a button the form, Delphi would automatically add a private member variable declaration "FButton1: TButton" to your class definition, as glimpsed here: http://www.delphisources.ru/pages/faq/master-delphi-7/content/images/fig05_02_0.jpg http://www.delphisources.ru/pages/faq/master-delphi-7/conten... The framework would know, from the GUI definition, that FButton1 was that button. You could edit it and move it around in your code, and it would still be bound correctly. Same thing with event handlers: If you went into the button's inspector and double-clicked on the "click" handler, it created the method for you, and placed the cursor in the right place so you could immediately fill it out with code. This system made developers insanely productive, because the "boilerplate interactions" were reduced to almost nothing, and all the work was actual work. No "IBOutlet" stuff needed, no manually connecting the variable to the right thing in the GUI builder, and very little setup. A few more brilliant, deceptively minor details made this even more magical. First, the form you edited was truly "live". Delphi actually rendered real controls in the editor. If you created a control that did custom rendering, it would render like that in the GUI editor, live. Interface Builder sort of does this, but not quite, and custom controls are a pain and apparently no longer supported. The second thing was the object inspector: https://www.ibm.com/developerworks/data/library/techarticle/dm-0404swart/figure2.jpg https://www.ibm.com/developerworks/data/library/techarticle/... Interface Builder has a very poor one; Delphi's felt natural. Every property exposed by a control would be visible there through reflection: Delphi would actually parse properties out of your code. It supported structured properties, so if something was a TFont, it expanded into sub-properties for font name, font size and so on. If you created a new class TGradientButton or something, and exposed two properties FromColor and ToColor, they would show up in the object inspector, automatically, and since these properties would be something like TColor, it would know to display an RGB widget for them. You could also register custom object inspector behaviour, so that, instead of FromColor/ToColor, perhaps there was only one property "Gradient" of type TGradient. Your custom object inspector thingy could then render a gradient editor for that property. XCode + Interface Builder is about 10% of what Delphi was. I say "was", it still exists, but I haven't touched it since around 2000-2001. It's insane that Delphi 1.0 in 1995 was more powerful than XCode + Interface Builder today. (I suppose it lives on in the Visual.NET tools; after creating Delphi, Anders Hejlsberg joined Microsoft and created C#. But I haven't used any of it.)