Hi all,
I wonder whether we should turn off drop shadows during grabbing a morph?
[cid:2b0e9a8e-fc25-455b-9db5-3187ed1fe59f]
And it looks even more strange when grabbing menu items (citing from Squeak by Example):
[cid:258a12de-bd97-46fe-ac1d-7471c6e04160]
This is related to the #menuAppearance3d preference, but I never met a physics system were shadows can throw their own shadows 🤔
Best, Christoph
Hi Christoph.
I wonder whether we should turn off drop shadows during grabbing a morph?
We already do at some places. See (some) senders of #hasDropShadow:. Still, it feels like a workaround and does not yet apply to the hand's caching procedure. See HandMorph >> #updateCacheCanvas:.
Best, Marcel Am 19.09.2020 21:04:28 schrieb Thiede, Christoph christoph.thiede@student.hpi.uni-potsdam.de: Hi all,
I wonder whether we should turn off drop shadows during grabbing a morph?
And it looks even more strange when grabbing menu items (citing from Squeak by Example):
This is related to the #menuAppearance3d preference, but I never met a physics system were shadows can throw their own shadows 🤔
Best, Christoph
On 2020-11-09, at 12:01 AM, Marcel Taeumel marcel.taeumel@hpi.de wrote:
Hi Christoph.
I wonder whether we should turn off drop shadows during grabbing a morph?
Honestly, I'd vote for dumping drop shadows entirely. It's an old, tired, neo-skeuomorphic approach that lingers on from the old days of pretending that some sort of photorealistic model of a messy desk would magically make everyone's lives organised.
It's dead Jim. Let's not render the corpse in 4k quality.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim The next generation of computers will have a "Warranty Expired" interrupt.
On 9. Nov 2020, at 18:44, tim Rowledge tim@rowledge.org wrote:
On 2020-11-09, at 12:01 AM, Marcel Taeumel marcel.taeumel@hpi.de wrote:
Hi Christoph.
I wonder whether we should turn off drop shadows during grabbing a morph?
Honestly, I'd vote for dumping drop shadows entirely. It's an old, tired, neo-skeuomorphic approach that lingers on from the old days of pretending that some sort of photorealistic model of a messy desk would magically make everyone's lives organised.
It's dead Jim. Let's not render the corpse in 4k quality.
In macOS, no windows have borders. Without drop shadows there's no way to discern them. The shadow is now the border. -t
On 2020-11-09, at 10:25 AM, Tobias Pape Das.Linux@gmx.de wrote:
In macOS, no windows have borders. Without drop shadows there's no way to discern them. The shadow is now the border.
Hmm, not seeing this on my current iMac setup. I don't have the very latest Mac OS installed (I'm still on Mojave), so maybe this is a recent change?
Either way, just because Apple does something that doesn't mean I agree with it. But they stopped listening to me a long time ago.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful Latin Phrases:- Fac ut vivas. = Get a life.
On 9. Nov 2020, at 19:52, tim Rowledge tim@rowledge.org wrote:
On 2020-11-09, at 10:25 AM, Tobias Pape Das.Linux@gmx.de wrote:
In macOS, no windows have borders. Without drop shadows there's no way to discern them. The shadow is now the border.
Hmm, not seeing this on my current iMac setup. I don't have the very latest Mac OS installed (I'm still on Mojave), so maybe this is a recent change?
Either way, just because Apple does something that doesn't mean I agree with it. But they stopped listening to me a long time ago.
One used to be able to disable drop shadows on macOS < 10.12 with kCGSDebugOptionNoShadows
If this was enabled, one could see that there are, in fact, no borders. The shadows beget the borders.
However that does no longer work with SIP enabled.
The neat thing is you no longer have to deal with borders if you do it that way and you get aaaall the screen real estate for full-size/full-screen windows without any extra handling (as there are naturally no shadows for windows that touch the border of the screen).
The less fun thing is when shadows bleed into other screens in multi-screen setups.
there we are. Where we go? -t
I'm evidently getting confused here. On my Mojave iMac I certainly see the fairly small and faint shadows (plus the slightly heavier one fro man active window) but there are also most definite visual borders on all the windows - thin, probably single pixel, but definitely there, all the way around the window.
Are you saying that the handling of the window resizing drag-handle things is tied to the shadow visual? That looks like it might be the case. I suppose that there is an argument for some visual clue for the active window (if indeed you have that concept, which not all GUIs do) but I'd choose something other than a faint shadow.
Where do we go? Dunno. I've made my suggestion that the way to simplify drop shadows in Squeak is simply not to have them. Nobody is forced to agree with me, at least, not before my Total Mind Control Satellite is launched.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim "E=Mc^5...nahhh...E=Mc^4...nahh...E=Mc^3...ah, the hell with it."
On 9. Nov 2020, at 20:12, tim Rowledge tim@rowledge.org wrote:
I'm evidently getting confused here. On my Mojave iMac I certainly see the fairly small and faint shadows (plus the slightly heavier one fro man active window) but there are also most definite visual borders on all the windows - thin, probably single pixel, but definitely there, all the way around the window.
Hmm, then the debug-shadow-be-gone maybe also kill the single pixle border? maybe…
Are you saying that the handling of the window resizing drag-handle things is tied to the shadow visual?
no, to the cutoff and a a tiny area around it.
That looks like it might be the case. I suppose that there is an argument for some visual clue for the active window (if indeed you have that concept, which not all GUIs do) but I'd choose something other than a faint shadow.
Where do we go? Dunno. I've made my suggestion that the way to simplify drop shadows in Squeak is simply not to have them. Nobody is forced to agree with me, at least, not before my Total Mind Control Satellite is launched.
Lol. yeah, it was merely a statement of undecidedness on my part…
Best regards -tobias
Hi Marcel!
Would this be a too simple fix for the issue?
In Morph >> #fullDrawOn:
...
"Pass 1: Draw eventual drop-shadow" - self hasDropShadow + (self hasDropShadow and: [(self ownerSatisfying: #isHandMorph) isNil]) + ifTrue: [self drawDropShadowOn: aCanvas].
....
Best, Christoph
________________________________ Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Taeumel, Marcel Gesendet: Montag, 9. November 2020 09:01:58 An: squeak-dev Betreff: Re: [squeak-dev] Drop shadows during grabbing
Hi Christoph.
I wonder whether we should turn off drop shadows during grabbing a morph?
We already do at some places. See (some) senders of #hasDropShadow:. Still, it feels like a workaround and does not yet apply to the hand's caching procedure. See HandMorph >> #updateCacheCanvas:.
Best, Marcel
Am 19.09.2020 21:04:28 schrieb Thiede, Christoph christoph.thiede@student.hpi.uni-potsdam.de:
Hi all,
I wonder whether we should turn off drop shadows during grabbing a morph?
[cid:2b0e9a8e-fc25-455b-9db5-3187ed1fe59f]
And it looks even more strange when grabbing menu items (citing from Squeak by Example):
[cid:258a12de-bd97-46fe-ac1d-7471c6e04160]
This is related to the #menuAppearance3d preference, but I never met a physics system were shadows can throw their own shadows 🤔
Best, Christoph
Hi Christoph.
Would this be a too simple fix for the issue?
I would not want to do that for every morph. That's the wrong place to fix it. Just take a look at HandMorph and fix the creation of that cached picture.
Best, Marcel Am 16.11.2020 16:41:16 schrieb Thiede, Christoph christoph.thiede@student.hpi.uni-potsdam.de: Hi Marcel!
Would this be a too simple fix for the issue?
In Morph >> #fullDrawOn: Â Â Â ... Â "Pass 1: Draw eventual drop-shadow" -Â Â Â self hasDropShadow + (self hasDropShadow and: [(self ownerSatisfying: #isHandMorph) isNil]) + ifTrue: [self drawDropShadowOn: aCanvas].
....
Best, Christoph Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Taeumel, Marcel Gesendet: Montag, 9. November 2020 09:01:58 An: squeak-dev Betreff: Re: [squeak-dev] Drop shadows during grabbing  Hi Christoph.
I wonder whether we should turn off drop shadows during grabbing a morph?
We already do at some places. See (some) senders of #hasDropShadow:. Still, it feels like a workaround and does not yet apply to the hand's caching procedure. See HandMorph >> #updateCacheCanvas:.
Best, Marcel Am 19.09.2020 21:04:28 schrieb Thiede, Christoph christoph.thiede@student.hpi.uni-potsdam.de: Hi all,
I wonder whether we should turn off drop shadows during grabbing a morph?
And it looks even more strange when grabbing menu items (citing from Squeak by Example):
This is related to the #menuAppearance3d preference, but I never met a physics system were shadows can throw their own shadows 🤔
Best, Christoph
squeak-dev@lists.squeakfoundation.org