Smalltalk › Squeak › Squeak - Dev

The Trunk: Morphic-kfr.958.mcz

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

18 messages Options

commits-2

The Trunk: Morphic-kfr.958.mcz

Karl Ramberg uploaded a new version of Morphic to project The Trunk:
http://source.squeak.org/trunk/Morphic-kfr.958.mcz

==================== Summary ====================

Name: Morphic-kfr.958
Author: kfr
Time: 2 May 2015, 7:18:54.572 pm
UUID: 8235819e-0435-b142-aa1b-7676dd49a995
Ancestors: Morphic-mt.957

Couple of layout and color fixes to NewColorPickerMorph

=============== Diff against Morphic-mt.957 ===============

Item was changed:
----- Method: NewColorPickerMorph>>newCloseButton (in category 'initialize-release') -----
newCloseButton
^ (PluggableButtonMorph
on: self
getState: nil
action: #delete
label: #closeButtonLabel)
vResizing: #spaceFill ;
+ hResizing: #spaceFill;
yourself!

Item was changed:
----- Method: NewColorPickerMorph>>setup (in category 'initialize-release') -----
setup
self
+ color: (Color white darker) ;
- color: (Color white slightlyDarker alpha: 0.88) ;
cornerStyle: #rounded ;
changeTableLayout ;
+ hResizing: #shrinkWrap ;
+ vResizing: #shrinkWrap ;
- hResizing: #rigid ;
- vResizing: #rigid ;
extent: 240@240 ;
addMorphBack: hsvaMorph ;
addMorphBack: self newColorExpressionMorph ;
addMorphBack: self newBottomRow ;
layoutInset: 4 ;
cellInset: 2.

+ !
- Preferences menuAppearance3d
- ifTrue: [self addDropShadow].!

marcel.taeumel (old)

Re: The Trunk: Morphic-kfr.958.mcz

Why did you remove the shadow? ;( ... ;)

Best,
Marcel

Karl Ramberg

Re: The Trunk: Morphic-kfr.958.mcz

Ah, that was a slip.

New change uploaded

Karl

On Sat, May 2, 2015 at 8:08 PM, Marcel Taeumel <[hidden email]> wrote:

Why did you remove the shadow? ;( ... ;)

Best,
Marcel

--
View this message in context: http://forum.world.st/The-Trunk-Morphic-kfr-958-mcz-tp4823778p4823795.html
Sent from the Squeak - Dev mailing list archive at Nabble.com.

Karl Ramberg

Re: The Trunk: Morphic-kfr.958.mcz

I noticed that NewColorPickerMorph is hard coded to use rounded corners.

And that the menu preference is not a pragma preference.

But one issue with pragma preferences is a big influx of new preferences scattered all over.

Should we have a like a WidgetMorph hierarchy that we can use for all the stuff that should look similar and use the same preferences ??

Karl

On Sat, May 2, 2015 at 10:06 PM, karl ramberg <[hidden email]> wrote:

Ah, that was a slip.
New change uploaded

Karl

On Sat, May 2, 2015 at 8:08 PM, Marcel Taeumel <[hidden email]> wrote:
Why did you remove the shadow? ;( ... ;)

Best,
Marcel

--
View this message in context: http://forum.world.st/The-Trunk-Morphic-kfr-958-mcz-tp4823778p4823795.html
Sent from the Squeak - Dev mailing list archive at Nabble.com.

marcel.taeumel (old)

Re: The Trunk: Morphic-kfr.958.mcz

Scattering is not a big deal here. Senders of those pragmas will find them all.

However, It is quite impeding to attach those pragma preferences -- is most cases -- to Morph classes. MVC tools don't get configurable at all... :-/

We should move those preferences to the class-side of ToolBuilder's spec classes. In the concrete builder classes, we could store project-specific migration code for preference changes.

Best,
Marcel

marcel.taeumel (old)

Re: The Trunk: Morphic-kfr.958.mcz

...but if we want to let Morphs access those preferences, we probably still need such a class-side abstraction in Morphs. Otherwise Morphic would be dependent on Tools, which should not be.

Such preference access happens in Morphs in many places right now. Even outside initialization code, which is not good because a single morph cannot behave differently to the system's preferences easily.

Best,
Marcel

Karl Ramberg

Re: The Trunk: Morphic-kfr.958.mcz

It's also hard for a user to find all preferences if every tiny widget have one.

Karl

On Sun, May 3, 2015 at 8:48 AM, Marcel Taeumel <[hidden email]> wrote:

...but if we want to let Morphs access those preferences, we probably still
need such a class-side abstraction in Morphs. Otherwise Morphic would be
dependent on Tools, which should not be.

Such preference access happens in Morphs in many places right now. Even
outside initialization code, which is not good because a single morph cannot
behave differently to the system's preferences easily.

Best,
Marcel

--
View this message in context: http://forum.world.st/The-Trunk-Morphic-kfr-958-mcz-tp4823778p4823904.html

Sent from the Squeak - Dev mailing list archive at Nabble.com.

marcel.taeumel (old)

Re: The Trunk: Morphic-kfr.958.mcz

Why? No "user" should have to scan classes. The Preferences Browser is for that. It integrates all scattered preferences. And it supports search as well as browsing the acutal senders.

It's a good thing that each new package/class can bring new preferences with it.

Best,
Marcel

Hannes Hirzel

Re: The Trunk: Morphic-kfr.958.mcz

Very interesting discussion. Is it possible to summarize the outcome
and post it at a more prominent place? In a separate thread, the wiki
or in a class comment?

HH

On 5/3/15, Marcel Taeumel <[hidden email]> wrote:

> Why? No "user" should have to scan classes. The Preferences Browser is for
> that. It integrates all scattered preferences. And it supports search as
> well as browsing the acutal senders.
>
> It's a good thing that each new package/class can bring new preferences
> with
> it.
>
> Best,
> Marcel
>
>
>
> --
> View this message in context:
> http://forum.world.st/The-Trunk-Morphic-kfr-958-mcz-tp4823778p4823948.html
> Sent from the Squeak - Dev mailing list archive at Nabble.com.
>
>

Karl Ramberg

Re: The Trunk: Morphic-kfr.958.mcz

In reply to this post by marcel.taeumel (old)

I mean this more like: when we have separate preferences for every widget it will be hard,confusing and tedious to hunt down every setting for color and corner rounding etc. to change the look of the system.
Even if the PreferenceBrowser access them all, it will become overwhelming with several hundred preferences

On Sun, May 3, 2015 at 11:56 AM, Marcel Taeumel <[hidden email]> wrote:

Why? No "user" should have to scan classes. The Preferences Browser is for
that. It integrates all scattered preferences. And it supports search as
well as browsing the acutal senders.

It's a good thing that each new package/class can bring new preferences with
it.

Best,
Marcel

--
View this message in context: http://forum.world.st/The-Trunk-Morphic-kfr-958-mcz-tp4823778p4823948.html

Sent from the Squeak - Dev mailing list archive at Nabble.com.

Chris Muller-3

Re: The Trunk: Morphic-kfr.958.mcz

On Sun, May 3, 2015 at 6:50 AM, karl ramberg <[hidden email]> wrote:
> I mean this more like: when we have separate preferences for every widget it
> will be hard,confusing and tedious to hunt down every setting for color and
> corner rounding etc. to change the look of the system.
> Even if the PreferenceBrowser access them all, it will become overwhelming
> with several hundred preferences

It might help to understand what you want to do. You mentioned
hunting down every setting for color, etc., so what about that
DictionaryOfPreferences, isn't that it? Isn't that the place where
every pref in the system is collected up together?

Karl Ramberg

Re: The Trunk: Morphic-kfr.958.mcz

Hi,

I guess I am more questioning the sheer number of preferences. There are around 300 preferences in the system now.

Many of them I think can be deprecated.

Karl

On Mon, May 4, 2015 at 3:01 AM, Chris Muller <[hidden email]> wrote:

On Sun, May 3, 2015 at 6:50 AM, karl ramberg <[hidden email]> wrote:
> I mean this more like: when we have separate preferences for every widget it
> will be hard,confusing and tedious to hunt down every setting for color and
> corner rounding etc. to change the look of the system.
> Even if the PreferenceBrowser access them all, it will become overwhelming
> with several hundred preferences

It might help to understand what you want to do. You mentioned
hunting down every setting for color, etc., so what about that
DictionaryOfPreferences, isn't that it? Isn't that the place where
every pref in the system is collected up together?

Chris Muller-3

Re: The Trunk: Morphic-kfr.958.mcz

In reply to this post by Karl Ramberg

One thing I don't like about the scattered preferences is how the
preference API is no longer supported. I have a script which sets up
my preferred preferences, I tried to write:

Preferences disable: #showMessageIcons

just like I can for "normal" preferences, however, the above doesn't
work and doesn't report an error...

On Sun, May 3, 2015 at 6:50 AM, karl ramberg <[hidden email]> wrote:

> I mean this more like: when we have separate preferences for every widget it
> will be hard,confusing and tedious to hunt down every setting for color and
> corner rounding etc. to change the look of the system.
> Even if the PreferenceBrowser access them all, it will become overwhelming
> with several hundred preferences
>
> On Sun, May 3, 2015 at 11:56 AM, Marcel Taeumel
> <[hidden email]> wrote:
>>
>> Why? No "user" should have to scan classes. The Preferences Browser is for
>> that. It integrates all scattered preferences. And it supports search as
>> well as browsing the acutal senders.
>>
>> It's a good thing that each new package/class can bring new preferences
>> with
>> it.
>>
>> Best,
>> Marcel
>>
>>
>>
>> --
>> View this message in context:
>> http://forum.world.st/The-Trunk-Morphic-kfr-958-mcz-tp4823778p4823948.html
>> Sent from the Squeak - Dev mailing list archive at Nabble.com.
>>
>
>
>
>

Chris Muller-3

Re: The Trunk: Morphic-kfr.958.mcz

On Mon, May 4, 2015 at 4:18 PM, Chris Muller <[hidden email]> wrote:
> One thing I don't like about the scattered preferences is how the
> preference API is no longer supported. I have a script which sets up
> my preferred preferences, I tried to write:
>
> Preferences disable: #showMessageIcons
>
> just like I can for "normal" preferences, however, the above doesn't
> work and doesn't report an error...

In fact, it can even cause a duplicate preference to be added (see picture).

two-of-the-same-prefs.png (20K) Download Attachment

Karl Ramberg

Re: The Trunk: Morphic-kfr.958.mcz

That must be a bug.

Karl

On Mon, May 4, 2015 at 11:27 PM, Chris Muller <[hidden email]> wrote:

On Mon, May 4, 2015 at 4:18 PM, Chris Muller <[hidden email]> wrote:
> One thing I don't like about the scattered preferences is how the
> preference API is no longer supported. I have a script which sets up
> my preferred preferences, I tried to write:
>
> Preferences disable: #showMessageIcons
>
> just like I can for "normal" preferences, however, the above doesn't
> work and doesn't report an error...

In fact, it can even cause a duplicate preference to be added (see picture).

Karl Ramberg

Re: The Trunk: Morphic-kfr.958.mcz

So you must access with

Preferences disable: #'Browser>>showMessageIcons'

Otherwise a new preference is added :-(

Unrelated, in a ObjectExplorer you can't click to get a menu on all preferences because the ObjectExplorer show a abbreviated text: eg.

#'CodeHolder>>useMultiWindowBrowser' will show in the ObjectExplorer as #'CodeHolder>>u...indowBrowser'

Karl

On Tue, May 5, 2015 at 3:35 AM, karl ramberg <[hidden email]> wrote:

That must be a bug.

Karl

On Mon, May 4, 2015 at 11:27 PM, Chris Muller <[hidden email]> wrote:
On Mon, May 4, 2015 at 4:18 PM, Chris Muller <[hidden email]> wrote:
> One thing I don't like about the scattered preferences is how the
> preference API is no longer supported. I have a script which sets up
> my preferred preferences, I tried to write:
>
> Preferences disable: #showMessageIcons
>
> just like I can for "normal" preferences, however, the above doesn't
> work and doesn't report an error...

In fact, it can even cause a duplicate preference to be added (see picture).

marcel.taeumel (old)

Re: The Trunk: Morphic-kfr.958.mcz

In reply to this post by Chris Muller-3

We definitely need a fall-back. It should be no problem to find the PragmaPreference and configure it.

Let me take a look at that.

Best,
Marcel

Karl Ramberg

Re: The Trunk: Morphic-kfr.958.mcz

In reply to this post by Karl Ramberg

Preferences>>enable: and Preferences>>disable: considered harmful.

Both methods have side effects that are not desirable.

The naming scheme of PragmaPreferences and old Preferences do not match.

PragmaPreference key #'Browser>>showMessageIcons'

Preference key #alwaysHideHScrollbar

Both methods enable: and disable: automatically create a new preference in the dictionary if the key searched for is not found. This can easily lead to duplicate entries in the DictionaryOfPreferences.

Karl

On Tue, May 5, 2015 at 4:14 AM, karl ramberg <[hidden email]> wrote:

So you must access with
Preferences disable: #'Browser>>showMessageIcons'

Otherwise a new preference is added :-(

Unrelated, in a ObjectExplorer you can't click to get a menu on all preferences because the ObjectExplorer show a abbreviated text: eg.
#'CodeHolder>>useMultiWindowBrowser' will show in the ObjectExplorer as #'CodeHolder>>u...indowBrowser'

Karl

On Tue, May 5, 2015 at 3:35 AM, karl ramberg <[hidden email]> wrote:
That must be a bug.

Karl

On Mon, May 4, 2015 at 11:27 PM, Chris Muller <[hidden email]> wrote:
On Mon, May 4, 2015 at 4:18 PM, Chris Muller <[hidden email]> wrote:
> One thing I don't like about the scattered preferences is how the
> preference API is no longer supported. I have a script which sets up
> my preferred preferences, I tried to write:
>
> Preferences disable: #showMessageIcons
>
> just like I can for "normal" preferences, however, the above doesn't
> work and doesn't report an error...

In fact, it can even cause a duplicate preference to be added (see picture).