Stephan Rudlof | 27 Mar 19:44 2000
Picon

Re: [Morphic][BUG?][Drag&Drop] mouseLeaveDragging events occure too many and these at wrong times

Bob and others,

the changeset in the ML mail with subject

"[Morphic][Events][Drag&Drop] Event handler for border crossing mouse
events: What do you think about the implementation?"

(new thread started) supplies a much better solution to the problem as
the suggestion below...

Regards,

Stephan

Stephan Rudlof wrote:
> 
> Here is my suggestion for mouseUp events: HandMorph>>
> 
> handleMouseUp: evt
>         "Stephan's variant..."
>         "Dispatch a mouseUp event."
>         | oldFocus |
>         clickState ~~ #idle ifTrue: [self checkForDoubleClick: evt].
>         "drop morphs being carried, if any"
>         self hasSubmorphs ifTrue: [self dropMorphsEvent: evt].
>         ">>>>>mouseDownMorph = nil ifTrue: [^ self].<<<<<"
>         oldFocus _ mouseDownMorph.
>         "make sure that focus becomes nil."
>         mouseDownMorph _ nil.
>         "mouse focus transaction ends when mouse goes up"
(Continue reading)

Lex Spoon | 17 Mar 11:57 2000
Picon

Re: Performance

Marcel Weiher <marcel <at> metaobject.com> wrote:
> That makes them better factored, not more readable.  In fact, my  
> point is that as the fragments get smaller, readability suffers,  
> possibly to the point of utter incomprehension.  This is certainly a  
> problem in a lot of OO code (one I've been dealing with myself) and  
> some early case studies in AOP use point this out as a major problem  
> as well.  IIRC, the problem was very significant, to the point of  
> making the whole scheme unusable.
> 

Do you remember where you saw these studies?  It sounds quite
intresting.

Lex

AGREE | 17 Mar 03:03 2000

RE: String hierarchy (was: UTC-8 (was ...))

> Whatever you do, please, please, please!!! name the abstract > string class String.  I know that it
involves extra steps, > but IMHO would be best to keep the name pure.
> > Perhaps:
> > String
>      UnicodeString
>          Utc8String
>              AsciiString
> > Whatever the intermediate classes you use or don't use, push > the primitive string calls into AsciiString.

I like this a great deal in principle, but am concerned about breaking a great deal of code, that is unless
String new: automatically generates an asciiString by default unless the string contains non-ascii
codes.  I may be overreacting, and admit I haven't thought at all about it.  In particular,

	String streamContents: [...]

seems to risk being broken in virtually every changeset in the world, without some special presumption or
treatment.  On the other hand, would making such accomodations break the hierarchy?

Finally, is there an ANSI standard issue?

Norton, Chris | 14 Mar 17:01 2000

RE: First impressions [was: Re: Word from the Squeakend]

Hi Henrik.

Many good points...  I'm especially interested in:

	- Why not include some text material in the image: 1) Many people
have modem
	connections. 2) It's easier to find, esp. for a newbie.

Some of us (me, myself & I) don't always Squeak on-line.  That means we
don't have access to the Web from Squeak (I have to go out of my way to get
updates into my "home" image).  I, for one, would appreciate a way to
download the Squeak docs and take 'em home with me (hyperlinked into my
image, of course :-).

Cheers,

---==> Chris

Lex Spoon | 14 Mar 13:36 2000
Picon

Re: Celeste encoding (was: Duplicate messages in Celeste)

> The suggestion to use Windows CP 1252 as a base instead of Latin1 or Latin9
> is a good one; it will make the transition from MacRoman _much_ more painless
> as it includes a lot of the worthwhile MacRoman characters, like
> 6...9 66...99 quotation marks.  UNIX users _can_ get their electronic hands
> on compatible fonts for the X Window system, so not only would the switch
> support all the characters UNIX users are used to, it _could_ support the
> others as well.

Well, my man page formatter has a flag for Latin-1 encodings, but
nothing else.  When Netscape works, it displays things in Latin-1.  So
at least this Unix user would find Latin-1 more familiar and convenient than
anything else.

> 	
> Someone else asked:
> 	Well, isn't Latin-1 the de facto standard for the Internet?
> 
> In a word, NO.  HTML 3.2 is defined in terms of Latin 1, but a lot of the
> Web pages I _have_ to deal with are actually CP 1525.  HTML 4.0 is
> defined in terms of ISO 10646, but it's still not really practical to
> actually _rely_ on that to any marked extent.

So it's not a de facto standard, but an actual specified standard.  All
the more reason to go with Latin-1, it would seem.

Sure there are systems that do it wrong, but how are we to detect which
ones do it wrong and which ones do it right?  Should we really display
correct pages wrong, just so that we can display shabby pages correctly?

Surely, we'd still do isoToSqueak by default when we download a web
(Continue reading)

John Duncan | 23 Mar 14:18 2000
Picon

RE: SqueakEast '00 now on Swiki

A good commentary, but ... considering a weighted demography of computer
professionals, perhaps it is better to divide North America into at least
two sections... :)

-John

