Hi skri
Glenn is also working for a company and building an alternative to Spec
to support mobile and others. What is important is that
- we should continue to clean and improve spec and its documentation.
- understand and push alternative solutions
- so I suggest that you should make sure that other people can use
what you are doing and continue to
push it.
Nothing is curved on stones.
I clean Morphic regularly but I will be happy to through away all my
work if something better is coming (bloc for example).
Stef
On 28/8/14 15:21, S Krish wrote:
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, p...@highoctane.be
<mailto:p...@highoctane.be> <p...@highoctane.be
<mailto:p...@highoctane.be>> 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
<henrik.s.johan...@veloxit.no
<mailto:henrik.s.johan...@veloxit.no>> 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 <step...@stack.nl
<mailto:step...@stack.nl>> 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
>
>
>
>
