Smalltalk › Squeak › Squeak - Dev

[Please Review] Some updates for resize grips

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

9 messages Options

marcel.taeumel

[Please Review] Some updates for resize grips

Hi, there.

Please find attached a change set that basically changes AbstractResizerMorph and its subclasses. I pursued the following two goals:

1. Fix a bug with occlusion culling in windows that occured due to misplaced corner grips. (See SystemWindowTests).

2. Make all resize grips compatible with UserInterfaceTheme.

Please try it out, review the code, and tell me any issues about that update. I plan to put it into trunk in a few days.

Best,

Marcel

grip-fix.2.cs (39K) Download Attachment

Karl Ramberg

Re: [Please Review] Some updates for resize grips

I had to turn off Deprecation warnings for this to load

Log attached

Cheers,

Karl

On Fri, Jan 4, 2019 at 12:44 PM Marcel Taeumel <[hidden email]> wrote:

Hi, there.

Please find attached a change set that basically changes AbstractResizerMorph and its subclasses. I pursued the following two goals:

1. Fix a bug with occlusion culling in windows that occured due to misplaced corner grips. (See SystemWindowTests).
2. Make all resize grips compatible with UserInterfaceTheme.

Please try it out, review the code, and tell me any issues about that update. I plan to put it into trunk in a few days.

Best,
Marcel

SqueakDebug.log (20K) Download Attachment

Chris Muller-3

Re: [Please Review] Some updates for resize grips

In reply to this post by marcel.taeumel

Hi Marcel,

As we derive colors from other colors, it seems like the "Dark" themes will generally be consistently the inverse of the normal daytime themes. Like, in this example, AbstractResizerMorph>>#handleColor defaults to "muchDarker". I see you allowed themes to specify a resizerColorModifier, that's a cool customization, but do you think there is a commonality among themes under 50% luminance which would have them generally wanting to go with #muchLighter all around? Currently they all have to duplicated in each dark theme, for each attribute.

