The blend level of a stack...

[bogs]

Yep, just as -hh said, it is a glitch that only works on 'nix, which is a very sad thing imho, as it works so well there

Having had a long hard think about everything else posted in here (and re-reading the entire thread 3 more times), I did finally break down and use an image on the main stack and set it to windowShape, while retaining the second stack as a blend in/out stack, which works well enough I suppose.

The effective rect indeed was what I needed as well, thanks again Hermann!


One thing I still don't understand is this, though. I didn't change the transparency of the image in Lc, I created the rounded rect picture in GIMP and set the trasparency of it in there. How come the field sitting on top of it is also semi-transparent? After all, it (shouldn't) be inheriting the images transparency, should it, like it would from the stack? But it sure seems to

[[-hh]]

The transparency of the stack window should, as Mark said on my bug report, be controlled by the opaque of the stack (and be inherited).
So what you demo with your stack on linux is at the very end a feature request for the other platforms.

[SparkOut]

Having a stack level opaque setting on all platforms that can have inheritance or individual inheritance blocking for child controls would be really cool. I once needed to have a feature like this to have a scrolling window of text across a user's desktop. Faking this with snapshotting the text changes and continually changing the windowshape was a disappointment and nowhere near fast enough.
But I dare say this is not very high on the list of priorities in Edinburgh

[bogs]

I thought, after how poorly I was expressing everything else in this thread, to work up a picture of what I meant for this comment...

One thing I still don't understand is this, though.1. I didn't change the transparency of the image in Lc, I created the rounded rect picture in GIMP and set the trasparency of it in there. How come the field sitting on top of it is also semi-transparent? After all, 2. it (shouldn't) be inheriting the images transparency, should it, like it would from the stack?

If a picture is worth 1000 words,...

1.) The top 2 images I changed nothing but the window shape, the image is the same image for both.
2.) The 3rd stack has the same image as a solid black, and is set to window shape.
3.) The terminal window in the picture works as I would expect opacity *should* work, pretty much as SparkOut says, with each element's opacity set individually.

The transparency of the stack window should, as Mark said on my bug report, be controlled by the opaque of the stack (and be inherited).

Yes, this is exactly how I was thinking it should be working, but instead, it appears the transparency of the stack is being controlled by the transparency of the image (which is correct), and is affecting every control placed on it down the line (which is not correct), so that while the blendlevel of the stack (which is what should be inherited by the objects) is '0', the objects are instead inheriting the base image's alpha setting.

This seems to be a bug paralleling the one in the report you made, but one which is reproducible on all 3 desktop OS'es, in all versions of Lc I was able to test it in.

Or I could just be WAY off, I spend so much time way off I forget how to get back.

[[-hh]]

Your "bug" is a consequence of combining objects with different alpha composition rules. This is very hard to handle.
But now, as you already made all the documentation work, you should report it.
This will be a valuable demo for the team whenever someone starts to implement the opacity of a stack.

[bogs]

@ Hermann,

I appended the additional blends (all under Structural Blends) that elicit the behavior you reported in bug id=19700, as well as linking a screenshot.

The following additional blends also produce this effect, the level is where you reach absolute transparency :
1. blendXor - level 0
2. blendDstAtop - level 100
3. blendDstOut - level 0
4. blendSrcOut - any level
5. blendDstIn - level 100
6. blendSrcIn - level 100
7. blendSrc - level 100
8. blendClear - any level

Here is a screen shot showing the last of these, blendClear, on a button.
https://i.imgur.com/h6hAW8l.png

I'm checking to see if there is any other reports I didn't know about concerning the windowShape issue, if I don't find one, should I append it to your report as well? Or just start another report? The two issues seem to be closely related.

*Edit 1 - I see our friend Richard filed another report of similar nature id=16782 ...

* Edit 2 - Never mind, I didn't see anything else specifically referring to this (as far as I could tell), so I submitted it as id=22301

[bogs]

The window is recreated from OS routines when decorations are toggled, hence the reinitialization.

I found out this morning doing retro-testing on the alpha bug that this was not always the case. In MetaCard 2.5, RunRev 2.2.1, and Revolution 3, changing the window shape does *not* move the window anywhere, it just applies wherever the window is.

I wonder why that changed, it sure seems to work better for workflow without having to move the window if your switching back and forth.

I also was able to determine the bug apparently started in or just before v3, it shows in Revolution 3 but not in RunRev 2.2.1. Sure wish I had copies of the IDE from inbetween those 2 versions

[bogs]

Well, after a lot of experimenting with the image used for the base shape, with a blendlevel of 0 on the stack, this was about the best I could come up with, lining the text up over the fully opaque parts of the image. Of course, it drifts right out if you go up with the blendlevel on the stack at all