On Wed September 19 2007, GeertC wrote:

Brad Fuller-2 wrote:

...

Join our UI efforts in the UI mailing list!

brad

How come the "comp.lang.smalltalk.squeak.ui" is not on Nabble?

i dunno. don't know how to do it. It's on gmane.

El 9/19/07 8:36 PM, "GeertC" geert.wl.claes@gmail.com escribió:

I don't fully understand what you were talking about but I assume its more a decision on the technical approach to clean-up Squeak rather than whether it should be done or not?

It's not only technical, is political too. Many people don't like Etoys go out. As more visible thing inside Squeak is Etoys

How do we get a consensus on how to move forward on cleaning-up the standard image? Where does this need to be raised

This issue was discussed here and into the specialized list as the old Morphic team and now into the 3.10 release team list.

How does the clean-up of the core image affect the Squeal UI initiative?

I hope no effect if Pavel, Juan, me and others messing with smaller images do well our job :=)

But people on the UI list should be aware of changes in Morphic. As Morphic is more that you see...

Edgar

On Thu, Sep 20, 2007 at 05:45:32AM -0700, GeertC wrote:

Edgar J. De Cleene wrote:

...

...

It's not only technical, is political too. Many people don't like Etoys go out. As more visible thing inside Squeak is Etoys

I think everyone agrees that eToys should be an optional component and not part of the Squeak/Smalltalk core image, if this is not the case I would be really really surprised :)

Etoys wouldn't be the first thing I would want to take out of a core image. That would be (in order): - MVC - Browsers - sources and changes file support - Etoys - Compiler

A good core image would be Morphic and a package loader. Usable and customizable. I wouldn't want to distribute anything more or less to a non-technical user.

Matthew Fulmer wrote:

Etoys wouldn't be the first thing I would want to take out of a core image. That would be (in order):

• MVC
• Browsers
• sources and changes file support
• Etoys
• Compiler

A good core image would be Morphic and a package loader. Usable and customizable. I wouldn't want to distribute anything more or less to a non-technical user.

Interesting, I like the idea of stripping down to the basics and letting the user decide which packages they wish to load in their image.

So what needs to be done to make it happen?

On Fri, Sep 21, 2007 at 10:42:35AM +1200, Michael van der Gulik wrote:

On 9/21/07, Matthew Fulmer tapplek@gmail.com wrote: Etoys wouldn't be the first thing I would want to take out of a core image. That would be (in order): - MVC - Browsers - sources and changes file support - Etoys - Compiler

 A good core image would be Morphic and a package loader. Usable
 and customizable. I wouldn't want to distribute anything more or
 less to a non-technical user.

You'd leave Morphic in? o_O

How would you load packages without a compiler or sources/changes file support?

You must have missed the subliminal reference to spoon I hid in the message

Spoon doesn't need a compiler to load packages. After all, CompiledMethods are just a series of bytecodes and a literal list.

Is spoon still active?

Yes.

-C

-- Craig Latta improvisational musical informaticist www.netjam.org Smalltalkers do: [:it | All with: Class, (And love: it)]

for squeak 3.11 or 4.0 I would like to see implemented the roadmap I sent for 3.10.

Now it is also important to learn from the failure of VisualWorks new UI: they tried revolution and failed ow they are following evolution: ie instead of continuing to write a brand new framework they are improving the existing one: now my take for squeak would be - clean Morphic (remove borken code, class referencing subclasses, favor instance variable access over dictionary use) - make sure that a new framework like Morphic3 or xxx could be loaded - check out Sophie code that could be packaged and used for Squeak.

Stef

It was and now I would add be based on pavel mini image + more tests and repackaging at the package level.

Here are the main actions I would like to see happening:

- be able to load Tweak

- be able to load Sophie infrastructural elements (ressource location...) => even substitute current Squeak ones with sophie ones (Rome renderer)

- curve/remove Etoy/projects (without having to reload them)

- remove nebraska and others/ remove packages early in the process

- new compile method format if available else klaus fix for source limits

- may be newcompiler if ready

- aggressive cleans in a lot of areas

- look at Pavel overrides problems => ideally be able to use Pavel image as a basis for 10/4

- Use tool builder (looking at the tool plus) and change the current tools (the ones that deserve migration)

- more tests

- may be using MC2 if ready

- better integration of AST and refactoring support

So if you want to help there on a regular basis or on specific items please say it

Stef

On 9/19/07, GeertC geert.wl.claes@gmail.com wrote: What does the roadmap look like for the Squeak core image (the one downloaded from www.squeak.org)?

As far as I've been able to tell, the roadmap looks like:

• The current release team will continue to correct bugs in Squeak

as reported until they have decided they are done, they are exhausted, they are told to stop, or someone comes up with a new plan for version 3.11 / 4.0.

• The next step in the roadmap is based on someone coming up with

what they want to do next, proposing it, and getting it accepted by the board. (Ideally more than 1 group would come up with an idea they would be willing to undertake, and the board could chose between them). They then start the next relase.

• This continues until we as a community decide to do it some

other way.

The Board (or at least members of the board) have stated that they weren't elected to decide where Squeak was going technically, but rather to handle other issues such as the legal formation of the community and other non-technical issues. This doesn't have to be this way - and we can choose to make that change at the next election if we want too - and demand it during the election. Or, someone could propose another structure for technical direction - maybe have the board appoint a 'temporary technical dictator' that holds the title until that person is removed from office by that (or a later) board.

If you like that roadmap that you proposed and you can find some like-minded individuals that would like to work on that for the next release AND you have the time and dedication to follow through on it, then a great next step would be to start aggitating for the next release cycle to be those goals. Come up with a proposal (I think that mainly means specific goals, rough dates, and a team roster, maybe other stuff - I haven't actually read any of the previous ones) and forward it to the board and/or list for discussion. If it is accepted, negotiate with the current release team about their completion date and when you are going to start.

At least, this is my interpretation of how these things are currently being handled. I'd be happy to be corrected wherever necessary.

-Chris

2007/9/20, stephane ducasse stephane.ducasse@free.fr:

for squeak 3.11 or 4.0 I would like to see implemented the roadmap I sent for 3.10.

Now it is also important to learn from the failure of VisualWorks new UI: they tried revolution and failed

They didn't fail. They had a working product with people using it to build stuff. They just decided to not ship it.

Cheers Philippe

ow they are following evolution: ie instead of continuing to write a brand new framework they are improving the existing one: now my take for squeak would be - clean Morphic (remove borken code, class referencing subclasses, favor instance variable access over dictionary use) - make sure that a new framework like Morphic3 or xxx could be loaded - check out Sophie code that could be packaged and used for Squeak.

Stef

It was and now I would add be based on pavel mini image + more tests and repackaging at the package level.

Here are the main actions I would like to see happening:

    - be able to load Tweak

    - be able to load Sophie infrastructural elements (ressource

location...) => even substitute current Squeak ones with sophie ones (Rome renderer)

    - curve/remove Etoy/projects (without having to reload them)

    - remove nebraska and others/ remove packages early in the process

    - new compile method format if available else klaus fix for source

limits

    - may be newcompiler if ready

    - aggressive cleans in a lot of areas

    - look at Pavel overrides problems
    => ideally be able to use Pavel image as a basis for 10/4

    - Use tool builder (looking at the tool plus) and change the current

tools (the ones that deserve migration)

    - more tests

    - may be using MC2 if ready

    - better integration of AST and refactoring support

So if you want to help there on a regular basis or on specific items please say it

Stef

...

On 9/19/07, GeertC geert.wl.claes@gmail.com wrote: What does the roadmap look like for the Squeak core image (the one downloaded from www.squeak.org)?

As far as I've been able to tell, the roadmap looks like:

• The current release team will continue to correct bugs in Squeak

as reported until they have decided they are done, they are exhausted, they are told to stop, or someone comes up with a new plan for version 3.11 / 4.0.

• The next step in the roadmap is based on someone coming up with

what they want to do next, proposing it, and getting it accepted by the board. (Ideally more than 1 group would come up with an idea they would be willing to undertake, and the board could chose between them). They then start the next relase.

• This continues until we as a community decide to do it some

other way.

The Board (or at least members of the board) have stated that they weren't elected to decide where Squeak was going technically, but rather to handle other issues such as the legal formation of the community and other non-technical issues. This doesn't have to be this way - and we can choose to make that change at the next election if we want too - and demand it during the election. Or, someone could propose another structure for technical direction - maybe have the board appoint a 'temporary technical dictator' that holds the title until that person is removed from office by that (or a later) board.

If you like that roadmap that you proposed and you can find some like-minded individuals that would like to work on that for the next release AND you have the time and dedication to follow through on it, then a great next step would be to start aggitating for the next release cycle to be those goals. Come up with a proposal (I think that mainly means specific goals, rough dates, and a team roster, maybe other stuff - I haven't actually read any of the previous ones) and forward it to the board and/or list for discussion. If it is accepted, negotiate with the current release team about their completion date and when you are going to start.

At least, this is my interpretation of how these things are currently being handled. I'd be happy to be corrected wherever necessary.

-Chris

Seems like this is a can of worms and a lot of people like to see some major changes happen to the Squeak core image. What is Squeak's "board" view on this?

stephane ducasse wrote:

for squeak 3.11 or 4.0 I would like to see implemented the roadmap I sent for 3.10.

Now it is also important to learn from the failure of VisualWorks new UI: they tried revolution and failed ow they are following evolution: ie instead of continuing to write a brand new framework they are improving the existing one: now my take for squeak would be

• clean Morphic (remove borken code, class referencing subclasses, favor

instance variable access over dictionary use)

• make sure that a new framework like Morphic3 or xxx could be loaded
• check out Sophie code that could be packaged and used for Squeak.

Stef

It was and now I would add be based on pavel mini image + more tests and repackaging at the package level.

Here are the main actions I would like to see happening:

• be able to load Tweak
• be able to load Sophie infrastructural elements (ressource location...)

=> even substitute current Squeak ones with sophie ones (Rome renderer)

• curve/remove Etoy/projects (without having to reload them)
• remove nebraska and others/ remove packages early in the process
• new compile method format if available else klaus fix for source limits
• may be newcompiler if ready
• aggressive cleans in a lot of areas
• look at Pavel overrides problems => ideally be able to use Pavel image

as a basis for 10/4

• Use tool builder (looking at the tool plus) and change the current

tools (the ones that deserve migration)

• more tests
• may be using MC2 if ready
• better integration of AST and refactoring support

So if you want to help there on a regular basis or on specific items please say it

Stef

Hi--

Seems like this is a can of worms and a lot of people like to see some major changes happen to the Squeak core image. What is Squeak's "board" view on this?

Squeak's board was elected by the community; it doesn't need quotation marks around it. :) I'm a member of the board, and my view is that yes, a lot of people would like to see major changes to Squeak, many of them contradictory. It is indeed a can of worms.

Ultimately, any technical decisions the leadership makes will upset some significant part of the community. As with many communities, this may lead to wildly different decisions as the leadership changes over time, as well as growth and attrition in the community itself.

-C

-- Craig Latta improvisational musical informaticist www.netjam.org Smalltalkers do: [:it | All with: Class, (And love: it)]

Where can the community find what the leadership's roadmap and progress for Squeak is? I hear from quite a few users - some have even experimented themselves - to strip down the Squeak image, allowing users to choose what is in their image. Another major change request involves the UI to give users at least an option - die-hard Squeakers actually seem to like the current ui for some reason :) - to have a more intuitive gui. I reckon Squeak needs some public visible roadmap and progress indicator like some other open source projects have (Trac?)

Craig Latta wrote:

  Squeak's board was elected by the community; it doesn't need 

quotation marks around it. :) I'm a member of the board, and my view is that yes, a lot of people would like to see major changes to Squeak, many of them contradictory. It is indeed a can of worms.

  Ultimately, any technical decisions the leadership makes will 

upset some significant part of the community. As with many communities, this may lead to wildly different decisions as the leadership changes over time, as well as growth and attrition in the community itself.

Chris Cunningham wrote:

As far as I've been able to tell, the roadmap looks like:

• The next step in the roadmap is based on someone coming up with what

