A roadmap for 3.9
humasect at shaw.ca
Fri Dec 10 22:42:17 UTC 2004
----- Original Message -----
From: "stéphane ducasse" <ducasse at iam.unibe.ch>
To: "The general-purpose Squeak developers list"
<squeak-dev at lists.squeakfoundation.org>
Sent: Friday, December 10, 2004 12:50 PM
Subject: Re: A roadmap for 3.9
> > 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 Aqua is not my code, but I will see the exact differences from the base
window (et al) display code, and see what I can come up with. (Attached for
the curious and/or greedy)
> 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.
I agree, but cleanliness of the code (performance /and/ functional
appearance of execution of) itself is what I'm concerned with directly.
(Simply said, my use of this Aqua changeset is primarily to increase UI
responsiveness. At a guess, perhaps because it uses more bitmaps than
primitives to render windows, I have not yet looked. I will try to get code
when I find myself back there)
> A cleaning and reordering of the menu items would be good too.
Which menu items? All of them? I wouldn't disagree.
> > 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?
What I'm asking, if the compiler is automatically selected based on 'Etoy
use' or 'normal use'. If not, it seems to me to be a cautious inclusion.
> > 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 :)
=) Some day, I really look forward to it.
> > 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 surprised Services is not already included.
> > ...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
Yeah. Performance and 'higher media formats' are my concerns and focuses
with Squeak at the moment; I'm still digging around as I work with things.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 24383 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20041210/e38616b2/Aqua.obj
More information about the Squeak-dev