[Squeakfoundation]re: TrueType font support and 3.6

Sun Jun 22 15:30:33 CEST 2003

> Andreas, does this help?

Abstractly yes, concretely I'm not sure. I'll give you my take on it in the
TTF discussion:

* Is it the simplest thing that could possibly work?

I would claim so. When Yoshiki first did it I was more than just a little
surprised to see not only that he'd done it but also how simple it was. I
had been looking into this myself and there were a number of problems where
I simply had no idea how to do them (most importantly how to deal with color
changes in the text). Given that Yoshiki's code does not require any kind of
low-level surgery (such as new primitives, BitBlt combination rules etc),
yes I claim it is absolutely the simplest thing that could possibly work.

* Does it have dead code?

The one method you mentioned (and where I still don't understand the
critique about sending to super and implicitly returning self ;-) seems
unused. I've attached a fix which simply removes it.

* Does it have extensions to classes which are not strictly required?

All of the extensions are required.

* Does it break or undo other peoples work?

There is one conflict with an MCP change to which a fix is attached.

Summary: If I take your measures then to me everything's fine with the two
attached minor changes.

Cheers,
  - Andreas

> -----Original Message-----
> From: squeakfoundation-bounces at lists.squeakfoundation.org 
> [mailto:squeakfoundation-bounces at lists.squeakfoundation.org] 
> On Behalf Of Daniel Vainsencher
> Sent: Sunday, June 22, 2003 3:33 AM
> To: Discussing the Squeak Foundation
> Subject: RE: [Squeakfoundation]re: TrueType font support and 3.6
> 
> 
> I'll take that as a reminder that we haven't yet created the official
> submission/review policy we talked about last week. Here's a draft -
> 
> Code submitted should be the simplest thing that could possibly work
> (*), where "work" is defined as providing the functionality promised
> (ENH) or correcting the bug (FIX) without creating others.
> 
> (*) note that this precludes, among other forms of complexity -
> 1. Dead code that does nothing.
> 2. Extensions to existing classes that are not strictly 
> required for the
> code to work.
> 3. Breaking or undoing other peoples changes.
> 
> Andreas, does this help?
> 
> Daniel
> 
> Andreas Raab <andreas.raab at gmx.de> wrote:
> > Hi Daniel,
> > 
> > > > If alpha is closed without the TTF stuff
> > > > it means you've delayed the most important improvement to 
> > > > Squeak's user interface in the last three years.
> > > Have you ever failed a test because you didn't put in the 
> > > effort and had to do it over? did you blame the teacher for
> > > writing the test? 
> > 
> > Yes, but in these situations the rules were clear to me and 
> I knew what
> > exactly I should have done differently.
> > 
> > Again: Please explain to me what your desired code quality 
> is. What measures
> > do you use? What are the rules?
> > 
> > > You may see things so that you think that I'm delaying 
> this code, but
> > > this code could easily be cleaner, and you know it, and you can do
> > > something about it just as easily as me.
> > 
> > Only if I know the rules. Otherwise I can only wait until  
> there is some
> > critique here or there and depending on your workload this 
> may take days,
> > weeks, or months.
> > 
> > > [Conflicts are hard to find]
> > > Well, yes. Do you think that the fact that conflict 
> detection is hard
> > > means that we should ignore it?
> > 
> > You lost me here. Finding potential conflicts with other 
> packages is quite
> > simple once you've got the stuff loaded. Just go into a 
> dual change sorter
> > and choose "conflicts with other change sets" and it'll 
> list you all of
> > them. Then you turn on the diffs and voila! all your 
> conflicts get nicely
> > highlighted. Fixing them can be a different matter though ;-)
> > 
> > > [DecPools and KCP]
> > > The fact that conflicts with packages are hard to solve is a sad
> > > consequence of not having package releases. It is made more 
> > > difficult by having more packages, but the solution is not
> > > in going back to a monolithic image, but in improving our
> > > infrastructure (SM1.1).
> > 
> > You lost me again. I don't see how the above is related to 
> my question about
> > how to handle a concrete case in a concrete situation. 
> Please explain.
> > 
> > > Wish I could give you a release date for that, but I can't.
> > 
> > I sure hope it's soon. I already started to manually mirror 
> important
> > packages in order to be able to rely on the right versions. 
> It sucks like
> > hell but there's nothing else I can do.
> > 
> > > When we're talking about a package, like RB, what I did 
> was fork it into
> > > two packages. When we're talking about a patch like 
> DecPools, I would
> > track
> > > the current alpha, because the version for an old 3.6 won't be
> > particularly
> > > useful to anyone.
> > 
> > I think it's quite valuable to have it available for older 
> Squeak versions.
> > The point is that someone may want to load a package which 
> contains a
> > declarative pool in something like 3.4/3.5. Having the 
> package at SqueakMap
> > means that they have at least a chance to try it.
> > 
> > Cheers,
> >   - Andreas
> > 
> > _______________________________________________
> > Squeakfoundation mailing list
> > Squeakfoundation at lists.squeakfoundation.org
> > http://lists.squeakfoundation.org/listinfo/squeakfoundation
> _______________________________________________
> Squeakfoundation mailing list
> Squeakfoundation at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/listinfo/squeakfoundation
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: RemoveGrafportMethod.1.cs
Type: application/octet-stream
Size: 180 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/squeakfoundation/attachments/20030622/003b62f2/RemoveGrafportMethod.1.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: FixConflict.1.cs
Type: application/octet-stream
Size: 1963 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/squeakfoundation/attachments/20030622/003b62f2/FixConflict.1.obj