A process proposal for 3.10
Locked
1234567
1234567
Re: Morphic is to MVC as Traits are to Classes (was: Re: Removing Morphic)
 
|
On Oct 18, 2006, at 9:31 PM, Andreas Raab wrote: > although Nathanael solved the harder problem he also solved the > less interesting problem Ok, I'll bite. What was the easier but more interesting problem? Colin |
Re: Morphic is to MVC as Traits are to Classes (was: Re: Removing Morphic)
|
|
Colin Putney wrote:
> > On Oct 18, 2006, at 9:31 PM, Andreas Raab wrote: > >> although Nathanael solved the harder problem he also solved the less >> interesting problem > > Ok, I'll bite. What was the easier but more interesting problem? Composing objects (aspects) instead of namespaces. What we were really looking for is some system-level representation for users combining behaviors. If you've ever seen Director's drag and drop behaviors you know what I mean. We want to be able to do the same, e.g., take a behavior drop this onto an object and have the object do "something sensible" with the behavior. The easier problem is indeed to say we'll just take the behavior as an object in itself and simply expose a subset of its interface to the container and then figure out how to interact with it. The less interesting (but harder) problem that Nathanael solved was how to take the entire interface and embed it into the container. Cheers, - Andreas |
|
|
In reply to this post by Ron Teitelbaum
>What is the community's feeling about removing Morphic and replacing it with
Currently Tweak's UI "feels" slow for me. And it eats 100% of processor when Tweak is full screen mode in squeak. -- Vaidotas Didžbalis, |
|
|
In reply to this post by keith1y
Further to my little idea, I have improved 'Installer' to be able to
grab files straight from mantis. Check out this example script which can be doit-ed in a workspace: http://smallwiki.unibe.ch/smallwiki/pier/examplescript/ Keith > > 2. Present a wiki page consisting of an install script > > This wiki needs the following features > - full support for "history of page" and authors of edits. > - diffs between page versions (if possible) > - wiki links within preformatted text for the script to be annotated. > > Send instant messages to your online friends http://uk.messenger.yahoo.com |
Re: Re: A process proposal for 3.10
|
|
The release process needs to be more automated, and Keith Hodges' idea
seems pretty reasonable. -Ralph Johnson |
|
|
In reply to this post by Giovanni Giorgi-3
On Wed, Oct 18, 2006 at 03:03:32PM +0200, Giovanni Giorgi wrote:
> As I have understood, there is a new eToy implementation in progress > inside Tweak. I am not sure how relevant this is, but Scratch seems to have many of the same goals and purposes as EToys, and is under active development. Perhaps it could be "The New eToys"? http://scratch.mit.edu/ -- Matthew Fulmer |
Re: Scratch (was Re: Removing Etoys)
|
|
Am 19.10.2006 um 18:25 schrieb Matthew Fulmer:
> On Wed, Oct 18, 2006 at 03:03:32PM +0200, Giovanni Giorgi wrote: >> As I have understood, there is a new eToy implementation in >> progress >> inside Tweak. > > I am not sure how relevant this is, but Scratch seems to have > many of the same goals and purposes as EToys, and is under > active development. Perhaps it could be "The New eToys"? > http://scratch.mit.edu/ Not quite. Scratch is awesome, but it's not etoys. The very fact that there is a distinction between authoring tools and the scripted object makes it different. One of the fundamentals of etoys is that "authoring is always on" and that you can script *everything*. The Scratch beta is open now, btw, so have a try: http://weblogs.media.mit.edu/llk/scratch/archives/2006/10/download.html - Bert - |
Re: Re: A process proposal for 3.10
|
|
In reply to this post by Ralph Johnson
I want to add my 2 cents to the discussion.
Keith Hodges' idea sounds good, but maybe making a full featured test server takes a big effort. I want to propose a more pragmatic solution, based in my experience at Mercap. At Mercap, before integrating changes to the main thunk we run some tests, that are categorized as follows: Tests that covers functionality: - Unit Tests: There are a lot of them (currently 11000+), they are really unitary (an example are the Aconcagua/Chalten packages published by Hernan/Maxi T), and we run them very often during development - "User Story" Tests: We call in that way to the tests focused in "user stories", they touches a lot of "modules" in the system, just to cover an "user story". - Functional Tests: We call in that way to the tests that cover the UI. They are really slow, and we don't run them very often. Tests for "coding standards" (I don't know how to call them in English): - "Coding standard tests": They tests how applications are named (more or less the equivalent to Squeak "package" or "System Categories"), how classes are named, if tests classes are in the wrong application.. etc - "Code Quality": They check a defined set of SmallLint rules, and test coverage (we only check for 100% coverage of some applications, because this test can be an overkill to keep green) - "Architecture tests": They test things like: application dependencies (In Squeak could be if an MC package declares all the dependencies), if there are invalid references in the System dictionary, if all methods are well compiled, etc The names of the taxonomy are somewhat arbitrary but the important points to me are: 1. In Squeak the unit tests take too long, so programmers are not encouraged to run them very often 2. The taxonomy of unit tests (they are different test suites) allows us to run selected parts when necessary 3. The "coding standards" are really useful, because they allow us to catch potential bugs early (a sender of #halt, senders of a message that is bogus or deprecated, unimplemented subclassResponsibility, etc) Translated to Squeak: - I think that should be necessary to split the tests in different categories. Unit tests should be really unitary, and fast. Other tests that take a lot of time should be in other test suite. - It would be cool to make a tool to do automated package testing on release. An use case could be more or less like this: 1) A programmer wants to release an MC package, so him goes to the World Menu an chooses something like a "Package Release Wizard" ;) 2) "Package Release Wizard" takes the package, and runs all the Squeak unit tests, and them runs some "coding standards" tests on the package. 3) If the tests pass, releases the package. 4) The programmer could release the package by hand even when the tests fails but him is aware of this, and should be comment it in the change log. I think that this approach is more simple that the test server. The "Package Release Wizard" could be initially an object that ask for the package name and instantiates an abstract test case for that package. The main problem to me, is that unit tests in Squeak are not really unitary. So the Squeak "programming community" doesn't have the practice to run them more often. Regards. Diego.- On 10/19/06, Ralph Johnson <[hidden email]> wrote: > The release process needs to be more automated, and Keith Hodges' idea > seems pretty reasonable. > > -Ralph Johnson > > |
|
|
In reply to this post by Ron Teitelbaum
Is the morphic concept a bad one, or is the implimentation just problematic
at the moment? I'm just asking, since you seem to be interested in ditching Morphic in favour of Tweek. Or is this just an issue of; it's easier to just replace then fix? I'm just curious, not taking a side. >From: "Ron Teitelbaum" <[hidden email]> >Reply-To: [hidden email], The general-purpose Squeak developers >list<[hidden email]> >To: "'The general-purpose Squeak developers >list'"<[hidden email]> >Subject: Removing Morphic (was: Removing Etoys (was Re: A process >proposalfor 3.10)) >Date: Wed, 18 Oct 2006 21:14:52 -0400 > >These are good reasons to remove eToys, if the removal of the application >lends to nominal improvements in Morphic. If the goal is to clean up and >re-factor without a goal to improve Morphic, I would still vote against it. > > >I disagree with Squeak should not include applications, but I won't argue >the point. > >What is the community's feeling about removing Morphic and replacing it >with >Tweak so that squeak can run both Tweak, Croquet, and can be a platform for >new versions hopefully better packaged eToys? We need to be thinking about >folding in and adopting both the private and research functionality that is >currently being developed. How difficult would it be to modify current >toolBuilder tools to use Tweak instead? Would Andreas even agree that this >is a good idea and agree to maintain Tweak in Squeak? What is the >possibility that if we adopt Tweak that current Croquet development could >also be folded in? > >(Putting on my flame proof suit) > >Ron Teitelbaum > > > > From: [hidden email] > > Sent: Wednesday, October 18, 2006 9:56 AM > > > > The ones I can think of right now are: > > > > 1) Squeak should not include applications. And eToys, (for a Smalltalk > > programmer) is an application. > > > > 2) eToys code is everywhere in the system, not only in eToys classes. > > > > 3) the impact of eToys in Morphic is terrible. Just download my image >from > > http://www.jvuletich.org/Squeak/EToysFreeMorphic/EtoysFreeMorphic.html >and > > browse a bit Morph or any core Morphic classes. Then compare with 3.9. > > > > 4) Cleaning (or refactoring or redesigning) Morphic is almost impossible > > with eToys around. > > > > 5) eToys is not being maintained. People who use it, actually use other > > Squeak distributions, like Squeakland and SmallLand. > > > > I'm sure there are others. > > Cheers, > > Juan Vuletich > > > > > This ignores the reasons that Juan wants to remove EToys in the first > > > place. > > > > > > Juan, I'm sure I've read these reasons elsewhere, but could you > > > please repeat them for the benefit of this thread? > > > > > > Thanks, > > > Josh > > > > > > > > > > > > On Oct 18, 2006, at 9:03 AM, Giovanni Giorgi wrote: > > > > > >> As I have understood, there is a new eToy implementation in > > >> progress inside Tweak. > > >> We can wait until this implementation is a bit stable. > > >> When this will be true, the other part depending from eToy1 will be > > >> able to migrate to eToy2. > > >> After that we can start to deliver an official squeak distribution > > >> with eToy2 and eToy1 side by side. > > >> Then after w ahile we can start to evict eToy1. > > >> > > >> This will save some efforts, at cost of a bit larger image (but > > >> avoiding some hours of work can be a good exchange ;) > > >> > > >> > > >> On 10/18/06, [hidden email] <[hidden email]> wrote: Of > > >> course. > > >> > > >> That's why I'm asking the Board to decide, or advice. > > >> > > >> Cheers, > > >> Juan Vuletich > > >> > > >> > As Juan wrote, removing Etoys from Morphic while keeping it both > > >> > loadable and functioning properly is futile. > > >> > > > >> > So either you leave it in, or you consciously give up compatibility > > >> > with anyone using Etoys now, like the squeakland distribution, OLPC > > >> > distribution, Smalland, the Spanish LinEx version, the Japanese > > >> > Nihongo version etc. Already synchronizing Squeakland and 3.8 was > > >> > hard, nobody has tried yet for 3.9, but this would make it outright > > >> > impossible. > > >> > > > >> > I'm *not* saying you should not do this, but please be aware of the > > >> > possible consequences. > > >> > > > >> > > >> > > >> > > >> > > >> > > >> > > >> -- > > >> "Just Design It" -- GG > > >> Software Architect > > >> http://www.objectsroot.com/ > > >> > > > > > > > > > > > > > > > > _________________________________________________________________ Get today's hot entertainment gossip http://movies.msn.com/movies/hotgossip?icid=T002MSN03A07001 |
|
|
In reply to this post by keith1y
>From: Keith Hodges <[hidden email]> >Reply-To: The general-purpose Squeak developers >list<[hidden email]> >To: [hidden email], The general-purpose Squeak developers >list<[hidden email]> >Subject: Re: Removing Morphic >Date: Thu, 19 Oct 2006 02:33:44 +0100 > >Personally I have never got on with morphic and would much rather see >something elegant in its place like Model-View-Presenter as used >superlatively in Dolphin. > This is something I was wondering about. I was playing with Dolphin before squeak (still will for windows things) and I thought the MVP concept was a good one. I haven't had time to dig through all the papers, etc. to find out if Morphic is a step backward or forward. What I mean by that is; Multiple inheritance, I would consider a technological step back, but traits are a big step forward. _________________________________________________________________ Stay in touch with old friends and meet new ones with Windows Live Spaces http://clk.atdmt.com/MSN/go/msnnkwsp0070000001msn/direct/01/?href=http://spaces.live.com/spacesapi.aspx?wx_action=create&wx_url=/friends.aspx&mkt=en-us |
|
|
In reply to this post by J J-6
Hi J J,
I don't know either. For me Morphic IS EToys. For others Morphic IS toolBuilder. For me Tweak is Croquet. It appears that for others Tweak is dead and too slow, (but that seems very short sighted since if Tweak IS Croquet then there is major development going on which we could all benefit from) I asked the questions which no one wants to answer. Can Tweak be ToolBuilder? How difficult would it be to redo the tools in Tweak? Can we integrate Tweak and will Andreas support it in Squeak? Can we integrate some of the Croquet functionality? If EToys is too enmeshed with Morphic and Tweak is clean shouldn't we adopt Tweak as a way of cleaning up (wasn't that the whole goal of tweak?) Can we leave both and transition to Tweak? My only goal is community bridges and expanding the opportunities for people to contribute and resources for people to use. (I would also like to see better wxSqueak support!) These are just questions not suggestions! I guess it's safe to take the flame proof suit off now? Ron Teitelbaum > From: J J > Sent: Friday, October 20, 2006 2:26 PM > > Is the morphic concept a bad one, or is the implimentation just > problematic > at the moment? > > I'm just asking, since you seem to be interested in ditching Morphic in > favour of Tweek. Or is this just an issue of; it's easier to just replace > then fix? > > I'm just curious, not taking a side. > > > >From: "Ron Teitelbaum" <[hidden email]> > >Reply-To: [hidden email], The general-purpose Squeak developers > >list<[hidden email]> > >To: "'The general-purpose Squeak developers > >list'"<[hidden email]> > >Subject: Removing Morphic (was: Removing Etoys (was Re: A process > >proposalfor 3.10)) > >Date: Wed, 18 Oct 2006 21:14:52 -0400 > > > >These are good reasons to remove eToys, if the removal of the application > >lends to nominal improvements in Morphic. If the goal is to clean up and > >re-factor without a goal to improve Morphic, I would still vote against > it. > > > > > >I disagree with Squeak should not include applications, but I won't argue > >the point. > > > >What is the community's feeling about removing Morphic and replacing it > >with > >Tweak so that squeak can run both Tweak, Croquet, and can be a platform > for > >new versions hopefully better packaged eToys? We need to be thinking > about > >folding in and adopting both the private and research functionality that > is > >currently being developed. How difficult would it be to modify current > >toolBuilder tools to use Tweak instead? Would Andreas even agree that > this > >is a good idea and agree to maintain Tweak in Squeak? What is the > >possibility that if we adopt Tweak that current Croquet development could > >also be folded in? > > > >(Putting on my flame proof suit) > > > >Ron Teitelbaum > > > > > > > From: [hidden email] > > > Sent: Wednesday, October 18, 2006 9:56 AM > > > > > > The ones I can think of right now are: > > > > > > 1) Squeak should not include applications. And eToys, (for a Smalltalk > > > programmer) is an application. > > > > > > 2) eToys code is everywhere in the system, not only in eToys classes. > > > > > > 3) the impact of eToys in Morphic is terrible. Just download my image > >from > > > http://www.jvuletich.org/Squeak/EToysFreeMorphic/EtoysFreeMorphic.html > >and > > > browse a bit Morph or any core Morphic classes. Then compare with 3.9. > > > > > > 4) Cleaning (or refactoring or redesigning) Morphic is almost > impossible > > > with eToys around. > > > > > > 5) eToys is not being maintained. People who use it, actually use > other > > > Squeak distributions, like Squeakland and SmallLand. > > > > > > I'm sure there are others. > > > Cheers, > > > Juan Vuletich > > > > > > > This ignores the reasons that Juan wants to remove EToys in the > first > > > > place. > > > > > > > > Juan, I'm sure I've read these reasons elsewhere, but could you > > > > please repeat them for the benefit of this thread? > > > > > > > > Thanks, > > > > Josh > > > > > > > > > > > > > > > > On Oct 18, 2006, at 9:03 AM, Giovanni Giorgi wrote: > > > > > > > >> As I have understood, there is a new eToy implementation in > > > >> progress inside Tweak. > > > >> We can wait until this implementation is a bit stable. > > > >> When this will be true, the other part depending from eToy1 will be > > > >> able to migrate to eToy2. > > > >> After that we can start to deliver an official squeak distribution > > > >> with eToy2 and eToy1 side by side. > > > >> Then after w ahile we can start to evict eToy1. > > > >> > > > >> This will save some efforts, at cost of a bit larger image (but > > > >> avoiding some hours of work can be a good exchange ;) > > > >> > > > >> > > > >> On 10/18/06, [hidden email] <[hidden email]> wrote: Of > > > >> course. > > > >> > > > >> That's why I'm asking the Board to decide, or advice. > > > >> > > > >> Cheers, > > > >> Juan Vuletich > > > >> > > > >> > As Juan wrote, removing Etoys from Morphic while keeping it both > > > >> > loadable and functioning properly is futile. > > > >> > > > > >> > So either you leave it in, or you consciously give up > compatibility > > > >> > with anyone using Etoys now, like the squeakland distribution, > OLPC > > > >> > distribution, Smalland, the Spanish LinEx version, the Japanese > > > >> > Nihongo version etc. Already synchronizing Squeakland and 3.8 was > > > >> > hard, nobody has tried yet for 3.9, but this would make it > outright > > > >> > impossible. > > > >> > > > > >> > I'm *not* saying you should not do this, but please be aware of > the > > > >> > possible consequences. > > > >> > > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> -- > > > >> "Just Design It" -- GG > > > >> Software Architect > > > >> http://www.objectsroot.com/ > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > _________________________________________________________________ > Get today's hot entertainment gossip > http://movies.msn.com/movies/hotgossip?icid=T002MSN03A07001 > > |
|
|
>From: "Ron Teitelbaum" <[hidden email]>
>Reply-To: [hidden email], The general-purpose Squeak developers >list<[hidden email]> >To: "'The general-purpose Squeak developers >list'"<[hidden email]> >Subject: Removing Morphic >Date: Fri, 20 Oct 2006 14:47:52 -0400 > >Hi J J, > >I don't know either. For me Morphic IS EToys. For others Morphic IS >toolBuilder. For me Tweak is Croquet. It appears that for others Tweak is >dead and too slow, (but that seems very short sighted since if Tweak IS >Croquet then there is major development going on which we could all benefit >from) > Well, I haven't looked at the GUI stuff at all yet (well very little). For me the GUI was my interface as a devoloper and I don't care much how it looks, so long as it's fast and not distracting. But thanks for the breakdown on those things, so if I get time I know what things to go read about. >My only goal is community bridges and expanding the opportunities for >people >to contribute and resources for people to use. I agree. It seems the more powerful languages (Smalltalk and Lisp) allow one to easily make a "dialect" for the problems they are solving and program in that. The problem seems to be, they don't come back. Just like in spoken dialects, it doesn't take long for forks to happen that bar the way back (it is interesting to watch german speakers trying to decode the swiss dialect. :). _________________________________________________________________ Try the next generation of search with Windows Live Search today! http://imagine-windowslive.com/minisites/searchlaunch/?locale=en-us&source=hmtagline |
|
|
In reply to this post by Andreas.Raab
>From: Andreas Raab <[hidden email]>
>Reply-To: The general-purpose Squeak developers >list<[hidden email]> >To: The general-purpose Squeak developers >list<[hidden email]> >Subject: Morphic is to MVC as Traits are to Classes (was: Re: >RemovingMorphic) >Date: Wed, 18 Oct 2006 19:28:52 -0700 > >Keith Hodges wrote: >For example, I can send the message #bounds to the costume and get the >composite bounds for the entire costume or I can send the message #bounds >to the text aspect and get only the text bounds. It is always clear what I >mean since I have to specify either "costume bounds" or "costume text >bounds" and it never changes, neither in the aspect nor the costume. >Compare this to a traits solution where I'd have to rename one of the two. >Which one is clearer? The one where I say "bounds" when I implement a trait >and "textBounds" when I use it? Where "show me the senders of #textBounds" >finds the senders in the composition but not in the trait? Or where >"senders of bounds" also lists all the senders of #textBounds since they >were once called #bounds? I think the answer is clear. > I thought traits were only for the specific situation where single inheritance wont work. The paper I read described them as being a better solution then multiple inheritance, java interfaces, etc.. So I guess what I am missing in this example is: what was the driving force that would make you need traits here, and how did you end up solving it? _________________________________________________________________ Use your PC to make calls at very low rates https://voiceoam.pcs.v2s.live.com/partnerredirect.aspx |
|
|
In reply to this post by J J-6
J J skrev:
> > > >> From: Keith Hodges <[hidden email]> >> Reply-To: The general-purpose Squeak developers >> list<[hidden email]> >> To: [hidden email], The general-purpose Squeak developers >> list<[hidden email]> >> Subject: Re: Removing Morphic >> Date: Thu, 19 Oct 2006 02:33:44 +0100 >> >> Personally I have never got on with morphic and would much rather see >> something elegant in its place like Model-View-Presenter as used >> superlatively in Dolphin. >> > > This is something I was wondering about. I was playing with Dolphin > before squeak (still will for windows things) and I thought the MVP > concept was a good one. I haven't had time to dig through all the > papers, etc. to find out if Morphic is a step backward or forward. > What I mean by that is; Multiple inheritance, I would consider a > technological step back, but traits are a big step forward. morphs as you go, instance based, kind of like building your program in the Inspector. This is not implemented the same way in Squeak. Morphic in Squeak is mostly programmed through classes, but you can still manipulate the Morphs directly in very cool way. Pull things apart etc. For me Morpic is far more attractive than MVC. That does not mean I thinks it perfect. There is lot of room for improvements. But I also think the look of the SystemWindows are a quite secondary concern for me. Karl |
|
|
In reply to this post by Ron Teitelbaum
Hi Ron -
Couple of comments: > I don't know either. For me Morphic IS EToys. For others Morphic IS > toolBuilder. For me Tweak is Croquet. It appears that for others Tweak is > dead and too slow, (but that seems very short sighted since if Tweak IS > Croquet then there is major development going on which we could all benefit > from) I agree that the best way to look at Tweak is in the context of Croquet. > I asked the questions which no one wants to answer. Can Tweak be > ToolBuilder? Not sure what you mean by "being" ToolBuilder. Tweak does support ToolBuilder, yes (it has from the very beginning). > How difficult would it be to redo the tools in Tweak? I did the PlusTools as an experiment to see how hard it would be and it turns out that it's not terribly hard but it's also nothing you could do over a weekend. > Can we integrate Tweak and will Andreas support it in Squeak? There are two answers to that: For one thing, I have already been supporting it for a couple of years in Squeak 3.6 and 3.8. On the other hand, no single person can single-handedly provide support for the whole Squeak community. The truth is obviously somewhere in the middle. > Can we integrate some of the Croquet functionality? Actually, this will be a requirement in the not too distant future. Supporting Tweak outside of Croquet is simply too much of an effort for me. Which means that if you want Tweak you'll need islands, future messages, and event-loop concurrency (replication may remain optional though). Those will execute on top of the Croquet Metaclass kernel which will make it a nicely self-contained package that has barely any entanglements with other parts of Squeak. > If EToys is too enmeshed with Morphic > and Tweak is clean shouldn't we adopt Tweak as a way of cleaning up (wasn't > that the whole goal of tweak?) Can we leave both and transition to Tweak? The goal of Tweak wasn't to "clean up Morphic" simply because architecturally there isn't anything to clean up. Morphic is Morphic both the good and the bad. It chooses one set of tradeoffs which are perfectly reasonable in itself. Tweak chooses another set of tradeoffs and those come with the good and the bad, too. Cheers, - Andreas |
|
|
In reply to this post by karl-8
There's something fundamental missing from Morphic WRT direct manipulation. You can put together assemblies of morphs, but using them as a template for created duplicate assemblies is lacking (or I never discovered the nifty technique that lets me freeze-dry a morph and reanimate it on demand ala NextStep's InterfaceBuilder).
Nobody builds morphic UI using direct manipulation because it doesn't fully support it. On Oct 20, 2006, at 12:46 PM, karl wrote:
|
|
|
You can drag a morph assembly into a
palette and then when you drag it back out you create a clone of the
assembly. I think the reason most people use code to create assemblies is
that the tools make reuse of a class easier than reuse of instances. If
you take a look at the Self system where instances have a more first-class role
in the tooling it works a bit better (which is where Morphic was invented). Michael From:
[hidden email]
[mailto:[hidden email]] On Behalf Of Todd Blanchard There's something fundamental missing from Morphic WRT direct
manipulation. You can put together assemblies of morphs, but using them as a
template for created duplicate assemblies is lacking (or I never discovered the
nifty technique that lets me freeze-dry a morph and reanimate it on demand ala
NextStep's InterfaceBuilder). Nobody builds morphic UI using direct manipulation because it doesn't
fully support it. On Oct 20, 2006, at 12:46 PM, karl wrote:
Morphic is a direct manipulation
framework. I Self you program the morphs as you go, instance based, kind of
like building your program in the Inspector. This
is not implemented the same way in Squeak. Morphic in Squeak is mostly
programmed through classes, but you can still manipulate the Morphs directly in
very cool way. Pull things apart etc. |
|
|
In reply to this post by tblanchard
Actually, this is what you do with etoys all the time. It's only that
those boring morphs (lists, text fields, what you would call "widgets") are not equipped with the methods to wire them. Dan's Fabrik stuff is still there I think and could maybe reanimated if you want a NeXT-Style interface builder. - Bert - Am 21.10.2006 um 08:09 schrieb Todd Blanchard: > There's something fundamental missing from Morphic WRT direct > manipulation. You can put together assemblies of morphs, but using > them as a template for created duplicate assemblies is lacking (or > I never discovered the nifty technique that lets me freeze-dry a > morph and reanimate it on demand ala NextStep's InterfaceBuilder). > > Nobody builds morphic UI using direct manipulation because it > doesn't fully support it. > > On Oct 20, 2006, at 12:46 PM, karl wrote: > >> Morphic is a direct manipulation framework. I Self you program the >> morphs as you go, instance based, kind of like building your >> program in the Inspector. This is not implemented the same way in >> Squeak. Morphic in Squeak is mostly programmed through classes, >> but you can still manipulate the Morphs directly in very cool way. >> Pull things apart etc. > > |
|
|
In reply to this post by J J-6
J J wrote:
> (it is interesting to watch german speakers trying to decode the > swiss dialect. :). However, they could easily communicate in High German. The difference in expressibility is mostly "hear and feel". Regards, Lothar |
|
|
On Sat, 21 Oct 2006 12:24:27 +0200, Lothar Schenk wrote:
> J J wrote: > >> (it is interesting to watch german speakers trying to decode the >> swiss dialect. :). > > However, they could easily communicate in High German. The difference in > expressibility is mostly "hear and feel". And the doubling of verbs ;-) /Klaus > Regards, Lothar > > |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |