Changeset 358eeae for doc

Jun 12, 2010, 3:29:01 PM (14 years ago)
David Benjamin <>
master, release-1.10, release-1.7, release-1.8, release-1.9
David Benjamin <> (06/03/10 19:06:34)
David Benjamin <> (06/12/10 15:29:01)
Add some notes at the bottom
1 edited


  • doc/owl-window.txt

    rfcce3f1 r358eeae  
    134134point. Mostly using the GObject signals to play with them, and because
    135135we'd likely get some form of automatic binding generation.)
     138Known issues and notes
     141- owl_window does not export the underlying WINDOW*. This is
     142  intentional. To safely resize windows, owl_window reserves the right
     143  to destroy/recreate the window whenever it feels like. We can add
     144  "window-realized"/"window-unrealized" signals if people really want
     145  though.
     147- This is currently using GObject. This buys us a lot of niceness, but
     148  it is adding a new library with full-blown (and somewhat
     149  overengineered) object system. It's very useful for prototyping, but
     150  if people want, it can be replaced. I think it's actually
     151  worthwhile, as most of the overengineering is explicitly designed
     152  for language bindings, something we could be better at.
     154- There is this really sketchy "three types in one" thing going on
     155  with the screen, panels, and subwins. I'd like to refactor that into
     156  some sort of subtyping, but that would ideally involve even more use
     157  of GObject.
     159- owl_mainwin is not very well ported and the windows do not have a
     160  very consistent implementation. This is a known problem that will be
     161  addressed in the next iteration. The current ports were done partly
     162  as experiments for conventions and mostly to get something working
     163  as soon as possible. Among things that should change is for the
     164  widgets to all use new/delete/pointers instead of
     165  init/cleanup/embed-in-struct.
     167- There is a generated GObject that emits signals for all variables
     168  and random other properties. It's currently not used much. It may be
     169  useful later, or not. I think there is some value in having change
     170  notifications for all our variables, although the initial port of
     171  the mainwin and sepbar turned out not to use it.
     173- The editwin and a few others are strange and keep track of signal
     174  ids. This is somewhat a side effect of us not using GObject
     175  everywhere; the signals can automatically disconnect in the right
     176  contexts if we do.
Note: See TracChangeset for help on using the changeset viewer.