Stacking PtPanes

Hi

I have a stack of identically sized PtPanes with different contents. A
number of buttons (one per pane) are used to PtWidgetToFront(ABW_…) the
pane that goes with the button. Its a bit like folder tabs. The buttons and
panes are all on a larger pane.

The challenge I have is that while the approach works there is a lot of
flickering of the stack of panes when one is pulled to the front, almost as
if some of the panes are being redrawn (I can see at least one which is in
the middle of the stack become visible for a short time) as one of them is
pulled to the front. Is this expected behaviour ? and if so is there a way
round it.
4.12 & 1.14 latest patches from web site.

Steve

After some experimenting,

The effect is caused by the highlight roundness parameter, I was using 10.
When it is 0 the stack behaves as expected and only the selected pane is
redrawn. Set it to non zero and the multiple redraw happens. It looks like
Photon does not realise that a fully covered pane is not damages when an
identical one behind it is pulled to the front except when it has square
corners. I can also see the effect while editing the stack of panes in phab.

Steve

Previously, Stephen F Terrell wrote in qdn.public.qnx4.photon:

After some experimenting,

The effect is caused by the highlight roundness parameter, I was using 10.
When it is 0 the stack behaves as expected and only the selected pane is
redrawn. Set it to non zero and the multiple redraw happens. It looks like
Photon does not realise that a fully covered pane is not damages when an
identical one behind it is pulled to the front except when it has square
corners. I can also see the effect while editing the stack of panes in phab.

I’m guessing, but I think I can explain this. As soon as
roundness is non-zero, the widget library must use a
transparency bitmap in order for the part of the widget
outside the rounded edge to show through. Not knowing what
parts of the lower panes will actually need redrawing, it
redraws them all using the painters algorithm, drawing
widgets furtherest to closest.

\

Mitchell Schoenbrun --------- maschoen@pobox.com

I’m guessing, but I think I can explain this. As soon as
roundness is non-zero, the widget library must use a
transparency bitmap in order for the part of the widget
outside the rounded edge to show through. Not knowing what
parts of the lower panes will actually need redrawing, it
redraws them all using the painters algorithm, drawing
widgets furtherest to closest.

\

Mitchell Schoenbrun --------- > maschoen@pobox.com


Its got to be something like that.

Its a pity because the rounded corners look quite cool but the redrawing
makes it look like its broken.
Perhaps there should be a health warning in the docs on this parameter.
Steve

Stephen F Terrell <stephen@trsystem.demon.co.uk> wrote:
: Its got to be something like that.
: Its a pity because the rounded corners look quite cool but the redrawing
: makes it look like its broken.
: Perhaps there should be a health warning in the docs on this parameter.

I’ll look into adding a note.

Did you consider using a picture module?


Steve Reid stever@qnx.com
TechPubs (Technical Publications)
QNX Software Systems

Previously, Stephen F Terrell wrote in qdn.public.qnx4.photon:

Its got to be something like that.
Its a pity because the rounded corners look quite cool but the redrawing
makes it look like its broken.
Perhaps there should be a health warning in the docs on this parameter.

The problem extends much wider than the rounding parameter. I’m on a
project where we had a lot of reshow type problems. One way to control
this is to un-realize the widgets that you know will not show. Then
the widget library has no reason to re-paint them. This puts the
burdeon on you of course. At the conference I was told that Photon 2.0
(NTO only) would do better optomization in this area.

A related issue had to do with controling the order in which widgets
are reshown. This is an issue if the user can perceive the redraw
and it occurs in a random fashion. The overal impression was bad.
I found that by putting widgets in a pane, and
realizing/unrealizing the pane I had better control.



Mitchell Schoenbrun --------- maschoen@pobox.com

The problem extends much wider than the rounding parameter. I’m on a
project where we had a lot of reshow type problems. One way to control
this is to un-realize the widgets that you know will not show. Then
the widget library has no reason to re-paint them. This puts the
burdeon on you of course. At the conference I was told that Photon 2.0
(NTO only) would do better optomization in this area.

A related issue had to do with controling the order in which widgets
are reshown. This is an issue if the user can perceive the redraw
and it occurs in a random fashion. The overal impression was bad.
I found that by putting widgets in a pane, and
realizing/unrealizing the pane I had better control.

Mitchell Schoenbrun --------- > maschoen@pobox.com


Thanks. I did look into the realise/unrealise approach some time ago but

dropped it then because I really want non visible windows to remember the
state of their contents (slider positions, list contents, combo box
selections, scroll bar positions, etc.) as they were before another window
was pulled in front of them so that when they are made visible again they
look the same as before.
One of my main problems is getting the right window/dialog/pane to the front
and keeping it there while the user clicks on other widgets on that or other
windows in the application. I know it should just be a problem of getting
the parent right and a few other rules but it somehow seems much harder than
that. How about a white paper ?

While on the realising issue, I do realise an oscilloscope type dialog which
I subsequently re-parent so that I can use it on different windows and keep
it visible and active. Occasionally it fails to appear !. The calls to
realise it and reparent it do not return a fault but when this happens I
cannot find it anywhere (I.e. by pulling away the windows via the Extended
World View to see if it is behind a visible window). There is not really
anywhere for it to hide so it looks like it was not drawn. Stopping the
program and restarting usually fixes the problem. This seems to happen
randomly but more often when I run the application from Phab. Anyone have
any ideas?

Steve

Previously, Stephen F Terrell wrote in qdn.public.qnx4.photon:

Thanks. I did look into the realise/unrealise approach some time ago but
dropped it then because I really want non visible windows to remember the
state of their contents (slider positions, list contents, combo box
selections, scroll bar positions, etc.) as they were before another window
was pulled in front of them so that when they are made visible again they
look the same as before.

Well, an unrealize/realize cycle should not change the state. The only
problem I’ve had is with a container widget. If widgets within a
container widget are unrealized and you cycle the container, all
widgets become realized. There is a widget bit you can set to
prevent a specific widget from realizing under these circumstances.

One of my main problems is getting the right window/dialog/pane to the front
and keeping it there while the user clicks on other widgets on that or other
windows in the application. I know it should just be a problem of getting
the parent right and a few other rules but it somehow seems much harder than
that. How about a white paper ?

Hmmmm. I think PtWidgetChildFront() should work if they are all
brothers.

Mitchell Schoenbrun --------- maschoen@pobox.com

Well, an unrealize/realize cycle should not change the state. The only
problem I’ve had is with a container widget. If widgets within a
container widget are unrealized and you cycle the container, all
widgets become realized. There is a widget bit you can set to
prevent a specific widget from realizing under these circumstances.

I didn’t “realize” that!

My problem was probably the use of the realize callback to initialise the
widget and hence destroy any memory of its state.

Steve

Stephen F Terrell <stephen@trsystem.demon.co.uk> wrote:
:> Well, an unrealize/realize cycle should not change the state. The only
:> problem I’ve had is with a container widget. If widgets within a
:> container widget are unrealized and you cycle the container, all
:> widgets become realized. There is a widget bit you can set to
:> prevent a specific widget from realizing under these circumstances.
:>
: I didn’t “realize” that!

: My problem was probably the use of the realize callback to initialise the
: widget and hence destroy any memory of its state.

Here’s another way to deal with your panes that avoids unrealizing and
realizing them: position the unwanted panes at some large negative
coordinates. They still exist; they’re just not displayed.


Steve Reid stever@qnx.com
TechPubs (Technical Publications)
QNX Software Systems

Here’s another way to deal with your panes that avoids unrealizing and
realizing them: position the unwanted panes at some large negative
coordinates. They still exist; they’re just not displayed.


Steve Reid > stever@qnx.com
TechPubs (Technical Publications)
QNX Software Systems

I like that one, thanks
Steve