Changeset 358eeae


Ignore:
Timestamp:
Jun 12, 2010, 3:29:01 PM (14 years ago)
Author:
David Benjamin <davidben@mit.edu>
Branches:
master, release-1.10, release-1.7, release-1.8, release-1.9
Children:
4eee948
Parents:
fcce3f1
git-author:
David Benjamin <davidben@mit.edu> (06/03/10 19:06:34)
git-committer:
David Benjamin <davidben@mit.edu> (06/12/10 15:29:01)
Message:
Add some notes at the bottom
File:
1 edited

Legend:

Unmodified
Added
Removed
  • 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.)
     136
     137----------------------
     138Known issues and notes
     139----------------------
     140
     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.
     146
     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.
     153
     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.
     158
     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.
     166
     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.
     172
     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.