I'm not using NAV. I am using Virex, so I disabled that just for kicks and restarted. No difference. I just DL'd Squeak again, and it's the same as the one I got about a month ago. The VM appears to be Squeak 3.0Alpha8MT. I have both the image that came in that package, and the fully updated 3.1 image. They both behave the same way. For what it's worth I'm on a Mac G4 with OS 9.04.

Thanks, Glenn

Glenn,

This phenomenon has been seen when running older versions of the Mac VM on systems that have the Norton Antivirus extension installed.

I believe that recent Mac VM's claim not to have this problem (starting, IIRC, with 3.0.11) though I've never actually heard positive confirmation of this.

For a start, try disabling the NAV extension (if you're using it) and see if the problem goes away. Then try installing a newer version of the VM, re-enable NAV, and see if all is well.

Please let us know what you find out!

Cheers,

-- Scott

At 12:06 PM -0400 7/31/01, Glenn S. Fisher wrote:

...

... I'm working on a Mac and noticing a strange and annoying behavior. When I move another active application window in front of the Squeak window, the Squeak window remains active, sort of. Mouse movements and clicks pass through the active application window to the Squeak window and cause menus to open, items to be selected, etc. This doesn't happen if I remember to collapse the Squeak window, so there is a work around. It's just a little annoying.

-- Glenn S. Fisher CTO Websound, Inc. 802.254.3800 ext.202 gfisher@websound.com

Hi all

The following citations have prompted me to answer. I perceive them as summarizing the key points to this important discussion. I like to propose a moderate, easy to implement solution which solves a real problem which has prompted several people in the past to quit this list.

Dan Shafer wrote: (emphasis added by me)

Following threads was very difficult at best and _filtering out topics_ in which I was not interested proved all but _impossible_.

Rosemary Michelle Simpson wrote: (additional emphasis added by me)

The issue, I think, is having a variety of tools for different mindsets that captures the same material. This is the issue faced by information structure designers and indexers - providing different gateways into and _different_ structures over the same material. Thus, we need the mailing list _plus_ other tools that could feed the mailing list content into

(1) spatial hypertext interfaces for exploring related material such as the ConceptLab project I'm currently working on,

(2) database archives such as the Yahoo archive only with much much more flexible and powerful toolsets,

(3) Swiki pages, and other vehicles as people think of them.

The point is that _the mailing list is not the problem_; the lack of other tools over the same material is.

In the rest of the email I will follow the outline:

1. Mailing list as the main discussion channel in the Squeak community 2. Swiki use 3. Advantages of a mailing list 4. Proposal: Additional Squeak Mailing List Conventions to aid filtering 5. Summary 6. Further steps

1. Mailing list as the main discussion channel in the Squeak community ----------------------------------------------------------------------

When thinking of changeing away from the mailing list one has to bear in mind that this list is the main discussion channel in the Squeak community which feeds various derived services.

See Squeak Email List *http://minnow.cc.gatech.edu/squeak/608*

This list is the source of various extracts:

See: Mailing List Archives *http://minnow.cc.gatech.edu/squeak/775*

The German Smalltalk users group runs a Swiki with just the extracts of the topics marked with [Bug] and [Fix]

- Bug Reports Archive at *http://swiki.gsug.org/sqbugs/* - Bug Fixes Archive at *http://swiki.gsug.org/sqfixes/*

See Reporting Bugs and Fixes *http://minnow.cc.gatech.edu/squeak/398* for more information on this

The mail archive in Vienna (for example *http://macos.tuwien.ac.at:9009/MailArchive.recentTopics*) powered by the original Squeak powered web server by Georg Gollmann has now about 40000 entries. (*http://macos.tuwien.ac.at/English.html*). It seems that this useful service has been happily running without too much interaction by Georg.

Note on mail reader: A mail reader with processing rules is helpful in dealing with the 1000 or so messages a month this list generates. (e.g. I'm using MS Outlook at the moment). This already eases the task considerably. (see also proposal for additional tags below)

2. Swiki use ------------

We have a Swiki which is not yet used to it's full potential.

I think there should be more interaction between this list and the swiki such as - cross-reference to a swiki page - take out a specialised discussion to the swiki - edit a summary of a discussion on this list an put it onto a swiki. - discuss something here and put it in the swiki faq or recipe collection.

Note: Actually this is already the case. But there could be more of this.

I suppose that many people are not yet used to the idea of editing a website together with other participants ("tele-cooperation", I hope that the word 'cooperation' has no negative connotation in English, in German it is just neutral.)

In the past minnow was unreliable. It's now considerably better.

Hint: Don't forget to consult the 'changed' list often as there you see somehow going on the line of discussion on the swiki.

The purpose of the Swiki is to contain the more 'stable' information.

3. Advantages of a mailing list -------------------------------

I'd like to mention some advantages I perceive:

a) Somewhat more "personal". (In a sense an illusion, because of the archives which actually let the messages appear like in a newsgroup)

b) Allows digression in topics because of it's relatively unstructured approach. Important in discussing research topics, gathering new ideas. (associative/lateral thinking)

c) Implements "forgetting things": Many things uttered here often are draft issues, ideas, suggestions, criticisms (justfied /unjustified).

