ftp.nice.ch/peanuts/GeneralData/Usenet/news/1990/CSN-90.tar.gz#/comp-sys-next/1990/Apr/Updating-the-Unknown-Application

This is Updating-the-Unknown-Application in view mode; [Up]


Date: Sun 25-Apr-1990 23:39:07 From: lane@sumex-aim.stanford.edu (Christopher Lane) Subject: Updating the Unknown Application Taking Jiro Nakamura's subtle hint in his recent article in Buzzings #5, I'm updating my 'Unknown' application to allow the specification of what Unix utility to invoke on a file, as well as what icon to use. I have this up and running (still needs a little polishing) but could use the following information: What other obvious file to utility associations are there similar to *.Z => uncompress (including switches)? Has anyone come up with icons for use with Unknown (for either current or new entries)? Now would be a good time to send them to me. What other features should the 'Unknown' application incorporate? Thanks for any suggestions, - Christopher -------
Date: Sun 26-Apr-1990 08:50:00 From: rca@cs.brown.edu (Ronald C.F. Antony) Subject: Re: Updating the Unknown Application Maybe it would be better to write an compress/uncompress app. as an icon there could be used something like the SQZ utility uses on the mac. The main thing however should be that this app should do 2 if a .Z file is clicked on, it should do the obvious: decompress it. But what would be nice is if we had something similar to the kill utility in the workspace: just drag in an icon over a window and compress it. Even better: if it is a directory: tar it and then compress it. Well, obviously, an other extension to register would be tar files. (suggested icon: a good old tape roll...) The best thing would be to write a whole utility app that combines the kill, compress, tar, wc etc. utilities in one place. Just have a window with more than on view, and depending on where you an icon, it does something else. Ok, were these enough ideas? :) I guess if I had more time I would do something like this, but at the moment it is quite impossible to find the time. Ronald ------------------------------------------------------------------------------ "The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man." Bernhard Shaw | rca@cs.brown.edu or antony@browncog.bitnet
Date: Sun 26-Apr-1990 20:44:49 From: stone@hydra.unm.edu (Andrew Stone) Subject: Re: Updating the Unknown Application In article <37773@brunix.UUCP> rca@cs.brown.edu (Ronald C.F. Antony) writes: >Maybe it would be better to write an compress/uncompress app. as an ... >But what would be nice is if we had something similar to the kill >utility in the workspace: just drag in an icon over a window and >compress it. Even better: if it is a directory: tar it and then >compress it. >Ronald Erica has been working on just such a model: register the app's miniWorld as listener port to receive the iconDragged:: and iconEntered:: messages, then do your stuff with a system call. Guess what?? Works fine if the miniIcon is out of the dock, but once placed in dock, it no longer responds to icons being dragged in. Why? the dock windowlist tier is "higher" than the workspace icon windows that are dragged around, thus you can't quite get your icon "over" the docked app icon, and no messages are sent. Jason, Bruce, and [welcome back Ali, don't let Paul catch you reading news] any comments or clues? Here's another of those windowlist level things. Has anyone successfully created a floating palette type window? It seems a subClass of menu would do it, but somehow, my instances don't get stuck into the higher list. That is, this new subclass is in the same window list as the rest of the app's windows,so your document will cover the tool palette when clicked on. Even responding to windowDidBecomeKey: is not enough: certain clicks don't send this event. Responding to update: is totally a cpu pig and lacks all aethetic appeal. App group, please prevent _underScoreAbuse:sender, provide us with a floating palette. Or simpler yet, an convincing argument as to why I should never need floating tool windows... andrew ||<<++>>||<<-->>||<<==>>||<<++>>||<<??>>||<<++>>||<<-->>||<<==>>||<<++>>|| !! Andrew Stone !! Stone Design Corp. !! !! stone@hydra.unm.edu <> Albuquerque, New Mexico !! ||<<++>>||<<-->>||<<==>>||<<++>>||<<??>>||<<++>>||<<-->>||<<==>>||<<++>>||
Date: Sun 27-Apr-1990 08:53:14 From: eps@toaster.SFSU.EDU (Eric P. Scott) Subject: Re: Updating the Unknown Application In article <37773@brunix.UUCP> rca@cs.brown.edu (Ronald C.F. Antony) writes: >The best thing would be to write a whole utility app that combines the Swiss Army App!! >I guess if I had more time I would do something like this, but at the >moment it is quite impossible to find the time. You too, huh? I was thinking about making an animated "machine" with gears and pulleys and whistles that Dr. Suess would be proud of... You'd drag files to an input funnel and it would churn and put stars on their bellies XXX perform transformations (compress, uuencode, etc.) and then have the output glide back to the Browser from which the input came... -=EPS=-

These are the contents of the former NiCE NeXT User Group NeXTSTEP/OpenStep software archive, currently hosted by Marcel Waldvogel and Netfuture.ch.