Event handling challenges

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

Event handling challenges

Trygve
Hi Squeakers,
My SRE context browser is a tool for drawing a snapshot of a selected structure of interlinked objects where each object is shown as a rectangular symbol. This diagram shows an object with its class and superclass objects:


SRE has worked for years, last in 'Squeak3.10.2'. In 'Squeak5.3', the same program went into an infinite loop. It transpired that myClass>>processEvent: anEvent using: defaultDispatcher had become a new thing called an event filter and needed to return an Event or a Symbol. That problem fixed; the program still misbehaves. The problem seems to be with event handling. I have never been into that corner of Smalltalk but have read some Squeak documentation. I have not found any concrete code.  I realize that I will never understand Squeak's event handling by reading code, code comments, and even the documentation I have found. There has apparently been a significant increase in complexity lately. An example: In 3,10,2, class MorphicEventDispatcher has 4 methods. In 5,3, it has 16.

Here's the beginning of my challenges with 5.3: I find two anomalies in a diagram with just one symbol:
  1.     When I move some other window to a position within the diagram, the diagram grabs it and makes it a submorph of itself.  In 3.10.2, the diagram ignores it.
  2.     The cursor becomes a text cursor when I move the mouse across a symbol.
I have no explanation for either anomaly. My SRE code is a kludge and is almost unreadable. It is hard to formulate a question without the whole code as a background, and I have tried to reproduce them in a simple example. I managed to reproduce the first, but not the second anomaly. In a workspace, copy, select,  and do it. The XXX-symbol becomes attached to the cursor, and I place it in the blue background.
joe := PasteUpMorph new color: Color lightBlue.
joe bounds: (500@400 corner: 800@600).
joe dropEnabled: true.
joe openInWorld.
circle := CircleMorph new.
joe addMorphCentered: circle.
tex := TextMorphXX new
        contents: 'XXX';
        borderWidth: 1;
        color: Color red;
        extent: 100@100.
tex openInHand.

There is only one  method in class TextMorphXX (sco TextMorph):
processEvent: anEvent using: defaultDispatcher
    ^#rejected



I move some background window,  actually a collapsed Monticello thing, to Joe's position, Joe grabs it and makes it into a submorph. Any hints about how to proceed will be greatly appreciated.
--Trygve






--

The essence of object orientation is that objects collaborate  to achieve a goal.
Trygve Reenskaug      
[hidden email]
Morgedalsvn. 5A       
http://folk.uio.no/trygver/
N-0378 Oslo             
http://fullOO.info
Norway                     Tel: (+47) 468 58 625



Reply | Threaded
Open this post in threaded view
|

Re: Event handling challenges

Karl Ramberg
Hi,
When you open a morph for dropping it will accept all dropped morphs:
joe dropEnabled: true.

To filter what is accepted you must override acceptDroppingMorph: aMorph event: evt
Look at implementors for that method.

Best,
Karl



On Mon, Jun 15, 2020 at 2:44 PM Trygve Reenskaug <[hidden email]> wrote:
Hi Squeakers,
My SRE context browser is a tool for drawing a snapshot of a selected structure of interlinked objects where each object is shown as a rectangular symbol. This diagram shows an object with its class and superclass objects:


SRE has worked for years, last in 'Squeak3.10.2'. In 'Squeak5.3', the same program went into an infinite loop. It transpired that myClass>>processEvent: anEvent using: defaultDispatcher had become a new thing called an event filter and needed to return an Event or a Symbol. That problem fixed; the program still misbehaves. The problem seems to be with event handling. I have never been into that corner of Smalltalk but have read some Squeak documentation. I have not found any concrete code.  I realize that I will never understand Squeak's event handling by reading code, code comments, and even the documentation I have found. There has apparently been a significant increase in complexity lately. An example: In 3,10,2, class MorphicEventDispatcher has 4 methods. In 5,3, it has 16.

Here's the beginning of my challenges with 5.3: I find two anomalies in a diagram with just one symbol:
  1.     When I move some other window to a position within the diagram, the diagram grabs it and makes it a submorph of itself.  In 3.10.2, the diagram ignores it.
  2.     The cursor becomes a text cursor when I move the mouse across a symbol.