If it prompts somebody to come with a more useful thought or a solution then it has served it's purpose. The things here can then be forgotten. The ones which are important are picked by somebody and brought in a more definite form. Through the big volume of the list this 'forgetting function' is implemented which I consider important for real advance. You have to give room for unfinished thoughts and change of opinion.

d) Good offline medium: I download the mails on my laptop and then have a database of interesting things available when I'm not connected to the net. It allows people with limited access to the net to participate actively (for whatever reason e.g. cost issue, not in all countries of the world internet access is cheap. If you can download the things in bulk that's fine).

e) Not necessary to follow everything. It doesn't matter if you don't read everything. (BTW For this really to become true we should have more editors who do summaries on the Swiki, excerpts and comments)

4. Additional Squeak Mailing List Conventions to aid filtering --------------------------------------------------------------

This list uses some conventions at the moment (See also 'Reporting Bugs and Fixes' http://minnow.cc.gatech.edu/squeak/398 )

In the title string tags are used in a operative sense: [Bug] Bug report [Fix] Fix for a bug [ENH] Enhancement [GOODIE] Little addition which can be little application or some change of Squeak like changing the appearance [ANN] Announcement of a major addition [Q] Question [Newbie] Question by a newbie or somebody how thinks he is one.

I propose that there would be a considerable benefit in this system if some more generally accepted tags would be used. There should't be too many of them as they have to be known by heart for ease of use.

The following is a proposal for additional content oriented tags: (alphabetical order)

[Deployment] Deployment related topics like "majorShrink" issues, release number questions, configuration questions and the like. [Dynabook] Conceptual issues regarding the dynabook vision and it's implementation. [EToys] EToys related things [HW] Topics related to a specific Hardware (for example iPaq implementation) [IDE] Integrated Development Environment; topics regarding browser variants, inspectors explorers and the debugger. [Idea] Tag for discussing new ideas what to do with Squeak [IO] Input / Output related things like driving a lego RCX, serial connection [Morphic] General Morphic related topics (Design patterns, usage, missing things) [Multimedia] Multimedia issues like how to use squeak for presentations and font, sound, graphic and movie related issues. [Reln.n] Issues specifically in connection with a specific official release n.n like 3.0 (the last one) [SqApp] Squeak applications like Celeste, Scamper, PDAMorph, Nebraska [ST] General Smalltalk related issues [Teach] Discussion on how to teach Squeak or how to use Squeak in teaching. [Tutorial] Squeak tutorials (for example Dan Shafer and John Hinsley asking questions when they are developing tutorials just to mention two recent authors, or users of tutorials who want them to have updated.) [VM] Virtual Machine related topics (VM Maker, code generator, porting efforts) [XP] Recently people have been beginning to use this list as a very moderate kind of Extreme Programming (XP) style through email by posting unfinished things (e.g. change sets) and asking other to participate. This hasn't been the case in the past and I think this is very valuable. However not everybody want's to join in and even shouldn't therefore by having a mailfilter directing the messages marked with [XP] to a subfolder everything would be fine.

Why use this tags?

The tags should serve the sole purpose of dividing up the chunk of a 1000 or so mails per month into more managable chunks.

They should be understandable without having to consult this list. This list has the purpose of coming up with a proposal for a commonly agreed set.

The other purpose of these tags is that derived services are still easy to implement.

Several of the tags can be used in the same message title if necessary.

Tag application examples

For example there are VM implementors which do a excellent job for the community. However that's not in everybodys focus. So a tag discussing VM issues would allow easy filtering and archiving. A swiki like the German User's Groups bug tracking swiki could collect VM-related things.

Another example: Some people are interested in EToy others are not. This tag helps to separate mail.

The [Teach] tag could be used to set up a swiki with copies of the mails where people could further add things for tutorials and instructions.

Implementation of these additional tags

Additional tags can be introduced gradually as we need them. And they can as well be used without to much consultation as long as we don't have too many of them (say less then 20).

5. Summary ----------

I consider it important to organize the discussion around concepts. For this purpose the mailing list is a valuable tool.

However to facilitate automatic processing / filtering it helps to have a common more or less agreed set of general tags. Somewhat overlapping tags are OK as as long as there are not too many.

So I propose to use semantic tags like the ones listed under Point 4 consistenly in the title string of the mails. Implementation: 'As we go along, just use them'. *Nobody* will complain having some more tags in the title string.

The costs of implementing other solutions are considerable for the community. This solution costs very little (time and cognitive effort) but brings a big additional value with existing tools and setups.

6. Further steps ----------------

I put this mail unchanged (besides some formatting) as well on the Swiki:

http://minnow.cc.gatech.edu/squeak/1962

Just edit it and change it or add things. You may reedit it completely. I don't mind or if I do, I will change things again. ;-)

I would like to see a more or less commonly agreed tagset ("controlled thesaurus").

This does not contradict the the fact that we can already *start now* using these additional tags. We'll see what works and what doesn't. It will be no big issue if for some time there is some inconsistency. In fact it will be better not worse. It was actually the same thing with the already existing tags.

A typical very simple application scenario will then be to set up a mail filter which puts mails within one group of tags (a personal selection) in one folder and the rest in another folder.

Hannes Hirzel

Hello Hans, I've done quite a bit work producing web sites and pages through "tele co-operation", the Open University tends to call it online collaboration, but "tele-cooperation" would sound OK to an English person.

One of the main lessons I learned is to not wait for total or majority consensus in a project but to make a start on the project and then others will join in because otherwise things won't get done or drag on.

I propose that anyone who wishes to implement a new system that collaborates with the mail list, does so and then we can see if others take to it, use it or find it useful.

For me personally, if someone got the list working as a newsgroup that collaborated with the mail list, I would use Free Agent as I have the same preference as Dan Shafer.

:-)