-----Original Message-----
From: aran <at> meme.hokudai.ac.jp [mailto:aran <at> meme.hokudai.ac.jp]
Sent: Thursday, March 23, 2000 1:10 AM
To: squeak <at> cs.uiuc.edu
Subject: Re: SqueakEast '00 now on Swiki

> I've placed SqueakEast '00 info on the swiki.

>From my vantage-point fourteen time zones east of Pittsburgh, the idea
of using up a perfectly good name like "SqueakEast" for an event that
hasn't even left the local land mass does seem slightly to underplay
Squeak's global ambitions.

Still, I'm sure there are ways to bridge the gap.  I look forward to the
announcement of SqueakEeeeeeeast, somewhere in Europe.

Aran
--
Aran Lunzer                 aran <at> bigfoot.com
Meme Media Laboratory       lab: +81 11 706 7255 / fax 7808
Hokkaido University
Sapporo 060-8628, JAPAN     http://ca.meme.hokudai.ac.jp/people/aran/

(Continue reading)

Bert Freudenberg | 31 Mar 11:46 2000
Picon

Re: [BUG][FIX][UNIX] VM bugs and make problems

On Thu, 30 Mar 2000, Michael Rueger wrote:

> 2) The target headless in the make file is missing

You have to run "../conf/configure --without-x" manually from the build
directory ... But you're right, that's not obvious, and there are some
minor (known) bugs - like HEADLESS not getting defined with certain
autoconf versions. A workaround is to put this on top of sqXWindow.c:

#ifndef HAVE_LIBX11
#define HEADLESS
#endif

> Andreas hacked a workaround, but maybe one of the countless ;-)
> config/make wizards can fix this?

You could automate this by inserting the following in the toplevel
Makefile:

reconfigheadless <at> :
		 <at> $(MAKE) CONFARGS=--without-x reconfig
		 <at> -/bin/rm -f $(TARGET)/sqXWindow.o

Then you just have to type "make reconfigheadless squeak" to build a
headless vm.

  -Bert-


(Continue reading)

Lex Spoon | 5 Mar 15:05 2000
Picon

Re: How to handle Attachments with Celeste?

"Bernhard Pieber" <pieber <at> acm.org> wrote:
> I am considering using Celeste as my mail reader. I have some questions to
> those of you do so already.
> 
> If I receive a message with an attachment, like an Excel file, how can I
> reconstruct that file from the encoded version in the message? Can I do it
> from Squeak or do I need an external tool? Which tool would you suggest? And
> how about attaching such a file to a message I compose in Squeak?
> 

Celeste doesn't handle attachments.  What I do (on Unix) is use "save
message" and then run metamail on it.

If anyone wants to implement multip-part messages in Celeste, that would
be great.  The easiest approach seems to be to extent MailMessage with
code for dealing with multiple parts, and then extending Celeste with a
UI for viewing these parts.  I would have done it long ago if I could
have thought of a good UI, but I haven't, and so it's never gotten done.

Heck, if someone can just propose a UI for multipart messages, that
would be progress over the current situation.

Lex

Bert Freudenberg | 2 Mar 17:32 2000
Picon

Re: [Bug][Fix] Unicode characters in HtmlParser

On Thu, 2 Mar 2000, Mark Guzdial wrote:

> My Sophomore Squeak-learners are developing personal newspapers drawn 
> from other news web sites, and they found that ESPN's site has 
> Unicode characters in it (via ampersand stuff) that breaks the 
> HtmlParser and Scamper. 

Well, there are a lot of specialEntities like umlauts (&auml;) etc. that
are not currently handled correctly. Also, iso8859-1 to Squeak charset
conversion is not done. I posted a changeset a while ago but it didn't
make it into the image - it's the third attachment in
	http://swiki.gsug.org/SQFIXES/275

  -Bert-


Alan Kay | 6 Mar 20:10 2000
Picon

RE: [ENH] Anti-aliasing type support & FreeType 2.0 betaplugin(very beta)

Good luck, Andrew!

Cheers,

Alan

-----

At 10:59 AM -0800 3/6/00, agree <at> carltonfields.com wrote:
>> As I have said several times before, I don't think there is > anything
>>in the
>> patent that wasn't covered by prior art ... (but reality > doesn't always
>> hold sway in court ...).
>
>Indeed.  The problem is that to prove a patent invalid, one must do so to
>the satisfaction of a jury by clear and convincing evidence.  The C&CE
>standard is the highest standard used in civil cases, analogous to "beyond
>a reasonable doubt."  Ultimately, when a jury (just six or so guys off the
>street) is sitting cross-eyed after a week-long (if lucky) trial of
>meaningless gobbledygook, and the judge says that they must find for the
>plaintiff unless the hold a strong and unwavering conviction of invalidity
>-- well, you can guess where things stand.  In practice, to litigate
>invalidity, you pretty much have to plan on winning after appeal, which is
>very, very expensive.
>
>It is for this reason that I believe it is essential that the standard
>applied for validity over prior art not considered by the patent examiner
>be decided by the usual "preponderance of the evidence" standard.  I
>intend to get frighteningly political on this point, as I believe it is
>the essential flaw in the patent system today; the rest being wounds that
(Continue reading)


Gmane