they want to do next, proposing it, and getting it accepted by the board. (Ideally more than 1 group would come up with an idea they would be willing to undertake, and the board could chose between them). They then start the next release.

How or where does one start the discussion for a roadmap towards lets say Squeak 4 - the stripped down, lean and mean version of Squeak 3 :)

Chris Cunningham wrote:

The Board (or at least members of the board) have stated that they weren't elected to decide where Squeak was going technically, but rather to handle other issues such as the legal formation of the community and other non-technical issues. This doesn't have to be this way - and we can choose to make that change at the next election if we want too - and demand it during the election. Or, someone could propose another structure for technical direction - maybe have the board appoint a 'temporary technical dictator' that holds the title until that person is removed from office by that (or a later) board.

If you like that roadmap that you proposed and you can find some like-minded individuals that would like to work on that for the next release AND you have the time and dedication to follow through on it, then a great next step would be to start aggitating for the next release cycle to be those goals. Come up with a proposal (I think that mainly means specific goals, rough dates, and a team roster, maybe other stuff - I haven't actually read any of the previous ones) and forward it to the board and/or list for discussion. If it is accepted, negotiate with the current release team about their completion date and when you are going to start.

What is the proposal form and/or protocol for the "board"? I don't consider myself skilled enough do make changes to the Squeak core image, but I do have a view and ideas to make Squeak's more user friendly and accessible - if that's what the Squeak community wants.

Edgar J. De Cleene wrote:

Squeak 3.10 , the first image without some of packages of previous Squeak (now load from Universes), with quality control process (few red test from more of 2200)

Which packages were removed in 3.10?

Cheers, - Andreas

Edgar J. De Cleene wrote:

Squeak what only do 3 + 4 and exit and several micro images ==> exists from a long, long time by works of Alejandro Reimondo (Fenix system)

Squeak super mininimal system => exists from a long, long time by works of Craig Latta

Squeak "kernel" system exists from a long time by works of Pavel Krivanek

SqueakLight , the more powerful and versatil and comes with a pack of beer cans exists from a long time by works of me I deny rumors of it running on iPhone...:=)

Squeak "MinimalMorphic" , the next step we should do, exists from a long time by works of Pavel Krivanek and some contributions of me.

And you could count Juan Vuletich Morphic 3.0.image as very valuable idea...

So , you could choose to who join forces.

Shouldn't one of these approaches be incorporated by Squeak itself rather than all these different spin-offs? It seems to me that Pavel has done a great job at stripping Squeak down to the kernel (which is probably all Squeak should be), now it only needs some good IDE options with Morphic being one of them ...

ps. where can I find Juan's image?

El 9/20/07 10:03 PM, "GeertC" geert.wl.claes@gmail.com escribió:

Shouldn't one of these approaches be incorporated by Squeak itself rather than all these different spin-offs? It seems to me that Pavel has done a great job at stripping Squeak down to the kernel (which is probably all Squeak should be), now it only needs some good IDE options with Morphic being one of them ...

Could be better, some don't like or wish Traits. And the neo Latin (or lame English) most we understand is enough, so no need of Mulltillingual.

That's why SqueakLightSwiki.430.image have 5.8 mb and Shout,Services, FileMan,DebugReport,Skins, All Kom more HV2 and AniAniWeb into.

This week and I put the logic for using remote from regular Firefox browser (I do this at 3.10 begginning and have 105 different ip from all around the world)

ps. where can I find Juan's image?

Juan answer this. I said I want Morphic 3.0 !!! Grande Juan !!!

Edgar

Oh, BTW I have implemented quite a bit of the image processing approach to anti-aliasing for images I describe at my page. Currently it's awfully slow, it needs a VM plugin. Anyway, I'll publish it soon.

Cheers, Juan Vuletich

Juan Vuletich wrote:

Hi Folks,

My image (in an early development stage) is at my web site www.jvuletich.org . Please read what I'm writing about it, as many of my objectives and ideas are a bit unusual.

Edgar J. De Cleene wrote:

...

...

ps. where can I find Juan's image?

Juan answer this. I said I want Morphic 3.0 !!! Grande Juan !!!

Edgar

Gracias, Edgar :)

Juan Vuletich