Thanks! Gary

----- Original Message ----- From: "Hannes Hirzel" hirzel@spw.unizh.ch To: squeak-dev@lists.squeakfoundation.org Sent: Wednesday, August 01, 2001 12:31 PM Subject: Re: [OT] How We Discuss Things

Hi all

The following citations have prompted me to answer. I perceive them as summarizing the key points to this important discussion. I like to propose a moderate, easy to implement solution which solves a real problem which has prompted several people in the past to quit this list.

Dan Shafer wrote: (emphasis added by me)

...

Following threads was very difficult at best and _filtering out topics_ in which I was not interested proved all but _impossible_.

Rosemary Michelle Simpson wrote: (additional emphasis added by me)

...

The issue, I think, is having a variety of tools for different mindsets that captures the same material. This is the issue faced by information structure designers and indexers - providing different gateways into and _different_ structures over the same material. Thus, we need the mailing list _plus_ other tools that could feed the mailing list content into

...

(1) spatial hypertext interfaces for exploring related material such as the ConceptLab project I'm currently working on,

...

(2) database archives such as the Yahoo archive only with much much more flexible and powerful toolsets,

...

(3) Swiki pages, and other vehicles as people think of them.

The point is that _the mailing list is not the problem_; the lack of other tools over the same material is.

In the rest of the email I will follow the outline:

1. Mailing list as the main discussion channel in the Squeak community

2. Swiki use

3. Advantages of a mailing list

4. Proposal: Additional Squeak Mailing List Conventions to aid filtering

5. Summary

6. Further steps

7. Mailing list as the main discussion channel in the Squeak community

---

When thinking of changeing away from the mailing list one has to bear in mind that this list is the main discussion channel in the Squeak community which feeds various derived services.

See Squeak Email List *http://minnow.cc.gatech.edu/squeak/608*

This list is the source of various extracts:

See: Mailing List Archives *http://minnow.cc.gatech.edu/squeak/775*

The German Smalltalk users group runs a Swiki with just the extracts of the topics marked with [Bug] and [Fix]

• Bug Reports Archive at *http://swiki.gsug.org/sqbugs/*
• Bug Fixes Archive at *http://swiki.gsug.org/sqfixes/*

See Reporting Bugs and Fixes *http://minnow.cc.gatech.edu/squeak/398* for more information on this

The mail archive in Vienna (for example *http://macos.tuwien.ac.at:9009/MailArchive.recentTopics*) powered by the original Squeak powered web server by Georg Gollmann has now about 40000 entries. (*http://macos.tuwien.ac.at/English.html*). It seems that this useful service has been happily running without too much interaction by Georg.

Note on mail reader: A mail reader with processing rules is helpful in dealing with the 1000 or so messages a month this list generates. (e.g. I'm using MS Outlook at the moment). This already eases the task considerably. (see also proposal for additional tags below)

2. Swiki use

---

We have a Swiki which is not yet used to it's full potential.

I think there should be more interaction between this list and the swiki such as

• cross-reference to a swiki page
• take out a specialised discussion to the swiki
• edit a summary of a discussion on this list an put it onto a swiki.
• discuss something here and put it in the swiki faq or recipe collection.

Note: Actually this is already the case. But there could be more of this.

I suppose that many people are not yet used to the idea of editing a website together with other participants ("tele-cooperation", I hope that the word 'cooperation' has no negative connotation in English, in German it is just neutral.)

In the past minnow was unreliable. It's now considerably better.

Hint: Don't forget to consult the 'changed' list often as there you see somehow going on the line of discussion on the swiki.

The purpose of the Swiki is to contain the more 'stable' information.

3. Advantages of a mailing list

---

I'd like to mention some advantages I perceive:

a) Somewhat more "personal". (In a sense an illusion, because of the archives which actually let the messages appear like in a newsgroup)

b) Allows digression in topics because of it's relatively unstructured approach. Important in discussing research topics, gathering new ideas. (associative/lateral thinking)

c) Implements "forgetting things": Many things uttered here often are draft issues, ideas, suggestions, criticisms (justfied /unjustified).

If it prompts somebody to come with a more useful thought or a solution then it has served it's purpose. The things here can then be forgotten. The ones which are important are picked by somebody and brought in a more definite form. Through the big volume of the list this 'forgetting function' is implemented which I consider important for real advance. You have to give room for unfinished thoughts and change of opinion.

d) Good offline medium: I download the mails on my laptop and then have a database of interesting things available when I'm not connected to the net. It allows people with limited access to the net to participate actively (for whatever reason e.g. cost issue, not in all countries of the world internet access is cheap. If you can download the things in bulk that's fine).

e) Not necessary to follow everything. It doesn't matter if you don't read everything. (BTW For this really to become true we should have more editors who do summaries on the Swiki, excerpts and comments)

4. Additional Squeak Mailing List Conventions to aid filtering

---

