The blend level of a stack...
Moderators: FourthWorld, heatherlaine, Klaus, kevinmiller
Re: The blend level of a stack...
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
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
-
- VIP Livecode Opensource Backer
- Posts: 2262
- Joined: Thu Feb 28, 2013 11:52 pm
- Location: Göttingen, DE
Re: The blend level of a stack...
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.
So what you demo with your stack on linux is at the very end a feature request for the other platforms.
shiftLock happens
Re: The blend level of a stack...
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
But I dare say this is not very high on the list of priorities in Edinburgh
Re: The blend level of a stack...
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...
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.
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.
1.) The top 2 images I changed nothing but the window shape, the image is the same image for both.bogs wrote: ↑Mon Aug 05, 2019 9:35 pmOne 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?
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.
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.
-
- VIP Livecode Opensource Backer
- Posts: 2262
- Joined: Thu Feb 28, 2013 11:52 pm
- Location: Göttingen, DE
Re: The blend level of a stack...
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.
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
Re: The blend level of a stack...
@ 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.
*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
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.
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.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
*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
Re: The blend level of a stack...
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.FourthWorld wrote: ↑Thu Aug 01, 2019 11:52 pmThe window is recreated from OS routines when decorations are toggled, hence the reinitialization.
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
Re: The blend level of a stack...
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