Smalltalk › Cuis Smalltalk

New updates: Reference Finder by Andres Valloud

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

34 messages Options

Juan Vuletich-4

New updates: Reference Finder by Andres Valloud

Hi Folks,

I've just pushed to https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev
some new updates and an updated image.

This bunch includes Andrés Valloud's great Reference Finder. A new menu
in inspectors and explorers opens this new tool. It finds instantly all
references from globals (actually from the array of special objects) to
our subject, and opens an explorer like tool with all the shortests
reference paths. This is muuuch faster then the old pointer explorer,
and it is meant to replace it.

Thanks Andrés!

Please play with this, and when we are all happy, we'll remove the old
pointer explorer from the image.

This commit also includes contributions from Germán, Ken and yours
truly. Enjoy!

Cheers,
Juan Vuletich

Ps. Maybe when this gets a bit of testing from you all it will be a good
time to call this "4.3" and do an official release. Thoughts?

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

garduino

Re: New updates: Reference Finder by Andres Valloud

Thanks!

And yes, the Reference Finder look very interesting and fast!

2013/12/28 Juan Vuletich <[hidden email]>

Hi Folks,

I've just pushed to https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev some new updates and an updated image.

This bunch includes Andrés Valloud's great Reference Finder. A new menu in inspectors and explorers opens this new tool. It finds instantly all references from globals (actually from the array of special objects) to our subject, and opens an explorer like tool with all the shortests reference paths. This is muuuch faster then the old pointer explorer, and it is meant to replace it.

Thanks Andrés!

Please play with this, and when we are all happy, we'll remove the old pointer explorer from the image.

This commit also includes contributions from Germán, Ken and yours truly. Enjoy!

Cheers,
Juan Vuletich

Ps. Maybe when this gets a bit of testing from you all it will be a good time to call this "4.3" and do an official release. Thoughts?

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

Saludos / Regards,
Germán Arduino
www.arduinosoftware.com

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

Casey Ransberger-2

Re: New updates: Reference Finder by Andres Valloud

In reply to this post by Juan Vuletich-4

I'm inclined to take the zoom button off of our SystemWindows. It doesn't work right and MVC lived without it just fine. It can make a triumphant return later when it works.

Seems better to ship without the button than with the button broken.

Any objections to this?

> On Dec 28, 2013, at 2:35 PM, Juan Vuletich <[hidden email]> wrote:
>
> Hi Folks,
>
> I've just pushed to https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev some new updates and an updated image.
>
> This bunch includes Andrés Valloud's great Reference Finder. A new menu in inspectors and explorers opens this new tool. It finds instantly all references from globals (actually from the array of special objects) to our subject, and opens an explorer like tool with all the shortests reference paths. This is muuuch faster then the old pointer explorer, and it is meant to replace it.
>
> Thanks Andrés!
>
> Please play with this, and when we are all happy, we'll remove the old pointer explorer from the image.
>
> This commit also includes contributions from Germán, Ken and yours truly. Enjoy!
>
> Cheers,
> Juan Vuletich
>
> Ps. Maybe when this gets a bit of testing from you all it will be a good time to call this "4.3" and do an official release. Thoughts?
>
> _______________________________________________
> 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

KenDickey

Re: New updates: Reference Finder by Andres Valloud

On Sun, 29 Dec 2013 01:35:16 -0800
Casey Ransberger <[hidden email]> wrote:

> I'm inclined to take the zoom button off of our SystemWindows. It doesn't work right and MVC lived without it just fine. It can make a triumphant return later when it works.
..
> Any objections to this?

If you mean the '+' button, I have only used it a couple of times and only for ReferenceBrowser and MessageTally.

I could certainly live without it.

-KenD

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

-KenD

garduino

Re: New updates: Reference Finder by Andres Valloud

On the contrary here....I use the maximize button all the time, in the Browser window, Message Names, really in most of the windows.

Cheers.

2013/12/29 Ken Dickey <[hidden email]>

On Sun, 29 Dec 2013 01:35:16 -0800
Casey Ransberger <[hidden email]> wrote:

> I'm inclined to take the zoom button off of our SystemWindows. It doesn't work right and MVC lived without it just fine. It can make a triumphant return later when it works.

..
> Any objections to this?

If you mean the '+' button, I have only used it a couple of times and only for ReferenceBrowser and MessageTally.

I could certainly live without it.

-KenD

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

Saludos / Regards,
Germán Arduino
www.arduinosoftware.com

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

Casey Ransberger-2

Re: New updates: Reference Finder by Andres Valloud

Unless something's changed recently, German, it's exactly that and nothing more: maximize a window and then click it again. Nothing happens. It's broken and that's not a nice thing to do to new users. We should rip it out.

On Sun, Dec 29, 2013 at 9:17 AM, Germán Arduino <[hidden email]> wrote:

On the contrary here....I use the maximize button all the time, in the Browser window, Message Names, really in most of the windows.

Cheers.

2013/12/29 Ken Dickey <[hidden email]>

On Sun, 29 Dec 2013 01:35:16 -0800
Casey Ransberger <[hidden email]> wrote:

> I'm inclined to take the zoom button off of our SystemWindows. It doesn't work right and MVC lived without it just fine. It can make a triumphant return later when it works.

..
> Any objections to this?

If you mean the '+' button, I have only used it a couple of times and only for ReferenceBrowser and MessageTally.

I could certainly live without it.

-KenD

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

--
Saludos / Regards,
Germán Arduino
www.arduinosoftware.com

_______________________________________________
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

garduino

Re: New updates: Reference Finder by Andres Valloud

And what more should happen? If I press a maximize button I only expect that the window get maximized ...

I understand that you mean that pressing again the + button should make that the window is restored to its original size, right?

I remember Juan explained that is a thing not solved yet only for time reasons, but I still think that the maximize button is useful.

2013/12/29 Casey Ransberger <[hidden email]>

Unless something's changed recently, German, it's exactly that and nothing more: maximize a window and then click it again. Nothing happens. It's broken and that's not a nice thing to do to new users. We should rip it out.

On Sun, Dec 29, 2013 at 9:17 AM, Germán Arduino <[hidden email]> wrote:

On the contrary here....I use the maximize button all the time, in the Browser window, Message Names, really in most of the windows.

Cheers.

2013/12/29 Ken Dickey <[hidden email]>

On Sun, 29 Dec 2013 01:35:16 -0800
Casey Ransberger <[hidden email]> wrote:

> I'm inclined to take the zoom button off of our SystemWindows. It doesn't work right and MVC lived without it just fine. It can make a triumphant return later when it works.

..
> Any objections to this?

If you mean the '+' button, I have only used it a couple of times and only for ReferenceBrowser and MessageTally.

I could certainly live without it.

-KenD

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

--
Saludos / Regards,
Germán Arduino
www.arduinosoftware.com

_______________________________________________
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

Saludos / Regards,
Germán Arduino
www.arduinosoftware.com

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

Casey Ransberger-2

Re: New updates: Reference Finder by Andres Valloud

Yes, obviously the window should return to it's previous size and position.

My concern is that shipping releases with obvious UX problems might scare off newcomers. At least with the button removed, the user will be able to intuit manual resizing.

On Dec 30, 2013, at 7:58 AM, Germán Arduino <[hidden email]> wrote:

And what more should happen? If I press a maximize button I only expect that the window get maximized ...

I understand that you mean that pressing again the + button should make that the window is restored to its original size, right?

I remember Juan explained that is a thing not solved yet only for time reasons, but I still think that the maximize button is useful.

2013/12/29 Casey Ransberger <[hidden email]>

Unless something's changed recently, German, it's exactly that and nothing more: maximize a window and then click it again. Nothing happens. It's broken and that's not a nice thing to do to new users. We should rip it out.

On Sun, Dec 29, 2013 at 9:17 AM, Germán Arduino <[hidden email]> wrote:

On the contrary here....I use the maximize button all the time, in the Browser window, Message Names, really in most of the windows.

Cheers.

2013/12/29 Ken Dickey <[hidden email]>

On Sun, 29 Dec 2013 01:35:16 -0800
Casey Ransberger <[hidden email]> wrote:

> I'm inclined to take the zoom button off of our SystemWindows. It doesn't work right and MVC lived without it just fine. It can make a triumphant return later when it works.

..
> Any objections to this?

If you mean the '+' button, I have only used it a couple of times and only for ReferenceBrowser and MessageTally.

I could certainly live without it.

-KenD

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

--
Saludos / Regards,
Germán Arduino
www.arduinosoftware.com

_______________________________________________
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

--
Saludos / Regards,
Germán Arduino
www.arduinosoftware.com

_______________________________________________
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

KenDickey

Grow Button [WAS Re: New updates: Reference Finder..]

On Mon, 30 Dec 2013 20:25:05 -0800
Casey Ransberger <[hidden email]> wrote:

> Yes, obviously the window should return to it's previous size and position.

So why not just make the window do that? [See attached].

Easier than wrangling (less fun perhaps ;^)

-KenD

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

SystemWindow-fullScreen.st (1K) Download Attachment

-KenD

Casey Ransberger-2

Re: Grow Button [WAS Re: New updates: Reference Finder..]

My recollection (which could be wrong as it's been rather a long time) was that Morphic 3 for some reason would likely see us removing the solution, so we weren't putting in the effort.

I seriously considered fixing it, but I would have been happy enough with manual resize.

> On Dec 30, 2013, at 8:57 PM, Ken Dickey <[hidden email]> wrote:
>
> On Mon, 30 Dec 2013 20:25:05 -0800
> Casey Ransberger <[hidden email]> wrote:
>
>> Yes, obviously the window should return to it's previous size and position.
>
> So why not just make the window do that? [See attached].
>
> Easier than wrangling (less fun perhaps ;^)
>
> -KenD
> <SystemWindow-fullScreen.st>
> _______________________________________________
> 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

Hannes Hirzel

Re: Grow Button [WAS Re: New updates: Reference Finder..]

Ken, your method

SystemWindow>>fullScreen

works fine.
Thank you!

--Hannes

'From Cuis 4.2 of 25 July 2013 [latest update: #1910] on 30 December
2013 at 8:44:57.613143 pm'!

!SystemWindow methodsFor: 'menu' stamp: 'KenD 12/30/2013 20:44'!
fullScreen
"Zoom Window to Full World size with possible DeskMargins"

"SystemWindow fullScreen"

| left right possibleBounds |
(self hasProperty: #originalBounds)
ifFalse: [ "Expand"
self setProperty: #originalBounds toValue: self morphBoundsInWorld.
left := right := 0.
possibleBounds := (RealEstateAgent maximumUsableAreaInWorld: self world)
insetBy: (left @ 0 corner: right @ 0).
(Preferences fullScreenLeavesDeskMargins)
ifTrue: [ possibleBounds := possibleBounds insetBy: 22 ].
self morphBoundsInWorld: possibleBounds
]
ifTrue: [ "Contract"
possibleBounds := self valueOfProperty: #originalBounds.
self removeProperty: #originalBounds.
self morphBoundsInWorld: possibleBounds
]! !

On 12/31/13, Casey Ransberger <[hidden email]> wrote:

> My recollection (which could be wrong as it's been rather a long time) was
> that Morphic 3 for some reason would likely see us removing the solution, so
> we weren't putting in the effort.
>
> I seriously considered fixing it, but I would have been happy enough with
> manual resize.
>
>> On Dec 30, 2013, at 8:57 PM, Ken Dickey <[hidden email]> wrote:
>>
>> On Mon, 30 Dec 2013 20:25:05 -0800
>> Casey Ransberger <[hidden email]> wrote:
>>
>>> Yes, obviously the window should return to it's previous size and
>>> position.
>>
>> So why not just make the window do that? [See attached].
>>
>> Easier than wrangling (less fun perhaps ;^)
>>
>> -KenD
>> <SystemWindow-fullScreen.st>
>> _______________________________________________
>> 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
>

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

KenDickey

Re: Grow Button [WAS Re: New updates: Reference Finder..]

On Tue, 31 Dec 2013 11:01:42 +0000
"H. Hirzel" <[hidden email]> wrote:

> Ken, your method
>
> SystemWindow>>fullScreen
>
>
> works fine.
> Thank you!

You are very welcome.

Needs a better name though. :)

-KenD

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

-KenD

Hannes Hirzel

Re: Grow Button [WAS Re: New updates: Reference Finder..]

What about

#toggleMaximumUsableArea

or
#toggleMaximumPossibleBounds

?

On 12/31/13, Ken Dickey <[hidden email]> wrote:

> On Tue, 31 Dec 2013 11:01:42 +0000
> "H. Hirzel" <[hidden email]> wrote:
>
>> Ken, your method
>>
>> SystemWindow>>fullScreen
>>
>>
>> works fine.
>> Thank you!
>
> You are very welcome.
>
> Needs a better name though. :)
>
> -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

KenDickey

Re: Grow Button [WAS Re: New updates: Reference Finder..]

On Tue, 31 Dec 2013 15:32:49 +0000
"H. Hirzel" <[hidden email]> wrote:

> What about
>
> #toggleMaximumUsableArea
>
> or
> #toggleMaximumPossibleBounds
>
> ?

A bit long. How about #toggleFullBounds ?

Other suggestions?

Casey? Juan? ..

-KenD

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

-KenD

Casey Ransberger-2

Re: Grow Button [WAS Re: New updates: Reference Finder..]

#toggleFullBounds sounds great. Either that or #thanksKen.

Interesting that your solution uses the properties mechanism. I've never touched that. I'd have probably given SystemWindow a couple of instance variables to cache location and extent. Forgive me for saying that it's a very Lispy way to go about things! :)

Anyway I'm pretty sure users will have a better experience with this in than without. Unless someone can find an obvious problem with the design (the code looks pretty clean to me. Short and sweet.)

Especially when looking at your solution, in its brevity, I'm kind of annoyed with myself that I didn't just solve it and move on. Mea culpa and such.

Thanks Ken. You fixed my favorite bug.

--C

On Tue, Dec 31, 2013 at 7:47 AM, Ken Dickey <[hidden email]> wrote:

On Tue, 31 Dec 2013 15:32:49 +0000
"H. Hirzel" <[hidden email]> wrote:

> What about
>
> #toggleMaximumUsableArea
>
> or
> #toggleMaximumPossibleBounds
>
> ?

A bit long. How about #toggleFullBounds ?

Other suggestions?

Casey? Juan? ..

-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

KenDickey

Re: Grow Button [WAS Re: New updates: Reference Finder..]

On Tue, 31 Dec 2013 08:40:54 -0800
Casey Ransberger <[hidden email]> wrote:

> #toggleFullBounds sounds great. Either that or #thanksKen.

Shorter than #youAreWelcomeCasey ;^)

> Interesting that your solution uses the properties mechanism. I've never
> touched that. I'd have probably given SystemWindow a couple of instance
> variables to cache location and extent.

My model is that Classes use messages/methods/iVars
but individual instances use events/handlers/properties.

In particular, part of my list of past sins includes writing code in and for MultiMedia authoring environments. MM authoring -- particularly for media centric people who are not programmers -- tends to be more prototype based than class based.

One starts with a bunch of media pallets and explorers, splats media on the stage, adds behaviors, ... Authoring tends to me more graphical by nature. [See mTropolis UI examples below].

One of the things I am thinking about is pushing Morphic toward a more direct/graphic style of authoring.

One change to think about is making some tests more instance based.

Why have an entire class of instances respond to some message when only a few instances need to? An extra subclass with just a few methods.

Simple (possibly useless) example.

We could change some methods to look for properties.

Say

Morph>>allowsSubmorphDrag
^ self hasProperty: #allowsSubMorphDrag

So a class can still short-circuit this by

SomeSubclassOfMorph>>>>allowsSubmorphDrag
^true

With no bad effects -- all the current code still works! ;^)

