ColorEditor updated

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
25 messages Options
12
Reply | Threaded
Open this post in threaded view
|

ColorEditor updated

KenDickey
Hi all,

I updated Morphic-ColorEditor for simpler layout and font preferences updating.

I also updated Morphic-Misc1 for font preferences update.

Dan, note that the Morphic-ColorEditor uses #when:send:to: for updates.  You can file it in and check senders.

Bugs to /dev/null, er, I mean to me.  ;^)

Cheers,
-KenD

_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
-KenD
Reply | Threaded
Open this post in threaded view
|

Re: ColorEditor updated

Dan Norton
On 29 Oct 2015 at 16:56, KenD wrote:

> Hi all,
>
> I updated Morphic-ColorEditor for simpler layout and font
> preferences updating.
>
> I also updated Morphic-Misc1 for font preferences update.
>
> Dan, note that the Morphic-ColorEditor uses #when:send:to: for
> updates.  You can file it in and check senders.
>

I've done that and I see that messages to SystemChangeNotifier are not required in order to use the method.

Also, the dependency mechanism itself uses #when:send:to:.

Any object can use  #when:send:to: because it is an Object instance method.

So, should this be named a different mechanism or is it just a different use of the dependency mechanism?

If it's a different mechanism, is "Signals" the right name? This by Marcel Taeumel:

           https://www.hpi.uni-potsdam.de/hirschfeld/trac/SqueakCommunityProjects/wiki/signals#FeatureComparison

 - Dan

_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
Reply | Threaded
Open this post in threaded view
|

Re: ColorEditor updated

KenDickey
On Sat, 31 Oct 2015 22:01:06 -0400
"Dan Norton" <[hidden email]> wrote:

> On 29 Oct 2015 at 16:56, KenD wrote:
..
> > Dan, note that the Morphic-ColorEditor uses #when:send:to: for
> > updates.  You can file it in and check senders.
..

> I've done that and I see that messages to SystemChangeNotifier are not required in order to  use the method.
>
> Also, the dependency mechanism itself uses #when:send:to:.
>
> Any object can use  #when:send:to: because it is an Object instance method.
>
> So, should this be named a different mechanism or is it just a different use of the
> dependency mechanism?
>
> If it's a different mechanism, is "Signals" the right name? This by Marcel Taeumel:
>
> https://www.hpi.uni-potsdam.de/hirschfeld/trac/SqueakCommunityProjects/wiki/signals#Featu
> reComparison

Hi Dan.

I took a look at the Signals implementation some time ago and my recollection is that I found the implementation to be complex and less useful than I had hoped.

For my limited uses, I prefer #when:send:to:

Simplicity wins.  In the longer term I hope somebody gets a chance to rewrite the older #changed: code to use the #when:send:to: mechanism so that we can remove #changed: .

I agree that having two update mechanisms is one too many.  Adding a third dependency update, Signals, would be going in the wrong direction IMHO.

$0.02
-KenD

_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
-KenD
Reply | Threaded
Open this post in threaded view
|

Re: ColorEditor updated

Dan Norton
Hi Ken,

Comments in line.

On 1 Nov 2015 at 20:52, KenD wrote:

> On Sat, 31 Oct 2015 22:01:06 -0400
> "Dan Norton" <[hidden email]> wrote:
>
> > On 29 Oct 2015 at 16:56, KenD wrote:
> ..
> > > Dan, note that the Morphic-ColorEditor uses #when:send:to: for
> > > updates.  You can file it in and check senders.
> ..
> > I've done that and I see that messages to SystemChangeNotifier are
> not required in order to  use the method.
> >
> > Also, the dependency mechanism itself uses #when:send:to:.
> >
> > Any object can use  #when:send:to: because it is an Object
> instance method.
> >
> > So, should this be named a different mechanism or is it just a
> different use of the
> > dependency mechanism?
> >
> > If it's a different mechanism, is "Signals" the right name? This
> by Marcel Taeumel:
> >      
> >
> https://www.hpi.uni-potsdam.de/hirschfeld/trac/SqueakCommunityProjec
> ts/wiki/signals#Featu
> > reComparison
>
> Hi Dan.
>
> I took a look at the Signals implementation some time ago and my
> recollection is that I found the implementation to be complex and
> less useful than I had hoped.
>
> For my limited uses, I prefer #when:send:to:
>
> Simplicity wins.

+1

  In the longer term I hope somebody gets a chance
> to rewrite the older #changed: code to use the #when:send:to:
> mechanism so that we can remove #changed: .
>
> I agree that having two update mechanisms is one too many.  Adding a
> third dependency update, Signals, would be going in the wrong
> direction IMHO.
>

That's fine. I was casting about for some name besides " #when:send:to: mechanism" for
use in a brief essay on PluggableListMorph Principles of Operation when I came across
Signals. I already wrote a paragraph on Dependency Mechanism.

So, the simple principle here is to just use #when:send:to: and forget about or maybe deprecate #changed: and #update:? The advantage IIUC is #when:send:to:
           can be sent by any object,
           the receiver can be any object,
           the to: parameter can be any object, and
           the send: parameter doesn't necessarily have to exist because WeakMessageSend is used!

What a deal :).

However, I see a problem common to dependency and #when:send:to: which is the identification and explanation of the various symbols which are communicated as the parameters for send: or changed: . When you're trying to design a model or view similar to something already in existence, the tools are not much help with that.

I'm thinking maybe: document in comments? <rant>Nah. We don't do comments.</rant>

Would appreciate any thoughts.

 - Dan

_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
Reply | Threaded
Open this post in threaded view
|

Re: ColorEditor updated

KenDickey
On Mon, 02 Nov 2015 15:58:26 -0500
"Dan Norton" <[hidden email]> wrote:

>.. I was casting about for some name besides " #when:send:to: mechanism" for
> use in a brief essay on PluggableListMorph Principles of Operation when I came across
> Signals. I already wrote a paragraph on Dependency Mechanism.