I have no explanation for either anomaly. My SRE code is a kludge and is almost unreadable. It is hard to formulate a question without the whole code as a background, and I have tried to reproduce them in a simple example. I managed to reproduce the first, but not the second anomaly. In a workspace, copy, select,  and do it. The XXX-symbol becomes attached to the cursor, and I place it in the blue background.
joe := PasteUpMorph new color: Color lightBlue.
joe bounds: (500@400 corner: 800@600).
joe dropEnabled: true.
joe openInWorld.
circle := CircleMorph new.
joe addMorphCentered: circle.
tex := TextMorphXX new
        contents: 'XXX';
        borderWidth: 1;
        color: Color red;
        extent: 100@100.
tex openInHand.

There is only one  method in class TextMorphXX (sco TextMorph):
processEvent: anEvent using: defaultDispatcher
    ^#rejected



I move some background window,  actually a collapsed Monticello thing, to Joe's position, Joe grabs it and makes it into a submorph. Any hints about how to proceed will be greatly appreciated.
--Trygve






--

The essence of object orientation is that objects collaborate  to achieve a goal.
Trygve Reenskaug      
[hidden email]
Morgedalsvn. 5A       
http://folk.uio.no/trygver/
N-0378 Oslo             
http://fullOO.info
Norway                     Tel: (+47) 468 58 625




Reply | Threaded
Open this post in threaded view
|

Re: Event handling challenges

Trygve
Not quite. Joe now throws the the strange Morph back to where it came from instead of ignoring it.
I need Joe to accept all TexMorphXX but ignore the rest.
PasteUpMorphXX>>acceptDroppingMorph: morphToDrop event: evt
    (morphToDrop isKindOf: TextMorphXX) ifFalse: [
        ^morphToDrop rejectDropMorphEvent: evt].



On 2020.06.15 15:13, karl ramberg wrote:
Hi,
When you open a morph for dropping it will accept all dropped morphs:
joe dropEnabled: true.

To filter what is accepted you must override acceptDroppingMorph: aMorph event: evt
Look at implementors for that method.

Best,
Karl



On Mon, Jun 15, 2020 at 2:44 PM Trygve Reenskaug <[hidden email]> wrote:
Hi Squeakers,
My SRE context browser is a tool for drawing a snapshot of a selected structure of interlinked objects where each object is shown as a rectangular symbol. This diagram shows an object with its class and superclass objects:


SRE has worked for years, last in 'Squeak3.10.2'. In 'Squeak5.3', the same program went into an infinite loop. It transpired that myClass>>processEvent: anEvent using: defaultDispatcher had become a new thing called an event filter and needed to return an Event or a Symbol. That problem fixed; the program still misbehaves. The problem seems to be with event handling. I have never been into that corner of Smalltalk but have read some Squeak documentation. I have not found any concrete code.  I realize that I will never understand Squeak's event handling by reading code, code comments, and even the documentation I have found. There has apparently been a significant increase in complexity lately. An example: In 3,10,2, class MorphicEventDispatcher has 4 methods. In 5,3, it has 16.

Here's the beginning of my challenges with 5.3: I find two anomalies in a diagram with just one symbol:
  1.     When I move some other window to a position within the diagram, the diagram grabs it and makes it a submorph of itself.  In 3.10.2, the diagram ignores it.
  2.     The cursor becomes a text cursor when I move the mouse across a symbol.
I have no explanation for either anomaly. My SRE code is a kludge and is almost unreadable. It is hard to formulate a question without the whole code as a background, and I have tried to reproduce them in a simple example. I managed to reproduce the first, but not the second anomaly. In a workspace, copy, select,  and do it. The XXX-symbol becomes attached to the cursor, and I place it in the blue background.
joe := PasteUpMorph new color: Color lightBlue.
joe bounds: (500@400 corner: 800@600).
joe dropEnabled: true.
joe openInWorld.
circle := CircleMorph new.
joe addMorphCentered: circle.
tex := TextMorphXX new
        contents: 'XXX';
        borderWidth: 1;
        color: Color red;
        extent: 100@100.
tex openInHand.

There is only one  method in class TextMorphXX (sco TextMorph):
processEvent: anEvent using: defaultDispatcher
    ^#rejected



I move some background window,  actually a collapsed Monticello thing, to Joe's position, Joe grabs it and makes it into a submorph. Any hints about how to proceed will be greatly appreciated.
--Trygve






--

The essence of object orientation is that objects collaborate  to achieve a goal.
Trygve Reenskaug      
[hidden email]
Morgedalsvn. 5A       
http://folk.uio.no/trygver/
N-0378 Oslo             
http://fullOO.info
Norway                     Tel: (+47) 468 58 625




    

--

The essence of object orientation is that objects collaborate  to achieve a goal.
Trygve Reenskaug      
[hidden email]
Morgedalsvn. 5A       
http://folk.uio.no/trygver/
N-0378 Oslo             
http://fullOO.info
Norway                     Tel: (+47) 468 58 625



Reply | Threaded
Open this post in threaded view
|

Re: Event handling challenges

Karl Ramberg
Try this
PasteUpMorphXX>>acceptDroppingMorph: morphToDrop event: evt
    (morphToDrop isKindOf: TextMorphXX) ifFalse: [
        ^morphToDrop rejectDropMorphEvent: evt].
    super acceptDroppingMorph: aPiece event: evt.

Best,
Karl


On Mon, Jun 15, 2020 at 3:47 PM Trygve Reenskaug <[hidden email]> wrote:
Not quite. Joe now throws the the strange Morph back to where it came from instead of ignoring it.
I need Joe to accept all TexMorphXX but ignore the rest.
PasteUpMorphXX>>acceptDroppingMorph: morphToDrop event: evt
    (morphToDrop isKindOf: TextMorphXX) ifFalse: [
        ^morphToDrop rejectDropMorphEvent: evt].



On 2020.06.15 15:13, karl ramberg wrote:
Hi,
When you open a morph for dropping it will accept all dropped morphs:
joe dropEnabled: true.

To filter what is accepted you must override acceptDroppingMorph: aMorph event: evt
Look at implementors for that method.

Best,
Karl



On Mon, Jun 15, 2020 at 2:44 PM Trygve Reenskaug <[hidden email]> wrote:
Hi Squeakers,
My SRE context browser is a tool for drawing a snapshot of a selected structure of interlinked objects where each object is shown as a rectangular symbol. This diagram shows an object with its class and superclass objects:


SRE has worked for years, last in 'Squeak3.10.2'. In 'Squeak5.3', the same program went into an infinite loop. It transpired that myClass>>processEvent: anEvent using: defaultDispatcher had become a new thing called an event filter and needed to return an Event or a Symbol. That problem fixed; the program still misbehaves. The problem seems to be with event handling. I have never been into that corner of Smalltalk but have read some Squeak documentation. I have not found any concrete code.  I realize that I will never understand Squeak's event handling by reading code, code comments, and even the documentation I have found. There has apparently been a significant increase in complexity lately. An example: In 3,10,2, class MorphicEventDispatcher has 4 methods. In 5,3, it has 16.

Here's the beginning of my challenges with 5.3: I find two anomalies in a diagram with just one symbol:
  1.     When I move some other window to a position within the diagram, the diagram grabs it and makes it a submorph of itself.  In 3.10.2, the diagram ignores it.
  2.     The cursor becomes a text cursor when I move the mouse across a symbol.
I have no explanation for either anomaly. My SRE code is a kludge and is almost unreadable. It is hard to formulate a question without the whole code as a background, and I have tried to reproduce them in a simple example. I managed to reproduce the first, but not the second anomaly. In a workspace, copy, select,  and do it. The XXX-symbol becomes attached to the cursor, and I place it in the blue background.
joe := PasteUpMorph new color: Color lightBlue.
joe bounds: (500@400 corner: 800@600).
joe dropEnabled: true.
joe openInWorld.
circle := CircleMorph new.
joe addMorphCentered: circle.
tex := TextMorphXX new
        contents: 'XXX';
        borderWidth: 1;
        color: Color red;
        extent: 100@100.
tex openInHand.

There is only one  method in class TextMorphXX (sco TextMorph):
processEvent: anEvent using: defaultDispatcher
    ^#rejected



I move some background window,  actually a collapsed Monticello thing, to Joe's position, Joe grabs it and makes it into a submorph. Any hints about how to proceed will be greatly appreciated.
--Trygve






--

The essence of object orientation is that objects collaborate  to achieve a goal.
Trygve Reenskaug      
[hidden email]
Morgedalsvn. 5A       
http://folk.uio.no/trygver/
N-0378 Oslo             
http://fullOO.info
Norway                     Tel: (+47) 468 58 625




    

--

The essence of object orientation is that objects collaborate  to achieve a goal.
Trygve Reenskaug      
[hidden email]
Morgedalsvn. 5A       
http://folk.uio.no/trygver/
N-0378 Oslo             
http://fullOO.info
Norway                     Tel: (+47) 468 58 625



Reply | Threaded
Open this post in threaded view
|

Re: Event handling challenges

Karl Ramberg
I answered a little fast. This should work:
acceptDroppingMorph: morphToDrop event: evt
    (morphToDrop isKindOf: TextMorph) ifFalse: [
        ^Project current world acceptDroppingMorph: morphToDrop event: evt].
     ^super acceptDroppingMorph: morphToDrop event: evt

On Mon, Jun 15, 2020 at 3:57 PM karl ramberg <[hidden email]> wrote:
Try this
PasteUpMorphXX>>acceptDroppingMorph: morphToDrop event: evt
    (morphToDrop isKindOf: TextMorphXX) ifFalse: [
        ^morphToDrop rejectDropMorphEvent: evt].
    super acceptDroppingMorph: aPiece event: evt.

Best,
Karl


On Mon, Jun 15, 2020 at 3:47 PM Trygve Reenskaug <[hidden email]> wrote:
Not quite. Joe now throws the the strange Morph back to where it came from instead of ignoring it.
I need Joe to accept all TexMorphXX but ignore the rest.
PasteUpMorphXX>>acceptDroppingMorph: morphToDrop event: evt
    (morphToDrop isKindOf: TextMorphXX) ifFalse: [
        ^morphToDrop rejectDropMorphEvent: evt].



On 2020.06.15 15:13, karl ramberg wrote:
Hi,
When you open a morph for dropping it will accept all dropped morphs:
joe dropEnabled: true.

To filter what is accepted you must override acceptDroppingMorph: aMorph event: evt
Look at implementors for that method.

Best,
Karl



On Mon, Jun 15, 2020 at 2:44 PM Trygve Reenskaug <[hidden email]> wrote:
Hi Squeakers,
My SRE context browser is a tool for drawing a snapshot of a selected structure of interlinked objects where each object is shown as a rectangular symbol. This diagram shows an object with its class and superclass objects:


SRE has worked for years, last in 'Squeak3.10.2'. In 'Squeak5.3', the same program went into an infinite loop. It transpired that myClass>>processEvent: anEvent using: defaultDispatcher had become a new thing called an event filter and needed to return an Event or a Symbol. That problem fixed; the program still misbehaves. The problem seems to be with event handling. I have never been into that corner of Smalltalk but have read some Squeak documentation. I have not found any concrete code.  I realize that I will never understand Squeak's event handling by reading code, code comments, and even the documentation I have found. There has apparently been a significant increase in complexity lately. An example: In 3,10,2, class MorphicEventDispatcher has 4 methods. In 5,3, it has 16.

Here's the beginning of my challenges with 5.3: I find two anomalies in a diagram with just one symbol:
  1.     When I move some other window to a position within the diagram, the diagram grabs it and makes it a submorph of itself.  In 3.10.2, the diagram ignores it.
  2.     The cursor becomes a text cursor when I move the mouse across a symbol.
