Squeak-dev May 1999

squeak-dev@lists.squeakfoundation.org

126 participants
289 discussions

Re: Thinking about a better UI (volume of discussion)
by merlyn＠stonehenge.com 20 May '99

20 May '99

>>>>> "Peter" == Peter Crowther <Peter.Crowther(a)IT-IQ.com> writes: Peter> I repeat my offer: if anyone wants 'news' access to this group, Peter> where it is possible [depending on your newsreader] to kill Peter> threads and therefore not see followups, please mail me Peter> directly. If there's enough interest, I'll set up a private Peter> newsgroup with access passwords to try to prevent general spam Peter> on the list. Or, you can upgrade to GNUS, the mail/news-reader inside GNU Emacs, which reads mailing lists as if they were news under a unified model. Scorefiles... threads... etc etc. Very nice. -- Name: Randal L. Schwartz / Stonehenge Consulting Services (503)777-0095 Keywords: Perl training, UNIX[tm] consulting, video production, skiing, flying Email: <merlyn(a)stonehenge.com> Snail: (Call) PGP-Key: (finger merlyn(a)teleport.com) Web: <A HREF="http://www.stonehenge.com/merlyn/">My Home Page!</A> Quote: "I'm telling you, if I could have five lines in my .sig, I would!" -- me

1 0

Re: Thinking about a better UI (volume of discussion)
by Lex Spoon 20 May '99

20 May '99

> Using Notes has really slowed me down at reading email, as > it has to go out to a server for each and every piece of mail. All in all, I > really dislike it. Are any of the web-based services like HotMail good at > handling large volumes of email? > > Do they have a pop server? Or do people just not read work email from home? If they have POP, then most any mail reader will work with it. Just an idea. Maybe the droids over there could be convinced of the utility of a POP server. Lex

1 0

Re: Thinking about a better UI
by Marcel Weiher 20 May '99

20 May '99

> From: Joachim Durchholz <joachim.durchholz(a)munich.netsurf.de> > Marcel Weiher wrote: > > > > > 1) Why this difference? (This question probably doesn't go to Squeak > > > in general but to Andreas Raab.) > > > > Because Windows got it wrong... I don't know if commnd-key > > equivalents were present in early ST UIs, but I know that c/v/x for > > copy/paste/cut were present in the Mac UI using the Option Key, > > predating Windows by quite a bit. Since Control-Key combinations are > > needed to type control sequences, this makes sense. Why Gates > > messed up on this I haven't a clue. > > They didn't mess it up. Windows just has two command keys: Ctrl and Alt. > Roughly speaking, Alt is for activating the window menu and Ctrl is for > doing things directly without going through a menu. I think this is very > useful. Yes it is. The problem (I think) is that this is one modifier key short of what is needed, Apple and NeXT had 3 (in addition to shift). Apple Key: Menu shortcuts (Command key on NeXT) Option Key: Special characters (Alt Key) Control Key: Control characters The problem with using the Control key for menu shortcuts is that it isn't available for typing control characters. Maybe it's the best they could do with the hardware that was available, AFAIK, newer PCs have an additional 'Windows' key. Marcel

8 7

RE: Thinking about a better UI (volume of discussion)
by Peter Crowther 20 May '99

20 May '99

> The reality is that in this format, message volume is going > to surge from time to time. And, there just isn't a good solution to that > problem at the moment. What would be nice is a server side solution where > one could tune out certain threads. Or, only get the first message in a > thread and ignore follow ups unless the user declares an interest in the > thread. It's called a _newsgroup_, preferably on a dedicated news server, and there was no interest at all last time I broached the subject [in fact, several people mailed to tell me they actively *didn't* want a news server]. I repeat my offer: if anyone wants 'news' access to this group, where it is possible [depending on your newsreader] to kill threads and therefore not see followups, please mail me directly. If there's enough interest, I'll set up a private newsgroup with access passwords to try to prevent general spam on the list.

1 0

RE: Platform independent abstractions on platform specific models
by Norton, Chris 20 May '99

20 May '99

Hi Stephen! > Stephen Pair [SMTP:spair@advantive.com] said: I like the policies idea. [some has been stuff snipped] > I think time is better spent improving the Squeak UI rather than making it > look like other UIs (of course others may find it worthwile to emulate > other > windowing systems). > [snip] > To me, the ultimate would be to have many native OS windowing systems > wrappered and available if desired. Tools and applications could come in > several UI flavors: MVC, Morphic, or any of a number of host windowing > systems. > [Norton, Chris] That's the idea. I don't want to preclude native windows / widget support, but rather I'd like to encourage some enterprising Squeak-hacker to implement it in a generic way (Policy wrappers!). If a nice framework were in place, then I suspect the native support would soon follow (some native support prototypes already exist, I believe). I can understand your reluctance to implement multiple look policies for a single platform for all widgets. However, it might be very useful to implement such a policy for a few widgets. Here's a great daydream: what if we could create a new application using Squeak and set the look policies to "apply native look policies if they are available". Thus, on an OS like Windoze, my Squeak app would approximate any other commercially available software. But it would also run with the same functionality on a Unix box with no native support. On that platform, the look policies would default to "generic" which, of course, would either be MVC or Morphic. In order for Squeak to become widely accessible, I believe that it must support native controls and API calls for at least one or two platforms. If we could produce "ready to sell" applications with Squeak, we could convince our respective employers that Squeak is a viable development environment. As it is today, Squeak is really cool, but it's a toy / research tool. I don't know about your company, but mine won't be porting to Squeak anytime soon. However, it would really be cool if somebody with real graphics design talent were to look over the existing Squeak widgets and create a new "look policy" for some / all available widgets. We could trade these policies with each other and come up with a huge repository of look policies! I expect that human-to-software interface will change rapidly over the next few years (if history is any guide). Plug & play look policies would ensure that Squeak is forever on the vanguard of technology. ---==> Chris

2 1

Assertions
by Benoit St-Jean 20 May '99

20 May '99

For those of you who don't have the time to integrate signatures in the Squeak environment or for those who want a fast and simple way to have some kind of assertion mechanism within Squeak, here's a quick and dirty Assertion mechanism. 2 attached files Content-Type: application/octet-stream; name="Assertion.st" Content-Disposition: attachment; filename="Assertion.st" Attachment converted: Anon:Assertion.st (????/----) (0000A758) Content-Type: application/octet-stream; name="Object-BSTJ-Additions.st" Content-Disposition: attachment; filename="Object-BSTJ-Additions.st" Attachment converted: Anon:Object-BSTJ-Additions.st (????/----) (0000A759) ____________________________________________________________________________ Benoit St-Jean Creative Technologies International 871-8585 #234 1440 Ste-Catherine ouest, Bureau 400 email (work) : bstjean(a)creative.ca Montreal, Quebec, Canada, H3C 3R7 (home) : lamneth(a)aei.ca The opinions expressed in this message are my own personal views and do not reflect the official views of CTI

2 1

Off topic - SETI@home
by thomas k. 20 May '99

20 May '99

At the risk of being slammed, I am passing this along for anyone who might be interested. SETI@home officially launched Monday, 5/17/99. Let your computer be crunching numbers for SETI when it would otherwise be idle. Available for Windows, Mac and Unix. It's FREE, easy to use and could contribute to the discovery of intelligent life beyond this site. For more info or to participate, visit: http://setiathome.ssl.berkeley.edu thomas k.

1 0

Re: Thinking about a better UI
by Joachim Durchholz 20 May '99

20 May '99

agree(a)carltonfields.com wrote: > > > "Andrew C. Greenberg" wrote: > > > By the way, good messaging code makes for lousy function-based > > > programming, stylistically speaking -- if you think in terms of > > > functions, there's lots of global state being thrown around, > > > Global state? I don't see much global state. Message sends > > > (by any name) just pass values forth and back. These objects may > > > be large, but they are not global: you can always create a second > > > instance. > > Well, for starters, the class and metaclass structure, the structure > and existence of which is presumed in Joachim's model of messaging as > procedures, is a global state. Yes. As is the class structure in any OO language. Or with available funtions and modules in any programming language, OO or not. There's no problem with large global state as long as that state is immutable. Given that most Smalltalk code doesn't modify the class structure at run-time, I don't see a problem here. I hope it is consensus here that creating or destroying a class or method at run-time is a dangerous operation that application code should with proper care if at all! > And with respect, the "big object" dodge distinctly distinguishes :(( > modern procedural programming methodologies, where the very point > of a parameter list is *narrow* the state that is being considered. An interface can still be very narrow even if the passed objects are huge. This is not a dogde, this is the standard way of doing abstractions. The important point being, of course, that the callee doesn't make use of everything in the large parameter; it just uses a specific protocol of what it's being passed. Smalltalk doesn't have a formal way of specifying this, but I think the Squeak methods limit themselves in exactly this fashion. I conclude this from the fact that Squeak is working - it would have collapsed under the sheer complexity and intricate interdependencies of that wide-interface coding style :) > Under Joachim's model, no multiple-parameter functions are needed at > all, since all function calls can be modelled as a single-parameter > call, passing just the "large object," call it "mobyMemory." Sorry, this is grossly misrepresenting what I said. Please do me a favor and don't select the most unreasonable interpretation of what I say just to make a point. > > As long as the side effects are limited to the objects involved as > > parameters passed or results returned or being the message > > recipient, this is as side-effect-free as one can get when doing > > real work. Of course, the objects may be large, but that is not a > > problem in itself. > > This is mere wordplay. An object that is taken to be a large "local > state" is methodologically equivalent to using global function calls. > Indeed, Joachim's argument can be applied to C as well to argue there > can be no side-effects or global variables in a c-function. After > all, a C-function call is just a function call with an implied (albeit > large) parameter to the global state. Wrong. You cannot have two sets of global variables in C. Globals are wrong for two reasons: 1) Because you cannot have two of them if you need them, so reusing the code in a context where the globals become instances is often impossible. 2) Because globals tend to be a very wide interface. You keep talking about (2), I was addressing just (1). No wonder you're finding deficiencies in my arguments :} > > Well, a method should name which of its parameters it modifies (in > > an abstract sense: it is OK if some object just does some caching > > or otherwise not externally visible things). > > This, of course, points out a fundamental *pedagogical* difference > between the method and the message. The message doesn't care about > (or even relate to) any underlying structure of the object -- it > doesn't impliedly "name" the parameters it modifies. The message > > aStream next > > may or may not make a reference to a collection and point, to a file > or to a seed for a random number generator. Nor does every method > called to implement a message for a particular class need to know > everything there is to know about the local state to function, when > it can define the operations by way of messaging. It is the > difference between focusing on the protocols and focusing on the > implementation. I don't understand what you're saying here. > > > and of course, the problem that every Squeak > > > "function" is and can be a coroutine. > > > This is new to me. How this? > > I wrote a pipe-and-filter implementation as an example in a recent > colloquy with Marcel, all entirely in Squeak, and all without using > any operating system calls. Each filter is written precisely as > though it completely runs through its input stream, along the lines > of: > > inStream atEnd whileFalse: [ outStream nextPut: inStream next ] > > Each filter cedes the machine when its streams aren't available as > expected, and ultimately the filterStream (sorry Marcel :-) ) has the > desired overall effect. Sure, this can be coded in an operating > system (which views processes as coroutines), but it is not > "inherent" in each C program. Yes, that's one way of how filters can work. However, how do you stop the processing? If you're doing it with blocks, you're just using closures: hardly an OO-specific technique. > > You seem to have undergone a mental shift lately, so you may > > be able to explain it to somebody who obviously hasn't lately. > > Please do! > > I have been trying to do so. :-) Bear with me. Indeed :) > Meanwhile, my suggestion is to defer to others, particularly guys > like Alan, while you mess with it -- build something real, and build > it again. See how much less painful it is to "build one to throw > away," as each refactoring gets better, simpler and more functional. > Eventually, you start discarding "old tricks," stop trying to > "optimize" things you routinely considered a principal priority, and > when the entire result actually runs better, faster and more cleanly > than your other efforts, you'll see that "something" is "different." > > If it was easy to articulate reasons for this, Smalltalk would not > have been so fixed all these years in its status as a minority > programming language. Well, I have always being rather insistent on getting explanations why. I keep getting on people's nerves with that habit, but it helped me gain lots of interesting insights. Apologies if anybody finds this irritating. Regards, Joachim -- Please don't send unsolicited ads.