But now one can have various instances support dragging submorphs without having to create a special subclass just to do this. Just dynamically add (or remove!) a property.

Anyway, this is the kind of stuff I am playing with in the background.

Cheers,
-KenD

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

Logic+Extras-Palettes.png (195K) Download Attachment

MouseMessage-When.png (21K) Download Attachment

Messenger-dialog.png (56K) Download Attachment

ImageEffect-dialog.png (55K) Download Attachment

Behavior-score3.png (163K) Download Attachment

-KenD

Casey Ransberger-2

Direct interfaces and HyperCard (Was Re: Grow Button [WAS Re: New updates: Reference Finder..])

If only Self was popular. Direct user interface construction is one of my favorite ideas. Sadly no one in the Smalltalk community seems to have thought all that hard about how to do it. Every time I bring up the Self object transporter, it seems like there's a rack of people saying "don't." It works in Self?

I've been looking very seriously at Ted Kaehler's DynaBook Junior spec and thinking about doing an implementation in Cuis, which is at least a start. A HyperCard analogue.

Of course there's a mostly unloved implementation sitting in Squeak thanks to Ted K. But it won't work in Cuis. We need a new implementation.

It's just it seems like no one wants even that.

Damned fools,

--C

> On Dec 31, 2013, at 2:08 PM, Ken Dickey <[hidden email]> wrote:
>
> On Tue, 31 Dec 2013 08:40:54 -0800
> Casey Ransberger <[hidden email]> wrote:
>
>> #toggleFullBounds sounds great. Either that or #thanksKen.
>
> Shorter than #youAreWelcomeCasey ;^)
>
>> Interesting that your solution uses the properties mechanism. I've never
>> touched that. I'd have probably given SystemWindow a couple of instance
>> variables to cache location and extent.
>
> My model is that Classes use messages/methods/iVars
> but individual instances use events/handlers/properties.
>
> In particular, part of my list of past sins includes writing code in and for MultiMedia authoring environments. MM authoring -- particularly for media centric people who are not programmers -- tends to be more prototype based than class based.
>
> One starts with a bunch of media pallets and explorers, splats media on the stage, adds behaviors, ... Authoring tends to me more graphical by nature. [See mTropolis UI examples below].
>
> One of the things I am thinking about is pushing Morphic toward a more direct/graphic style of authoring.
>
> One change to think about is making some tests more instance based.
>
> Why have an entire class of instances respond to some message when only a few instances need to? An extra subclass with just a few methods.
>
> Simple (possibly useless) example.
>
> We could change some methods to look for properties.
>
> Say
>
> Morph>>allowsSubmorphDrag
> ^ self hasProperty: #allowsSubMorphDrag
>
> So a class can still short-circuit this by
>
> SomeSubclassOfMorph>>>>allowsSubmorphDrag
> ^true
>
> With no bad effects -- all the current code still works! ;^)
>
> But now one can have various instances support dragging submorphs without having to create a special subclass just to do this. Just dynamically add (or remove!) a property.
>
> Anyway, this is the kind of stuff I am playing with in the background.
>
> Cheers,
> -KenD
> <Logic+Extras-Palettes.png>
> <Logic+Extras-Palettes.png>
> <MouseMessage-When.png>
> <Messenger-dialog.png>
> <ImageEffect-dialog.png>
> <Behavior-score3.png>
> _______________________________________________
> 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