I have no explanation for either anomaly. My SRE code is a kludge and is almost unreadable. It is hard to formulate a question without the whole code as a background, and I have tried to reproduce them in a simple example. I managed to reproduce the first, but not the second anomaly. In a workspace, copy, select,  and do it. The XXX-symbol becomes attached to the cursor, and I place it in the blue background.
joe := PasteUpMorph new color: Color lightBlue.
joe bounds: (500@400 corner: 800@600).
joe dropEnabled: true.
joe openInWorld.
circle := CircleMorph new.
joe addMorphCentered: circle.
tex := TextMorphXX new
        contents: 'XXX';
        borderWidth: 1;
        color: Color red;
        extent: 100@100.
tex openInHand.

There is only one  method in class TextMorphXX (sco TextMorph):
processEvent: anEvent using: defaultDispatcher
    ^#rejected



I move some background window,  actually a collapsed Monticello thing, to Joe's position, Joe grabs it and makes it into a submorph. Any hints about how to proceed will be greatly appreciated.
--Trygve






--

The essence of object orientation is that objects collaborate  to achieve a goal.
Trygve Reenskaug      
[hidden email]
Morgedalsvn. 5A       
http://folk.uio.no/trygver/
N-0378 Oslo             
http://fullOO.info
Norway                     Tel: (+47) 468 58 625




    

--

The essence of object orientation is that objects collaborate  to achieve a goal.
Trygve Reenskaug      
[hidden email]
Morgedalsvn. 5A       
http://folk.uio.no/trygver/
N-0378 Oslo             
http://fullOO.info
Norway                     Tel: (+47) 468 58 625



Reply | Threaded
Open this post in threaded view
|

Re: Event handling challenges

Karl Ramberg
In reply to this post by Trygve
As for the TextMorphXX.
Do you want the TextMorphXX to behave like a StringMorph, eg. editing will not activate on mouse over/ move events ?

tex := StringMorph new
        contents: 'XXX';
        borderWidth: 1;
        color: Color red;
        extent: 100@100.
tex openInHand.

On Mon, Jun 15, 2020 at 2:44 PM Trygve Reenskaug <[hidden email]> wrote:
Hi Squeakers,
My SRE context browser is a tool for drawing a snapshot of a selected structure of interlinked objects where each object is shown as a rectangular symbol. This diagram shows an object with its class and superclass objects:


SRE has worked for years, last in 'Squeak3.10.2'. In 'Squeak5.3', the same program went into an infinite loop. It transpired that myClass>>processEvent: anEvent using: defaultDispatcher had become a new thing called an event filter and needed to return an Event or a Symbol. That problem fixed; the program still misbehaves. The problem seems to be with event handling. I have never been into that corner of Smalltalk but have read some Squeak documentation. I have not found any concrete code.  I realize that I will never understand Squeak's event handling by reading code, code comments, and even the documentation I have found. There has apparently been a significant increase in complexity lately. An example: In 3,10,2, class MorphicEventDispatcher has 4 methods. In 5,3, it has 16.

Here's the beginning of my challenges with 5.3: I find two anomalies in a diagram with just one symbol:
  1.     When I move some other window to a position within the diagram, the diagram grabs it and makes it a submorph of itself.  In 3.10.2, the diagram ignores it.
  2.     The cursor becomes a text cursor when I move the mouse across a symbol.
I have no explanation for either anomaly. My SRE code is a kludge and is almost unreadable. It is hard to formulate a question without the whole code as a background, and I have tried to reproduce them in a simple example. I managed to reproduce the first, but not the second anomaly. In a workspace, copy, select,  and do it. The XXX-symbol becomes attached to the cursor, and I place it in the blue background.
joe := PasteUpMorph new color: Color lightBlue.
joe bounds: (500@400 corner: 800@600).
joe dropEnabled: true.
joe openInWorld.
circle := CircleMorph new.
joe addMorphCentered: circle.
tex := TextMorphXX new
        contents: 'XXX';
        borderWidth: 1;
        color: Color red;
        extent: 100@100.
tex openInHand.

There is only one  method in class TextMorphXX (sco TextMorph):
processEvent: anEvent using: defaultDispatcher
    ^#rejected



