home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / lang / tcl / 1269 < prev    next >
Encoding:
Internet Message Format  |  1992-08-29  |  3.0 KB
  1. Path: sparky!uunet!olivea!mintaka.lcs.mit.edu!bloom-picayune.mit.edu!athena.mit.edu!joe
  2. From: joe@athena.mit.edu (Joseph C Wang)
  3. Newsgroups: comp.lang.tcl
  4. Subject: Re: tk-style interface to other windowing systems
  5. Message-ID: <1992Aug29.112358.11140@athena.mit.edu>
  6. Date: 29 Aug 92 11:23:58 GMT
  7. References: <1992Aug27.181758.27042@twg.com>
  8. Sender: news@athena.mit.edu (News system)
  9. Organization: Massachusetts Institute of Technology
  10. Lines: 55
  11. Nntp-Posting-Host: major.mit.edu
  12.  
  13. In article <1992Aug27.181758.27042@twg.com> "David Herron" <david@twg.com> writes:
  14. [Possibilties for porting Tk to MS-Windows]
  15.  
  16. >1) Use MS-Windows soley to provide windows & graphics primitives.  This would
  17. >be done the same as is currently done on top of Xlib.
  18.  
  19. >2) Do it as an encapsulation of MS-Windows widgets.  The `button' command
  20. >would ultimately do whatever MS-Windows magic creates one of its button
  21. >widgets, for instance.  MS-Windows events would be captured internally and
  22. >fixed up so they become appropriate TK procedure calls.
  23.  
  24. >3) Create a 1-1 mapping of windows function calls and data structures to
  25. >commands in TCL.  (Kind of like how WaFe is done).  Then proceed from there
  26. >to somehow write an all new set of scripts for the user interface to
  27. >the application.
  28.  
  29. I have a suggestion.......
  30.  
  31. Do 1), and then write a Tk initialization file so that MS-Windows
  32. emulation is done in Tk instead on in C-code.  The advantage is that
  33. you have the functionality of 2) with only the work of 1).  For one
  34. thing, if you do things this way, you can grep the Tk code for the x
  35. graphics primitives, and you'll know all the places that you need to
  36. change.  
  37.  
  38. One BIG advantage in putting the Windows-like behavior in the Tk
  39. initialization file is that you can get Windows-like behavior on a
  40. unix X11 box through Tk.  This means that you can test your Windows
  41. emulation on your sparcstation, while you are converting your C code.
  42.  
  43. In short, worry only about converting the graphics primitives while
  44. you are converting C code.  Do all your worrying about getting
  45. MS-Windows like behavior in Tk.
  46.  
  47. Also it would be really nice if while coding your new Windows-Tk, you
  48. could arrange things so that all the system dependent calls are in one
  49. file.  The Tk procedures would call procedures defined in a file
  50. called "windows-primitives.c." To get an X application, one would call
  51. procedures defined in a file "x11-primitives.c."  That way, it would
  52. be possible for someone to port Tk be just writing a file
  53. "mac-primitives.c" or "os2-primitives.c" or even maybe
  54. "block-terminal-primitives.c"
  55.  
  56. Also, if you abstract away the system dependencies, then it would be
  57. much, much easier to convert non-canonical Tk widgets to run in
  58. MS-Windows.  Just use your graphics primitives instead of the X11
  59. ones.
  60.  
  61. Whatever you do, don't do 3).  It's more work for you, and if you do 
  62. either 1 or 2 instead of 3), we'll all be able to get our Tk scripts
  63. running in MS-Windows.  In particular, if you do 1 or 2, I'll be able
  64. to port my hypertext browser to MS-Windows and use Tk as a standard
  65. hypertext interchange language.
  66.  
  67. Good luck!!!!!!!
  68.