The blend level of a stack...

Got a LiveCode personal license? Are you a beginner, hobbyist or educator that's new to LiveCode? This forum is the place to go for help getting started. Welcome!

Moderators: Klaus, FourthWorld, heatherlaine, kevinmiller

bogs
Posts: 3710
Joined: Sat Feb 25, 2017 10:45 pm

Re: The blend level of a stack...

Post by bogs » Mon Aug 05, 2019 9:35 pm

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!
Image

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 :roll:
Image

[-hh]
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 2091
Joined: Thu Feb 28, 2013 11:52 pm
Location: Göttingen, DE

Re: The blend level of a stack...

Post by [-hh] » Mon Aug 05, 2019 11:42 pm

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.
shiftLock happens

SparkOut
Posts: 2015
Joined: Sun Sep 23, 2007 4:58 pm

Re: The blend level of a stack...

Post by SparkOut » Tue Aug 06, 2019 8:12 am

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
Posts: 3710
Joined: Sat Feb 25, 2017 10:45 pm

Re: The blend level of a stack...

Post by bogs » Tue Aug 06, 2019 11:23 am

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...
bogs wrote:
Mon Aug 05, 2019 9:35 pm
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?
stackWindowShapeAndText.png
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.
[-hh] wrote:
Mon Aug 05, 2019 11:42 pm
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.
Image

[-hh]
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 2091
Joined: Thu Feb 28, 2013 11:52 pm
Location: Göttingen, DE

Re: The blend level of a stack...

Post by [-hh] » Tue Aug 06, 2019 12:46 pm

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.
shiftLock happens

bogs
Posts: 3710
Joined: Sat Feb 25, 2017 10:45 pm

Re: The blend level of a stack...

Post by bogs » Tue Aug 06, 2019 9:10 pm

@ 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
Image

bogs
Posts: 3710
Joined: Sat Feb 25, 2017 10:45 pm

Re: The blend level of a stack...

Post by bogs » Thu Aug 08, 2019 12:09 pm

FourthWorld wrote:
Thu Aug 01, 2019 11:52 pm
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 :cry:
Image

bogs
Posts: 3710
Joined: Sat Feb 25, 2017 10:45 pm

Re: The blend level of a stack...

Post by bogs » Thu Aug 08, 2019 4:55 pm

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 :?

Image
Image

Post Reply

Return to “Getting Started with LiveCode - Complete Beginners”