4 4

68k SoundCodec and 3D libraries
by Bruce O'Neel 19 May '99

19 May '99

Hi, Just to be a shade perverse I built the SoundCodecPrims and Squeak3D libraries for 68k macs. This means that Play With Me 7 now works on 68k macs. Now, before you get all excited I only have an LC040, ie, one without hardware floating point, so, I built it *WITHOUT* the hardware floating point instructions. So what this really means is that you can brew and drink a cup of coffee between each example command in PWM7. If someone has a full 040 or a an 030 with a FPU I'm happy to build with the FPU instructions for you. The file http://www.mindspring.com/~beoneel/68k_3d_codec_prims.sea.bin contains both shared libraries as well as CW11 project files to build them. I haven't tested the SoundCodecPrims yet, but, I think it will work. cheers bruce

1 0

Re: Platform independent abstractions on platform specific models
by Joachim Durchholz 19 May '99

19 May '99

"Norton, Chris" wrote: > > This is a subject that I have spent some time thinking about (& I've > posted stuff on it twice). I agree with you when you suggest that > platform abstractions should be handled outside of the VM. A class > based system is great, because you can easily maintain it without > having lots of custom C++ VM code to re-write. Besides, stuff outside the VM is easer to activate if case you have to act out-of-character for a while. Imagine building or parsing file names for a Windows machine on a Linux Squeak: impossible to reuse if there's a built-in policy in the VM; a matter of a bit tweaking if it's all Smalltalk source code. Regards, Joachim -- Please don't send unsolicited ads.

1 0

← Newer
1
...
7
8
9
10
11
12
13
...
29
Older →

Jump to page: