Z-order and occlusion

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 [[hidden email]]
Sent: Monday, November 07, 2011 8:45 PM
To: VWNC NC
Cc: Terry Raymond
Subject: Re: [vwnc] Z-order and occlusion

 

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:

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
Sent: Monday, November 07, 2011 7:51 PM
To: 'VWNC NC'

Subject: Re: [vwnc] Z-order and occlusion

 

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]]
Sent: Monday, November 07, 2011 6:13 PM
To: Terry Raymond; VWNC NC
Subject: Re: [vwnc] Z-order and occlusion

 

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,
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

-- 
*********************************************************************

Dit e-mailbericht is alleen bestemd voor de geadresseerde(n).

Gebruik door anderen is niet toegestaan. Indien u niet degeadresseerde(n) bent wordt u verzocht de verzender hiervan op de hoogte te stellen en het bericht te verwijderen. Door de elektronische verzending kunnen aan de inhoud van dit bericht geen rechten worden ontleend.

Soops B.V. is gevestigd te Amsterdam, Nederland, en is geregistreerd bij de Kamer van Koophandel onder nummer 33240368.
Soops B.V. levert volgens de Fenit voorwaarden, gedeponeerd te Den Haag op 8 december 1994 onder nummer 1994/189.
**********************************************************************

This e-mail message is intended to be exclusively for the addressee.

If you are not the intended recipient you are kindly requested not to make any use whatsoever of the contents and to notify the sender immediately by returning this e-mail message. No rights can be derived from this message.

Soops B.V. is a private limited liability company and has its seat at Amsterdam, The Netherlands and is registered with the Trade Registry of the Chamber of Commerce and Industry under number 33240368.
Soops B.V. delivers according to the General Terms and Conditions of Business of Fenit, registered at The Hague, The Netherlands on December 8th, 1994, under number 1994/189
**********************************************************************

BlockClosure>>uiEventFor: is used all the time, by customer and system code, and has been around for roughly 15 years. What's unsanctioned or untested about it?

 

Why do you need to wrap it in another api call? The simple rule is, if a forked process wants to update some model of the UI, where updating that model would lead to dependency updates of views, use one of

    uiEvent

    uiEventFor:

    uiEventNow

    uiEventNowFor:

so the update happens in the window's UI process, rather than the forked process. Why is that hard to get right?

On 11/8/2011 1:43 PM, Terry Raymond wrote:

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.

What you describe here is low-level multi-processing assembly code.
No-one gets this right on first try.


Where is the sanctioned (tested!) API for this abstraction?



Reinout
-------

 

Terry

 

===========================================================

Terry Raymond

Crafted Smalltalk

80 Lazywood Ln.

Tiverton, RI  02878

(401) 624-4517      [hidden email]

===========================================================

 

From: Jon Paynter [[hidden email]]
Sent: Monday, November 07, 2011 8:45 PM
To: VWNC NC
Cc: Terry Raymond
Subject: Re: [vwnc] Z-order and occlusion

 

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:

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
Sent: Monday, November 07, 2011 7:51 PM
To: 'VWNC NC'

Subject: Re: [vwnc] Z-order and occlusion

 

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]]
Sent: Monday, November 07, 2011 6:13 PM
To: Terry Raymond; VWNC NC
Subject: Re: [vwnc] Z-order and occlusion

 

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,
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

-- 
*********************************************************************

Dit e-mailbericht is alleen bestemd voor de geadresseerde(n).

Gebruik door anderen is niet toegestaan. Indien u niet degeadresseerde(n) bent wordt u verzocht de verzender hiervan op de hoogte te stellen en het bericht te verwijderen. Door de elektronische verzending kunnen aan de inhoud van dit bericht geen rechten worden ontleend.

Soops B.V. is gevestigd te Amsterdam, Nederland, en is geregistreerd bij de Kamer van Koophandel onder nummer 33240368.
Soops B.V. levert volgens de Fenit voorwaarden, gedeponeerd te Den Haag op 8 december 1994 onder nummer 1994/189.
**********************************************************************

This e-mail message is intended to be exclusively for the addressee.

If you are not the intended recipient you are kindly requested not to make any use whatsoever of the contents and to notify the sender immediately by returning this e-mail message. No rights can be derived from this message.

Soops B.V. is a private limited liability company and has its seat at Amsterdam, The Netherlands and is registered with the Trade Registry of the Chamber of Commerce and Industry under number 33240368.
Soops B.V. delivers according to the General Terms and Conditions of Business of Fenit, registered at The Hague, The Netherlands on December 8th, 1994, under number 1994/189
**********************************************************************

-- 
*********************************************************************

Dit e-mailbericht is alleen bestemd voor de geadresseerde(n).

Gebruik door anderen is niet toegestaan. Indien u niet degeadresseerde(n) bent wordt u verzocht de verzender hiervan op de hoogte te stellen en het bericht te verwijderen. Door de elektronische verzending kunnen aan de inhoud van dit bericht geen rechten worden ontleend.

Soops B.V. is gevestigd te Amsterdam, Nederland, en is geregistreerd bij de Kamer van Koophandel onder nummer 33240368.
Soops B.V. levert volgens de Fenit voorwaarden, gedeponeerd te Den Haag op 8 december 1994 onder nummer 1994/189.
**********************************************************************

This e-mail message is intended to be exclusively for the addressee.

If you are not the intended recipient you are kindly requested not to make any use whatsoever of the contents and to notify the sender immediately by returning this e-mail message. No rights can be derived from this message.

Soops B.V. is a private limited liability company and has its seat at Amsterdam, The Netherlands and is registered with the Trade Registry of the Chamber of Commerce and Industry under number 33240368.
Soops B.V. delivers according to the General Terms and Conditions of Business of Fenit, registered at The Hague, The Netherlands on December 8th, 1994, under number 1994/189
**********************************************************************