Z-order and occlusion
Locked
 
|
So I have a window which has some custom graphics being drawn and I
need to put some widgets on top of the drawn graphics (No, I can't change this requirement). I add the graphics area first which is the size of the window. Then I add the widgets. When the window opens everything looks great, but when graphics get drawn or scrollbars get clicked on the graphics area the widgets get drawn on top. If I hide the window and reveal it everything looks and works fine, but then any graphics that get drawn draw over the widgets. This surprises me. I was assuming that the VW widget framework would handle this sort of occlusion automatically. Shouldn't widgets that are on top of other widgets not be overdrawn by the widgets below them? -Carl Gundel http://www.libertybasic.com http://www.runbasic.com _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
|
|
There is a method ...
wrapper widgetState isOccluded: true that "should" resolve this??? assuming you have not tried that. My approach is to mark a window as having occluded widgets, then walk all the wrappers in it and invoke the above. On Nov 6/11 6:43 PM, Carl Gundel wrote: > So I have a window which has some custom graphics being drawn and I > need to put some widgets on top of the drawn graphics (No, I can't > change this requirement). I add the graphics area first which is the > size of the window. Then I add the widgets. When the window opens > everything looks great, but when graphics get drawn or scrollbars get > clicked on the graphics area the widgets get drawn on top. If I hide > the window and reveal it everything looks and works fine, but then any > graphics that get drawn draw over the widgets. > > This surprises me. I was assuming that the VW widget framework would > handle this sort of occlusion automatically. Shouldn't widgets that > are on top of other widgets not be overdrawn by the widgets below > them? > > -Carl Gundel > http://www.libertybasic.com > http://www.runbasic.com > _______________________________________________ > vwnc mailing list > [hidden email] > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc -- Dennis Smith +1 416.798.7948 Cherniak Software Development Corporation Fax: +1 416.798.0948 509-2001 Sheppard Avenue East [hidden email] Toronto, ON M2J 4Z8 sip:[hidden email] Canada http://www.CherniakSoftware.com Entrance off Yorkland Blvd south of Sheppard Ave east of the DVP _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
|
|
Dennis,
Thanks. How do you mark the window, using the same isOccluded: method? I just tried to using isOccluded: true as you describe after opening the window. I tried marking just the widgets that are getting drawn over, and also including the widget that is drawing over them. No difference either way. Is there any documentation for this? -Carl Gundel http://www.libertybasic.com http://www.runbasic.com On Sun, Nov 6, 2011 at 6:58 PM, Dennis Smith <[hidden email]> wrote: > There is a method ... > > wrapper widgetState isOccluded: true > > that "should" resolve this??? assuming you have not tried that. > > My approach is to mark a window as having occluded widgets, then walk > all the wrappers in it > and invoke the above. > > > > > On Nov 6/11 6:43 PM, Carl Gundel wrote: >> So I have a window which has some custom graphics being drawn and I >> need to put some widgets on top of the drawn graphics (No, I can't >> change this requirement). I add the graphics area first which is the >> size of the window. Then I add the widgets. When the window opens >> everything looks great, but when graphics get drawn or scrollbars get >> clicked on the graphics area the widgets get drawn on top. If I hide >> the window and reveal it everything looks and works fine, but then any >> graphics that get drawn draw over the widgets. >> >> This surprises me. I was assuming that the VW widget framework would >> handle this sort of occlusion automatically. Shouldn't widgets that >> are on top of other widgets not be overdrawn by the widgets below >> them? >> >> -Carl Gundel >> http://www.libertybasic.com >> http://www.runbasic.com >> _______________________________________________ >> vwnc mailing list >> [hidden email] >> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > > -- > Dennis Smith +1 416.798.7948 > Cherniak Software Development Corporation Fax: +1 416.798.0948 > 509-2001 Sheppard Avenue East [hidden email] > Toronto, ON M2J 4Z8 sip:[hidden email] > Canada http://www.CherniakSoftware.com > Entrance off Yorkland Blvd south of Sheppard Ave east of the DVP > > _______________________________________________ > vwnc mailing list > [hidden email] > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
|
|
It SEEMS you have to mark it on each widget wrapper IN the window.
I assume?? that if the window contains a subcanvas, that you can just mark it on the subcanvas, but I am not 100% sure of that. My code looks something like this (modified to remove code related to some Builder customization) ... postBuildWith: aBld aBld namedComponents do: [:wrapper | wrapper widgetState isOccluded: true ] This assumes that all widgets of interest have ID's -- we make sure ALL ours do. On Nov 6/11 7:54 PM, Carl Gundel wrote: > Dennis, > > Thanks. How do you mark the window, using the same isOccluded: > method? I just tried to using isOccluded: true as you describe after > opening the window. I tried marking just the widgets that are getting > drawn over, and also including the widget that is drawing over them. > No difference either way. > > Is there any documentation for this? > > -Carl Gundel > http://www.libertybasic.com > http://www.runbasic.com > > On Sun, Nov 6, 2011 at 6:58 PM, Dennis Smith > <[hidden email]> wrote: >> There is a method ... >> >> wrapper widgetState isOccluded: true >> >> that "should" resolve this??? assuming you have not tried that. >> >> My approach is to mark a window as having occluded widgets, then walk >> all the wrappers in it >> and invoke the above. >> >> >> >> >> On Nov 6/11 6:43 PM, Carl Gundel wrote: >>> So I have a window which has some custom graphics being drawn and I >>> need to put some widgets on top of the drawn graphics (No, I can't >>> change this requirement). I add the graphics area first which is the >>> size of the window. Then I add the widgets. When the window opens >>> everything looks great, but when graphics get drawn or scrollbars get >>> clicked on the graphics area the widgets get drawn on top. If I hide >>> the window and reveal it everything looks and works fine, but then any >>> graphics that get drawn draw over the widgets. >>> >>> This surprises me. I was assuming that the VW widget framework would >>> handle this sort of occlusion automatically. Shouldn't widgets that >>> are on top of other widgets not be overdrawn by the widgets below >>> them? >>> >>> -Carl Gundel >>> http://www.libertybasic.com >>> http://www.runbasic.com >>> _______________________________________________ >>> vwnc mailing list >>> [hidden email] >>> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc >> -- >> Dennis Smith +1 416.798.7948 >> Cherniak Software Development Corporation Fax: +1 416.798.0948 >> 509-2001 Sheppard Avenue East [hidden email] >> Toronto, ON M2J 4Z8 sip:[hidden email] >> Canada http://www.CherniakSoftware.com >> Entrance off Yorkland Blvd south of Sheppard Ave east of the DVP >> >> _______________________________________________ >> vwnc mailing list >> [hidden email] >> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc >> > _______________________________________________ > vwnc mailing list > [hidden email] > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc -- Dennis Smith +1 416.798.7948 Cherniak Software Development Corporation Fax: +1 416.798.0948 509-2001 Sheppard Avenue East [hidden email] Toronto, ON M2J 4Z8 sip:[hidden email] Canada http://www.CherniakSoftware.com Entrance off Yorkland Blvd south of Sheppard Ave east of the DVP _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
|
|
In reply to this post by Carl Gundel-2
On Nov 6, 2011, at 3:43 PM, Carl Gundel wrote: This surprises me. I was assuming that the VW widget framework would Are you using invalidate? It sounds from your description as if you're not, and you should be. I could be wrong, need more details I guess. -- Travis Griggs Objologist Simplicity is the Ultimate Sophistication -- Leonardo da Vinci _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
|
|
I thought I already replied to this, but it isn't posted. :-/
I'm not really sure what you mean by "use invalidate". If you still have that GraphPanePart example I sent you, that is the widget I am placing other widgets on top of. If I'm doing any particular thing wrong in that implementation, please toss your thoughts my way. Maybe this is the perfect opportunity to post about the proper use of invalidated and isOccluded on that blog you are starting. ;-) Thanks, -Carl Gundel http://www.libertybasic.com http://www.runbasic.com On Mon, Nov 7, 2011 at 1:01 AM, Travis Griggs <[hidden email]> wrote: > On Nov 6, 2011, at 3:43 PM, Carl Gundel wrote: > > This surprises me. I was assuming that the VW widget framework would > handle this sort of occlusion automatically. Shouldn't widgets that > are on top of other widgets not be overdrawn by the widgets below > them? > > Are you using invalidate? It sounds from your description as if you're not, > and you should be. I could be wrong, need more details I guess. > -- > Travis Griggs > Objologist > Simplicity is the Ultimate Sophistication -- Leonardo da Vinci > _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
|
|
On Nov 7, 2011, at 9:54 AM, Carl Gundel wrote: > I thought I already replied to this, but it isn't posted. :-/ > > I'm not really sure what you mean by "use invalidate". If you still > have that GraphPanePart example I sent you, that is the widget I am > placing other widgets on top of. If I'm doing any particular thing > wrong in that implementation, please toss your thoughts my way. > > Maybe this is the perfect opportunity to post about the proper use of > invalidated and isOccluded on that blog you are starting. ;-) See "Redisplay all or Part of a View" in the GUI Dev Guide. It's pretty straightforward actually. A VW widget implements a #displayOn: method where it should use the GC handed to it to do all of its drawing. It should use that GC, not another, and shouldn't store the GC for later use. When you want all or part of a widget to be redrawn, you should send #invalidate to it. For complex views, if it's easy to compute a region of change, you can use invalidateRectangle: to restrict the scope of change. If you're stepping outside of those bounds, then you've decided you know better than the framework and get to manage it yourself. :) Side note. I really wish people wouldn't use the #invalidateRectangle:andRepairNow: true unless they're sure they need to. It may go away, or at least become moot in the future. -- Travis Griggs Objologist I multiply all time estimates by pi, to account for running around in circles. _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
|
|
> Side note. I really wish people wouldn't use the > #invalidateRectangle:andRepairNow: true unless they're sure they need to. > It may go away, or at least become moot in the future. +100 IMHO no widgets should require immediate redisplay, all should retain enough state to display properly via deferred invalidate. Terry =========================================================== Terry Raymond Crafted Smalltalk 80 Lazywood Ln. Tiverton, RI 02878 (401) 624-4517 [hidden email] =========================================================== > -----Original Message----- > From: [hidden email] [mailto:[hidden email]] On > Behalf Of Travis Griggs > Sent: Monday, November 07, 2011 1:55 PM > To: Carl Gundel; VWNC NC > Subject: Re: [vwnc] Z-order and occlusion > > > On Nov 7, 2011, at 9:54 AM, Carl Gundel wrote: > > > I thought I already replied to this, but it isn't posted. :-/ > > > > I'm not really sure what you mean by "use invalidate". If you still > > have that GraphPanePart example I sent you, that is the widget I am > > placing other widgets on top of. If I'm doing any particular thing > > wrong in that implementation, please toss your thoughts my way. > > > > Maybe this is the perfect opportunity to post about the proper use of > > invalidated and isOccluded on that blog you are starting. ;-) > > > See "Redisplay all or Part of a View" in the GUI Dev Guide. > > It's pretty straightforward actually. > > A VW widget implements a #displayOn: method where it should use the GC > handed to it to do all of its drawing. It should use that GC, not another, > shouldn't store the GC for later use. > > When you want all or part of a widget to be redrawn, you should send > #invalidate to it. For complex views, if it's easy to compute a region of > change, you can use invalidateRectangle: to restrict the scope of change. > > If you're stepping outside of those bounds, then you've decided you know > better than the framework and get to manage it yourself. :) > > Side note. I really wish people wouldn't use the > #invalidateRectangle:andRepairNow: true unless they're sure they need to. > It may go away, or at least become moot in the future. > > -- > Travis Griggs > Objologist > I multiply all time estimates by pi, to account for running around in > > > > > _______________________________________________ > vwnc mailing list > [hidden email] > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
|
|
Isn't updating a widget before a long-running operation would otherwise get around to it good enough reason to repair now? That case has nothing to do with widget state... Dave Stevenson[hidden email] From: Terry Raymond <[hidden email]> To: VWNC NC <[hidden email]> Sent: Mon, November 7, 2011 3:14:53 PM Subject: Re: [vwnc] Z-order and occlusion > Side note. I really wish people wouldn't use the > #invalidateRectangle:andRepairNow: true unless they're sure they need to. > It may go away, or at least become moot in the future. +100 IMHO no widgets should require immediate redisplay, all should retain enough state to display properly via deferred invalidate. Terry =========================================================== Terry Raymond Crafted Smalltalk 80 Lazywood Ln. Tiverton, RI 02878 (401) 624-4517 [hidden email] =========================================================== > -----Original Message----- > From: [hidden email] [mailto:[hidden email]] On > Behalf Of Travis Griggs > Sent: Monday, November 07, 2011 1:55 PM > To: Carl Gundel; VWNC NC > Subject: Re: [vwnc] Z-order and occlusion > > > On Nov 7, 2011, at 9:54 AM, Carl Gundel wrote: > > > I thought I already replied to this, but it isn't posted. :-/ > > > > I'm not really sure what you mean by "use invalidate". If you still > > have that GraphPanePart example I sent you, that is the widget I am > > placing other widgets on top of. If I'm doing any particular thing > > wrong in that implementation, please toss your thoughts my way. > > > > Maybe this is the perfect opportunity to post about the proper use of > > invalidated and isOccluded on that blog you are starting. ;-) > > > See "Redisplay all or Part of a View" in the GUI Dev Guide. > > It's pretty straightforward actually. > > A VW widget implements a #displayOn: method where it should use the GC > handed to it to do all of its drawing. It should use that GC, not another, > shouldn't store the GC for later use. > > When you want all or part of a widget to be redrawn, you should send > #invalidate to it. For complex views, if it's easy to compute a region of > change, you can use invalidateRectangle: to restrict the scope of change. > > If you're stepping outside of those bounds, then you've decided you know > better than the framework and get to manage it yourself. :) > > Side note. I really wish people wouldn't use the > #invalidateRectangle:andRepairNow: true unless they're sure they need to. > It may go away, or at least become moot in the future. > > -- > Travis Griggs > Objologist > I multiply all time estimates by pi, to account for running around in > > > > > _______________________________________________ > vwnc mailing list > [hidden email] > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
|
|
No. Structure the sequence of your events so the update event occurs before the long running operation. One problem I ran into was I was updating the state of my model/view and it resulted in the need for the scroll bars to be updated also. Unfortunately, they did a repair now. The rectangles got combined to form one rectangle encompassing the whole view and then it decided to do a repair now, in the middle of the state update of my model. So when the display was rendered it was incorrect because the model had not finished updating. If the widget used a deferred invalidate, the model would have completed its update and would have rendered properly. Put it another way, widgets should use deferred invalidate. Your own view may be able to take liberties with that and do a repair now but I would not recommend it. Terry =========================================================== Terry Raymond Crafted Smalltalk 80 Lazywood Ln. Tiverton, RI 02878 (401) 624-4517 [hidden email] =========================================================== From: Dave Stevenson [mailto:[hidden email]] Isn't updating a widget before a long-running operation would otherwise get around to it good enough reason to repair now? That case has nothing to do with widget state... Dave Stevenson From: Terry Raymond <[hidden email]> _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
|
|
I should have been clearer. You want to insure that the model state, and resulting view state, have been completely updated before any redisplay occurs. If you use repair now you run the risk that the model or view state has not been completely updated before being redisplayed. Terry =========================================================== Terry Raymond Crafted Smalltalk 80 Lazywood Ln. Tiverton, RI 02878 (401) 624-4517 [hidden email] =========================================================== From: [hidden email] [mailto:[hidden email]] On Behalf Of Terry Raymond No. Structure the sequence of your events so the update event occurs before the long running operation. One problem I ran into was I was updating the state of my model/view and it resulted in the need for the scroll bars to be updated also. Unfortunately, they did a repair now. The rectangles got combined to form one rectangle encompassing the whole view and then it decided to do a repair now, in the middle of the state update of my model. So when the display was rendered it was incorrect because the model had not finished updating. If the widget used a deferred invalidate, the model would have completed its update and would have rendered properly. Put it another way, widgets should use deferred invalidate. Your own view may be able to take liberties with that and do a repair now but I would not recommend it. Terry =========================================================== Terry Raymond Crafted Smalltalk 80 Lazywood Ln. Tiverton, RI 02878 (401) 624-4517 [hidden email] =========================================================== From: Dave Stevenson [mailto:[hidden email]] Isn't updating a widget before a long-running operation would otherwise get around to it good enough reason to repair now? That case has nothing to do with widget state... Dave Stevenson From: Terry Raymond <[hidden email]> _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
|
|
Ive used this when i want to guarantee the view updates before returning to my application code. In particular for a progress indicator or something thats called from some long running application code. I found too many times the view updates would get put into a queue or batched in some way such that no updates occurred until my long running process was complete. Which defeats the purpose of any kind of progress indicator. Using #invalidateRectangle:andRepairNow: true fixed the problem Is there a better way to accomplish the same thing? On Mon, Nov 7, 2011 at 5:11 PM, Terry Raymond <[hidden email]> wrote:
_______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
|
|
In reply to this post by Travis Griggs-4
I am using #invalidateNow for a feedback button and am a bit out of imagination on how to do it differently
(while I agree with the point for most other occasions). Scenario: I have a button on the toolbar which sends out a bunch of requests asynchronously. Whenever a request comes back, I want to inform the user on the number of outstanding requests by repainting the button showing this number. (I do optimize painting by throwing away display requests when displaying is in progress). How could you do that with simply invalidation - almost nothing will be drawn since the UI doesn't get enough events from the OS? Especially with feedback on asynchronous events, I don't see any other way than to force a redraw... Cheers, Christian > -----Ursprüngliche Nachricht----- > Von: [hidden email] [mailto:[hidden email]] Im > Auftrag von Terry Raymond > Gesendet: Montag, 7. November 2011 23:01 > An: 'VWNC NC' > Betreff: Re: [vwnc] Z-order and occlusion > > > > Side note. I really wish people wouldn't use the > > #invalidateRectangle:andRepairNow: true unless they're sure they need > to. > > It may go away, or at least become moot in the future. > > +100 > > IMHO no widgets should require immediate redisplay, all should retain > enough state to display properly via deferred invalidate. > > Terry > > ========================================================== > = > Terry Raymond > Crafted Smalltalk > 80 Lazywood Ln. > Tiverton, RI 02878 > (401) 624-4517 [hidden email] > ========================================================== > = > > > -----Original Message----- > > From: [hidden email] [mailto:[hidden email]] On > > Behalf Of Travis Griggs > > Sent: Monday, November 07, 2011 1:55 PM > > To: Carl Gundel; VWNC NC > > Subject: Re: [vwnc] Z-order and occlusion > > > > > > On Nov 7, 2011, at 9:54 AM, Carl Gundel wrote: > > > > > I thought I already replied to this, but it isn't posted. :-/ > > > > > > I'm not really sure what you mean by "use invalidate". If you still > > > have that GraphPanePart example I sent you, that is the widget I am > > > placing other widgets on top of. If I'm doing any particular thing > > > wrong in that implementation, please toss your thoughts my way. > > > > > > Maybe this is the perfect opportunity to post about the proper use > > > of invalidated and isOccluded on that blog you are starting. ;-) > > > > > > See "Redisplay all or Part of a View" in the GUI Dev Guide. > > > > It's pretty straightforward actually. > > > > A VW widget implements a #displayOn: method where it should use the > GC > > handed to it to do all of its drawing. It should use that GC, not > > another, > and > > shouldn't store the GC for later use. > > > > When you want all or part of a widget to be redrawn, you should send > > #invalidate to it. For complex views, if it's easy to compute a region > > of change, you can use invalidateRectangle: to restrict the scope of change. > > > > If you're stepping outside of those bounds, then you've decided you > > know better than the framework and get to manage it yourself. :) > > > > Side note. I really wish people wouldn't use the > > #invalidateRectangle:andRepairNow: true unless they're sure they need > to. > > It may go away, or at least become moot in the future. > > > > -- > > Travis Griggs > > Objologist > > I multiply all time estimates by pi, to account for running around in > circles. > > > > > > > > > > _______________________________________________ > > vwnc mailing list > > [hidden email] > > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > > > > _______________________________________________ > vwnc mailing list > [hidden email] > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
|
|
In reply to this post by Jon Paynter-2
Yes, there is a proper way. Whenever you have a window that is periodically updated to show some kind of status of a long running process you should open the window in its own window manager and elevate the priority of the window process. Additionally, you should make sure to use #uiEventFor: or one of its variations to communicate with the window process. Terry =========================================================== Terry Raymond Crafted Smalltalk 80 Lazywood Ln. Tiverton, RI 02878 (401) 624-4517 [hidden email] =========================================================== From: Jon Paynter [mailto:[hidden email]] Ive used this when i want to guarantee the view updates before returning to my application code. In particular for a progress indicator or something thats called from some long running application code. I found too many times the view updates would get put into a queue or batched in some way such that no updates occurred until my long running process was complete. Which defeats the purpose of any kind of progress indicator. I should have been clearer. You want to insure that the model state, and resulting view state, have been completely updated before any redisplay occurs. If you use repair now you run the risk that the model or view state has not been completely updated before being redisplayed. Terry =========================================================== Terry Raymond Crafted Smalltalk 80 Lazywood Ln. Tiverton, RI 02878 (401) 624-4517 [hidden email] =========================================================== From: [hidden email] [mailto:[hidden email]] On Behalf Of Terry Raymond
No. Structure the sequence of your events so the update event occurs before the long running operation. One problem I ran into was I was updating the state of my model/view and it resulted in the need for the scroll bars to be updated also. Unfortunately, they did a repair now. The rectangles got combined to form one rectangle encompassing the whole view and then it decided to do a repair now, in the middle of the state update of my model. So when the display was rendered it was incorrect because the model had not finished updating. If the widget used a deferred invalidate, the model would have completed its update and would have rendered properly. Put it another way, widgets should use deferred invalidate. Your own view may be able to take liberties with that and do a repair now but I would not recommend it. Terry =========================================================== Terry Raymond Crafted Smalltalk 80 Lazywood Ln. Tiverton, RI 02878 (401) 624-4517 [hidden email] =========================================================== From: Dave Stevenson [mailto:[hidden email]] Isn't updating a widget before a long-running operation would otherwise get around to it good enough reason to repair now? That case has nothing to do with widget state... Dave Stevenson From: Terry Raymond <[hidden email]>
_______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
|
|
In reply to this post by Christian Haider
Christian
First of all the replies should come back using #uiEventFor: , they should not do direct updates of the model/view state. You should consider the state of the model and view as owned by the window process and any updates must be done as an asynchronous message using a variation of #uiEventFor:. The action being done in the ui block can do a simple invalidate which will result in the display being updated. If you are concerned about a background process starving the window process then you either elevate the priority of the window process or lower the priority of the background process. Terry =========================================================== Terry Raymond Crafted Smalltalk 80 Lazywood Ln. Tiverton, RI 02878 (401) 624-4517 [hidden email] =========================================================== > -----Original Message----- > From: [hidden email] [mailto:[hidden email]] On > Behalf Of Christian Haider > Sent: Tuesday, November 08, 2011 6:54 AM > To: VWNC NC > Subject: Re: [vwnc] Z-order and occlusion > > I am using #invalidateNow for a feedback button and am a bit out of > imagination on how to do it differently (while I agree with the point for most > other occasions). > > Scenario: I have a button on the toolbar which sends out a bunch of requests > asynchronously. Whenever a request comes back, I want to inform the user > on the number of outstanding requests by repainting the button showing > this number. (I do optimize painting by throwing away display requests when > displaying is in progress). How could you do that with simply invalidation - > almost nothing will be drawn since the UI doesn't get enough events from > the OS? Especially with feedback on asynchronous events, I don't see any > other way than to force a redraw... > > Cheers, > Christian > > > -----Ursprüngliche Nachricht----- > > Von: [hidden email] [mailto:[hidden email]] Im > > Auftrag von Terry Raymond > > Gesendet: Montag, 7. November 2011 23:01 > > An: 'VWNC NC' > > Betreff: Re: [vwnc] Z-order and occlusion > > > > > > > Side note. I really wish people wouldn't use the > > > #invalidateRectangle:andRepairNow: true unless they're sure they > > > need > > to. > > > It may go away, or at least become moot in the future. > > > > +100 > > > > IMHO no widgets should require immediate redisplay, all should retain > > enough state to display properly via deferred invalidate. > > > > Terry > > > > > ========================================================== > > = > > Terry Raymond > > Crafted Smalltalk > > 80 Lazywood Ln. > > Tiverton, RI 02878 > > (401) 624-4517 [hidden email] > > > ========================================================== > > = > > > > > -----Original Message----- > > > From: [hidden email] [mailto:[hidden email]] > On > > > Behalf Of Travis Griggs > > > Sent: Monday, November 07, 2011 1:55 PM > > > To: Carl Gundel; VWNC NC > > > Subject: Re: [vwnc] Z-order and occlusion > > > > > > > > > On Nov 7, 2011, at 9:54 AM, Carl Gundel wrote: > > > > > > > I thought I already replied to this, but it isn't posted. :-/ > > > > > > > > I'm not really sure what you mean by "use invalidate". If you > > > > still have that GraphPanePart example I sent you, that is the > > > > widget I am placing other widgets on top of. If I'm doing any > > > > particular thing wrong in that implementation, please toss your > thoughts my way. > > > > > > > > Maybe this is the perfect opportunity to post about the proper use > > > > of invalidated and isOccluded on that blog you are starting. ;-) > > > > > > > > > See "Redisplay all or Part of a View" in the GUI Dev Guide. > > > > > > It's pretty straightforward actually. > > > > > > A VW widget implements a #displayOn: method where it should use the > > GC > > > handed to it to do all of its drawing. It should use that GC, not > > > another, > > and > > > shouldn't store the GC for later use. > > > > > > When you want all or part of a widget to be redrawn, you should send > > > #invalidate to it. For complex views, if it's easy to compute a > > > region of change, you can use invalidateRectangle: to restrict the > change. > > > > > > If you're stepping outside of those bounds, then you've decided you > > > know better than the framework and get to manage it yourself. :) > > > > > > Side note. I really wish people wouldn't use the > > > #invalidateRectangle:andRepairNow: true unless they're sure they > > > need > > to. > > > It may go away, or at least become moot in the future. > > > > > > -- > > > Travis Griggs > > > Objologist > > > I multiply all time estimates by pi, to account for running around > > > in > > circles. > > > > > > > > > > > > > > > _______________________________________________ > > > vwnc mailing list > > > [hidden email] > > > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > > > > > > > > _______________________________________________ > > vwnc mailing list > > [hidden email] > > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > > > > > _______________________________________________ > vwnc mailing list > [hidden email] > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
|
|
In reply to this post by Christian Haider
Hello.
On 8.11.2011 12:54, Christian Haider wrote: > I am using #invalidateNow for a feedback button and am a bit out of imagination on how to do it differently > (while I agree with the point for most other occasions). > > Scenario: I have a button on the toolbar which sends out a bunch of requests asynchronously. Whenever > a request comes back, I want to inform the user on the number of outstanding requests by repainting > the button showing this number. (I do optimize painting by throwing away display requests when displaying > is in progress). How could you do that with simply invalidation - almost nothing will be drawn since the > UI doesn't get enough events from the OS? Especially with feedback on asynchronous events, I don't see any > other way than to force a redraw... Maybe I don't follow but what about #uiEventFor: / #uiEventNowFor:? The events are asynchronous so I guess you process them in a separate thread anyway (i.e. outside the UI thread). If so then when you have processed the answer and updated your internal state appropriately, you only have to update the UI via a variant of #uiEvent... The UI thread will process this event *immediately* and redisplay any pending invalidation automatically at the end of its processing. > almost nothing will be drawn since the UI doesn't get enough events from the OS Do your work in a background process and use a variant of #uiEventFor: to update the UI from there and it will be drawn and updated properly. HTH, Ladislav Lenart _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
|
|
In reply to this post by Terry Raymond
Hello.
Ignore my previous post. The below is EXACTLY what I was trying to articulate but wasn't able to. Thank you Terry :-) Ladislav Lenart On 8.11.2011 13:50, Terry Raymond wrote: > Christian > > First of all the replies should come back using #uiEventFor: , they should > not > do direct updates of the model/view state. > > You should consider the state of the model and view as owned by the window > process and any updates must be done as an asynchronous message using a > variation of #uiEventFor:. The action being done in the ui block can do a > simple > invalidate which will result in the display being updated. If you are > concerned > about a background process starving the window process then you either > elevate > the priority of the window process or lower the priority of the background > process. > > Terry _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
|
|
In reply to this post by Terry Raymond
But watch out for OS damage events during your long operation. The model that the window displays from may be in an illegal state part-way through some part of the long operation, but the OS damage event will be processed immediately by VW, leading to a redisplay that gives an error.
And don't rely on VW's event mechanism processing events in order: e.g. opening any dialog will break the order. Steve > -----Original Message----- > From: [hidden email] [mailto:[hidden email]] On > Behalf Of Terry Raymond > Sent: 8. marraskuuta 2011 14:51 > To: 'Christian Haider'; 'VWNC NC' > Subject: Re: [vwnc] Z-order and occlusion > > Christian > > First of all the replies should come back using #uiEventFor: , they > should > not > do direct updates of the model/view state. > > You should consider the state of the model and view as owned by the > window > process and any updates must be done as an asynchronous message using a > variation of #uiEventFor:. The action being done in the ui block can do > a > simple > invalidate which will result in the display being updated. If you are > concerned > about a background process starving the window process then you either > elevate > the priority of the window process or lower the priority of the > background > process. > > Terry > > =========================================================== > Terry Raymond > Crafted Smalltalk > 80 Lazywood Ln. > Tiverton, RI 02878 > (401) 624-4517 [hidden email] > =========================================================== > > > -----Original Message----- > > From: [hidden email] [mailto:[hidden email]] On > > Behalf Of Christian Haider > > Sent: Tuesday, November 08, 2011 6:54 AM > > To: VWNC NC > > Subject: Re: [vwnc] Z-order and occlusion > > > > I am using #invalidateNow for a feedback button and am a bit out of > > imagination on how to do it differently (while I agree with the point > for > most > > other occasions). > > > > Scenario: I have a button on the toolbar which sends out a bunch of > requests > > asynchronously. Whenever a request comes back, I want to inform the > user > > on the number of outstanding requests by repainting the button > showing > > this number. (I do optimize painting by throwing away display > requests > when > > displaying is in progress). How could you do that with simply > invalidation > - > > almost nothing will be drawn since the UI doesn't get enough events > from > > the OS? Especially with feedback on asynchronous events, I don't see > any > > other way than to force a redraw... > > > > Cheers, > > Christian > > > > > -----Ursprüngliche Nachricht----- > > > Von: [hidden email] [mailto:[hidden email]] Im > > > Auftrag von Terry Raymond > > > Gesendet: Montag, 7. November 2011 23:01 > > > An: 'VWNC NC' > > > Betreff: Re: [vwnc] Z-order and occlusion > > > > > > > > > > Side note. I really wish people wouldn't use the > > > > #invalidateRectangle:andRepairNow: true unless they're sure they > > > > need > > > to. > > > > It may go away, or at least become moot in the future. > > > > > > +100 > > > > > > IMHO no widgets should require immediate redisplay, all should > retain > > > enough state to display properly via deferred invalidate. > > > > > > Terry > > > > > > > > ========================================================== > > > = > > > Terry Raymond > > > Crafted Smalltalk > > > 80 Lazywood Ln. > > > Tiverton, RI 02878 > > > (401) 624-4517 [hidden email] > > > > > ========================================================== > > > = > > > > > > > -----Original Message----- > > > > From: [hidden email] [mailto:[hidden email]] > > On > > > > Behalf Of Travis Griggs > > > > Sent: Monday, November 07, 2011 1:55 PM > > > > To: Carl Gundel; VWNC NC > > > > Subject: Re: [vwnc] Z-order and occlusion > > > > > > > > > > > > On Nov 7, 2011, at 9:54 AM, Carl Gundel wrote: > > > > > > > > > I thought I already replied to this, but it isn't posted. :-/ > > > > > > > > > > I'm not really sure what you mean by "use invalidate". If you > > > > > still have that GraphPanePart example I sent you, that is the > > > > > widget I am placing other widgets on top of. If I'm doing any > > > > > particular thing wrong in that implementation, please toss your > > thoughts my way. > > > > > > > > > > Maybe this is the perfect opportunity to post about the proper > use > > > > > of invalidated and isOccluded on that blog you are starting. > ;-) > > > > > > > > > > > > See "Redisplay all or Part of a View" in the GUI Dev Guide. > > > > > > > > It's pretty straightforward actually. > > > > > > > > A VW widget implements a #displayOn: method where it should use > the > > > GC > > > > handed to it to do all of its drawing. It should use that GC, not > > > > another, > > > and > > > > shouldn't store the GC for later use. > > > > > > > > When you want all or part of a widget to be redrawn, you should > send > > > > #invalidate to it. For complex views, if it's easy to compute a > > > > region of change, you can use invalidateRectangle: to restrict > the > scope of > > change. > > > > > > > > If you're stepping outside of those bounds, then you've decided > you > > > > know better than the framework and get to manage it yourself. :) > > > > > > > > Side note. I really wish people wouldn't use the > > > > #invalidateRectangle:andRepairNow: true unless they're sure they > > > > need > > > to. > > > > It may go away, or at least become moot in the future. > > > > > > > > -- > > > > Travis Griggs > > > > Objologist > > > > I multiply all time estimates by pi, to account for running > around > > > > in > > > circles. > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > vwnc mailing list > > > > [hidden email] > > > > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > > > > > > > > > > > > _______________________________________________ > > > vwnc mailing list > > > [hidden email] > > > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > > > > > > > > > _______________________________________________ > > vwnc mailing list > > [hidden email] > > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > > > > _______________________________________________ > vwnc mailing list > [hidden email] > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
|
|
In reply to this post by Terry Raymond
Forgot one more important thing: if you have your background process in a lower-priority process than your window's process, you also need to consider disabling other actions in your window while the background process runs.
Steve Steven Kelly wrote: > > But watch out for OS damage events during your long operation. The > model that the window displays from may be in an illegal state part-way > through some part of the long operation, but the OS damage event will > be processed immediately by VW, leading to a redisplay that gives an > error. > > And don't rely on VW's event mechanism processing events in order: e.g. > opening any dialog will break the order. > > Steve > > > -----Original Message----- > > From: [hidden email] [mailto:[hidden email]] On > > Behalf Of Terry Raymond > > Sent: 8. marraskuuta 2011 14:51 > > To: 'Christian Haider'; 'VWNC NC' > > Subject: Re: [vwnc] Z-order and occlusion > > > > Christian > > > > First of all the replies should come back using #uiEventFor: , they > > should > > not > > do direct updates of the model/view state. > > > > You should consider the state of the model and view as owned by the > > window > > process and any updates must be done as an asynchronous message using > a > > variation of #uiEventFor:. The action being done in the ui block can > do > > a > > simple > > invalidate which will result in the display being updated. If you are > > concerned > > about a background process starving the window process then you > either > > elevate > > the priority of the window process or lower the priority of the > > background > > process. > > > > Terry > > > > =========================================================== > > Terry Raymond > > Crafted Smalltalk > > 80 Lazywood Ln. > > Tiverton, RI 02878 > > (401) 624-4517 [hidden email] > > =========================================================== > > > > > -----Original Message----- > > > From: [hidden email] [mailto:[hidden email]] On > > > Behalf Of Christian Haider > > > Sent: Tuesday, November 08, 2011 6:54 AM > > > To: VWNC NC > > > Subject: Re: [vwnc] Z-order and occlusion > > > > > > I am using #invalidateNow for a feedback button and am a bit out of > > > imagination on how to do it differently (while I agree with the > point > > for > > most > > > other occasions). > > > > > > Scenario: I have a button on the toolbar which sends out a bunch of > > requests > > > asynchronously. Whenever a request comes back, I want to inform the > > user > > > on the number of outstanding requests by repainting the button > > showing > > > this number. (I do optimize painting by throwing away display > > requests > > when > > > displaying is in progress). How could you do that with simply > > invalidation > > - > > > almost nothing will be drawn since the UI doesn't get enough events > > from > > > the OS? Especially with feedback on asynchronous events, I don't > see > > any > > > other way than to force a redraw... > > > > > > Cheers, > > > Christian > > > > > > > -----Ursprüngliche Nachricht----- > > > > Von: [hidden email] [mailto:[hidden email]] > Im > > > > Auftrag von Terry Raymond > > > > Gesendet: Montag, 7. November 2011 23:01 > > > > An: 'VWNC NC' > > > > Betreff: Re: [vwnc] Z-order and occlusion > > > > > > > > > > > > > Side note. I really wish people wouldn't use the > > > > > #invalidateRectangle:andRepairNow: true unless they're sure > they > > > > > need > > > > to. > > > > > It may go away, or at least become moot in the future. > > > > > > > > +100 > > > > > > > > IMHO no widgets should require immediate redisplay, all should > > retain > > > > enough state to display properly via deferred invalidate. > > > > > > > > Terry > > > > > > > > > > > ========================================================== > > > > = > > > > Terry Raymond > > > > Crafted Smalltalk > > > > 80 Lazywood Ln. > > > > Tiverton, RI 02878 > > > > (401) 624-4517 [hidden email] > > > > > > > ========================================================== > > > > = > > > > > > > > > -----Original Message----- > > > > > From: [hidden email] [mailto:vwnc- > [hidden email]] > > > On > > > > > Behalf Of Travis Griggs > > > > > Sent: Monday, November 07, 2011 1:55 PM > > > > > To: Carl Gundel; VWNC NC > > > > > Subject: Re: [vwnc] Z-order and occlusion > > > > > > > > > > > > > > > On Nov 7, 2011, at 9:54 AM, Carl Gundel wrote: > > > > > > > > > > > I thought I already replied to this, but it isn't posted. :- > / > > > > > > > > > > > > I'm not really sure what you mean by "use invalidate". If > you > > > > > > still have that GraphPanePart example I sent you, that is the > > > > > > widget I am placing other widgets on top of. If I'm doing > any > > > > > > particular thing wrong in that implementation, please toss > your > > > thoughts my way. > > > > > > > > > > > > Maybe this is the perfect opportunity to post about the > proper > > use > > > > > > of invalidated and isOccluded on that blog you are starting. > > ;-) > > > > > > > > > > > > > > > See "Redisplay all or Part of a View" in the GUI Dev Guide. > > > > > > > > > > It's pretty straightforward actually. > > > > > > > > > > A VW widget implements a #displayOn: method where it should use > > the > > > > GC > > > > > handed to it to do all of its drawing. It should use that GC, > not > > > > > another, > > > > and > > > > > shouldn't store the GC for later use. > > > > > > > > > > When you want all or part of a widget to be redrawn, you should > > send > > > > > #invalidate to it. For complex views, if it's easy to compute a > > > > > region of change, you can use invalidateRectangle: to restrict > > the > > scope of > > > change. > > > > > > > > > > If you're stepping outside of those bounds, then you've decided > > you > > > > > know better than the framework and get to manage it yourself. > :) > > > > > > > > > > Side note. I really wish people wouldn't use the > > > > > #invalidateRectangle:andRepairNow: true unless they're sure > they > > > > > need > > > > to. > > > > > It may go away, or at least become moot in the future. > > > > > > > > > > -- > > > > > Travis Griggs > > > > > Objologist > > > > > I multiply all time estimates by pi, to account for running > > around > > > > > in > > > > circles. > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > vwnc mailing list > > > > > [hidden email] > > > > > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > > > > > > > > > > > > > > > > _______________________________________________ > > > > vwnc mailing list > > > > [hidden email] > > > > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > > > > > > > > > > > > > _______________________________________________ > > > vwnc mailing list > > > [hidden email] > > > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > > > > > > > > _______________________________________________ > > vwnc mailing list > > [hidden email] > > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
|
|
In reply to this post by Steven Kelly
Not so as long as the model state is updated only by the window process.
What you wrote would be correct if the model state is updated by a background process. If the window process is updating the model state then the OS damage event will wait until the model update has completed. You must be scrupulous about making sure that model updates only occur in the window process. Terry =========================================================== Terry Raymond Crafted Smalltalk 80 Lazywood Ln. Tiverton, RI 02878 (401) 624-4517 [hidden email] =========================================================== > -----Original Message----- > From: [hidden email] [mailto:[hidden email]] On > Behalf Of Steven Kelly > Sent: Tuesday, November 08, 2011 8:24 AM > To: VWNC NC > Subject: Re: [vwnc] Z-order and occlusion > > But watch out for OS damage events during your long operation. The model > that the window displays from may be in an illegal state part-way through > some part of the long operation, but the OS damage event will be processed > immediately by VW, leading to a redisplay that gives an error. > > And don't rely on VW's event mechanism processing events in order: e.g. > opening any dialog will break the order. > > Steve > > > -----Original Message----- > > From: [hidden email] [mailto:[hidden email]] On > > Behalf Of Terry Raymond > > Sent: 8. marraskuuta 2011 14:51 > > To: 'Christian Haider'; 'VWNC NC' > > Subject: Re: [vwnc] Z-order and occlusion > > > > Christian > > > > First of all the replies should come back using #uiEventFor: , they > > should not do direct updates of the model/view state. > > > > You should consider the state of the model and view as owned by the > > window process and any updates must be done as an asynchronous > message > > using a variation of #uiEventFor:. The action being done in the ui > > block can do a simple invalidate which will result in the display > > being updated. If you are concerned about a background process > > starving the window process then you either elevate the priority of > > the window process or lower the priority of the background process. > > > > Terry > > > > > ========================================================== > = > > Terry Raymond > > Crafted Smalltalk > > 80 Lazywood Ln. > > Tiverton, RI 02878 > > (401) 624-4517 [hidden email] > > > ========================================================== > = > > > > > -----Original Message----- > > > From: [hidden email] [mailto:[hidden email]] > On > > > Behalf Of Christian Haider > > > Sent: Tuesday, November 08, 2011 6:54 AM > > > To: VWNC NC > > > Subject: Re: [vwnc] Z-order and occlusion > > > > > > I am using #invalidateNow for a feedback button and am a bit out of > > > imagination on how to do it differently (while I agree with the > > > point > > for > > most > > > other occasions). > > > > > > Scenario: I have a button on the toolbar which sends out a bunch of > > requests > > > asynchronously. Whenever a request comes back, I want to inform the > > user > > > on the number of outstanding requests by repainting the button > > showing > > > this number. (I do optimize painting by throwing away display > > requests > > when > > > displaying is in progress). How could you do that with simply > > invalidation > > - > > > almost nothing will be drawn since the UI doesn't get enough events > > from > > > the OS? Especially with feedback on asynchronous events, I don't see > > any > > > other way than to force a redraw... > > > > > > Cheers, > > > Christian > > > > > > > -----Ursprüngliche Nachricht----- > > > > Von: [hidden email] [mailto:[hidden email]] > Im > > > > Auftrag von Terry Raymond > > > > Gesendet: Montag, 7. November 2011 23:01 > > > > An: 'VWNC NC' > > > > Betreff: Re: [vwnc] Z-order and occlusion > > > > > > > > > > > > > Side note. I really wish people wouldn't use the > > > > > #invalidateRectangle:andRepairNow: true unless they're sure they > > > > > need > > > > to. > > > > > It may go away, or at least become moot in the future. > > > > > > > > +100 > > > > > > > > IMHO no widgets should require immediate redisplay, all should > > retain > > > > enough state to display properly via deferred invalidate. > > > > > > > > Terry > > > > > > > > > > > > ========================================================== > > > > = > > > > Terry Raymond > > > > Crafted Smalltalk > > > > 80 Lazywood Ln. > > > > Tiverton, RI 02878 > > > > (401) 624-4517 [hidden email] > > > > > > > > ========================================================== > > > > = > > > > > > > > > -----Original Message----- > > > > > From: [hidden email] [mailto:vwnc- > [hidden email]] > > > On > > > > > Behalf Of Travis Griggs > > > > > Sent: Monday, November 07, 2011 1:55 PM > > > > > To: Carl Gundel; VWNC NC > > > > > Subject: Re: [vwnc] Z-order and occlusion > > > > > > > > > > > > > > > On Nov 7, 2011, at 9:54 AM, Carl Gundel wrote: > > > > > > > > > > > I thought I already replied to this, but it isn't posted. :-/ > > > > > > > > > > > > I'm not really sure what you mean by "use invalidate". If you > > > > > > still have that GraphPanePart example I sent you, that is the > > > > > > widget I am placing other widgets on top of. If I'm doing any > > > > > > particular thing wrong in that implementation, please toss > > > > > > your > > > thoughts my way. > > > > > > > > > > > > Maybe this is the perfect opportunity to post about the proper > > use > > > > > > of invalidated and isOccluded on that blog you are starting. > > ;-) > > > > > > > > > > > > > > > See "Redisplay all or Part of a View" in the GUI Dev Guide. > > > > > > > > > > It's pretty straightforward actually. > > > > > > > > > > A VW widget implements a #displayOn: method where it should use > > the > > > > GC > > > > > handed to it to do all of its drawing. It should use that GC, > > > > > not another, > > > > and > > > > > shouldn't store the GC for later use. > > > > > > > > > > When you want all or part of a widget to be redrawn, you should > > send > > > > > #invalidate to it. For complex views, if it's easy to compute a > > > > > region of change, you can use invalidateRectangle: to restrict > > the > > scope of > > > change. > > > > > > > > > > If you're stepping outside of those bounds, then you've decided > > you > > > > > know better than the framework and get to manage it yourself. :) > > > > > > > > > > Side note. I really wish people wouldn't use the > > > > > #invalidateRectangle:andRepairNow: true unless they're sure they > > > > > need > > > > to. > > > > > It may go away, or at least become moot in the future. > > > > > > > > > > -- > > > > > Travis Griggs > > > > > Objologist > > > > > I multiply all time estimates by pi, to account for running > > around > > > > > in > > > > circles. > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > vwnc mailing list > > > > > [hidden email] > > > > > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > > > > > > > > > > > > > > > > _______________________________________________ > > > > vwnc mailing list > > > > [hidden email] > > > > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > > > > > > > > > > > > > _______________________________________________ > > > vwnc mailing list > > > [hidden email] > > > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > > > > > > > > _______________________________________________ > > vwnc mailing list > > [hidden email] > > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > > _______________________________________________ > vwnc mailing list > [hidden email] > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
| Free forum by Nabble | Edit this page |