What if, alternatively, a testing method in UserInterfaceTheme (#isDark or whatever) could allow these places to derive one way or the other (darker or lighter) depending on that boolean attribute, since this needing to go either darker or lighter seems like a recurring theme (sorry for the pun! :) ).

Another option may be to have instead of resizerColorModifier, simply a #colorModifier in general. That would at least require only one per theme, instead of one per theme per widget. Interested in your thoughts.

Best,

Chris

On Fri, Jan 4, 2019 at 5:44 AM Marcel Taeumel <[hidden email]> wrote:

Hi, there.

Please find attached a change set that basically changes AbstractResizerMorph and its subclasses. I pursued the following two goals:

1. Fix a bug with occlusion culling in windows that occured due to misplaced corner grips. (See SystemWindowTests).
2. Make all resize grips compatible with UserInterfaceTheme.

Please try it out, review the code, and tell me any issues about that update. I plan to put it into trunk in a few days.

Best,
Marcel

timrowledge

Theme colours (was Re: [Please Review] Some updates for resize grips)

> On 2019-01-04, at 2:39 PM, Chris Muller <[hidden email]> wrote:
>
> Hi Marcel,
>
> As we derive colors from other colors, it seems like the "Dark" themes will generally be consistently the inverse of the normal daytime themes. Like, in this example, AbstractResizerMorph>>#handleColor defaults to "muchDarker".

For themes where there is a need for darker or lighter depending on the intent of the theme, rather than being specific in a confusing manner - ie actually using #darker etc - might it help to refer to something on a different axis? For example #stronger & #softer could be used in a bright or a dark theme to refer to the progression of colour without any reliance on the specific theme needs. Sort of an abstraction of intent. Give a theme a collection of colours and set the middle as 'normal'. Or have an algorithm specific to the theme. Or both, depending on the nice new Chronology state :-)

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Useful Latin Phrases:- Romani quidem artem amatoriam invenerunt. = You know, the Romans invented the art of love.

marcel.taeumel

Re: Theme colours (was Re: [Please Review] Some updates for resize grips)

Hi Chris, hi Tim, hi all,

yes, it would be interesting to find such concepts (or properties?) that can positively affect the complexity of a theme's implementation. Here, "#isDark" might only be the first of several to discover. Also, the uses of such properties might also be manifold. For example, the inversion of color saturation (or brightness) could be a good start to think about it.

At the moment, I try to reduce code duplication within a single theme (class) through UserInterfaceTheme >> #derive:for:from:at:. Yet, it is often difficult to decide from which property to derive another property. For the resize grips, I just picked a window's border color as reference. Looks okay to me.

This "isDark" proposal addresses a higher-level reuse than what #derive: can provide right now. I like that. Still, I am not so sure whether the theme designer (person) could benefit from such a mechanism in the long term. There, I see more value in an interactive color-picker-like tool than in improving the implementation details of a UserInterfaceTheme subclass.

Finally, I want to point out that -- for the long term -- I want to look for a better way to manage theme instances and treat the class-level-initalization persistance thingy as one of maybe many (generated) serialization formats for themes. The current (manual) class serialization has been a good start so far. For us theme designers and as a good integration with ReleaseBuilder and Monticello (or code versioning).

Best,

Marcel

Am 05.01.2019 00:13:45 schrieb tim Rowledge <[hidden email]>:

> On 2019-01-04, at 2:39 PM, Chris Muller wrote:
>
> Hi Marcel,
>
> As we derive colors from other colors, it seems like the "Dark" themes will generally be consistently the inverse of the normal daytime themes. Like, in this example, AbstractResizerMorph>>#handleColor defaults to "muchDarker".

For themes where there is a need for darker or lighter depending on the intent of the theme, rather than being specific in a confusing manner - ie actually using #darker etc - might it help to refer to something on a different axis? For example #stronger & #softer could be used in a bright or a dark theme to refer to the progression of colour without any reliance on the specific theme needs. Sort of an abstraction of intent. Give a theme a collection of colours and set the middle as 'normal'. Or have an algorithm specific to the theme. Or both, depending on the nice new Chronology state :-)

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Useful Latin Phrases:- Romani quidem artem amatoriam invenerunt. = You know, the Romans invented the art of love.

marcel.taeumel

Re: [Please Review] Some updates for resize grips

In reply to this post by Karl Ramberg

Hi Karl.

I am trying to reproduce the behavior you observed in your image. I cannot. :-( Could you provide more details? I suspected the following preferences, which did not seem to do the trick:

[x] Force transcript updates to screen

[x] Show deprecation warnings

[x] Draw Corner Resize Handles

I have an open transcript, too. And a File List tool as I figured from your stack that you did use that to file-in the change set.

Best,

Marcel

Am 04.01.2019 15:57:52 schrieb karl ramberg <[hidden email]>:

I had to turn off Deprecation warnings for this to load
Log attached

Cheers,
Karl

On Fri, Jan 4, 2019 at 12:44 PM Marcel Taeumel <[hidden email]> wrote:
Hi, there.

Please find attached a change set that basically changes AbstractResizerMorph and its subclasses. I pursued the following two goals:

1. Fix a bug with occlusion culling in windows that occured due to misplaced corner grips. (See SystemWindowTests).
2. Make all resize grips compatible with UserInterfaceTheme.

Please try it out, review the code, and tell me any issues about that update. I plan to put it into trunk in a few days.

Best,
Marcel

Torge Husfeldt

Re: Theme colours (was Re: [Please Review] Some updates for resize grips)

In reply to this post by timrowledge

Hi,

On 05.01.19 00:13, tim Rowledge wrote:
>
>> On 2019-01-04, at 2:39 PM, Chris Muller <[hidden email]> wrote:
>>
>> Hi Marcel,
>>
>> As we derive colors from other colors, it seems like the "Dark" themes will generally be consistently the inverse of the normal daytime themes. Like, in this example, AbstractResizerMorph>>#handleColor defaults to "muchDarker".
> For themes where there is a need for darker or lighter depending on the intent of the theme, rather than being specific in a confusing manner - ie actually using #darker etc - might it help to refer to something on a different axis? For example #stronger & #softer could be used in a bright or a dark theme to refer to the progression of colour without any reliance on the specific theme needs. Sort of an abstraction of intent. Give a theme a collection of colours and set the middle as 'normal'. Or have an algorithm specific to the theme. Or both, depending on the nice new Chronology state :-)

Nice thought, but probably the color could not determine the "intent" on
its own, right?
So the solution would be probably along the lines of
Color>>stronger: aTheme
^aTheme isDark ifTrue:[self darker ] ifFlase:[self lighter]

So you still need to be able to ask the Theme about its darkness.
>
> tim
> --
> tim Rowledge; [hidden email]; http://www.rowledge.org/tim
> Useful Latin Phrases:- Romani quidem artem amatoriam invenerunt. = You know, the Romans invented the art of love.
>
>
>
Just my 2 cents
Torge

marcel.taeumel

Re: Theme colours (was Re: [Please Review] Some updates for resize grips)

Hi, there.

I would place #stronger: into the UserInterfaceTheme since the color cannot know about #isDark or similar theme abstractions. Maybe we could add "sunlight variations" to the discussion. :-)

Best,

Marcel

Am 07.01.2019 16:25:24 schrieb Torge Husfeldt <[hidden email]>:
Hi,

On 05.01.19 00:13, tim Rowledge wrote:
>
>> On 2019-01-04, at 2:39 PM, Chris Muller wrote:
>>
>> Hi Marcel,
>>
>> As we derive colors from other colors, it seems like the "Dark" themes will generally be consistently the inverse of the normal daytime themes. Like, in this example, AbstractResizerMorph>>#handleColor defaults to "muchDarker".
> For themes where there is a need for darker or lighter depending on the intent of the theme, rather than being specific in a confusing manner - ie actually using #darker etc - might it help to refer to something on a different axis? For example #stronger & #softer could be used in a bright or a dark theme to refer to the progression of colour without any reliance on the specific theme needs. Sort of an abstraction of intent. Give a theme a collection of colours and set the middle as 'normal'. Or have an algorithm specific to the theme. Or both, depending on the nice new Chronology state :-)

Nice thought, but probably the color could not determine the "intent" on
its own, right?
So the solution would be probably along the lines of
Color>>stronger: aTheme
^aTheme isDark ifTrue:[self darker ] ifFlase:[self lighter]

So you still need to be able to ask the Theme about its darkness.
>
> tim
> --
> tim Rowledge; [hidden email]; http://www.rowledge.org/tim
> Useful Latin Phrases:- Romani quidem artem amatoriam invenerunt. = You know, the Romans invented the art of love.
>
>
>
Just my 2 cents
Torge

timrowledge

Re: Theme colours (was Re: [Please Review] Some updates for resize grips)

> On 2019-01-07, at 7:28 AM, Marcel Taeumel <[hidden email]> wrote:
>
> Hi, there.
>
> I would place #stronger: into the UserInterfaceTheme since the color cannot know about #isDark or similar theme abstractions.

Exactly. We may need some subclasses of Theme to do all the things people want, but hey, that's what Smalltalk is all about, right?
An algorithmic theme would derive related colours by some rule; could be as simple as having a #strongerSelector and #gentlerSelector to send to the currently important colour. Could be a block? Could derive colours from time-of-day to gently move from daylight style to night style.
A listing theme might have a list of colours and #stronger goes up the list, #gentler goes down.
A random theme might cause fits in flash sensitive people. Let's avoid that.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Useful random insult:- Moves his lips to pretend he's reading.