I would talk about #when:send:to: as implementing the Observer Pattern.

> So, the simple principle here is to just use #when:send:to: and forget about or maybe
> deprecate #changed: and #update:?

Yes.  Let us work to eliminate #changed: !

> However, I see a problem common to dependency and #when:send:to: which is the
> identification and explanation of the various symbols which are communicated as the
> parameters for send: or changed: . When you're trying to design a model or view similar to
> something already in existence, the tools are not much help with that.
>
> I'm thinking maybe: document in comments? <rant>Nah. We don't do comments.</rant>

We should certainly add clarifying comments!

Your Comment Browser is a big help here.  Once people start using it more, comments will appear.

I suggest sending Juan a code update with an added "Open Comment Browser" Help menu item which autoloads the same way as TerseGuide.


However, class comments are not usually where design patterns show up.  8^|

In the case of #when:send:to: I suggest a slightly larger discussion around building paned windows which update dependent panes.

What constitutes good style?  What code patterns help?

Think "Useful Code Patterns" to augment "Useful Expressions".

You can do your own example, but looking at the ColorEditor:

ColorEditor>>buildMorphicWindow
        "Create a useful ColorEditor window"
       
        self layoutMorph beRow; " A row of columns"
                 separation: 6;
                 addMorph: self buildColorPaneColumn;
                 addMorph: self buildSliderColumn;
                 addMorph: self buildRadioButtonColumn;
                 color: self backgroundColor.
               
        self model when: #colorChanged send: #refreshColor to: self.
       
        ^ self

So trying for good style (hey, I need to improve here too!) one uses:

[Class]>buildMorphicWindow
    [Add (construct each pane).. to layout]
    [Add self or panes as observers]
  ^ self

Suggest
  Smalltalk browseAllImplementorsOf: #buildMorphicWindow
to see specific usage examples.

Of course, we will suffer some embarrassment as our real code is less than ideal. 8^(

But this is a great motivator to making our code better!  ;^)


$0.02
-KenD

_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
-KenD
Reply | Threaded
Open this post in threaded view
|

Re: ColorEditor updated

Hannes Hirzel
On 11/3/15, KenD <[hidden email]> wrote:

> On Mon, 02 Nov 2015 15:58:26 -0500
> "Dan Norton" <[hidden email]> wrote:
>
>>.. I was casting about for some name besides " #when:send:to: mechanism"
>> for
>> use in a brief essay on PluggableListMorph Principles of Operation when I
>> came across
>> Signals. I already wrote a paragraph on Dependency Mechanism.
>
> I would talk about #when:send:to: as implementing the Observer Pattern.
>
>> So, the simple principle here is to just use #when:send:to: and forget
>> about or maybe
>> deprecate #changed: and #update:?
>
> Yes.  Let us work to eliminate #changed: !
>
>> However, I see a problem common to dependency and #when:send:to: which is
>> the
>> identification and explanation of the various symbols which are
>> communicated as the
>> parameters for send: or changed: . When you're trying to design a model or
>> view similar to
>> something already in existence, the tools are not much help with that.
>>
>> I'm thinking maybe: document in comments? <rant>Nah. We don't do
>> comments.</rant>
>
> We should certainly add clarifying comments!
>
> Your Comment Browser is a big help here.  Once people start using it more,
> comments will appear.
>
> I suggest sending Juan a code update with an added "Open Comment Browser"
> Help menu item which autoloads the same way as TerseGuide.
+1
>
> However, class comments are not usually where design patterns show up.  8^|
>
> In the case of #when:send:to: I suggest a slightly larger discussion around
> building paned windows which update dependent panes.
>
> What constitutes good style?  What code patterns help?
>
> Think "Useful Code Patterns" to augment "Useful Expressions".
+1

> You can do your own example, but looking at the ColorEditor:
>
> ColorEditor>>buildMorphicWindow
> "Create a useful ColorEditor window"
>
> self layoutMorph beRow; " A row of columns"
> separation: 6;
> addMorph: self buildColorPaneColumn;
> addMorph: self buildSliderColumn;
> addMorph: self buildRadioButtonColumn;
> color: self backgroundColor.
>
> self model when: #colorChanged send: #refreshColor to: self.
>
> ^ self
>
> So trying for good style (hey, I need to improve here too!) one uses:
>
> [Class]>buildMorphicWindow
>     [Add (construct each pane).. to layout]
>     [Add self or panes as observers]
>   ^ self
>
> Suggest
>   Smalltalk browseAllImplementorsOf: #buildMorphicWindow
> to see specific usage examples.
>
> Of course, we will suffer some embarrassment as our real code is less than
> ideal. 8^(
>
> But this is a great motivator to making our code better!  ;^)
>
>
> $0.02
> -KenD
>
> _______________________________________________
> Cuis mailing list
> [hidden email]
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>

_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
Reply | Threaded
Open this post in threaded view
|

Re: ColorEditor updated

Dan Norton
In reply to this post by KenDickey
Ran across this comment for ActiveModel and thought it was interesting, historically.

Part of update 5005u16-Events.cs:

"Change Set: Events
Date: 11 February 2002
Author: Rob Withers et al.

Published to 3.3a as 4756Events.cs

The NuBlue events code. Finally..."

The new event model, originally from VisualSmalltalk.
This includes #when:send:to: and friends, in Object (generic implementation) and
ActiveModel (optimized implementation).
It renders the old change/update mechanism in Object and Model as obsolete, although still
used.

 - Dan

On 2 Nov 2015 at 15:27, KenD wrote:

> On Mon, 02 Nov 2015 15:58:26 -0500
> "Dan Norton" <[hidden email]> wrote:
>
> >.. I was casting about for some name besides " #when:send:to:
> mechanism" for
> > use in a brief essay on PluggableListMorph Principles of Operation
> when I came across
> > Signals. I already wrote a paragraph on Dependency Mechanism.
>
> I would talk about #when:send:to: as implementing the Observer
> Pattern.
>
> > So, the simple principle here is to just use #when:send:to: and
> forget about or maybe
> > deprecate #changed: and #update:?
>
> Yes.  Let us work to eliminate #changed: !
>
> > However, I see a problem common to dependency and #when:send:to:
> which is the
> > identification and explanation of the various symbols which are
> communicated as the
> > parameters for send: or changed: . When you're trying to design a
> model or view similar to
> > something already in existence, the tools are not much help with
> that.
> >
> > I'm thinking maybe: document in comments? <rant>Nah. We don't do
> comments.</rant>
>
> We should certainly add clarifying comments!
>
> Your Comment Browser is a big help here.  Once people start using it
> more, comments will appear.
>
> I suggest sending Juan a code update with an added "Open Comment
> Browser" Help menu item which autoloads the same way as
> TerseGuide.
>
>
> However, class comments are not usually where design patterns show
> up.  8^|
>
> In the case of #when:send:to: I suggest a slightly larger discussion
> around building paned windows which update dependent panes.
>
> What constitutes good style?  What code patterns help?
>
> Think "Useful Code Patterns" to augment "Useful Expressions".
>
> You can do your own example, but looking at the ColorEditor:
>
> ColorEditor>>buildMorphicWindow
> "Create a useful ColorEditor window"
>
> self layoutMorph beRow; " A row of columns"
> separation: 6;
> addMorph: self buildColorPaneColumn;
> addMorph: self buildSliderColumn;
> addMorph: self buildRadioButtonColumn;
> color: self backgroundColor.
>
> self model when: #colorChanged send: #refreshColor to: self.
>
> ^ self
>
> So trying for good style (hey, I need to improve here too!) one
> uses:
>
> [Class]>buildMorphicWindow
>     [Add (construct each pane).. to layout]
>     [Add self or panes as observers]
>   ^ self
>
> Suggest
>   Smalltalk browseAllImplementorsOf: #buildMorphicWindow
> to see specific usage examples.
>
> Of course, we will suffer some embarrassment as our real code is
> less than ideal. 8^(
>
> But this is a great motivator to making our code better!  ;^)
>
>
> $0.02
> -KenD



_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
Reply | Threaded
Open this post in threaded view
|

Re: ColorEditor updated

Juan Vuletich-4
In reply to this post by Dan Norton
(inline)

On 11/2/2015 5:58 PM, Dan Norton wrote:
Hi Ken,

Comments in line.

On 1 Nov 2015 at 20:52, KenD wrote:

> On Sat, 31 Oct 2015 22:01:06 -0400
> "Dan Norton" [hidden email] wrote:
>
> > On 29 Oct 2015 at 16:56, KenD wrote:
> ..
> > > Dan, note that the Morphic-ColorEditor uses #when:send:to: for
> > > updates.  You can file it in and check senders.
> ..
> > I've done that and I see that messages to SystemChangeNotifier are
> not required in order to  use the method.
> >
> > Also, the dependency mechanism itself uses #when:send:to:.
> >
> > Any object can use  #when:send:to: because it is an Object
> instance method.
> >
> > So, should this be named a different mechanism or is it just a
> different use of the
> > dependency mechanism?
> >
> > If it's a different mechanism, is "Signals" the right name? This
> by Marcel Taeumel:
> >      
> >
> ts/wiki/signals#Featu
> > reComparison
>
> Hi Dan.
>
> I took a look at the Signals implementation some time ago and my
> recollection is that I found the implementation to be complex and
> less useful than I had hoped.
>
> For my limited uses, I prefer #when:send:to:
>
> Simplicity wins.

+1

  In the longer term I hope somebody gets a chance
> to rewrite the older #changed: code to use the #when:send:to:
> mechanism so that we can remove #changed: .
>
> I agree that having two update mechanisms is one too many.  Adding a
> third dependency update, Signals, would be going in the wrong
> direction IMHO.
>

That's fine. I was casting about for some name besides " #when:send:to: mechanism" for
use in a brief essay on PluggableListMorph Principles of Operation when I came across
Signals. I already wrote a paragraph on Dependency Mechanism.

So, the simple principle here is to just use #when:send:to: and forget about or maybe deprecate #changed: and #update:? The advantage IIUC is #when:send:to:
           can be sent by any object,
           the receiver can be any object,
           the to: parameter can be any object, and
           the send: parameter doesn't necessarily have to exist because WeakMessageSend is used!

What a deal :).

However, I see a problem common to dependency and #when:send:to: which is the identification and explanation of the various symbols which are communicated as the parameters for send: or changed: . When you're trying to design a model or view similar to something already in existence, the tools are not much help with that.


Well, doing senders on any symbol (method selectors, but also event names) shows all references to it. I don't think it is that bad, but, do you have ideas for improvements on this?

I'm thinking maybe: document in comments? <rant>Nah. We don't do comments.</rant>

Let me disagree. Cuis includes 204019 characters in class comments. That would be like 2000 to 4000 lines, right? For a system with less than 100kLOC. Top 10 classes with extensive class comments are: BitBlt SmartRefStream Float ClosureScanner Color ContentPack Monitor AndreasSystemProfiler EventSensor ReferenceStream. Just check them. Several of these are rather recent, some were written specifically for Cuis.

We also have  27058 bytes of comments at the top of methods. Some methods with great comments are #vmParameterAt: #entriesIn: #eliotsClosureMeasurements2On: #getCurrentWorkingDirectory #whatIsAPrimitive #asUtf8: #howToModifyPrimitives #applySimpleGamma:to: #linearTosRGBGamma: #localMicrosecondClock #findBinaryIndex:do:ifNone: #findBinary:do:ifNone: #spyAllOn: , etc.

There is a lot to be learnt about the system from reading comments. And we want to improve.

(BTW, querying the system to find this out took me less time than writing this email)

Would appreciate any thoughts.

 - Dan


I think that both comments and tools are useful and should be enhanced.

Cheers,
Juan Vuletich


_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
Reply | Threaded
Open this post in threaded view
|