I move some background window,  actually a collapsed Monticello thing, to Joe's position, Joe grabs it and makes it into a submorph. Any hints about how to proceed will be greatly appreciated.
--Trygve






--

The essence of object orientation is that objects collaborate  to achieve a goal.
Trygve Reenskaug      
[hidden email]
Morgedalsvn. 5A       
http://folk.uio.no/trygver/
N-0378 Oslo             
http://fullOO.info
Norway                     Tel: (+47) 468 58 625




Reply | Threaded
Open this post in threaded view
|

Re: Event handling challenges

K K Subbu
In reply to this post by Trygve
On 15/06/20 7:17 pm, Trygve Reenskaug wrote:
> Not quite. Joe now throws the the strange Morph back to where it came
> from instead of ignoring it.

This will happen if dropEnabled is false.

> I need Joe to accept all TexMorphXX but ignore the rest
I think this is handled by wantsDroppedMorph... method.

PasteUpMorphXX>>wantsDroppedMorph: aMorph event: evt
    (aMorph isKindOf: TextMorphXX) ifFalse: [^false]
    ^super wantsDroppedMorph: aMorph event: evt

HTH .. Subbu

Reply | Threaded
Open this post in threaded view
|

Re: Event handling challenges

Stephen Pope
In reply to this post by Trygve

Hello all,

I’ve been working in Cuis and loving the reduced footprint, and Trygve’s note encourages me to ask whether there’s anyone who wants to contribute to a reimplementation of old-school MVC and an updated “wrapper” framework for GUI construction in Squeak/Cuis.

My application (Siren music tools) uses StandardSystemViews/Controllers, and so I’ve made file-ins that restore much of the View/Controller framework, but bottoming out to Morphs for the display objects.

Did I miss it in the years I was away? Has this been done before?

stp

--

                    Stephen Travis Pope   Santa Barbara, California, USA    

On Jun 15, 2020, at 5:44 AM, Trygve Reenskaug <[hidden email]> wrote:

Hi Squeakers,
My SRE context browser is a tool for drawing a snapshot of a selected structure of interlinked objects where each object is shown as a rectangular symbol. This diagram shows an object with its class and superclass objects:

<clfapgjkmegmpnfm.gif>
SRE has worked for years, last in 'Squeak3.10.2'. In 'Squeak5.3', the same program went into an infinite loop. It transpired that myClass>>processEvent: anEvent using: defaultDispatcher had become a new thing called an event filter and needed to return an Event or a Symbol. That problem fixed; the program still misbehaves. The problem seems to be with event handling. I have never been into that corner of Smalltalk but have read some Squeak documentation. I have not found any concrete code.  I realize that I will never understand Squeak's event handling by reading code, code comments, and even the documentation I have found. There has apparently been a significant increase in complexity lately. An example: In 3,10,2, class MorphicEventDispatcher has 4 methods. In 5,3, it has 16.

Here's the beginning of my challenges with 5.3: I find two anomalies in a diagram with just one symbol:
  1.     When I move some other window to a position within the diagram, the diagram grabs it and makes it a submorph of itself.  In 3.10.2, the diagram ignores it.
  2.     The cursor becomes a text cursor when I move the mouse across a symbol.
I have no explanation for either anomaly. My SRE code is a kludge and is almost unreadable. It is hard to formulate a question without the whole code as a background, and I have tried to reproduce them in a simple example. I managed to reproduce the first, but not the second anomaly. In a workspace, copy, select,  and do it. The XXX-symbol becomes attached to the cursor, and I place it in the blue background. 
joe := PasteUpMorph new color: Color lightBlue.
joe bounds: (500@400 corner: 800@600).
joe dropEnabled: true.
joe openInWorld.
circle := CircleMorph new.
joe addMorphCentered: circle.
tex := TextMorphXX new
        contents: 'XXX';
        borderWidth: 1;
        color: Color red;
        extent: 100@100.
tex openInHand.

There is only one  method in class TextMorphXX (sco TextMorph):
processEvent: anEvent using: defaultDispatcher
    ^#rejected

<ojfapckoaibeechh.png>