This list uses some conventions at the moment (See also 'Reporting Bugs and Fixes' http://minnow.cc.gatech.edu/squeak/398 )

In the title string tags are used in a operative sense: [Bug] Bug report [Fix] Fix for a bug [ENH] Enhancement [GOODIE] Little addition which can be little application or some change of Squeak like changing the appearance [ANN] Announcement of a major addition [Q] Question [Newbie] Question by a newbie or somebody how thinks he is one.

I propose that there would be a considerable benefit in this system if some more generally accepted tags would be used. There should't be too many of them as they have to be known by heart for ease of use.

The following is a proposal for additional content oriented tags: (alphabetical order)

[Deployment] Deployment related topics like "majorShrink" issues, release number questions, configuration questions and the like. [Dynabook] Conceptual issues regarding the dynabook vision and it's implementation. [EToys] EToys related things [HW] Topics related to a specific Hardware (for example iPaq implementation) [IDE] Integrated Development Environment; topics regarding browser variants, inspectors explorers and the debugger. [Idea] Tag for discussing new ideas what to do with Squeak [IO] Input / Output related things like driving a lego RCX, serial connection [Morphic] General Morphic related topics (Design patterns, usage, missing things) [Multimedia] Multimedia issues like how to use squeak for presentations and font, sound, graphic and movie related issues. [Reln.n] Issues specifically in connection with a specific official release n.n like 3.0 (the last one) [SqApp] Squeak applications like Celeste, Scamper, PDAMorph, Nebraska [ST] General Smalltalk related issues [Teach] Discussion on how to teach Squeak or how to use Squeak in teaching. [Tutorial] Squeak tutorials (for example Dan Shafer and John Hinsley asking questions when they are developing tutorials just to mention two recent authors, or users of tutorials who want them to have updated.) [VM] Virtual Machine related topics (VM Maker, code generator, porting efforts) [XP] Recently people have been beginning to use this list as a very moderate kind of Extreme Programming (XP) style through email by posting unfinished things (e.g. change sets) and asking other to participate. This hasn't been the case in the past and I think this is very valuable. However not everybody want's to join in and even shouldn't therefore by having a mailfilter directing the messages marked with [XP] to a subfolder everything would be fine.

Why use this tags?

The tags should serve the sole purpose of dividing up the chunk of a 1000 or so mails per month into more managable chunks.

They should be understandable without having to consult this list. This list has the purpose of coming up with a proposal for a commonly agreed set.

The other purpose of these tags is that derived services are still easy to implement.

Several of the tags can be used in the same message title if necessary.

Tag application examples

For example there are VM implementors which do a excellent job for the community. However that's not in everybodys focus. So a tag discussing VM issues would allow easy filtering and archiving. A swiki like the German User's Groups bug tracking swiki could collect VM-related things.

Another example: Some people are interested in EToy others are not. This tag helps to separate mail.

The [Teach] tag could be used to set up a swiki with copies of the mails where people could further add things for tutorials and instructions.

Implementation of these additional tags

Additional tags can be introduced gradually as we need them. And they can as well be used without to much consultation as long as we don't have too many of them (say less then 20).

5. Summary

---

I consider it important to organize the discussion around concepts. For this purpose the mailing list is a valuable tool.

However to facilitate automatic processing / filtering it helps to have a common more or less agreed set of general tags. Somewhat overlapping tags are OK as as long as there are not too many.

So I propose to use semantic tags like the ones listed under Point 4 consistenly in the title string of the mails. Implementation: 'As we go along, just use them'. *Nobody* will complain having some more tags in the title string.

The costs of implementing other solutions are considerable for the community. This solution costs very little (time and cognitive effort) but brings a big additional value with existing tools and setups.

6. Further steps

---

I put this mail unchanged (besides some formatting) as well on the Swiki:

http://minnow.cc.gatech.edu/squeak/1962

Just edit it and change it or add things. You may reedit it completely. I don't mind or if I do, I will change things again. ;-)

I would like to see a more or less commonly agreed tagset ("controlled thesaurus").

This does not contradict the the fact that we can already *start now* using these additional tags. We'll see what works and what doesn't. It will be no big issue if for some time there is some inconsistency. In fact it will be better not worse. It was actually the same thing with the already existing tags.

A typical very simple application scenario will then be to set up a mail filter which puts mails within one group of tags (a personal selection) in one folder and the rest in another folder.

Hannes Hirzel