Will there be any interest in alternative declarative framework, mostly fleshed out, worked in Pharo 2.0 / with little fixes for FileDirectory et als in 3.0
http://skrishnamachari.wordpress.com/2012/01/31/pharo-application-framework-aka-morphic-view-framework/ I can push this in with the required MIT license sign off as reqd. More importantly, move this framework to a more refactored cleaner state if there is a slight interest in alternatives. On Thu, Aug 28, 2014 at 5:51 PM, [email protected] <[email protected]> wrote: > No, it doesn't. > > We can improve Spec in the core, why wouldn't we be able to? > We use it in a lot of the tools, so, there are plenty of samples and > documentation exists. > > One can make sense of what's going on under the hood. > > Have a look at: (this is for Pharo 3.0) > > SpecInterpreter>>interpretASpec:selector: and ComposableModel + > NewValueHolder. > WindowModel is interesting to look into as well. > > The "famous" NewValueHolder is of interest too. > > > then implementors of defaultSpec provide a lot of specs to give to the > SpecInterpreter. > > Then one wants to look into the Spec-MorphicAdapters to see how Spec maps > its view on things with underlying Morphs (e.g. check the > MorphicDiffAdapter). > > We can only benefit by caring about this piece on our side, as there is > tremendous potential in being able to change the underlying system (e.g. > from Morphic to Bloc for example) in a piecemeal way, without breaking all > of the tools. > > Phil > > > On Thu, Aug 28, 2014 at 1:19 PM, Henrik Johansen < > [email protected]> wrote: > >> Does it really matter? >> If the external repository gets successfully relicensed, or Benjamin >> publishes new improvements as a separate, GPL-licensed change set, the end >> result is the same; >> no improvement he makes will make its way back into the versions in Core. >> >> I may not know his reasons, but I can certainly respect his wish that no >> further contributions are included in a core distribution. >> >> Whether to maintain/improve the current, MIT-licensed versions in Core >> without him, or unload it all and point potential users to the external >> library, is a separate decision. >> Though, from previous attempts, I’d say the chances of success of an >> external UI-builder framework seeing actual use are rather slim. >> >> Cheers, >> Henry >> >> On 28 Aug 2014, at 12:16 , Stephan Eggermont <[email protected]> wrote: >> >> > >> https://github.com/spec-framework/spec/commit/07ea83ca50523b4a912e363ff2f3974c69314b7f#commitcomment-7540588 >> > >> > I think the license might need further improvements. >> > I've taken a look at the commit history, and it looks >> > to me like there is a licensing problem there. >> > I am no lawyer, so don't know what the >> > exact consequences of that are. >> > >> > The (MIT licensed) Pharo code was copied >> > to the repository without including the copyright >> > notice, as is required by the MIT license. >> > >> > For new contributions, you now have the >> > license agreements, and with git it is >> > perfectly clear what is new, and under >> > the new license, and what is old, and >> > can therefore also be used under the >> > old license. And AFAIK MIT license >> > is compatible with GPL. >> > >> > I have no clue as to the license status of >> > changes between the copying and the >> > relicensing. >> > >> > Of course copyright holding contributors can >> > decide to relicense. The contributors to the >> > Spec-* packages in the Pharo/Pharo30 repo >> > seem to be: >> > >> > AlainPlantec >> > AndreiChis >> > BenComan >> > BenjaminVanRyseghem >> > BernardoContreras >> > CamilloBruni >> > CamilleTeruel >> > ChristopheDemarey >> > ClementBera >> > DamienCassou >> > ErwanDouaille >> > EstebanLorenzano >> > GabrielOmarCotelli >> > GuillermoPolito >> > HernanMoralesDurand >> > IgorStasenko >> > LeoGassman >> > MarcusDenker >> > MartinDias >> > NicolaiHess >> > PabloHerrero >> > PavelKrivanek >> > PhilippeBack >> > RobertoMinelli >> > SeanDeNigris >> > SebastianTleye >> > StephaneDucasse >> > SvenVanCaekenberghe >> > TorstenBergmann >> > TudorGirba >> > YuriyTymchuk >> > >> > Stephan >> > >> > >> > >> > >> >> >
