Regarding Polymorph
Locked
12
12
 
|
I tried for weeks early on to get polymorph working in a trunk image.
I even had it working for awhile, but I failed at what I wanted to do, namely to find it's essence and do for it what Andreas has done for traits. When enough Pharoisms had crept in that it was no longer loadable in Squeak, I tried another approach; just modify the object graph of the UI directly. For my experiment, (simply installing new buttons in the system windows) I learned of a couple of interesting gotchas. E.g. That windows made by toolbuilder behave differently than windows created the old fashioned way. Anyway I'll cut to the chase: having gotten to know the Polymorph codebase a little, I can say that it is full of ugly workarounds for the shortcomings of the UI in Squeak, and that this explains in part it's complexity. I think, as we are Trunk developers, that we can do much better than Polymorph's bolt-on solution. I think we can get a smaller, more elegant solution. This is something I'm passionate about, and I plan to spend some more time exploring in the skinnability department, once I'm done with 4.0. On Friday, March 12, 2010, Edgar J. De Cleene <[hidden email]> wrote: > > > > On 3/11/10 10:47 PM, "Levente Uzonyi" <[hidden email]> wrote: > >> Noone forces you to use Squeak. >> >> >> Levente > > > only misdirect those who know where they go > > > > -- Casey Ransberger |
|
|
2010/3/12 Casey Ransberger <[hidden email]>:
> I think, as we are Trunk developers, that we can do much better than > Polymorph's bolt-on solution. I think we can get a smaller, more > elegant solution. This is something I'm passionate about, and I plan > to spend some more time exploring in the skinnability department, once > I'm done with 4.0. Besides, there has been quite some work to factor and improve Morphic. It's a good moment to work on such things as adding skinning feature to Morphic. Ian. -- http://mecenia.blogspot.com/ |
|
|
Casey,
i think you are a bit subjective when saying that Polymorph is for Pharo only. Originally, it was developed for Squeak and used by squeak. Then, in times of apathy, when Squeak was a rotting swamp, Pharo team took an effort to incorporate this package into Pharo. -- Best regards, Igor Stasenko AKA sig. |
|
|
On 13 Mar 2010, at 01:02, Igor Stasenko wrote: > Casey, > i think you are a bit subjective when saying that Polymorph is for > Pharo only. > Originally, it was developed for Squeak and used by squeak. > Then, in times of apathy, when Squeak was a rotting swamp, Pharo team > took an effort to incorporate > this package into Pharo. Not quite accurate, the developer of polymorph integrated it into pharo, and did the work of keeping up with pharo. It loaded into squeak 3.10.2 already, The only reason it may not load into trunk now is if trunk contributors broke something, because evidently its developer doesn't have time to keep up with both forks. This is the inevitable scenario that forking produces. Keith |
|
|
In reply to this post by Igor Stasenko
Igor: I didn't say that Polymorph was "for Pharo only," what I said
was "When enough Pharoisms had crept in that it was no longer loadable in Squeak, I tried another approach..." Actually shortly after that enough Trunkisms had crept into Squeak that I was no longer easily able to work around the Pharoisms, ahahaha. At that point on loading it I would get a million debugger windows and the system would thrash and tank. That's when I finally gave up and started looking at smaller and simpler solutions. It's mostly being developed in Pharo now; and as such, the latest bits have (at last I checked and tried loading it up in Trunk) dependencies on some things that are in Pharo but not in Squeak. At this point, there is a bit of porting to do in order to get it working in Trunk; after porting it, I would probably have a fork of it, unless I did some work on Trunk itself to incorporate some Pharoisms. Both of these are IMHO valid approaches, but my point was orthogonal to this: that I think I can do better than Polymorph. Think small, simple, lightweight, loadable and unloadable, skinning by design, not a bolt-on collection of workarounds and multiple solutions to the same and similar problems. My observation in having browsed and played with the code is that Polymorph was developed in an environment when it was hard to get support for things into the core of Squeak; that's not the case anymore. One example here is that toolbuilderized things don't behave like other things, meaning Polymorph had to solve some problems (IIRC, system window buttons) twice, which is inelegant to my mind. I'm not knocking Polymorph. It works great! I had a lot of fun playing with it and rolling up custom subclasses of of UITheme when I was first learning to Squeak. And I have no qualms about saying that I admire what the Pharo team has done, either! I think it's neat that they took their vision in their own direction, and marched to the beat of their own drum. I use Pharo, and I enjoy using Pharo. My interest in Squeak is stronger than my interest in Pharo, however, and so here I am. On Fri, Mar 12, 2010 at 5:02 PM, Igor Stasenko <[hidden email]> wrote: > Casey, > i think you are a bit subjective when saying that Polymorph is for Pharo only. > Originally, it was developed for Squeak and used by squeak. > Then, in times of apathy, when Squeak was a rotting swamp, Pharo team > took an effort to incorporate > this package into Pharo. > > > > -- > Best regards, > Igor Stasenko AKA sig. > > -- Casey Ransberger |
|
|
Guys, your points taken.
This project, as well as many others are victims of monolithic design. Morphic is monolithic. And Polymorph, placed on top if it, inevitably inherits a worst from its base - a monolithic design :( Also, Pharo cut out many etoys-only stuff from Morphic, while Squeak proclaimed to keep etoys in place (until better times ;) GUI, as well as many other parts of system needs systematical approach - maintenance, support and improvement on a regular basis. Being a member of community for last 4 years i din't observed anything like that related to Morphic. Loading Polymorph into Squeak will not change things. We will just add another unmaintained project on top of already unmaintaned one, unless, of course, Gary will volunteer to become a Morphic maintainer in both Pharo and Squeak forks. Which i doubt, because he didn't wanted to do it, when i proposed it last time few years ago. -- Best regards, Igor Stasenko AKA sig. |
|
|
In reply to this post by keith1y
Actually the latest versions had some stuff that I recognized as
changes from Pharo, but otherwise, you're dead on, Keith. Some things it expects have changed in Trunk, and some things the latest bits expect are only in Pharo (I hope no one is offended by my use of the term Pharoism, it's not a slur -- as I've said, I think Pharo rocks!) On Fri, Mar 12, 2010 at 5:09 PM, keith <[hidden email]> wrote: > > On 13 Mar 2010, at 01:02, Igor Stasenko wrote: > >> Casey, >> i think you are a bit subjective when saying that Polymorph is for Pharo >> only. >> Originally, it was developed for Squeak and used by squeak. >> Then, in times of apathy, when Squeak was a rotting swamp, Pharo team >> took an effort to incorporate >> this package into Pharo. > > Not quite accurate, the developer of polymorph integrated it into pharo, and > did the work of keeping up with pharo. > > It loaded into squeak 3.10.2 already, > > The only reason it may not load into trunk now is if trunk contributors > broke something, because evidently its developer doesn't have time to keep > up with both forks. This is the inevitable scenario that forking produces. > > Keith > > > -- Casey Ransberger |
|
|
In reply to this post by Igor Stasenko
2010/3/13 Igor Stasenko <[hidden email]>:
> Guys, your points taken. > > This project, as well as many others are victims of monolithic design. > Morphic is monolithic. And Polymorph, placed on top if it, inevitably > inherits a worst > from its base - a monolithic design :( > Also, Pharo cut out many etoys-only stuff from Morphic, > while Squeak proclaimed to keep etoys in place (until better times ;) > > GUI, as well as many other parts of system needs systematical approach > - maintenance, > support and improvement on a regular basis. > Being a member of community for last 4 years i din't observed anything > like that related to Morphic. > Hey, it's far more involving than changing just Collections... The code base is large, tricky, and every change potentially break tools and put another image in you garbage bin. Plus, it's a huge work (See VW recent failure to replace wrappers). But the major risk is breaking every "cool" morphic project, and thus see your changes rejected by community. The only way I see is starting a parallel implementation from scratch (not Scratch the software ;). And I think Pharo would be a better place to experiment more radical changes, because not tied to the past. Nicolas > Loading Polymorph into Squeak will not change things. We will just add > another unmaintained project on top > of already unmaintaned one, unless, of course, Gary will volunteer to > become a Morphic maintainer in both Pharo and Squeak forks. > Which i doubt, because he didn't wanted to do it, when i proposed it > last time few years ago. > > -- > Best regards, > Igor Stasenko AKA sig. > > |
|
|
On 13 March 2010 10:06, Nicolas Cellier
<[hidden email]> wrote: > 2010/3/13 Igor Stasenko <[hidden email]>: >> Guys, your points taken. >> >> This project, as well as many others are victims of monolithic design. >> Morphic is monolithic. And Polymorph, placed on top if it, inevitably >> inherits a worst >> from its base - a monolithic design :( >> Also, Pharo cut out many etoys-only stuff from Morphic, >> while Squeak proclaimed to keep etoys in place (until better times ;) >> >> GUI, as well as many other parts of system needs systematical approach >> - maintenance, >> support and improvement on a regular basis. >> Being a member of community for last 4 years i din't observed anything >> like that related to Morphic. >> > > Hey, it's far more involving than changing just Collections... > The code base is large, tricky, and every change potentially break > tools and put another image in you garbage bin. True. So, let us then stop any development and use Squeak 1.0 image, since its "code base is large, tricky, and every change potentially break tools and put another image in you garbage bin". :) > Plus, it's a huge work (See VW recent failure to replace wrappers). > But the major risk is breaking every "cool" morphic project, and thus > see your changes rejected by community. Still, it doesn't makes my point less relevant: as any part of system it should be maintained and improved , otherwise it is doomed to rot and die. > The only way I see is starting a parallel implementation from scratch > (not Scratch the software ;). Like Tweak? I don't wanna get into a details, why Tweak failed to replace Morphic in Squeak, but i think this is what any brand new framework have to meet: compete with Morphic and die :) > And I think Pharo would be a better place to experiment more radical > changes, because not tied to the past. > So, the only conclusion i can draw from above is: if you want to see any improvement in Morphic, go Pharo. It is ok, as for me. But not for Squeak, i guess, because it doesn't helping it in any way. > Nicolas > -- Best regards, Igor Stasenko AKA sig. |
|
|
Er... I don't think there's anything intrinsic to Morphic which makes
skinning hard. It's the patchwork architecture of the tools that needs help. Toolbuilderize everything and include support in toolbuilder for skinning, and I imagine that at least a large part of Polymorph becomes unnecessary. I need to spend some time digging into toolbuilder to confirm this hunch; it's on my TODO list. On Sat, Mar 13, 2010 at 12:25 AM, Igor Stasenko <[hidden email]> wrote: > On 13 March 2010 10:06, Nicolas Cellier > <[hidden email]> wrote: >> 2010/3/13 Igor Stasenko <[hidden email]>: >>> Guys, your points taken. >>> >>> This project, as well as many others are victims of monolithic design. >>> Morphic is monolithic. And Polymorph, placed on top if it, inevitably >>> inherits a worst >>> from its base - a monolithic design :( >>> Also, Pharo cut out many etoys-only stuff from Morphic, >>> while Squeak proclaimed to keep etoys in place (until better times ;) >>> >>> GUI, as well as many other parts of system needs systematical approach >>> - maintenance, >>> support and improvement on a regular basis. >>> Being a member of community for last 4 years i din't observed anything >>> like that related to Morphic. >>> >> >> Hey, it's far more involving than changing just Collections... >> The code base is large, tricky, and every change potentially break >> tools and put another image in you garbage bin. > > True. So, let us then stop any development and use Squeak 1.0 image, > since its "code base is large, tricky, and every change potentially > break tools and put another image in you garbage bin". :) > >> Plus, it's a huge work (See VW recent failure to replace wrappers). >> But the major risk is breaking every "cool" morphic project, and thus >> see your changes rejected by community. > > Still, it doesn't makes my point less relevant: as any part of system > it should be maintained and improved , otherwise it is > doomed to rot and die. > >> The only way I see is starting a parallel implementation from scratch >> (not Scratch the software ;). > > Like Tweak? I don't wanna get into a details, why Tweak failed to > replace Morphic in Squeak, > but i think this is what any brand new framework have to meet: compete > with Morphic and die :) > >> And I think Pharo would be a better place to experiment more radical >> changes, because not tied to the past. >> > So, the only conclusion i can draw from above is: if you want to see > any improvement in Morphic, go Pharo. > It is ok, as for me. But not for Squeak, i guess, because it doesn't > helping it in any way. > >> Nicolas >> > > -- > Best regards, > Igor Stasenko AKA sig. > > -- Casey Ransberger |
|
|
In reply to this post by Igor Stasenko
On 3/13/2010 12:25 AM, Igor Stasenko wrote:
> Like Tweak? I don't wanna get into a details, why Tweak failed to > replace Morphic in Squeak, I'd be kinda curious what you think about that. My opinion is pretty clear: I never *wanted* Tweak to be a replacement for Morphic. It wasn't ready; it was a playground for lots of new ideas. > but i think this is what any brand new framework have to meet: compete > with Morphic and die :) You think so? Hm ... well maybe I should finally put a little release together. I think a decent Morphic competition is best done by being antithetical to Morphic. I'll see if I can find some time to polish things up a bit. Cheers, - Andreas |
|
|
On 13 March 2010 10:47, Andreas Raab <[hidden email]> wrote:
> On 3/13/2010 12:25 AM, Igor Stasenko wrote: >> >> Like Tweak? I don't wanna get into a details, why Tweak failed to >> replace Morphic in Squeak, > > I'd be kinda curious what you think about that. My opinion is pretty clear: > I never *wanted* Tweak to be a replacement for Morphic. It wasn't ready; it > was a playground for lots of new ideas. > It was just an example, of how far you should go, to be at least as rich in features as Morphic. It is much bigger investment than modifying existing code. And still you have big chances that it won't replace Morphic as a framework of choice for developers. So, it is much more risk, comparing to the risk of changing Morphic even if it breaks some 'cool' years old stuff. If that's not true, then there should be already dozens of different frameworks ready for use in Squeak :) >> but i think this is what any brand new framework have to meet: compete >> with Morphic and die :) > > You think so? Hm ... well maybe I should finally put a little release > together. I think a decent Morphic competition is best done by being > antithetical to Morphic. I'll see if I can find some time to polish things > up a bit. > Not sure i understood what is 'being antithetical to Morphic' means. I think that in Squeak situation, it is better to keep improving what we already have, instead of making a new framework. But this is exactly what Nicolas says that its highly unlikely to happen. > Cheers, > Â - Andreas > -- Best regards, Igor Stasenko AKA sig. |
|
|
On 3/13/2010 1:08 AM, Igor Stasenko wrote:
> It was just an example, of how far you should go, to be at least as > rich in features as Morphic. > It is much bigger investment than modifying existing code. And still > you have big chances that > it won't replace Morphic as a framework of choice for developers. > So, it is much more risk, comparing to the risk of changing Morphic > even if it breaks some 'cool' years old stuff. Unless you do it differently. There is no reason why a well-designed framework cannot happily coexist with Morphic. In which case you can build your framework pretty much without touching anything. Tweak had some of that; you could run Tweak projects inside Morphic but as with so many things it wasn't quite completed. >>> but i think this is what any brand new framework have to meet: compete >>> with Morphic and die :) >> >> You think so? Hm ... well maybe I should finally put a little release >> together. I think a decent Morphic competition is best done by being >> antithetical to Morphic. I'll see if I can find some time to polish things >> up a bit. >> > Not sure i understood what is 'being antithetical to Morphic' means. It means being abstract instead of concrete. Morphic is a very conrete environment; but if you look at a UI more abstractly, it's just rectangles with behaviors. Skinning ultimately does that - it demotecs the lively morphs to being rectangles with their looks being supplied from elsewhere. If you take that to its logical end you'll find yourself in a world that is made up of abstract widgets that don't even have a particular "binding" to a graphics interface. All they know is how to act in response to events. Pretty much all of the concreteness of Morphic is gone even though you could reintroduce that. But you start from a base that's very abstract and that's what I mean by being antithetical to Morphic. Cheers, - Andreas |
|
|
In reply to this post by keith1y
Indeed, Polymorph can still be loaded into 3.9 (though not a simple thing to
do due the "hacks" that were necessary since based around Morphic). Not tried a fresh load into 3.9 for a long while though, it is likely that the current Universes version would need to be used as a starting point, along with the Polymorph-Squeak-Widgets package (that factors out most of the Pharo/3.9 differences). It is becoming increasingly difficult to maintain 3.9 compatability due to Pharo adaptations. Keith is right that it is unfortunately too much work to keep up with an additional moving target (trunk). Even so, the Pharo version is quite different to the packaged version as available on SqueakSource. Of course, it would have been nicer if Morphic/EToys was less complicated and full of dependencies in the first place... Still, Morphic had a lot to offer, hence the decision to base Polymorph upon it. Polymorph could have been made to work *within* Morphic, without extensions but then, without rewriting the IDE tools, no benefits would be gained for the development environment, just for new "end user" applications. If nothing else, I hope that Polymorph has given people some ideas to help improve Squeak. It is not just about look and feel but also things you might take for granted in most other widget kits, DropLists, common dialogs etc... Regards, Gary ----- Original Message ----- From: "keith" <[hidden email]> To: "The general-purpose Squeak developers list" <[hidden email]> Sent: Saturday, March 13, 2010 1:09 AM Subject: Re: [squeak-dev] Regarding Polymorph > > On 13 Mar 2010, at 01:02, Igor Stasenko wrote: > >> Casey, >> i think you are a bit subjective when saying that Polymorph is for Pharo >> only. >> Originally, it was developed for Squeak and used by squeak. >> Then, in times of apathy, when Squeak was a rotting swamp, Pharo team >> took an effort to incorporate >> this package into Pharo. > > Not quite accurate, the developer of polymorph integrated it into pharo, > and did the work of keeping up with pharo. > > It loaded into squeak 3.10.2 already, > > The only reason it may not load into trunk now is if trunk contributors > broke something, because evidently its developer doesn't have time to > keep up with both forks. This is the inevitable scenario that forking > produces. > > Keith > > |
|
|
In reply to this post by Igor Stasenko
Hi Igor.
My hands are full enough with (paying) work and Polymorph maintenance... Morphic itself is hugely more work! Were I to do things again it would likely be from scratch with a nice, clean design, as you know. Of course, gaining any acceptance of a new UI framework would be next to impossible, not to mention leaving existing applications out in the cold. That's why Polymorph has been complicated... backwards compatability! Now, if everything had used ToolBuilder there would be a chance, although too limiting for all the fun stuff that has been done using Morphic across the years... Regards, Gary ----- Original Message ----- From: "Igor Stasenko" <[hidden email]> To: "The general-purpose Squeak developers list" <[hidden email]> Sent: Saturday, March 13, 2010 2:23 AM Subject: Re: [squeak-dev] Regarding Polymorph > Guys, your points taken. > > This project, as well as many others are victims of monolithic design. > Morphic is monolithic. And Polymorph, placed on top if it, inevitably > inherits a worst > from its base - a monolithic design :( > Also, Pharo cut out many etoys-only stuff from Morphic, > while Squeak proclaimed to keep etoys in place (until better times ;) > > GUI, as well as many other parts of system needs systematical approach > - maintenance, > support and improvement on a regular basis. > Being a member of community for last 4 years i din't observed anything > like that related to Morphic. > > Loading Polymorph into Squeak will not change things. We will just add > another unmaintained project on top > of already unmaintaned one, unless, of course, Gary will volunteer to > become a Morphic maintainer in both Pharo and Squeak forks. > Which i doubt, because he didn't wanted to do it, when i proposed it > last time few years ago. > > -- > Best regards, > Igor Stasenko AKA sig. > |
|
|
In reply to this post by Andreas.Raab
----- Original Message -----
From: "Andreas Raab" <[hidden email]> To: "The general-purpose Squeak developers list" <[hidden email]> Sent: Saturday, March 13, 2010 9:21 AM Subject: [squeak-dev] Re: Regarding Polymorph > On 3/13/2010 1:08 AM, Igor Stasenko wrote: >> It was just an example, of how far you should go, to be at least as >> rich in features as Morphic. >> It is much bigger investment than modifying existing code. And still >> you have big chances that >> it won't replace Morphic as a framework of choice for developers. >> So, it is much more risk, comparing to the risk of changing Morphic >> even if it breaks some 'cool' years old stuff. > > Unless you do it differently. There is no reason why a well-designed > framework cannot happily coexist with Morphic. In which case you can build > your framework pretty much without touching anything. Tweak had some of > that; you could run Tweak projects inside Morphic but as with so many > things it wasn't quite completed. > >>>> but i think this is what any brand new framework have to meet: compete >>>> with Morphic and die :) >>> >>> You think so? Hm ... well maybe I should finally put a little release >>> together. I think a decent Morphic competition is best done by being >>> antithetical to Morphic. I'll see if I can find some time to polish >>> things >>> up a bit. >>> >> Not sure i understood what is 'being antithetical to Morphic' means. > > It means being abstract instead of concrete. Morphic is a very conrete > environment; but if you look at a UI more abstractly, it's just rectangles > with behaviors. Skinning ultimately does that - it demotecs the lively > morphs to being rectangles with their looks being supplied from elsewhere. > If you take that to its logical end you'll find yourself in a world that > is made up of abstract widgets that don't even have a particular "binding" > to a graphics interface. All they know is how to act in response to > events. Pretty much all of the concreteness of Morphic is gone even though > you could reintroduce that. But you start from a base that's very abstract > and that's what I mean by being antithetical to Morphic. > Yes, that'd be the way I'd go if I had the time/support to do the vast amount of work required. Perhaps the other option... turn it all on its head and have the nice new framework with adapters to run Morphic within. That'd solve the backwards compatability issues while alowing new progress to be made. > Cheers, > - Andreas > |
|
|
In reply to this post by Casey Ransberger
For what it is worth...
I have been able to load Polymorph into trunk, not the easiest (mainly due to MC differences wrt Traits), takes around 5 minutes of manual fixing while loading... Once "in", clearly shows up the areas that have changed in trunk though... (process instructions available if desired...) My advice is, as I think you intend, is to learn from Polymorph and, even further, push for some kind of overall UI framework that can support the ideas. Otherwise you'll run into the same issues that I had to deal with (backwards compatability, acceptance, with/without-EToys etc.)... I believe you wanted to know what the "essence" of Polymorph was (in priority order)... 1. Look and feel familiar to end-application-users (non-Squeakers!). 2. Support for commonly expected widgets/controls/dialogs. 3. Integration with the (image/ide) environment to leverage the above for developers. 4. Improving tools for development (Diff tools etc.). 5. Hooking Morphic to allow look/feel to be extensible. Given the (end-user-unnaceptable) state the Squeak UI was in at the time of inception (2006), there was no way we could deliver an end-user application with the way Squeak was then. Even now there is no infrastructure to be able to do these things in a "clean" manner... A lot of work to refactor Morphic to handle such things even now... perhaps time for a change, though there's a lot of *great* stuff in Morphic when investigated. Regards, Gary ----- Original Message ----- From: "Casey Ransberger" <[hidden email]> To: "The general-purpose Squeak developers list" <[hidden email]> Sent: Friday, March 12, 2010 5:33 PM Subject: [squeak-dev] Regarding Polymorph >I tried for weeks early on to get polymorph working in a trunk image. > I even had it working for awhile, but I failed at what I wanted to do, > namely to find it's essence and do for it what Andreas has done for > traits. > > When enough Pharoisms had crept in that it was no longer loadable in > Squeak, I tried another approach; just modify the object graph of the > UI directly. For my experiment, (simply installing new buttons in the > system windows) I learned of a couple of interesting gotchas. E.g. > That windows made by toolbuilder behave differently than windows > created the old fashioned way. > > Anyway I'll cut to the chase: having gotten to know the Polymorph > codebase a little, I can say that it is full of ugly workarounds for > the shortcomings of the UI in Squeak, and that this explains in part > it's complexity. > > I think, as we are Trunk developers, that we can do much better than > Polymorph's bolt-on solution. I think we can get a smaller, more > elegant solution. This is something I'm passionate about, and I plan > to spend some more time exploring in the skinnability department, once > I'm done with 4.0. > > On Friday, March 12, 2010, Edgar J. De Cleene <[hidden email]> > wrote: >> >> >> >> On 3/11/10 10:47 PM, "Levente Uzonyi" <[hidden email]> wrote: >> >>> Noone forces you to use Squeak. >>> >>> >>> Levente >> >> >> only misdirect those who know where they go >> >> >> >> > > -- > Casey Ransberger > |
|
|
In reply to this post by Gary Chambers-4
Gary, you've echoed a suspicion that I have: "Now, if everything had
used ToolBuilder there would be a chance" In your opinion, if we went and toolbuilderized everything we could find, assuming we didn't have to worry about supporting other forks, roughly how much complexity would we be able to shave off of Polymorph? My thought is, we could greatly reduce the complexity of a user interface On Sat, Mar 13, 2010 at 4:29 AM, Gary Chambers <[hidden email]> wrote: > Hi Igor. > > My hands are full enough with (paying) work and Polymorph maintenance... > Morphic itself is hugely more work! > > Were I to do things again it would likely be from scratch with a nice, clean > design, as you know. Of course, gaining > any acceptance of a new UI framework would be next to impossible, not to > mention leaving existing applications out in the cold. > That's why Polymorph has been complicated... backwards compatability! > > Now, if everything had used ToolBuilder there would be a chance, although > too limiting for all the fun stuff that has been done using Morphic across > the years... > > Regards, Gary > > > ----- Original Message ----- From: "Igor Stasenko" <[hidden email]> > To: "The general-purpose Squeak developers list" > <[hidden email]> > Sent: Saturday, March 13, 2010 2:23 AM > Subject: Re: [squeak-dev] Regarding Polymorph > > >> Guys, your points taken. >> >> This project, as well as many others are victims of monolithic design. >> Morphic is monolithic. And Polymorph, placed on top if it, inevitably >> inherits a worst >> from its base - a monolithic design :( >> Also, Pharo cut out many etoys-only stuff from Morphic, >> while Squeak proclaimed to keep etoys in place (until better times ;) >> >> GUI, as well as many other parts of system needs systematical approach >> - maintenance, >> support and improvement on a regular basis. >> Being a member of community for last 4 years i din't observed anything >> like that related to Morphic. >> >> Loading Polymorph into Squeak will not change things. We will just add >> another unmaintained project on top >> of already unmaintaned one, unless, of course, Gary will volunteer to >> become a Morphic maintainer in both Pharo and Squeak forks. >> Which i doubt, because he didn't wanted to do it, when i proposed it >> last time few years ago. >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> > > > -- Casey Ransberger |
|
|
In reply to this post by Casey Ransberger
Gary Chambers said: "For what it is worth... I have been able to load Polymorph into trunk, not the easiest (mainly due to MC differences wrt Traits), takes around 5 minutes of manual fixing while loading... Once "in", clearly shows up the areas that have changed in trunk though... (process instructions available if desired...)" I'd like to see that. If you're offering instructions to load into the Trunk, I'd like them, please. And if you might provide an example for when it's loaded, something like Ellipse new openInWorld, or some kind of first Polymorph widget to look at. That would be great. Chris |
|
|
In reply to this post by Casey Ransberger
If it was ToolBuilder through and through I could have managed (mostly) with
no "extension" methods... that being the main grief with regards to ongoing changes in trunk... ToolBuilder itself has an adaptable start-point/factory (c.f. PSToolBuilder). As you identified, not all uses ToolBuilder, hence lower-level "hacks" required to theme the ide as a whole. Though, as I mentioned, (implied?) ToolBuilder does severely limit expressiveness for applications since the "protocol" of allowable things/widgets/controls is inherently limited. Not to say that ToolBuilder couldn't be adapted to essentially mirror a decent set of widgets/controls... Even so, there are parts of Morphic that, even with a rich ToolBuilder, would need some refactoring to become more flexible (a lot of assumptions in the the basic user-event handling and propogation, for example...) Regards, Gary ----- Original Message ----- From: "Casey Ransberger" <[hidden email]> To: "The general-purpose Squeak developers list" <[hidden email]> Sent: Saturday, March 13, 2010 5:13 PM Subject: Re: [squeak-dev] Regarding Polymorph > Gary, you've echoed a suspicion that I have: "Now, if everything had > used ToolBuilder there would be a chance" > > In your opinion, if we went and toolbuilderized everything we could > find, assuming we didn't have to worry about supporting other forks, > roughly how much complexity would we be able to shave off of > Polymorph? > > My thought is, we could greatly reduce the complexity of a user interface > > On Sat, Mar 13, 2010 at 4:29 AM, Gary Chambers > <[hidden email]> wrote: >> Hi Igor. >> >> My hands are full enough with (paying) work and Polymorph maintenance... >> Morphic itself is hugely more work! >> >> Were I to do things again it would likely be from scratch with a nice, >> clean >> design, as you know. Of course, gaining >> any acceptance of a new UI framework would be next to impossible, not to >> mention leaving existing applications out in the cold. >> That's why Polymorph has been complicated... backwards compatability! >> >> Now, if everything had used ToolBuilder there would be a chance, although >> too limiting for all the fun stuff that has been done using Morphic >> across >> the years... >> >> Regards, Gary >> >> >> ----- Original Message ----- From: "Igor Stasenko" <[hidden email]> >> To: "The general-purpose Squeak developers list" >> <[hidden email]> >> Sent: Saturday, March 13, 2010 2:23 AM >> Subject: Re: [squeak-dev] Regarding Polymorph >> >> >>> Guys, your points taken. >>> >>> This project, as well as many others are victims of monolithic design. >>> Morphic is monolithic. And Polymorph, placed on top if it, inevitably >>> inherits a worst >>> from its base - a monolithic design :( >>> Also, Pharo cut out many etoys-only stuff from Morphic, >>> while Squeak proclaimed to keep etoys in place (until better times ;) >>> >>> GUI, as well as many other parts of system needs systematical approach >>> - maintenance, >>> support and improvement on a regular basis. >>> Being a member of community for last 4 years i din't observed anything >>> like that related to Morphic. >>> >>> Loading Polymorph into Squeak will not change things. We will just add >>> another unmaintained project on top >>> of already unmaintaned one, unless, of course, Gary will volunteer to >>> become a Morphic maintainer in both Pharo and Squeak forks. >>> Which i doubt, because he didn't wanted to do it, when i proposed it >>> last time few years ago. >>> >>> -- >>> Best regards, >>> Igor Stasenko AKA sig. >>> >> >> >> > > > > -- > Casey Ransberger > |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |