Alright =)

----- 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
> welcome.
>
> Stef
>
>

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.

-Lyndon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Aqua.cs
Type: application/octet-stream
Size: 24383 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20041210/e38616b2/Aqua.obj