home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / sys / next / programm / 7172 < prev    next >
Encoding:
Text File  |  1992-11-11  |  2.6 KB  |  56 lines
  1. Newsgroups: comp.sys.next.programmer
  2. Path: sparky!uunet!stanford.edu!snorkelwacker.mit.edu!news.media.mit.edu!news
  3. From: wave@waits.media.mit.edu (Michael B. Johnson)
  4. Subject: IB Bugs/Problems
  5. Message-ID: <1992Nov12.053657.27247@news.media.mit.edu>
  6. Sender: news@news.media.mit.edu (USENET News System)
  7. Organization: MIT Media Laboratory
  8. Date: Thu, 12 Nov 1992 05:36:57 GMT
  9. Lines: 45
  10.  
  11. Hi folks.  I've found a few annoying things in IB, which I thought I'd share,  
  12. in the hopes that someone here might have some insight.  First the bugs:
  13.  
  14. When you load a palette into IB, IB initializes each of the objects in the  
  15. palette. Fine.  When you quit IB, or even when you unload the palette, IB does  
  16. not send a quit or a free message to any of these objects.  What's the problem,  
  17. you say?  In the palette-unloading case, what's a few bytes between friends,  
  18. and in the IB quitting case, all the memory for tha process will get freed up  
  19. anyway, so who cares?  Well, in my case, each of the objects on the palette is  
  20. acutally a proxy for another (set of) process(es) somewhere out on the net  
  21. which get started up when that object gets initialized.  When IB quits, and  
  22. doesn't warn my proxy object, the processes which it's connected to don't  
  23. realize it's gone until much later (if at all).  I can work around this, but  
  24. it's still incorrect behavior. Bug.
  25.  
  26. As has been discussed to death, once you load a palette into IB, as long as the  
  27. path to it is valid, it will continue to show up in your preferences.  You  
  28. should be able to select and delete one of these from inside IB, and you can't.   
  29. Bug.
  30.  
  31. Now to the suggestions:
  32.  
  33. IB is very good about if you subclass something and don't provide an inspector,  
  34. IB will let you use its superclass's inspector.  Unfortunately, as soon as you  
  35. provide an inspector, you no longer get access to the superclass inspector.   
  36. For example, let's say you have a class Foo which has a lot of info on it's  
  37. inspector panel, one set of which is a 4x4 matrix.  You now subclass Foo to  
  38. FooBar.  It would be nice if you could put only FooBar specific info on its  
  39. inspector and not have to replicate (among other things) the 4x4 of its  
  40. inspector.
  41.  
  42. Finally, can someone explain the philosophical difference between an  
  43. IBInspector and an IBEditor?  I know how to implement both, but I'm not sure  
  44. which is appropriate for what...
  45.  
  46. Hopefully, someone has some suggestions...
  47.  
  48. later.
  49.  
  50. --
  51.  
  52. -->  Michael B. Johnson
  53. -->  MIT Media Lab      --  Computer Graphics & Animation Group
  54. -->  (617) 253-0663     --  wave@media-lab.media.mit.edu
  55. -->  NeXT Mail accepted at  wave@nordine.media.mit.edu
  56.