diff options
| -rw-r--r-- | README.CWIDGET (renamed from README.VSCREEN) | 0 | ||||
| -rw-r--r-- | README.SMART-POINTERS | 10 | ||||
| -rw-r--r-- | README.THREADS | 14 |
3 files changed, 12 insertions, 12 deletions
diff --git a/README.VSCREEN b/README.CWIDGET index 90fe6081..90fe6081 100644 --- a/README.VSCREEN +++ b/README.CWIDGET diff --git a/README.SMART-POINTERS b/README.SMART-POINTERS index d4f11f48..7d1d23fc 100644 --- a/README.SMART-POINTERS +++ b/README.SMART-POINTERS @@ -96,7 +96,7 @@ and what the caveats are. generally works as you expect. To enforce the use of ref_ptr, all widget constructors are protected; static ::create methods are provided to actually allocate a new widget. Because the - vscreen_widget class initializes its reference count to 1, the + cwidget::widget class initializes its reference count to 1, the ::create method should explicitly decref() its return value; see the existing ::create routines for examples. @@ -119,7 +119,7 @@ and what the caveats are. - Beware sigc::bind. sigc::bind is an easy way to create bad circularities; moreover, it's actually unsafe to bind a ref_ptr - as a slot argument. The solution adopted in vscreen/ is to + as a slot argument. The solution adopted in cwidget is to exploit sigc++ weak references. If w is a ref_ptr, then rather than closing w, you should close over w.weak_ref(). @@ -131,10 +131,10 @@ and what the caveats are. a T&; the _bare method should simply instantiate a ref_ptr and call the main interface. For instance, - void add_widget(const ref_ptr<vscreen_widget> &w); - void add_widget_bare(vscreen_widget &w) + void add_widget(const ref_ptr<cwidget::widget> &w); + void add_widget_bare(cwidget::widget &w) { - add_widget(ref_ptr<vscreen_widget>(&w)); + add_widget(ref_ptr<cwidget::widget>(&w)); } Obviously this is less than ideal, but it will work. Be aware, diff --git a/README.THREADS b/README.THREADS index 7d61b2f0..1ac908cc 100644 --- a/README.THREADS +++ b/README.THREADS @@ -1,13 +1,13 @@ The basic threading philosophy followed in aptitude can be summarized thus: "if you aren't sure it's safe, do it in the main -thread". The mechanism for doing so is vscreen_post_event -(vscreen.cc), which places a callback object into the global event -queue and wakes the main thread (if necessary). You can also take a -global lock to get the same effect...but it's really recommended that -you use the event queue. +thread". The mechanism for doing so is cwidget::toplevel::post_event +(cwidget/toplevel.h), which places a callback object into the global +event queue and wakes the main thread (if necessary). You can also +take a global lock to get the same effect...but it's really +recommended that you use the event queue. The actual threading constructs used are the pthread wrappers in -src/generic/threads.h (and also src/generic/event_queue.h). +cwidget/generic/threads.h (and also cwidget/generic/event_queue.h). Background threads are spawned to do long-running operations, but they generally only access data that is "owned" by the thread. More @@ -45,7 +45,7 @@ thread. Existing background threads: - * The vscreen library creates threads to handle keyboard input, + * The cwidget library creates threads to handle keyboard input, certain asynchronous signals, and timed events. You generally don't need to worry about these. |