Smalltalk › Squeak › Squeak - Dev

Drop shadows during grabbing

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

10 messages Options

Christoph Thiede

Drop shadows during grabbing

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

Carpe Squeak!

marcel.taeumel

Re: 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 <[hidden email]>:

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

timrowledge

Re: Drop shadows during grabbing

> On 2020-11-09, at 12:01 AM, Marcel Taeumel <[hidden email]> 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; [hidden email]; http://www.rowledge.org/tim
The next generation of computers will have a "Warranty Expired" interrupt.

Tobias Pape

Re: Drop shadows during grabbing

> On 9. Nov 2020, at 18:44, tim Rowledge <[hidden email]> wrote:
>
>
>
>> On 2020-11-09, at 12:01 AM, Marcel Taeumel <[hidden email]> 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

timrowledge

Re: Drop shadows during grabbing

> On 2020-11-09, at 10:25 AM, Tobias Pape <[hidden email]> 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; [hidden email]; http://www.rowledge.org/tim
Useful Latin Phrases:- Fac ut vivas. = Get a life.

Tobias Pape

Re: Drop shadows during grabbing

> On 9. Nov 2020, at 19:52, tim Rowledge <[hidden email]> wrote:
>
>
>
>> On 2020-11-09, at 10:25 AM, Tobias Pape <[hidden email]> 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

timrowledge

Re: Drop shadows during grabbing

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; [hidden email]; http://www.rowledge.org/tim
"E=Mc^5...nahhh...E=Mc^4...nahh...E=Mc^3...ah, the hell with it."

Tobias Pape

Re: Drop shadows during grabbing

> On 9. Nov 2020, at 20:12, tim Rowledge <[hidden email]> 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

Christoph Thiede

Re: Drop shadows during grabbing

In reply to this post by marcel.taeumel

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 <[hidden email]> 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 <[hidden email]>:

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

Carpe Squeak!

marcel.taeumel

Re: Drop shadows during grabbing

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 <[hidden email]>:

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 <[hidden email]> 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 <[hidden email]>:

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