home *** CD-ROM | disk | FTP | other *** search
/ Dream 44 / Amiga_Dream_44.iso / Amiga / programmation / geometryengine.lha / GeometryEngine / README.txt
Text File  |  1997-08-27  |  4KB  |  90 lines
  1. "Design beautiful Gadgets, Menus, Requesters.  Think simplicity and
  2. elegance.  Always remember the fourth grader, the sophisticated user, and
  3. the poor soul who is terrified of breaking the machine"
  4.  
  5. "Dare to be gorgeous and unique.  But don't ever be cryptic or otherwise
  6. unfathomable.  Make it unforgetably great"
  7.  
  8.  -- -=RJ=-, from the Intuition Style Guide.
  9.  
  10. **************************************************************************
  11.  
  12. Warning:  This is only a demonstration of the Geometry Engine.  I accept no
  13. liability for anything that might happen.  Additionaly, nothing is set in
  14. stone, anything might (and probably will) change.  I make no claims as to
  15. the completeness, usability or beauty of this package.  The only purpose
  16. here is to let people see what this is, and get some hopefully constructive
  17. criticism and ideas as a result.
  18.  
  19. All suggestions, encouragement, or death threats are welcome.  I will
  20. entertain all opinions.
  21.  
  22. So lets get on with it.
  23.  
  24. What is the Geometry Engine?  It's a simple mechanism for creating
  25. environment sensitive (fonts, colours, etc), resizable GUI's.  That's it.
  26. It tries to be as flexible as possible, and allows user definable hooks for
  27. rendering, layout, etc.
  28.  
  29. The documentation is sparse, with no tutorial, just the autodocs.  But this
  30. is only a demo, not a development system.  You can go and use it with your
  31. own programs, but I don't recomend it right now, since I may change things
  32. if necessary.
  33.  
  34. Yes, it's crude, yes it's probably not as efficient as it could be, yes
  35. GadTools is annoying and not particularly efficient itself, yes it's no
  36. where near the level of many available GUI systems, yadda yadda.  Thffbbt!
  37.  
  38. In the future, I intend to release a more complete package, when I've decided
  39. to commit to the API.  I'd like to get BOOPSI support going, but I'd also like
  40. to create or adopt some other more efficient Object system (including possibly
  41. a more advanced BOOPSI-like system) to use.  OO is good.
  42.  
  43. I will implement "panels"; switchable pages of gadgets, which could be used
  44. like the click-tab things in many other GUI systems, or like the "pages" in
  45. the PrinterPS preferences.  I dislike almost every click-tab implementation
  46. I've seen, and mine would be completely flexible (I like the idea of click
  47. tabs.  I'd like the tabs to be simple, visualy; intuitive, and fast.
  48.  
  49. I'll also probably do a Geometry Engine preferences thing, to set all kinds of
  50. "gee-whiz" stuff like backrounds and button images etc.
  51.  
  52. And it will become a shared library as well as a linkable library, your
  53. choice (and maybe the link library routines will be smart enough to
  54. redirect to the library if it's there and newer).  I will support any
  55. language anyone wants to use, and the library will be usable from ARexx
  56. too.
  57.  
  58. Finaly, I'd like to make a graphical GUI builder that uses Geometry Engine.
  59. I have not seen any GUI builder that even comes close to what I want to do.
  60. The GUI builder is the eventual goal, as I think that, logicaly, a GUI
  61. ought to be constructed with a GUI.
  62.  
  63. My vision is this:
  64.  
  65. A GUI is created visualy, almost like a DTP or structured drawing program.
  66. Any language is supported, because the GUI definition can be loaded and
  67. used with simple library calls.  You could prototype your program using
  68. ARexx, which means no compiling; basicly, Visual ARexx.  You could then
  69. redo it in C or whatever.  Even mixing languages.  "Visual Anything".  In
  70. fact, to get real wild, this GUI editing envirionment should be a built in
  71. feature.  Let the user not only tweek things like colours and image styles
  72. etc, but even move gadgets around, etc.
  73.  
  74. It would be object oriented, using some kind of language independant object
  75. mechanism (*maybe* BOOPSI, but I'm not real fond of it.  For reference, I
  76. like the ideology of Objective C.  See "Object Oriented Programing, an
  77. evolutionary approach" by Brad J.  Cox).  This system should be fast, and
  78. flexible, and would allow objects to be shared across applications.
  79.  
  80. The object system would be very layered, and well thought out.  You only
  81. load what you need, and that includes possibly not loading a parent class
  82. if its functionality isn't asked for.  On the flip side, new functionality
  83. could be inserted dynamicaly without the objects or applications needing to
  84. specificaly know about it.
  85.  
  86. Above all, simple things should be simple and small and fast.
  87.  
  88. Aric Caley
  89. greywire@quick.net
  90.