ali@polya.Stanford.EDU (Ali T. Ozer) (12/14/88)
-- In article <307@internal.Apple.COM> lsr@Apple.COM (Larry Rosenstein) writes: >In article <7884@well.UUCP> Jef Poskanzer <jef@rtsg.ee.lbl.gov> writes: >>And while we're pointing out things that NeXT copied from, has anyone else >>noted the similarity of Application Builder to Paul Haeberli's "data-flow >>programming environment"? See the 1986 Summer Usenix proceedings, page 419. > >A reference on Interface Builder itself is "SOS Interface, Un generateur >d'Interfaces Homme-Machine" by J.M. Huillot from Bigre + Globule No 48, >January 1986. ... It should be noted that Jean-Marie Hullot (the author of the above article) is the person actually implementing Interface Builder on the NeXT machine. The implementation is based on his research from up to four years ago; the basic idea is that of user interface objects connected together with the "target-action" paradigm in an object oriented environment. Ali Ozer, NeXT Developer Support aozer@NeXT.com
stevem@hpvcfs1.HP.COM (Steve Miller) (11/11/89)
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
ali@polya.Stanford.EDU (Ali T. Ozer) (11/12/89)
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
hoffman@ux1.cso.uiuc.edu (11/13/89)
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 | |________________________|________________________________________|
edwardm@hpcuhc.HP.COM (Edward McClanahan) (11/15/89)
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
olson@brutus.cs.uiuc.edu (Robert Olson) (11/15/89)
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 Internet: olson@cs.uiuc.edu UUCP: {uunet|convex|pur-ee}!uiucdcs!olson
ali@polya.Stanford.EDU (Ali T. Ozer) (11/15/89)
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
dml@esl.com (Denis Lynch) (11/16/89)
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.
cfcgf@ux1.cts.eiu.edu (Chuck Fleming) (12/17/90)
When a custom object (not a View) is instantiated in IB, is there any way to get IB to send the - (const char*)inspectorName message to the custom object so that IB will use a custom inspector that I have written, rather than the default custom object inspector? I have objects that should not logically inherit from View and don't really need appear IB's palette window, but I would like them to have their own inspectors. Thanks for any suggestions on how to do this. chuck fleming
daniel@vicorp.com (Daniel Dee) (12/19/90)
I am using the IB and notice that if I put a button inside a box, the button becomes somewhat a part of the box in that I cannot move the button outside the box object. However, if I cut this button and paste it into another box in another window, this button is not part of that box. In other words, I can move this button out the box region. Why is this so? And how can I make the pasted button part of the box in the new window? Any help will be appreciated. Thank you. -- Daniel (ddee@vicorp.com)
gessel@cs.swarthmore.edu (Daniel Mark Gessel) (04/04/91)
Anybody used names in interface builder? I'm using named objects to implement a help system. Having the naming ability is cool in a big way, but there's one thing that IB does that really annoys me . . . Create a button. Change it's name from "Button" to "Info Button". Set up your help system key a help file to your nice name. Change the label on the button to "Info", since you realized you left it called "Button" and that's probably not as informative as you want it to be. Now watch your help system break because the buttons name is automatically changed to "Info". Aaargh!!! Did I miss a preferences setting in IB or something (I hope), or will I have to convince next that if your buttons are not named "Button" or "Button1" or "ButtonN", you really did change the name with a purpose. What the heck happened to the Next programmers mailing lists? There was all this argument about rtf newsreaders. A NextMail programmers mailing list would be nice to get on. Dan -- Daniel Mark Gessel Internet: gessel@cs.swarthmore.edu
geoff@circus.camex.com (Geoffrey Knauth) (05/11/91)
See the drawing on p. 98 of the New Yorker (5/13/91).
Geoffrey S. Knauth geoff@bos.camex.com
Camex, Inc., 75 Kneeland St. geoff%bos.camex@uunet.uu.net
Boston, MA 02111, (617) 426-3577 x451 --standard disclaimers--<DWN2@psuvm.psu.edu> (06/03/91)
To review the connections drag the Inspector to the Connections option. Clicking on anything with a bullet next to it will show the connection. E.G. If you what to know what a particular menu item is connected to, click on that item so the Connection Inspector brings up the associated info and then go the the Connection Inspector and click on anything with a bullet and the connect will show up. Clicking on some of the other things in the Inspector will also show the connections. Dave
rhodes@cc.vt.edu (Tim Rhodes) (06/04/91)
When using the interface builder on an existing project, as in examples in the /NextDeveloper/Examples, how do you make it show connections between the project inspector, classes, actions and the objects in the applications window. When defining the connections, you select an object or outlet and control drag to the associated outlet or action (method). The connection is displayed as a visual line between the pair. When reviewing or modifying an existing IB project, I can't get IB to display this association. Any help will be appreciated.