2009/7/2 Bert Freudenberg <bert at freudenbergs.de>:
> I have no idea where the myth comes from that the look of Squeak's Smalltalk
> development tools has anything whatsoever to do with Etoys, but anyhow it
> would be a good idea to stop spreading it.
>
> "Usability and look-and-feel" is what this thread is about so constructive
> ideas (or even better code and designs) are welcome, but blaming it on Etoys
> is just cheap.
>
> - Bert -

Hello Bert,

I can buy your statement as Etoys is not to be blamed. Squeak has
taken a direction for a long time and perhaps Etoys was caught in the
middle. Does it really matter who's or what's fault is? As long as we
can move forward. But it shouldn't surprise you that some people would
prefer Etoys as a package; it's overly interwoven with Morphic by your
own admission.

Regardless. Usability and look-and-feel should probably be a higher
priority than Etoys, or not Etoys. What do you guys think?

> Maybe the best use of development resources would be to
> consider the current Morphic+Etoys a unit and work on an alternative, leaner
> UI framework? So the two would not step on each other's feet?
>
> Ideas (and even more actual help) welcome.

I like the idea but it sounds hard work on a stake. Isn't Morphic an
alternative to MVC? Isn't Tweak an alternative to Morphic? I was
interested in the concept behind Tweak but it feels so stiff?! And it
wasn't on point when it comes to responsiveness. I should give another
round anyway. Something both flexible (Morphic) and structured (MVC)
comes to my mind...

2009/7/2 Bert Freudenberg <bert at freudenbergs.de>:
> On 01.07.2009, at 23:16, Ian Trudel wrote:
>> When it's time to wrap up Squeak into a product and deploy it, it turns
>> out bitter.
>
> This is sad to hear. Why is that? You don't really explain what's the
> problem in the rest of your post but just lay all the blame on Etoys.

My apologies if you thought that I was blaming Etoys for problems
related to deployment. It's not what I meant anyway.

It's difficult for me to thoroughly explain the problems related to
the requirements imposed to me because: 1) we're still investigating,
asserting each requirement against Squeak. 2) It's done in part time.
3) there might be some confidentiality issues to resolve beforehand.

The reason why I decided to speak up now rather once we're all set and
ready is really because I feel the community is ready to listen and
discuss. I'm not trying to rush anything here...

Hopefully, I will share more information in a reasonable time frame.

> Deploying apps in Squeak has been made considerably easier in the last
> couple of years - take a look at the Sophie or Seaside downloads for example
> which are good examples of how to bundle VMs for your target system with an
> image and support files in one directory structure. Or this brand new
> Etoys-To-Go beta ;)
>
> http://wiki.squeakland.org/display/sq/Etoys+To+Go

Yes, I have seen most of them. It's quite interesting indeed.
I've even tried Etoy's gettext support. :P


2009/7/2 Yoshiki Ohshima <yoshiki at vpri.org>:
>> I understand that. Could we consider Squeak to have its own roadmap?
>
>  Sure.
>
>  While there are questions like whether it can be done in a
> reasonable way or not and say, and whether it can be compatible with
> the previous Etoys systems, the vision of having "an authoring system
> for children of all ages and maintain it" is a worthy one, and quite a
> few seem to be supporting the idea.  And it wouldn't really harm
> "grown ups" view of the system.

I agree with that. Coexisting is definitively possible. Wouldn't a
grown up view would actually empower and benefit to "an authoring
system for children of all ages and maintain it"? Because the other
way around is just not the same.

>> Possibly. They were however at the head of the project. Doesn't it
>> tell you something?
>
>  Many things, but possibly we don't agree^^;

he he he. =)

> -- Yoshiki

All the best, Bert and Yoshiki. :)

Ian.

-- 
http://mecenia.blogspot.com/