home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / alt / bbs / 8150 < prev    next >
Encoding:
Text File  |  1993-01-24  |  2.5 KB  |  53 lines
  1. Newsgroups: alt.bbs
  2. Path: sparky!uunet!cs.utexas.edu!torn!csd.unb.ca!UNBVM1.CSD.UNB.CA
  3. From: E2KP <E2KP@UNB.CA>
  4. Subject: RE: GIF Menus on BBSs
  5. Message-ID: <24JAN93.01154076.0045@UNBVM1.CSD.UNB.CA>
  6. Lines: 41
  7. Sender: usenet@UNB.CA
  8. Organization: The University of New Brunswick
  9. References:  <h0k3p!q@rpi.edu>
  10. Date: Sun, 24 Jan 1993 05:04:06 GMT
  11.  
  12. In article <h0k3p!q@rpi.edu> cleggp@aix.rpi.edu (Paul Jason Clegg) writes:
  13. >I noticed a thread forming on BBS design, and graphic interfaces was one of
  14. >the major points I heard.  (BTW:  I'm all for a BBS design newsgroup)
  15. >
  16. >I came up with an idea about a year or two ago, when I was planning on
  17. >writing my own BBS code.  This is what I had wanted to do in my board (plus
  18. >other "new" things):
  19. >
  20. >GIF MENUS!
  21. >
  22. >Yes, I know to transfer the menu everytime would take forever, particularly
  23. >at the slower speeds.  But, why not do something like this:
  24. >
  25. >It's a given that a special term program will have to be written to allow
  26. >for graphics to begin with.  What the term program would do, however, is
  27. >receive a VERY short code from the remote host, perhaps a filename and a
  28. >date.  It would check to see if it has the filename (which would be the GIF
  29. >file) and check it's date to make sure it's current.  If these were not
  30. >true (ie no file or older file), the board (or term program) would prompt
  31. >the user if they wanted to d/l the new menu, and then (if yes) run a ZModem
  32. >(or some protocol) download of the proper menu.  BUT it would keep the menu
  33. >on the user's harddrive, so the user wouldn't have to d/l the menu everytime.
  34. >Once the menus are d/led, the display time for a menu would only be limited
  35. >by the user's computer system, and not the comm rate.  Of course, the board
  36. >would also allow ANSI/ASCII logons as well, and volatile information (file
  37. >dirs, messages) would still have to be transferred by normal means.
  38. >
  39. >I also had some ideas on mouse-driven menus using a similar idea (special
  40. >term + board codes).
  41. You have just essentially described the fundamenatals behind RoboBoard B
  42. BS.
  43. The menus are acombination between Line draw ala NAPLPS and Bitmaps a la
  44. Microsoft Win. Current resolution is at High Res EGA on the users end. 1
  45. 6 colours now - going to VGA 256 at 640x480 when 2.0FX is released in t
  46. second quarter of '93.  Similar concepts lie begind GETS and other
  47. terminal software. Prodigy is along those lines.
  48. RoboBoard has so far been the most successful at turning the concept ino
  49. to a workable BBS package for the massess - though bugs have plagued it.
  50.  
  51.  
  52.  
  53.