This is Interface-Builder in view mode; [Up]
Date: Sun 10-Nov-1989 20:26:01 From: Unknown Subject: Interface Builder I saw a demonstration of the NeXT yesterday and have a couple of questions on the Interface Builder (IB), especially from people who are familiar with Prototyper on the Mac. On the surface IB looked very similar to Prototyper except for the fact that (I assume) IB will generate object orientated code and (I would hope) you can create your own interface objects to be used in Inteface Builder. However, one concern that I have is when you finally build you interface and then you add all of you custom code to do the special things you program is ment to do, can you go back to IB and change things without any grief. With Prototyper, you often have to re-insert your own code after making interface changes effectively making Prototyper a one way street: once you create an interface and add your own code, you will probably not use Prototype again since you've modified the files it created. Does Interface Builder have similar problems? I would like to get a feeling to how it works and how easy it is to use Interface Builder through the entire development process. I'm looking for the dream development evironment that would allow truely using object orientated (visual) programming through the whole development process. Steven Miller Vancouver Division Hewlett Packard ...hplabs!hpvcfs1!stevem >From: surak@jessica.Stanford.EDU (Jayson Adams)
Date: Sun 11-Nov-1989 20:31:48 From: Unknown Subject: Re: Interface Builder In article <770001@hpvcfs1.HP.COM> stevem@hpvcfs1.HP.COM (Steve Miller) writes: >I saw a demonstration of the NeXT yesterday and have a couple of questions >on the Interface Builder (IB) ... > ... one concern that I have is when you finally build you interface and >then you add all of you custom code to do the special things you program is >ment to do, can you go back to IB and change things without any grief. With >Prototyper, you often have to re-insert your own code after making interface >changes effectively making Prototyper a one way street: once you create an >interface and add your own code, you will probably not use Prototype again >since you've modified the files it created. This is not a problem with Interface Builder; you can go back and change the interface as much as you want even after you've written your code. Interface Builder doesn't generate any code to create the user interface; it simply generates archive files that describe the user interface and the messages to be sent when the various user interface objects (buttons, sliders, etc) are fiddled with. In IB-speak, the messages to be sent by UI objects are known as "actions" and the objects to receive these messages are the "targets." All target-action messages follow the same structure: The only argument passed in the message is a pointer to the UI object sending the message. The target object will ask the sender for more details if it needs to. This makes it very easy to change the interface even after you've created and written all your back-end code. For instance, you can usually replace all your number input boxes with sliders within a matter of seconds and not have to change any code. >Does Interface Builder have similar problems? In some cases, yes, but to a much lesser extent, and not at all when it comes to creating/editing your interface. One case where it does happen is when you describe a new class of your own to Interface Builder through the IB class window. You can make IB generate skeleton interface & implementation files for your class by using the "Unparse" button. However, if you then go ahead and edit these skeleton files, you won't be able to "Unparse" anymore as IB will overwrite any changes. One way to get around this problem is to use the parse feature of IB: IB can read an interface file back in, through the "Parse" button. So you can make your changes to the interface and implementation files and then do a "Parse" to load the new description back into IB. If you follow the same format for describing the various actions and outlets as IB does when it generates the interface files, this will work out fine. Ali >From: hoffman@ux1.cso.uiuc.edu
Date: Sun 13-Nov-1989 01:31:00 From: Unknown Subject: Re: Interface Builder Besides, Prototyper produces VERY general (sloppy) code with tons of extra variables that you have to go remove yourself. Prototype also takes modularity to such an extreme it makes me ill. Steve ___________________________________________________________________ | Steve M. Hoffman | email: abby@uiuc.edu | | University of Illinois | internet: hoffman%ux1@uxc.cso.uiuc.edu | | Champaign/Urbana | uucp: uunet!uiucuxc!ux1!hoffman | |________________________| usmail: 515 Bash Ct. #24 | | I haven't a clue what | Champaign, IL 61820 | | I'm doing here | (217)/359-7448 | |________________________|________________________________________| >From: avie@wb1.cs.cmu.edu (Avadis Tevanian)
Date: Sun 14-Nov-1989 18:32:00 From: Unknown Subject: Re: Interface Builder Steve Miller writes: > I saw a demonstration of the NeXT yesterday and have a couple of questions > on the Interface Builder (IB), especially from people who are familiar with > Prototyper on the Mac. > However, one concern that I have is when you finally build you interface and > then you add all of you custom code to do the special things you program is > ment to do, can you go back to IB and change things without any grief. Although I'm not familiar with Prototype, I echo your concern. I asked this very question at a demo I attended several months ago (given by Bruce Webster). Unfortunately, the answer is NO (or, was 'no'). Apparently, NeXT sees IB as a "prototyper" and "initial implementation generator" and NOT as an Interface Modifier. Perhaps I would not be so sensitive to this "lack of a neato function", but I have seen a similar tool here at HP that DOES allow one to modify the interface. The basic idea with this tool is that you define "callbacks" (functions) for events. These functions are defined in #include files which are not modified by the interface builder. Unfortunately, the NeXT IB requires you to modify the files it generates. If you can figure out some way to do these modifications in a "repeatable" way, great! Good luck! =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Edward McClanahan Hewlett Packard Company Mail Stop 47UE -or- edwardm%hpda@hplabs.hp.com 19447 Pruneridge Avenue Cupertino, CA 95014 Phone: (408)447-5651 >From: eps@toaster.SFSU.EDU (Eric P. Scott)
Date: Sun 15-Nov-1989 03:32:07 From: Unknown Subject: Re: Interface Builder In article <680016@hpcuhc.HP.COM> edwardm@hpcuhc.HP.COM (Edward McClanahan) writes: >Steve Miller writes: > >> However, one concern that I have is when you finally build you interface and >> then you add all of you custom code to do the special things you program is >> ment to do, can you go back to IB and change things without any grief. > >Although I'm not familiar with Prototype, I echo your concern. I asked this >very question at a demo I attended several months ago (given by Bruce Webster). >Unfortunately, the answer is NO (or, was 'no'). Apparently, NeXT sees IB as >a "prototyper" and "initial implementation generator" and NOT as an Interface >Modifier. I don't have any great problem with this under 1.0, although it does take a little hacking. If you have an interface for a class Foo in files Foo.h and Foo.m and you want to add an action newAction: to Foo, add a method declaration - newAction:sender; to Foo.h and a method definition - newAction:sender { return self; } to Foo.m. Save the files, go into InterfaceBuilder, select Foo in the Class browser, and pull the pulldown to Parse. It will tell you that the methods have changed, do you want to do this?? Answer yes. Now if you look at the actions for Foo, you will see newAction: there and you will be able to connect to it. You can do the same with outlets. To add an outlet newOutlet to Foo, add id newOutlet; to the instance variables of Foo in Foo.h and the method - setNewOutlet:anObject { newOutlet = anObject; return self; } to Foo.m and repeat the parsing procedure. I assume you can delete actions and outlets by deleting the appropriate definitions and methods, but I haven't tried it. And of course, if you're not changing any outlets or actions you can fiddle with the rest of the interface to your heart's content without changing your custom code. Bob Bob Olson University of Illinois at Urbana/Champaign >From: ali@polya.Stanford.EDU (Ali T. Ozer)
Date: Sun 15-Nov-1989 15:54:09 From: Unknown Subject: Re: Interface Builder In article <680016@hpcuhc.HP.COM> Edward McClanahan writes: >Steve Miller writes: >> ..., one concern that I have is when you finally build you interface and >> then you add all of you custom code to do the special things you program is >> ment to do, can you go back to IB and change things without any grief. >Unfortunately, the answer is NO (or, was 'no'). Apparently, NeXT sees IB as >a "prototyper" and "initial implementation generator" and NOT as an Interface >Modifier. That's not correct; NeXT sees Interface Builder as a tool that lets you create and then modify the user interfaces of applications with equal ease at any time during the development. As I mentioned in an earlier message, IB does not generate any code at all for the interface, instead, it generates archive files that can be modified at any time with IB. One of the things you do when editing the UI through Interface Builder is to specify the object to be notified when an button is pressed (or a menu item is selected, etc) and specify what message is to be sent. The UI objects are instantiated and the connections between them and their targets are made when the archive file is read into the application (at runtime). The only time you fall into the problem you mention is when you use IB to generate ("unparse") skeleton interface/implementation files for your custom classes. (I talked about this in somewhat more detail in an earlier message.) After the first time you generate these files, if you edit them, it's not easy to use IB to add to them. So instead you end up editing the actual files and using IB's "parse" function to load the class descriptions back into IB. Not a big problem, and certainly not one that prevents you from editing/changing your user interface over and over. Ali >From: dml@esl.com (Denis Lynch)
Date: Sun 15-Nov-1989 22:23:46 From: Unknown Subject: Re: Interface Builder In article <680016@hpcuhc.HP.COM> edwardm@hpcuhc.HP.COM (Edward McClanahan) writes: Steve Miller writes: > I saw a demonstration of the NeXT yesterday and have a couple of questions > on the Interface Builder (IB), especially from people who are familiar with > Prototyper on the Mac. > However, one concern that I have is when you finally build you interface and > then you add all of you custom code to do the special things you program is > ment to do, can you go back to IB and change things without any grief. Although I'm not familiar with Prototype, I echo your concern. But the worst thing is that you're not familiar with the NeXT either! I have seen a similar tool here at HP that DOES allow one to modify the interface. The basic idea with this tool is that you define "callbacks" (functions) for events. These functions are defined in #include files which are not modified by the interface builder. Unfortunately, the NeXT IB requires you to modify the files it generates. I presume you are speaking of UIMX. The facilities of the two are not all that different. IB maintains its own files of what UI objects connect to what program objects, and what messages the UI objects send. UIMX does too. But UIMX eventually writes out UIL, which you are free to modify at your peril. The NeXT files you may be alluding to are the Objective C class definition files that IB will generate for you *as a convenience*. So consider a scenario where you are building a program and its interface. You connect a UI widget (say a button) to some object in the program (a valueController). You say that this button should send the reset message to the valueController. So what really happened here? You gave IB a spec for the valueController class, so it would know which messages can be sent to one of its instances. You can do this in two ways: you can tell IB to read in a class definition, or you can manually enter the class description and tell IB to generate the Objective C code. Now you want to change the class specification. You can do that either by editing the Objective C code, or by modifying the class description within IB. If you edit the source code, you can then ask IB to read it in and update its version of the specification. If you modify the class description within IB, then you have two choices again: ask IB to generate the Objective C code again, or modify the code by hand. If you choose the first path, then any changes you put in (like putting real code in those methods!) will be lost. Whoops. The second isn't real cute either, since there are no guarantees you make the same modes. So the moral is, if you're going to modify a class definition then modify the Objective C code and tell IB to go find out what you did. But the real question seems to be about something else entirely: what happens if you want to change the appearance of the UI object, or what it connects to, or what message it sends? In this case, IB does precisely the right thing: it keeps all this in data structures, it *never* generates code. You use IB to modify the data structures, even after the program is "delivered." For packaging convenience, NeXT applications are generally shipped with the IB description imbedded in a segment in the applications' Mach-O executable files. But they can still be extracted, edited with IB, and put back. So IB provides exactly the most important capability: you can modify the interface appearance and behavior well beyond the last minute, and without ever touching any code! Sorry to go on for so long, but all this discussion about how the software *might* work inspire me to "set the record straight." Denis Lynch ESL, Inc. >From: judge@gpu.utcs.utoronto.ca (Peter Judge)
Date: Sun 15-Nov-1989 03:32:07 From: Unknown Subject: Re: Interface Builder In article <680016@hpcuhc.HP.COM> edwardm@hpcuhc.HP.COM (Edward McClanahan) writes: >Steve Miller writes: > >> However, one concern that I have is when you finally build you interface and >> then you add all of you custom code to do the special things you program is >> ment to do, can you go back to IB and change things without any grief. > >Although I'm not familiar with Prototype, I echo your concern. I asked this >very question at a demo I attended several months ago (given by Bruce Webster). >Unfortunately, the answer is NO (or, was 'no'). Apparently, NeXT sees IB as >a "prototyper" and "initial implementation generator" and NOT as an Interface >Modifier. I don't have any great problem with this under 1.0, although it does take a little hacking. If you have an interface for a class Foo in files Foo.h and Foo.m and you want to add an action newAction: to Foo, add a method declaration - newAction:sender; to Foo.h and a method definition - newAction:sender { return self; } to Foo.m. Save the files, go into InterfaceBuilder, select Foo in the Class browser, and pull the pulldown to Parse. It will tell you that the methods have changed, do you want to do this?? Answer yes. Now if you look at the actions for Foo, you will see newAction: there and you will be able to connect to it. You can do the same with outlets. To add an outlet newOutlet to Foo, add id newOutlet; to the instance variables of Foo in Foo.h and the method - setNewOutlet:anObject { newOutlet = anObject; return self; } to Foo.m and repeat the parsing procedure. I assume you can delete actions and outlets by deleting the appropriate definitions and methods, but I haven't tried it. And of course, if you're not changing any outlets or actions you can fiddle with the rest of the interface to your heart's content without changing your custom code. Bob Bob Olson University of Illinois at Urbana/Champaign >From: judge@gpu.utcs.utoronto.ca (Peter Judge)
Date: Sun 15-Nov-1989 15:54:09 From: Unknown Subject: Re: Interface Builder In article <680016@hpcuhc.HP.COM> Edward McClanahan writes: >Steve Miller writes: >> ..., one concern that I have is when you finally build you interface and >> then you add all of you custom code to do the special things you program is >> ment to do, can you go back to IB and change things without any grief. >Unfortunately, the answer is NO (or, was 'no'). Apparently, NeXT sees IB as >a "prototyper" and "initial implementation generator" and NOT as an Interface >Modifier. That's not correct; NeXT sees Interface Builder as a tool that lets you create and then modify the user interfaces of applications with equal ease at any time during the development. As I mentioned in an earlier message, IB does not generate any code at all for the interface, instead, it generates archive files that can be modified at any time with IB. One of the things you do when editing the UI through Interface Builder is to specify the object to be notified when an button is pressed (or a menu item is selected, etc) and specify what message is to be sent. The UI objects are instantiated and the connections between them and their targets are made when the archive file is read into the application (at runtime). The only time you fall into the problem you mention is when you use IB to generate ("unparse") skeleton interface/implementation files for your custom classes. (I talked about this in somewhat more detail in an earlier message.) After the first time you generate these files, if you edit them, it's not easy to use IB to add to them. So instead you end up editing the actual files and using IB's "parse" function to load the class descriptions back into IB. Not a big problem, and certainly not one that prevents you from editing/changing your user interface over and over. Ali >From: dml@esl.com (Denis Lynch)
Date: Sun 15-Nov-1989 22:23:46 From: Unknown Subject: Re: Interface Builder In article <680016@hpcuhc.HP.COM> edwardm@hpcuhc.HP.COM (Edward McClanahan) writes: Steve Miller writes: > I saw a demonstration of the NeXT yesterday and have a couple of questions > on the Interface Builder (IB), especially from people who are familiar with > Prototyper on the Mac. > However, one concern that I have is when you finally build you interface and > then you add all of you custom code to do the special things you program is > ment to do, can you go back to IB and change things without any grief. Although I'm not familiar with Prototype, I echo your concern. But the worst thing is that you're not familiar with the NeXT either! I have seen a similar tool here at HP that DOES allow one to modify the interface. The basic idea with this tool is that you define "callbacks" (functions) for events. These functions are defined in #include files which are not modified by the interface builder. Unfortunately, the NeXT IB requires you to modify the files it generates. I presume you are speaking of UIMX. The facilities of the two are not all that different. IB maintains its own files of what UI objects connect to what program objects, and what messages the UI objects send. UIMX does too. But UIMX eventually writes out UIL, which you are free to modify at your peril. The NeXT files you may be alluding to are the Objective C class definition files that IB will generate for you *as a convenience*. So consider a scenario where you are building a program and its interface. You connect a UI widget (say a button) to some object in the program (a valueController). You say that this button should send the reset message to the valueController. So what really happened here? You gave IB a spec for the valueController class, so it would know which messages can be sent to one of its instances. You can do this in two ways: you can tell IB to read in a class definition, or you can manually enter the class description and tell IB to generate the Objective C code. Now you want to change the class specification. You can do that either by editing the Objective C code, or by modifying the class description within IB. If you edit the source code, you can then ask IB to read it in and update its version of the specification. If you modify the class description within IB, then you have two choices again: ask IB to generate the Objective C code again, or modify the code by hand. If you choose the first path, then any changes you put in (like putting real code in those methods!) will be lost. Whoops. The second isn't real cute either, since there are no guarantees you make the same modes. So the moral is, if you're going to modify a class definition then modify the Objective C code and tell IB to go find out what you did. But the real question seems to be about something else entirely: what happens if you want to change the appearance of the UI object, or what it connects to, or what message it sends? In this case, IB does precisely the right thing: it keeps all this in data structures, it *never* generates code. You use IB to modify the data structures, even after the program is "delivered." For packaging convenience, NeXT applications are generally shipped with the IB description imbedded in a segment in the applications' Mach-O executable files. But they can still be extracted, edited with IB, and put back. So IB provides exactly the most important capability: you can modify the interface appearance and behavior well beyond the last minute, and without ever touching any code! Sorry to go on for so long, but all this discussion about how the software *might* work inspire me to "set the record straight." Denis Lynch ESL, Inc. >From: chase@boulder.Colorado.EDU (Stumpy)
These are the contents of the former NiCE NeXT User Group NeXTSTEP/OpenStep software archive, currently hosted by Marcel Waldvogel and Netfuture.ch.