home *** CD-ROM | disk | FTP | other *** search
/ Atari Mega Archive 1 / Atari Mega Archive - Volume 1.iso / lists / gem / l_0799 / 731 < prev    next >
Encoding:
Internet Message Format  |  1994-08-27  |  2.9 KB
  1. Subject: Re: Gem List (fwd) from goemon 
  2. Date: Sun, 10 Jul 1994 13:31:52 +1000
  3. From: Warwick Allison <warwick@cs.uq.oz.au>
  4. Precedence: bulk
  5.  
  6. Ken Hollis:
  7. >Trust me, it's more difficult than what I posted, and it takes more time to
  8. >use.  Why not just TRY my code out and see for yourself?  Speed difference
  9. >is almost NIL.
  10.  
  11. For one application, this is correct.  But we're talking about standards
  12. here, and that means we have to think about every program doing this.
  13. Below, you suggets that only the top application will be allowed hot
  14. objects.  With that restriction, I would agree that the 1x1-pixel track
  15. might be appropriate.  And if the only hot object is editable objects,
  16. then this restriction too might be appropriate.  But hot objects, and
  17. rectangle tracking in general, is a useful visual effect for all sorts of
  18. things (eg. changing mouse cursor to cross-hairs inside drawing object;
  19. highlighing exit objects as the mouse moves over them [al-la menu items]).
  20.  
  21. >> Ken, I agree, that way is very easy to code.  The problem is whether it
  22. >> is of sufficiently low cost to impose it as a standard for applications
  23. >> to follow.
  24. >
  25. >I don't quite understand what you mean by saying "low cost".  It's just about
  26. >four lines of code that is easy to do.  It takes almost no time, because,
  27. >it checks the object under the mouse.
  28.  
  29. The cost I mean is the repeated calling of the application.  Don't get me
  30. wrong, I see a very strong argument for your method (and I'm suprised you
  31. haven't mentioned it) - that objc_find is an extremely efficient algorithm
  32. compared to the rectangle clipping algorithm required for the alternative
  33. solution.  You solution does not bust wait (as others suggest), but it does
  34. generate a LOT of events (especially on faster machines where the mouse is
  35. tracked more closely).  The coding cost of your solution is extremely low,
  36. while the coding cost of the larger-rectangle solution is quite high.
  37.  
  38. >The ONLY way you can find out which object is under the mouse is by using
  39. >objc_find.  There is absolutely no other way to get rectangles under the
  40. >mouse without having to SAVE the physical dimensions of the rectangles,
  41. >storing those in an array, and checking the array every time the mouse
  42. >moves.
  43.  
  44. Not really - you just generate the larger-rectangle from the object tree.
  45.  
  46. >> But if all GEM libraries are the same, why would you change from one to
  47. >> another?  GEM++ for example doesn't even use the Extended Object Types
  48. >> byte.  It uses full parameterized object instantiations presribed in
  49. >> the code, allowing any number of different types of object from sliders
  50. >> to scrolling self-drawing objects.
  51. >
  52. >That's the problem.  Not all GEM libraries are the same.  Why not use
  53. >Extended Object Types?
  54.  
  55. Because GEM++ can support thousands of different object types.  It focusses
  56. on behavioural objects rather than visual objects (eg. there are no different
  57. types of visual radio buttons - just the std GEM ones), so there is no gain
  58. in the WYSIWYG of RSC editing.
  59.  
  60. --
  61. Warwick
  62.