KenDickey

Re: Direct interfaces and HyperCard (Was Re: Grow Button [WAS Re: New updates: Reference Finder..])

On Tue, 31 Dec 2013 14:23:07 -0800
Casey Ransberger <[hidden email]> wrote:

> Damned fools,

Hey, I'm a damned fool myself.

But I only have to please myself.

And I have Cuis! Heh, heh! ;^)

-KenD

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

-KenD

Juan Vuletich-4

Re: Grow Button [WAS Re: New updates: Reference Finder..]

In reply to this post by KenDickey

Thanks Ken! Find it in the latest commit.

Cheers,
Juan Vuletich

On 12/31/2013 1:57 AM, Ken Dickey wrote:

On Mon, 30 Dec 2013 20:25:05 -0800
Casey Ransberger [hidden email] wrote:

Yes, obviously the window should return to it's previous size and position.

So why not just make the window do that?  [See attached].

Easier than wrangling (less fun perhaps ;^)

-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

Juan Vuletich-4

Re: Grow Button [WAS Re: New updates: Reference Finder..]

In reply to this post by KenDickey

On 12/31/2013 7:08 PM, Ken Dickey wrote:

> ...
> My model is that Classes use messages/methods/iVars
> but individual instances use events/handlers/properties.
>
> In particular, part of my list of past sins includes writing code in and for MultiMedia authoring environments. MM authoring -- particularly for media centric people who are not programmers -- tends to be more prototype based than class based.
>
> One starts with a bunch of media pallets and explorers, splats media on the stage, adds behaviors, ... Authoring tends to me more graphical by nature. [See mTropolis UI examples below].
>
> One of the things I am thinking about is pushing Morphic toward a more direct/graphic style of authoring.
>
> One change to think about is making some tests more instance based.
>
> Why have an entire class of instances respond to some message when only a few instances need to? An extra subclass with just a few methods.
>
> Simple (possibly useless) example.
>
> We could change some methods to look for properties.
>
> Say
>
> Morph>>allowsSubmorphDrag
> ^ self hasProperty: #allowsSubMorphDrag
>
> So a class can still short-circuit this by
>
> SomeSubclassOfMorph>>>>allowsSubmorphDrag
> ^true
>
> With no bad effects -- all the current code still works! ;^)
>
> But now one can have various instances support dragging submorphs without having to create a special subclass just to do this. Just dynamically add (or remove!) a property.
>
> Anyway, this is the kind of stuff I am playing with in the background.
>
> Cheers,
> -KenD
>

I like this Ken. This kind of ideas could really help an end user
authoring system. Feel free to submit stuff like this for inclusion. All
we need is to include some method comments, to let people know that this
is not yet finished, explain the idea, etc.

Cheers,
Juan Vuletich

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