NOTES 2.9 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990
  1. Notes on the Tk implementation.
  2. General
  3. TkTop represents a top-level window.
  4. It holds pointers to the widgets created in that
  5. window:
  6. windows gives a list of all windows (this includes "." and any menu widgets)
  7. root the list of all widgets, whether packed or not.
  8. Each Tk widget holds pointers to the widgets packed inside it, its slaves.
  9. Widgets that do their own child widget management (canvas
  10. and text) do not use the slaves list, but store pointers
  11. to them in their own data structures.
  12. Each Tk widget, w, holds a pointer to the widget it's packed or stored inside.
  13. w->master
  14. if it's packed or stored in a grid
  15. w->parent
  16. if it's a child widget of a canvas or text widget.
  17. A widget type is operated on through functions referred to in its TkMethod structure,
  18. defined in that widget type's source file, and pointed to by the
  19. method dispatch table, tkmethod, defined in xdata.c.
  20. utils.c contains the master table holding the built-in commands
  21. (e.g. widget creation, focus, grab, etc) with their
  22. associated functions.
  23. xdata.c holds the method table (tkmethod) mapping from
  24. widget type to the method functions supported by individual widgets.
  25. Coordinates:
  26. A widget requests a particular size allocation
  27. by setting its req.width and req.height fields.
  28. The packer (or its parent) determines the actual
  29. size allocation, and position and sets act.x, act.y, act.width
  30. and act.height appropriately.
  31. The requested width and height do not include the
  32. borderwidth, which is factored in additionally.
  33. Coordinates as delivered by the %x and %y verbs provided
  34. by bind(9) are relative to the top left of the widget,
  35. inside its border. I'll call this the "widget's coordinate system".
  36. The draw method of each widget type is provided with
  37. an "origin" argument.
  38. (origin.x + act.x + borderwidth, origin.y + act.y + borderwidth)
  39. gives the screen coordinate of (0, 0) in the widget coordinate
  40. system.
  41. Dirtiness
  42. Each widget has a "dirty" rectangle, the bounding
  43. box of any changes that it needs to make visible.
  44. This is in the widget's coordinate system.
  45. A widget does not have to update everything in
  46. the dirty rectangle, unless the Tkrefresh flag
  47. is set, in which case it must.
  48. A widget never has to draw anything outside of its dirty
  49. rectangle.
  50. Locking
  51. Mostly, Tk is non-reentrant because the interpreter is held
  52. when a call to, e.g. Tk_cmd, is made.
  53. However, when the display is remote, any access of the display
  54. (drawing, stringsize, etc) can do a release() and therefore
  55. let another thread access tk.
  56. The drawing code itself locks the display, so code invoked
  57. from within a widgets draw() method is guaranteed
  58. non-reentrant.
  59. If access to the draw device is required during code executed
  60. in a non-drawing context (e.g. to calculate the size of a
  61. string), care must be taken to lock the draw device
  62. appropriately. Tk provides some convenience functions to do
  63. this (e.g. tkstringsize).