I move some background window,  actually a collapsed Monticello thing, to Joe's position, Joe grabs it and makes it into a submorph. Any hints about how to proceed will be greatly appreciated.
--Trygve

-- 
The essence of object orientation is that objects collaborate  to achieve a goal. 
Trygve Reenskaug      
[hidden email]
Morgedalsvn. 5A       
http://folk.uio.no/trygver/
N-0378 Oslo             
http://fullOO.info
Norway                     Tel: (+47) 468 58 625 



Reply | Threaded
Open this post in threaded view
|

Re: [Cuis-dev] Event handling challenges

David T. Lewis
Hi Stephen,

On Mon, Jun 15, 2020 at 10:08:27AM -0700, stephen--- via Cuis-dev wrote:

>
> Hello all,
>
> I???ve been working in Cuis and loving the reduced footprint, and Trygve???s note encourages me to ask whether there???s anyone who wants to contribute to a reimplementation of old-school MVC and an updated ???wrapper??? framework for GUI construction in Squeak/Cuis.
>
> My application (Siren music tools) uses StandardSystemViews/Controllers, and so I???ve made file-ins that restore much of the View/Controller framework, but bottoming out to Morphs for the display objects.
>
> Did I miss it in the years I was away? Has this been done before?
>
> stp
>

Just in case you may be overlooking it, MVC is alive and well in Squeak 5.3.

  world menu -> open... -> mvc project

It may be in need of fixes and improvements, and if so there are several
people on the Squeak list (including me) who will be interested in helping.

It would be cool to see MVC in Cuis too. I think that Juan was recently
talking about re-implementing Squeak projects in Cuis, so that might make
it quite feasible.

The Squeak implementation of MVC may be carrying along some accumulated
baggage, so I'm not sure if it would be a suitable starting point for Cuis.

Dave


Reply | Threaded
Open this post in threaded view
|

Re: Event handling challenges

Trygve
In reply to this post by Karl Ramberg
This method is not called when I execute the script.

On 2020.06.15 15:57, karl ramberg wrote:
PasteUpMorphXX>>acceptDroppingMorph: morphToDrop event: evt
    (morphToDrop isKindOf: TextMorphXX) ifFalse: [
        ^morphToDrop rejectDropMorphEvent: evt].
    super acceptDroppingMorph: aPiece event: evt.


--

The essence of object orientation is that objects collaborate  to achieve a goal.
Trygve Reenskaug      
[hidden email]
Morgedalsvn. 5A       
http://folk.uio.no/trygver/
N-0378 Oslo             
http://fullOO.info
Norway                     Tel: (+47) 468 58 625



Reply | Threaded
Open this post in threaded view
|

Re: Event handling challenges

Stéphane Rollandin
In reply to this post by Stephen Pope
Not related to the topic, but since you asked what happened during the
years, I guessed I could mention that a framework for music composition
has been developed in Squeak:

http://www.zogotounga.net/comp/squeak/sqgeo.htm

Best,

Stef

Reply | Threaded
Open this post in threaded view
|

Re: Event handling challenges

Trygve
In reply to this post by Trygve
Sorry. My mistake. It WAS called.

On 2020.06.16 10:09, Trygve Reenskaug wrote:
This method is not called when I execute the script.

On 2020.06.15 15:57, karl ramberg wrote:
PasteUpMorphXX>>acceptDroppingMorph: morphToDrop event: evt
    (morphToDrop isKindOf: TextMorphXX) ifFalse: [
        ^morphToDrop rejectDropMorphEvent: evt].
    super acceptDroppingMorph: aPiece event: evt.


--

The essence of object orientation is that objects collaborate  to achieve a goal.
Trygve Reenskaug      
[hidden email]
Morgedalsvn. 5A       
http://folk.uio.no/trygver/
N-0378 Oslo             
http://fullOO.info
Norway                     Tel: (+47) 468 58 625


--

The essence of object orientation is that objects collaborate  to achieve a goal.
Trygve Reenskaug      
[hidden email]
Morgedalsvn. 5A       
http://folk.uio.no/trygver/
N-0378 Oslo             
http://fullOO.info
Norway                     Tel: (+47) 468 58 625