Re: ColorEditor updated

Juan Vuletich-4
In reply to this post by KenDickey
Hi Ken,

On 11/2/2015 8:27 PM, KenD wrote:
> ...
>
> However, class comments are not usually where design patterns show up.  8^|
>
> In the case of #when:send:to: I suggest a slightly larger discussion around building paned windows which update dependent panes.
>
> What constitutes good style?  What code patterns help?
>
> Think "Useful Code Patterns" to augment "Useful Expressions".

In 2009 I wrote
http://www.jvuletich.org/LightWidgets/AnExampleOfLightWidgetsProgramming.txt 
and
http://www.jvuletich.org/LightWidgets/ProgrammingWithLightWidgets.txt .
I've had the idea of making all the GUI code in Cuis follow this style.
But time is always short...

Cheers,
Juan Vuletich

_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
Reply | Threaded
Open this post in threaded view
|

Patterns

Dan Norton
On 6 Nov 2015 at 15:28, Juan Vuletich wrote Re: [Cuis] ColorEditor updated:

> Hi Ken,
>
> On 11/2/2015 8:27 PM, KenD wrote:
> > ...
> >
> > However, class comments are not usually where design patterns show
> up.  8^|
> >
> > In the case of #when:send:to: I suggest a slightly larger
> discussion around building paned windows which update dependent
> panes.
> >
> > What constitutes good style?  What code patterns help?
> >
> > Think "Useful Code Patterns" to augment "Useful Expressions".
>
> In 2009 I wrote
> http://www.jvuletich.org/LightWidgets/AnExampleOfLightWidgetsProgram
> ming.txt
> and
> http://www.jvuletich.org/LightWidgets/ProgrammingWithLightWidgets.tx
> t .
> I've had the idea of making all the GUI code in Cuis follow this
> style.
> But time is always short...
>

As one who benefits greatly from studying other people's code ;-) I favor copy and paste over reading prose. The most useful "Useful Code Patterns" would be something in a code window like "Useful Expressions" IMO. But where UE is code line oriented, it needs to be class and method orented.  It would be heavily commented as to what is on a line, or in a method, and why, because this is a big problem with Smalltalk in many cases. Once pasted, the comments would be customized or removed.

I started a package with a model and a view, trying to be minimalist about getting them to simply put up a window without bringing up the debugger. There are lots of comments. Please take a look and give me yours.

           https://github.com/dhnorton/Cuis-Smalltalk-patterns

It tries to be the most efficient, direct, and simple pattern for opening a view on a model in Cuis. It's deliberately not glitzy. Glitz is added by the user. Next, I plan to incorporate #when:send:to: fundamentals.

 - Dan

_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
Reply | Threaded
Open this post in threaded view
|

Re: Patterns

Luciano Notarfrancesco
Excelent, this exampe has exactly what I wanted yesterday. Models should implement #open for instance creation. Also, all the different ways we are currently using to open windows should be cleaned up and unified... but I'll be happy with #open in every model at least (and always returning the window).

Also Smalltalk|save, saveAs, quit.

I don't use menues much, I rather doIt ;)
Luciano

On Mon, Nov 16, 2015 at 10:30 PM, Dan Norton <[hidden email]> wrote:
On 6 Nov 2015 at 15:28, Juan Vuletich wrote Re: [Cuis] ColorEditor updated:

> Hi Ken,
>
> On 11/2/2015 8:27 PM, KenD wrote:
> > ...
> >
> > However, class comments are not usually where design patterns show
> up.  8^|
> >
> > In the case of #when:send:to: I suggest a slightly larger
> discussion around building paned windows which update dependent
> panes.
> >
> > What constitutes good style?  What code patterns help?
> >
> > Think "Useful Code Patterns" to augment "Useful Expressions".
>
> In 2009 I wrote
> ming.txt
> and
> t .
> I've had the idea of making all the GUI code in Cuis follow this
> style.
> But time is always short...
>

As one who benefits greatly from studying other people's code ;-) I favor copy and paste over reading prose. The most useful "Useful Code Patterns" would be something in a code window like "Useful Expressions" IMO. But where UE is code line oriented, it needs to be class and method orented.  It would be heavily commented as to what is on a line, or in a method, and why, because this is a big problem with Smalltalk in many cases. Once pasted, the comments would be customized or removed.

I started a package with a model and a view, trying to be minimalist about getting them to simply put up a window without bringing up the debugger. There are lots of comments. Please take a look and give me yours.


It tries to be the most efficient, direct, and simple pattern for opening a view on a model in Cuis. It's deliberately not glitzy. Glitz is added by the user. Next, I plan to incorporate #when:send:to: fundamentals.

 - Dan

_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org



_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
Reply | Threaded
Open this post in threaded view
|

Re: Patterns

Juan Vuletich-4
In reply to this post by Dan Norton
Hi Dan,

On 16/11/2015 07:30 p.m., Dan Norton wrote:

As one who benefits greatly from studying other people's code ;-) I favor copy and paste over reading prose. The most useful "Useful Code Patterns" would be something in a code window like "Useful Expressions" IMO. But where UE is code line oriented, it needs to be class and method orented.  It would be heavily commented as to what is on a line, or in a method, and why, because this is a big problem with Smalltalk in many cases. Once pasted, the comments would be customized or removed.

Ok, it is a good idea.

I started a package with a model and a view, trying to be minimalist about getting them to simply put up a window without bringing up the debugger. There are lots of comments. Please take a look and give me yours.


It tries to be the most efficient, direct, and simple pattern for opening a view on a model in Cuis. It's deliberately not glitzy. Glitz is added by the user. Next, I plan to incorporate #when:send:to: fundamentals.

 - Dan

Well, I don't like the #open method in the model. The idea of View / Model separation is that views know about models, but models don't know about views. A Model should exist independently of being used from Morphic, MVC, Seaside, or any other UI framework. It could live, for example, in a Gemstone database with no UI at all. Or ir could travel to and from other systems, like VA Smalltalk, where the UI framework is completely different from Cuis'.

