--- a/WindowGroup.st Fri May 12 20:10:19 1995 +0200
+++ b/WindowGroup.st Tue May 16 19:17:11 1995 +0200
@@ -22,7 +22,7 @@
COPYRIGHT (c) 1993 by Claus Gittinger
All Rights Reserved
-$Header: /cvs/stx/stx/libview/WindowGroup.st,v 1.25 1995-05-10 02:26:27 claus Exp $
+$Header: /cvs/stx/stx/libview/WindowGroup.st,v 1.26 1995-05-16 17:14:37 claus Exp $
'!
!WindowGroup class methodsFor:'documentation'!
@@ -43,7 +43,7 @@
version
"
-$Header: /cvs/stx/stx/libview/WindowGroup.st,v 1.25 1995-05-10 02:26:27 claus Exp $
+$Header: /cvs/stx/stx/libview/WindowGroup.st,v 1.26 1995-05-16 17:14:37 claus Exp $
"
!
@@ -55,22 +55,28 @@
There is no polling in controllers (not even conceptionally).
WindowGroups are responsible to wait for and forward events for a group of
- windows. All views in a group share a single input event queue.
+ windows. All views in a group share a single windowSensor which holdes the
+ event queue (therefore views all share the same input event queue).
+
Except for modal boxes, a separate process is created for each windowGroup
- which waits for and forwards them to a controller (*).
+ which waits for events and processes them, by sending corresponding
+ event messages to the views controller or the view (*).
Therefore, multiple applications run in parallel.
Modal boxes create an extra window group for the components of the modal
- box, but execute in the original process - therefore, the original windowgroup
- is blocked for the duration of the modal interaction.
+ box, but execute the event-processing loop in the original process -
+ therefore, the original windowgroup is blocked for the duration of the modal
+ interaction (**).
Normally, one windowgroup is associated to each topview (StandardSystemView)
- and all of its subviews. However, this is not required; it is possible
- to create extra windowgroups for subviews, which will let them run in
- parallel (for example, the FileBrowsers kill Button is created that way,
- to allow a kill of an executing unix command, while the browser itself
- reads the pipe for incoming text).
- On the other hand, multiple topviews can be associated in the same windowGroup;
- this allows for multiview applications, of which only one communicates with
+ and all of its subviews. However, this is not strictly required;
+ it is possible to create extra windowgroups for subviews, which will let them
+ run in parallel
+ (for example, the FileBrowsers kill Button is created that
+ way, to allow a kill of an executing unix command, while the browser
+ itself reads the pipeStream for incoming text).
+
+ On the other hand, multiple topviews can be placed into the same windowGroup;
+ which allows for multiview applications, of which only one communicates with
the user at a time.
Although currently not implemented, it is planned for a future version,
@@ -90,6 +96,7 @@
created for you automatically, when a view is opened.
instance variables:
+
views collection of views of this group
topViews collection of topviews of this group
@@ -112,15 +119,23 @@
ActiveGroup the currently active windowGroup
- ScheduledWindowGroups -- not currently used --
+ ScheduledWindowGroups -- not currently implemented / used --
- (*) due to historic reasons, many views have the controller functionality
+ (*)
+ due to historic reasons, many views have the controller functionality
integrated, and handle events themself. The windowSensor takes care
of this, by checking if a view has a controller, and, if so, forwarding
the events to it. Otherwise, events are sent directly to the view.
- In the future, all views will be rewritten to actually use a controller;
- currently, only buttons, toggles and subclasses do so.
+
+ In the future, all views will be rewritten to actually use a controller.
+ Currently (being in the middle of this migration), only some views
+ (buttons, toggles and subclasses) do so.
+
+ (**)
+ the modal-event loop peeks into the original groups damage queue
+ in regular time intervals - therefore, view updating is still done in
+ the blocked group.
For more information, read 'introduction to view programming' in the
doc/online directory.
@@ -140,11 +155,13 @@
"WindowGroup initialize"
! !
-!WindowGroup class methodsFor:'signal access'!
+!WindowGroup class methodsFor:'Signal constants'!
leaveSignal
"return the signal which is used to exit a modal loop.
- This private signal, is always cought while a modalbox is active."
+ This private signal, is always cought while a modalbox is active.
+ Raising it will exit the modal loop and return from the views #openModal
+ method."
^ LeaveSignal
! !
@@ -295,7 +312,7 @@
!WindowGroup methodsFor:'special'!
showCursor:aCursor
- "change the cursor to aCursor in all of my views"
+ "change the cursor to aCursor in all of my views."
|c|
@@ -334,7 +351,7 @@
aBlock valueNowOrOnUnwindDo:[
"
- restore cursors
+ restore cursors from the mapping
"
oldCursors keysAndValuesDo:[:view :cursor |
view cursor:cursor
@@ -787,7 +804,7 @@
printOn:aStream
"return a printed representation;
- just for more user friendlyness, add name of process."
+ just for more user friendlyness: add name of process."
myProcess isNil ifTrue:[
(previousGroup notNil and:[previousGroup process notNil]) ifTrue:[