A roadmap for 3.9

stéphane ducasse ducasse at iam.unibe.ch
Fri Dec 10 20:50:14 UTC 2004


> I am concerned with experiments conducted with Aqua L(not so much &F); 
> this
> seems to speed up general window interaction considerably. I don't 
> know what
> to make of formalities, it /is/ an emulation of an existing operating 
> system
> look, but, if it creates an environment where there is less happening
> between events and/or display updates, *while* maintaining the same 
> basic
> functionality, it should be investigated. I think it can be propogated
> backward to Squeak's current look.

Ok this seems indeed interesting. I do not have the time to check what 
you did now
but how intrusive are your changes, how big are they? This is true that 
having a nice
look for programmers would be really good. I like the look of diego but 
this is for kids.

A cleaning and reordering of the menu items would be good too.


> This all sounds quite tasty. It is mentioned in the closure compiler
> documents that switching the preference to use the old-style compiler 
> is
> needed when Etoys is invoked. Will this be done automatically for 
> official
> image?

Normally if I remember what marcus told me is that he introduced
a preference to be able to switch between full and not full closures 
but normally
we will use it in not full. Then as Etoy depends heavily on the old 
compiler we will
keep it until a good soul change etoy to use the new compiler but all 
the other method
compilation will use the new compiler). Marcus can you tell me whether 
I'm right?

> For System-stuff you mentioned, how about SmaCC?

Why not as a package. Good idea. What would be interesting is that 
someone check since
John produced some new version of Smacc with automatic generation of 
the domain code.
But again no time for that. If someone has the time, he should contact 
the Smacc maintainer
because this would be cool to have the latest version. There are also 
some utilities methods
missing that the VW version has.

> Exupery I'm not sure
> on useable status for any inclusion.

I do not think so even if this is really interesting work :)

>  Services need to be fixed up for latest
> Squeak. (They won't install based on two reports, first being a 
> conflict
> with KomServices IIRC)

Yes but they are much more central so I would give them the priority.
We can nicely ask romain to rename them anyway.

> ...I am also concerned with hardware accelerated display support. 
> Currently
> this is deeply wired with Balloon3D (which is nice, but more control 
> and not
> requiring Balloon3D would be interesting. I can see several ways to do 
> this,
> portably)

Contact the Balloon3D maintainer is you have spare cycle because I'm 
sure that
andreas does not have that much time, when I see that the fix of Pooh 
Ned did
have not been yet included in the package. I'm sure your help will be 
welcome.

Stef




More information about the Squeak-dev mailing list