I think it is better for the View to start it all.

Cheers,
Juan Vuletich

_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
Reply | Threaded
Open this post in threaded view
|

Re: Patterns

garduino


2015-11-16 22:06 GMT-03:00 Juan Vuletich <[hidden email]>:

Well, I don't like the #open method in the model. The idea of View / Model separation is that views know about models, but models don't know about views. A Model should exist independently of being used from Morphic, MVC, Seaside, or any other UI framework. It could live, for example, in a Gemstone database with no UI at all. Or ir could travel to and from other systems, like VA Smalltalk, where the UI framework is completely different from Cuis'.


Interesting, really I never heard of the use of  #open at the model or I do not remember it at all, but I think similar to Juan.

 
I think it is better for the View to start it all.


+1



_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
Reply | Threaded
Open this post in threaded view
|

Re: Patterns

Thierry Goubier
Le 17/11/2015 02:47, Germán Arduino a écrit :

>
>
> 2015-11-16 22:06 GMT-03:00 Juan Vuletich <[hidden email]
> <mailto:[hidden email]>>:
>
>     __
>
>     Well, I don't like the #open method in the model. The idea of View /
>     Model separation is that views know about models, but models don't
>     know about views. A Model should exist independently of being used
>     from Morphic, MVC, Seaside, or any other UI framework. It could
>     live, for example, in a Gemstone database with no UI at all. Or ir
>     could travel to and from other systems, like VA Smalltalk, where the
>     UI framework is completely different from Cuis'.
>
>
> Interesting, really I never heard of the use of  #open at the model or I
> do not remember it at all, but I think similar to Juan.

Hum, #open has to go somewhere, so...

Either it goes into a sort of Application Model, which regroup the
duties associated with the application (the view + model + whatever is
necessary in environment X), or it goes into an Application View which
then has model concerns in it (it knows how to start or connect to the
model, it knows what the model is composed of to connect subviews to
model elements, etc...).

>     I think it is better for the View to start it all.
>
>
> +1

I prefer to model an Application concept in the target desktop
environment if I want to model highly portable stuff.

That application concern can be folded into a dedicated view if that is
the preferred convention in the target environment.

Regards,

Thierry

>
>
>
> _______________________________________________
> Cuis mailing list
> [hidden email]
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>


_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
Reply | Threaded
Open this post in threaded view
|

Re: Patterns

Juan Vuletich-4
Hi Thierry,


On 11/17/2015 1:42 AM, Thierry Goubier wrote:

> Le 17/11/2015 02:47, Germán Arduino a écrit :
>>
>>
>> 2015-11-16 22:06 GMT-03:00 Juan Vuletich <[hidden email]
>> <mailto:[hidden email]>>:
>>
>>     __
>>
>>     Well, I don't like the #open method in the model. The idea of View /
>>     Model separation is that views know about models, but models don't
>>     know about views. A Model should exist independently of being used
>>     from Morphic, MVC, Seaside, or any other UI framework. It could
>>     live, for example, in a Gemstone database with no UI at all. Or ir
>>     could travel to and from other systems, like VA Smalltalk, where the
>>     UI framework is completely different from Cuis'.
>>
>>
>> Interesting, really I never heard of the use of  #open at the model or I
>> do not remember it at all, but I think similar to Juan.
>
> Hum, #open has to go somewhere, so...
>
> Either it goes into a sort of Application Model, which regroup the
> duties associated with the application (the view + model + whatever is
> necessary in environment X), or it goes into an Application View which
> then has model concerns in it (it knows how to start or connect to the
> model, it knows what the model is composed of to connect subviews to
> model elements, etc...).
>

The idea of view / model separation is pretty well explained in "Inside
Smalltalk Vol II" 1.3 to 1.3.4, pages 7 to 11.

I agree that an Application object or such might make sense when you are
building an application, especially if you need to deal with en external
environment. But here we were talking about whether the Model classes
should know about Morphs or not.

>>     I think it is better for the View to start it all.
>>
>>
>> +1
>
> I prefer to model an Application concept in the target desktop
> environment if I want to model highly portable stuff.
>
> That application concern can be folded into a dedicated view if that
> is the preferred convention in the target environment.
>
> Regards,
>
> Thierry

I wonder how would this result in practice. Do you have some examples to
share?

Cheers,
Juan Vuletich

_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
Reply | Threaded
Open this post in threaded view
|

Fwd: Patterns

Thierry Goubier

2015-11-17 15:00 GMT+01:00 Juan Vuletich <[hidden email]>:
Hi Thierry,


On 11/17/2015 1:42 AM, Thierry Goubier wrote:
Le 17/11/2015 02:47, Germán Arduino a écrit :


2015-11-16 22:06 GMT-03:00 Juan Vuletich <[hidden email]
<mailto:[hidden email]>>:

    __

    Well, I don't like the #open method in the model. The idea of View /
    Model separation is that views know about models, but models don't
    know about views. A Model should exist independently of being used
    from Morphic, MVC, Seaside, or any other UI framework. It could
    live, for example, in a Gemstone database with no UI at all. Or ir
    could travel to and from other systems, like VA Smalltalk, where the
    UI framework is completely different from Cuis'.


Interesting, really I never heard of the use of  #open at the model or I
do not remember it at all, but I think similar to Juan.

Hum, #open has to go somewhere, so...

Either it goes into a sort of Application Model, which regroup the duties associated with the application (the view + model + whatever is necessary in environment X), or it goes into an Application View which then has model concerns in it (it knows how to start or connect to the model, it knows what the model is composed of to connect subviews to model elements, etc...).


The idea of view / model separation is pretty well explained in "Inside Smalltalk Vol II" 1.3 to 1.3.4, pages 7 to 11.

Sadly, that view / model separation encounters pragmatic issues  when dealing with things more complex than standard widgets, such as your typical domain drawing editor. This is the fundamental reason for me to consider that Morphic departed from that model, and that the pinacle of that M / V separation is the M2VC of VisualWorks.

Newer models in the literature around those years such as PAC proposed better abstractions, but they were never implemented.

Now, it's interesting to see you advocate that model on top of Morphic.


I agree that an Application object or such might make sense when you are building an application, especially if you need to deal with en external environment. But here we were talking about whether the Model classes should know about Morphs or not.

In theory, no.

In practice, if you want a well tuned gui, I consider that yes, they need to be aware of them.

So the most elegant way I've used is the two models: a pure, abstract model, totally view independent. And a pragmatic, closer to the view / aware of the view, application model as an mediator.
 


    I think it is better for the View to start it all.


+1

I prefer to model an Application concept in the target desktop environment if I want to model highly portable stuff.

That application concern can be folded into a dedicated view if that is the preferred convention in the target environment.

Regards,

Thierry

I wonder how would this result in practice. Do you have some examples to share?

I have a complex example, a system browser, would that fit?

Regards,

Thierry


_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: Patterns

Juan Vuletich-4
Hi Thierry,

On 11/17/2015 11:32 AM, Thierry Goubier wrote:

2015-11-17 15:00 GMT+01:00 Juan Vuletich <[hidden email]>:
...

The idea of view / model separation is pretty well explained in "Inside Smalltalk Vol II" 1.3 to 1.3.4, pages 7 to 11.

Sadly, that view / model separation encounters pragmatic issues  when dealing with things more complex than standard widgets, such as your typical domain drawing editor.

This is the first time I hear this. Can you elaborate or provide references? I worked on several mid-size to large projects that did strict view / model separation, and I never saw "pragmatic issues" (that couldn't be solved by a good design).

This is the fundamental reason for me to consider that Morphic departed from that model, and that the pinacle of that M / V separation is the M2VC of VisualWorks.

PluggableMorphs attempted to follow this model (and give model compatibility between Morphic and MVC). Etoys (if I remember correctly) do the same, only that calling the model a "Player" and the view a "Costume". Later, people forgot about view / model separation, and Squeak became legacy software, in part because of that.

Newer models in the literature around those years such as PAC proposed better abstractions, but they were never implemented.
Now, it's interesting to see you advocate that model on top of Morphic.


I agree that an Application object or such might make sense when you are building an application, especially if you need to deal with en external environment. But here we were talking about whether the Model classes should know about Morphs or not.

In theory, no.

In practice, if you want a well tuned gui, I consider that yes, they need to be aware of them.

Please elaborate, or provide references.

So the most elegant way I've used is the two models: a pure, abstract model, totally view independent. And a pragmatic, closer to the view / aware of the view, application model as an mediator.
 


    I think it is better for the View to start it all.


+1

I prefer to model an Application concept in the target desktop environment if I want to model highly portable stuff.

That application concern can be folded into a dedicated view if that is the preferred convention in the target environment.

Regards,

Thierry

I wonder how would this result in practice. Do you have some examples to share?

I have a complex example, a system browser, would that fit?

Sure.

Regards,

Thierry


Cheers,
Juan Vuletich

_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
Reply | Threaded
Open this post in threaded view
|

Fwd: Fwd: Patterns

Thierry Goubier
Hi Juan,

2015-11-17 16:16 GMT+01:00 Juan Vuletich <[hidden email]>:
Hi Thierry,

On 11/17/2015 11:32 AM, Thierry Goubier wrote:

2015-11-17 15:00 GMT+01:00 Juan Vuletich <[hidden email]>:
...

The idea of view / model separation is pretty well explained in "Inside Smalltalk Vol II" 1.3 to 1.3.4, pages 7 to 11.

Sadly, that view / model separation encounters pragmatic issues  when dealing with things more complex than standard widgets, such as your typical domain drawing editor.

This is the first time I hear this. Can you elaborate or provide references? I worked on several mid-size to large projects that did strict view / model separation, and I never saw "pragmatic issues" (that couldn't be solved by a good design).

I would give HotDraw, and some of the original design pattern work on editors, especially the parts derived from the InterViews toolkit.

Now, I used to be pretty up to date on the literature and some of the criticism of the MVC model (especially the division between V and C) but my memory of that time is all fuzzy.
This is the fundamental reason for me to consider that Morphic departed from that model, and that the pinacle of that M / V separation is the M2VC of VisualWorks.

PluggableMorphs attempted to follow this model (and give model compatibility between Morphic and MVC). Etoys (if I remember correctly) do the same, only that calling the model a "Player" and the view a "Costume". Later, people forgot about view / model separation, and Squeak became legacy software, in part because of that.

Maybe. I'm not sure of that particular factor. I have the feeling that there is no clear and honest analysis on the state of GUI toolkits in that universe, for present and future ones.
 
Newer models in the literature around those years such as PAC proposed better abstractions, but they were never implemented.
Now, it's interesting to see you advocate that model on top of Morphic.


I agree that an Application object or such might make sense when you are building an application, especially if you need to deal with en external environment. But here we were talking about whether the Model classes should know about Morphs or not.

In theory, no.

In practice, if you want a well tuned gui, I consider that yes, they need to be aware of them.

Please elaborate, or provide references.

What would you think of a drag and drop feedback which is dependent of the type of the model elements?
 


So the most elegant way I've used is the two models: a pure, abstract model, totally view independent. And a pragmatic, closer to the view / aware of the view, application model as an mediator.
 


    I think it is better for the View to start it all.


+1

I prefer to model an Application concept in the target desktop environment if I want to model highly portable stuff.

That application concern can be folded into a dedicated view if that is the preferred convention in the target environment.

Regards,

Thierry

I wonder how would this result in practice. Do you have some examples to share?

I have a complex example, a system browser, would that fit?

Sure.

Well, a short estimate on that particular application is that, linked with the pluggable morphs, 10 to 20% of the code in the application model is:
- widget creation, setup, layout
- dynamic morph addition / removal when activating certain functions on the model
- workarounds the pluggable morphs api to:
  - dynamically refresh parts of the inside of widgets
  - disconnect then reconnect links between widgets so that the model-triggered update of one does not change the state of the other one (i.e. protect the model from unwanted view triggered updates when the model is changing part of its contents).

This application model uses mainly two widgets.

I do have a long term plan to port that to Cuis, and I expect I will have to write that very same code somewhere (maybe more, maybe less).

Regards,

Thierry
 

Regards,

Thierry


Cheers,
Juan Vuletich



_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: Fwd: Patterns

Juan Vuletich-4
Hi Thierry,

On 11/17/2015 1:51 PM, Thierry Goubier wrote:
Hi Juan,

2015-11-17 16:16 GMT+01:00 Juan Vuletich <[hidden email]>:
Hi Thierry,

On 11/17/2015 11:32 AM, Thierry Goubier wrote:

2015-11-17 15:00 GMT+01:00 Juan Vuletich <[hidden email]>:
...

The idea of view / model separation is pretty well explained in "Inside Smalltalk Vol II" 1.3 to 1.3.4, pages 7 to 11.

Sadly, that view / model separation encounters pragmatic issues  when dealing with things more complex than standard widgets, such as your typical domain drawing editor.

This is the first time I hear this. Can you elaborate or provide references? I worked on several mid-size to large projects that did strict view / model separation, and I never saw "pragmatic issues" (that couldn't be solved by a good design).

I would give HotDraw, and some of the original design pattern work on editors, especially the parts derived from the InterViews toolkit.

Uh, it is not easy to find stuff about that, so I can't really comment.

Now, I used to be pretty up to date on the literature and some of the criticism of the MVC model (especially the division between V and C) but my memory of that time is all fuzzy.

Well, in my opinion View / Model separation is a great property of the design of an application. Controller is more of a requirement of the ST-80 MVC framework. In principle, I see no problem in merging Controller into View. But, in Cuis, it can be argued that the Editor hierarchy is essentially a hierarchy of Controllers, and that's ok if the decomposition of responsibilities makes sense.

In View / Model separation there are two restrictions that need to be honored:
- The Model doesn't know about the possible Views. This means, for instance, that it could provide all its services, and exercise all its functionality, even if the GUI framework is completely absent. Model code should never fail because of this. This is great for moving models from and two different runtimes (client, server, gemstone, various dialects, etc) and also for writing tests.
- Model behavior should not leak into Views. This means that if the views are removed (maybe to be replaced by some others, in the same or in another framework), Model should not lose state nor behavior. Model must be complete by itself.
So, the idea is essentially to protect the integrity and consistency of Models.

This is the fundamental reason for me to consider that Morphic departed from that model, and that the pinacle of that M / V separation is the M2VC of VisualWorks.

PluggableMorphs attempted to follow this model (and give model compatibility between Morphic and MVC). Etoys (if I remember correctly) do the same, only that calling the model a "Player" and the view a "Costume". Later, people forgot about view / model separation, and Squeak became legacy software, in part because of that.

Maybe. I'm not sure of that particular factor. I have the feeling that there is no clear and honest analysis on the state of GUI toolkits in that universe, for present and future ones.
 
Newer models in the literature around those years such as PAC proposed better abstractions, but they were never implemented.
Now, it's interesting to see you advocate that model on top of Morphic.


I agree that an Application object or such might make sense when you are building an application, especially if you need to deal with en external environment. But here we were talking about whether the Model classes should know about Morphs or not.

In theory, no.

In practice, if you want a well tuned gui, I consider that yes, they need to be aware of them.

Please elaborate, or provide references.

What would you think of a drag and drop feedback which is dependent of the type of the model elements?

Well, lets assume a Model with 2 collections of elements. To make it sound a bit more concrete, lets call them Orders and Assets. And lets assume that the UI has some place(s) from where the user can drag many kinds of objects, like Orders, Assets, between others. Now, the user drags an Asset and wants to drop it into the Orders list. Given that the widget for the Orders list supports dropping, lets assume that its 'dropActionSelector' is #addOrder:. This #addOrder: model method would be called with an Asset. So, #addOrder: could answer false, to let sender know that the addition was rejected (because it was not an Order!). It makes sense to have the method in ListWidget that calls 'dropSelector' check for the result, and if it is false, let the user know that the drop was rejected, for instance, by keeping the dragged object in the hand.

 


So the most elegant way I've used is the two models: a pure, abstract model, totally view independent. And a pragmatic, closer to the view / aware of the view, application model as an mediator.
 


    I think it is better for the View to start it all.


+1

I prefer to model an Application concept in the target desktop environment if I want to model highly portable stuff.

That application concern can be folded into a dedicated view if that is the preferred convention in the target environment.

Regards,

Thierry

I wonder how would this result in practice. Do you have some examples to share?

I have a complex example, a system browser, would that fit?

Sure.

Well, a short estimate on that particular application is that, linked with the pluggable morphs, 10 to 20% of the code in the application model is:
- widget creation, setup, layout
- dynamic morph addition / removal when activating certain functions on the model
- workarounds the pluggable morphs api to:
  - dynamically refresh parts of the inside of widgets
  - disconnect then reconnect links between widgets so that the model-triggered update of one does not change the state of the other one (i.e. protect the model from unwanted view triggered updates when the model is changing part of its contents).

"View model" is a bit a misleading name. I'd say all this belongs in the Views world.

Besides, the method called to update Views after Model changes should not modify the Model. In this way, there would be no extra Model events triggered, and spurious updates would not occur. This might require enhancing the Views framework, if not mature enough.


This application model uses mainly two widgets.

I do have a long term plan to port that to Cuis, and I expect I will have to write that very same code somewhere (maybe more, maybe less).

Regards,

Thierry

Hopefully, it will be less :)

Cheers,
Juan Vuletich


_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: Fwd: Patterns

Thierry Goubier
Hi Juan,

Le 17/11/2015 18:36, Juan Vuletich a écrit :
> Hi Thierry,
>
>>
>>
>> I would give HotDraw, and some of the original design pattern work on
>> editors, especially the parts derived from the InterViews toolkit.
>
> Uh, it is not easy to find stuff about that, so I can't really comment.

InterViews was kept alive as the ivtools for long, very long after
InterViews lost to Motif as the X Window toolkit. Fresco, InterViews
successor, was also very interesting.

HotDraw is old as well. But I did some cool stuff with it (a hypermedia
system, in 1993).

>> Now, I used to be pretty up to date on the literature and some of the
>> criticism of the MVC model (especially the division between V and C)
>> but my memory of that time is all fuzzy.
>
> Well, in my opinion View / Model separation is a great property of the
> design of an application. Controller is more of a requirement of the
> ST-80 MVC framework. In principle, I see no problem in merging
> Controller into View. But, in Cuis, it can be argued that the Editor
> hierarchy is essentially a hierarchy of Controllers, and that's ok if
> the decomposition of responsibilities makes sense.
>
> In View / Model separation there are two restrictions that need to be
> honored:
> - The Model doesn't know about the possible Views. This means, for
> instance, that it could provide all its services, and exercise all its
> functionality, even if the GUI framework is completely absent. Model
> code should never fail because of this. This is great for moving models
> from and two different runtimes (client, server, gemstone, various
> dialects, etc) and also for writing tests.
> - Model behavior should not leak into Views. This means that if the
> views are removed (maybe to be replaced by some others, in the same or
> in another framework), Model should not lose state nor behavior. Model
> must be complete by itself.
> So, the idea is essentially to protect the integrity and consistency of
> Models.

I do agree with that objective, but, in practice, what I find as a
result is that an additional layer (model mediation or the M2 of MMVC)
helps immensely by:

- regrouping certain model features which are introduced to satisfy view
requirements...

   - For example a pure model can just have a copy or save to file
operation, but a view would like to have a feedback on the length of the
operation. In non gui mode, having the model expose that sort of
information is a needless waste of code and resources. This would better
be carried by a layer on top (which is still a model IMHO, since it
maintain a certain level of decoupling with a view).

- Expose explicitely certain adaptations which are made for a specific
toolkit (they are in that model).

- Allow for user-features oriented models to appear on top of the pure,
abstract model

   - In a browser, one can imagine scoped models of the code as a
user-oriented feature that a disconnected mode doesn't need to integrate.

Nothing really grandiose or earth-shattering, mind you. Just convenient.

>> What would you think of a drag and drop feedback which is dependent of
>> the type of the model elements?
>
> Well, lets assume a Model with 2 collections of elements. To make it
> sound a bit more concrete, lets call them Orders and Assets. And lets
> assume that the UI has some place(s) from where the user can drag many
> kinds of objects, like Orders, Assets, between others. Now, the user
> drags an Asset and wants to drop it into the Orders list. Given that the
> widget for the Orders list supports dropping, lets assume that its
> 'dropActionSelector' is #addOrder:. This #addOrder: model method would
> be called with an Asset. So, #addOrder: could answer false, to let
> sender know that the addition was rejected (because it was not an
> Order!). It makes sense to have the method in ListWidget that calls
> 'dropSelector' check for the result, and if it is false, let the user
> know that the drop was rejected, for instance, by keeping the dragged
> object in the hand.

Hum, I was more thinking of what I am dealing with at the moment, which
is a drop in the Orders list is a drop on a specific order item, which
has to tell:

- during the drag, if a drop would be honored
- after the drop, if it is accepted or rejected
- and, if accepted, that specific order item changes state and is shown
as such (and may also change the number of order items, etc...)

I found, when doing that, to have an intermediate model on top of my
Asset/Order object to mediate with the drag and drop API very usefull
(that is, what is displayed and dragged are Views on AssetModels which
are themselves observers of Assets).


>
>>
>>
>>>     So the most elegant way I've used is the two models: a pure,
>>>     abstract model, totally view independent. And a pragmatic, closer
>>>     to the view / aware of the view, application model as an mediator.
>>>
>>>
>>>
>>>                     I think it is better for the View to start it all.
>>>
>>>
>>>                 +1
>>>
>>>
>>>             I prefer to model an Application concept in the target
>>>             desktop environment if I want to model highly portable stuff.
>>>
>>>             That application concern can be folded into a dedicated
>>>             view if that is the preferred convention in the target
>>>             environment.
>>>
>>>             Regards,
>>>
>>>             Thierry
>>>
>>>
>>>         I wonder how would this result in practice. Do you have some
>>>         examples to share?
>>>
>>>
>>>     I have a complex example, a system browser, would that fit?
>>
>>     Sure.
>>
>>
>> Well, a short estimate on that particular application is that, linked
>> with the pluggable morphs, 10 to 20% of the code in the application
>> model is:
>> - widget creation, setup, layout
>> - dynamic morph addition / removal when activating certain functions
>> on the model
>> - workarounds the pluggable morphs api to:
>>   - dynamically refresh parts of the inside of widgets
>>   - disconnect then reconnect links between widgets so that the
>> model-triggered update of one does not change the state of the other
>> one (i.e. protect the model from unwanted view triggered updates when
>> the model is changing part of its contents).
>
> "View model" is a bit a misleading name. I'd say all this belongs in the
> Views world.

As I said, it may be moved into the View world, in the sense that it
holds view-related concerns. But, at the same time, it has Model like
decoupling from the Views.

> Besides, the method called to update Views after Model changes should
> not modify the Model. In this way, there would be no extra Model events
> triggered, and spurious updates would not occur. This might require
> enhancing the Views framework, if not mature enough.

I'll let you have a try at that :)

>>
>> This application model uses mainly two widgets.
>>
>> I do have a long term plan to port that to Cuis, and I expect I will
>> have to write that very same code somewhere (maybe more, maybe less).
>>
>> Regards,
>>
>> Thierry
>
> Hopefully, it will be less :)

I'm certainly looking forward to it.

Regards,

Thierry

_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
12