dhg@sinix.UUCP (David Griffith) (05/01/91)
I'm lazy. That's why I like the file browser in Workspace Manager. I hate typing "cd, ls, cd... etc". But here's the problem: you've browsed your way down a deep directory path and decided you want to do something unixy with the files you see. So you'd like to launch a terminal window at the current directory. But you can't! It's so frustrating. New shells always start at your home directory again, so you're back to some heavy typing to get where you want to be. Now this is such an obvious requirement that I'm sure I'm missing some easy way to do it. But I've searched TFM. And it would be so easy to implement. You could just double click on a directory icon. Last night I checked the Tools Inspector for directories, but no luck. I tried dragging a directory icon over Terminal and over Stuart. Still no luck. Anyone know how to do it? On a related note, I was showing off the capabilities of IB to a friend, adding buttons and sliders galore, and she commented "Yes but it's all a bit shallow isn't it?". At first I brushed this remark aside, but perhaps she has a point. Maybe we're all a little too hung up on interfaces and nib's. And there's a limit to the functional changes you can make to a given binary application. For example, I like the BlastApp, but wanted to make it bigger. So I used Simson Garfinkel's NibEdit programs to extract the nibs, entered IB and enlarged the playing area. The program recognized the increased width, but not the height. Then last night I decided to try and add a file browser to the Terminal application to solve my laziness problem. I failed. You can nib edit and interface build to add a menu item to send a message to some object. But the object needs new code and you can't re-link edit an executable file. This is a real pity. It would be a great boost to the idea of object orientated programming on the NeXT if the binary executables somehow still contained relocation information thus allowing you to add new functionality. Almost as good as source code! But then maybe application developers don't like the idea of their applications being ripped apart like some old car for spare parts... Enough rambling. Dave Griffiths
bb@math.ufl.edu (Brian Bartholomew) (05/02/91)
In article <1991May1.142136.19889@sinix.UUCP> dhg@sinix.UUCP (David Griffith) writes: > and she commented "Yes but it's all a bit shallow isn't it?". At first > I brushed this remark aside, but perhaps she has a point. .... And > there's a limit to the functional changes you can make to a given > binary application. Yeah, but it beats the heck out of not being able to make changes at all. > This is a real pity. It would be a great boost to the idea of object > orientated programming on the NeXT if the binary executables somehow > still contained relocation information thus allowing you to add new > functionality. Almost as good as source code! Why re-implement source code? If you want to do things that need source code, get source code. Source allows you the ultimate freedom in reusability. > But then maybe application developers don't like the idea of their > applications being ripped apart like some old car for spare parts... I would personally be flattered if someone thought some code of mine was good enough to use in one of their own apps. I understand (but do not agree with) commercial developers who would rather not see a competitor make a 10% improvement to one of their products by starting with 90% of the developers' code. -- "Any sufficiently advanced technology is indistinguishable from a rigged demo." ------------------------------------------------------------------------------- Brian Bartholomew UUCP: ...gatech!uflorida!beach.cis.ufl.edu!bb University of Florida Internet: bb@math.ufl.edu
jmynatt@ragnarok (Jim Mynatt) (05/04/91)
In article <1991May1.142136.19889@sinix.UUCP> dhg@sinix.UUCP (David Griffith) writes: > I'm lazy. That's why I like the file browser in Workspace Manager. I > hate typing "cd, ls, cd... etc". But here's the problem: you've > browsed your way down a deep directory path and decided you want to > do something unixy with the files you see. So you'd like to launch > a terminal window at the current directory. But you can't! It's so < rambling deleted > What Terminal (or Stuart) needs to do is provide a service which expects a 'thing' (document or directory) and then cd to the appropriate directory before initing or becoming key (if already running). Then the file viewer menu would provide something like Services>Terminal>cd to dir p (or something similar). Of course a new app could be written that provides the service then launches Terminal. Aren't services wonderful? Are you listening Scott Hess? <swede>
ta-aca@cunixb.cc.columbia.edu (Andrew C. Athan) (05/04/91)
>> I'm lazy. That's why I like the file browser in Workspace Manager. I >> hate typing "cd, ls, cd... etc". But here's the problem: you've >> browsed your way down a deep directory path and decided you want to >> do something unixy with the files you see. So you'd like to launch >> a terminal window at the current directory. But you can't! It's so >< rambling deleted > > > >What Terminal (or Stuart) needs to do is provide a service which expects a >'thing' (document or directory) and then cd to the appropriate directory >before >initing or becoming key (if already running). Then the file viewer menu >would >provide something like Services>Terminal>cd to dir p (or something similar). > >Of course a new app could be written that provides the service then launches >Terminal. It is impotant to understand the difference between Terminal (or Stuart) [[The App]] and the program that is running in the Terminal window [[The Shell]]. It is the shell which needs to "cd" Stuart/Terminal have nothing to do with details of what the app in the window is doing (besides acting as one end of a pty). So ... the problem is communicating the "cd" command to csh/ksh/bash/whatever. Probably the only generic guranteed to work solution is to have the Services> item of which you speak "type" a cd command into the window in question. You, as the user of the Service, would have to make sure your shell is at a prompt which can accept the "cd." aca //Email: ta-aca@cunixb.cc.columbia.edu OR athan@cs.columbia.edu
tilley@ccu.umanitoba.ca (Richard Tilley) (05/04/91)
In <1991May3.230846.27038@cunixf.cc.columbia.edu> ta-aca@cunixb.cc.columbia.edu (Andrew C. Athan) writes: >csh/ksh/bash/whatever. Probably the only generic guranteed to work solution >is to have the Services> item of which you speak "type" a cd command into the >window in question. You, as the user of the Service, would have to make sure >your shell is at a prompt which can accept the "cd." I would gladly type the "cd" as long as I could copy and paste the path.
dbg@sinix.UUCP (David George) (05/06/91)
In article <1991May1.142136.19889@sinix.UUCP> dhg@sinix.UUCP (David Griffith) writes: >... >This is a real pity. It would be a great boost to the idea of object >orientated programming on the NeXT if the binary executables >somehow still contained relocation information thus allowing you >to add new functionality. Almost as good as source code! But then >maybe application developers don't like the idea of their applications >being ripped apart like some old car for spare parts... Maybe all these so called "messages" should be like real messages and go through some sort of post office... all you have to do is say "hallo I'M application 'wombat' and I live at this address, then just wait for the mailbox flag to be raised". Still I bet that would make everything horribly slow... Still look on the bright side of life, it's not 5.4, eh? T.L.K.
scott@erick.gac.edu (Scott Hess) (05/06/91)
In article <660@rosie.NeXT.COM> jmynatt@ragnarok (Jim Mynatt) writes: In article <1991May1.142136.19889@sinix.UUCP> dhg@sinix.UUCP (David Griffith) writes: > I'm lazy. That's why I like the file browser in Workspace Manager. I > hate typing "cd, ls, cd... etc". But here's the problem: you've > browsed your way down a deep directory path and decided you want to > do something unixy with the files you see. So you'd like to launch > a terminal window at the current directory. But you can't! It's so < rambling deleted > What Terminal (or Stuart) needs to do is provide a service which expects a 'thing' (document or directory) and then cd to the appropriate directory before initing or becoming key (if already running). Then the file viewer menu would provide something like Services>Terminal>cd to dir p (or something similar). Of course a new app could be written that provides the service then launches Terminal. Aren't services wonderful? Are you listening Scott Hess? Sure. I'm always listening. As pointed out in another post, the main problem is that Stuart really can't be sure who's running in the subshell. Say I drop a file into emacs while running GNUS. You'll be telling it something like "Give me a fried shoe with cheese on it, and force it down my throat". Well, not quite that, of course, but it will make about as much sense. Then again, that's up to the user. If the user can't handle it, that's the user's problem. The Workspace _still_ needs that ability. For instance, if you could copy the pathname of the current file from the Workspace, you could then move to (say) an Open Panel and paste the pathname in there, and it would then go to the path. I'm sure it could be used in other places (say you get a reference to a documentation file - copy and paste it into Workspace to get there). But, as I don't see NeXT jumping on this, I could probably manage to implement something of the sort eventually. Maybe not tomorrow, that's for certain :-). But, eventually . . . what is really needed is a subshell that understands/can work with Stuart. I'd love to have something that I could send special escape sequences and the like to that could then understand those as mouse-based selection, and cut, and copy, and paste. Then, this wouldn't be a problem at all. Would this be a possibility with tcsh? Anyone out there with a AT&T license that would be willing to work on something of the sort this summer? Or maybe it could just be added to Bash? Later, -- scott hess scott@gac.edu Independent NeXT Developer GAC Undergrad <almost out!> <I still speak for nobody>
jmynatt@next.com (05/07/91)
In article <1991May3.230846.27038@cunixf.cc.columbia.edu> ta-aca@cunixb.cc.columbia.edu (Andrew C. Athan) writes: <cruft deleted> > > It is impotant to understand the difference between Terminal (or Stuart) > [[The App]] and the program that is running in the Terminal window [[The > Shell]]. It is the shell which needs to "cd" Stuart/Terminal have nothing > to do with details of what the app in the window is doing (besides acting as > one end of a pty). > > So ... the problem is communicating the "cd" command to > csh/ksh/bash/whatever. Probably the only generic guranteed to work solution > is to have the Services> item of which you speak "type" a cd command into the > window in question. You, as the user of the Service, would have to make sure > your shell is at a prompt which can accept the "cd." > > aca > //Email: ta-aca@cunixb.cc.columbia.edu OR athan@cs.columbia.edu If I write an app which runs a program such as 'csh/ksh/bash/whatever', I can invoke that program with control. If that means i issue a cd and a clear then so be it. Stuart and Terminal have a lot to do with the details of what the app in the window is doing. Stuart/ Terminal / Whatever then app object is, has complete control and can even do things like monitor what you are typing into the Text object (which sits between the window and the program ) and take appropriate action such as capturing typing rates for data entry applications. The user of the Service I was describing is the FileViewer. The Service responder (Stuart or Terminal) recognizes that it has been invoked by a service request (speaker/listener pair) and can get the information needed (directory path) and start up the appropriate program (csh/ksh/bash/whatever) and issue 'cd' commands or whatever. The Stuart/Terminal window opened can be a new one or a existing on (a feature which should be set by the user preferences). Hope this clears things up a bit. jim
glenn@heaven.woodside.ca.us (Glenn Reid) (05/08/91)
Scott Hess writes > Then again, that's up to the user. If the user can't handle it, > that's the user's problem. The Workspace _still_ needs that > ability. For instance, if you could copy the pathname of the > current file from the Workspace, you could then move to (say) > an Open Panel and paste the pathname in there, and it would then > go to the path. I'm sure it could be used in other places (say > you get a reference to a documentation file - copy and paste > it into Workspace to get there). Isn't it interesting that the Workspace Manager has a full "Edit" menu with copy/cut/paste and none of them do anything in the normal browser mode? Nor are they greyed out, as they should be if there is no text object active. I tried "Copy" when sitting on a file path that appealed to me, and it was happy to highlight the "Copy" menu, but nothing got put on the pasteboard, alas. -- Glenn Reid RightBrain Software glenn@heaven.woodside.ca.us NeXT/PostScript developers ..{adobe,next}!heaven!glenn 415-326-2974 (NeXTfax 326-2977)
howie@ivory.cc.columbia.edu (Howie Kaye) (05/09/91)
In article <493@heaven.woodside.ca.us> glenn@heaven.woodside.ca.us (Glenn Reid) writes: > Isn't it interesting that the Workspace Manager has a full "Edit" > menu with copy/cut/paste and none of them do anything in the normal > browser mode? Nor are they greyed out, as they should be if there > is no text object active. > > I tried "Copy" when sitting on a file path that appealed to me, and > it was happy to highlight the "Copy" menu, but nothing got put on > the pasteboard, alas. > Actually, it lets you copy the filename of the selected file from the Icon path. Not too useful, but.... ------------------------------------------------------------ Howie Kaye howie@columbia.edu Columbia University hlkcu@cuvma.bitnet UNIX Systems Group ...!rutgers!columbia!howie
adonis1@nwnexus.WA.COM (Adonis Corporation ) (05/10/91)
In article <SCOTT.91May6135522@erick.gac.edu> scott@erick.gac.edu (Scott Hess) writes: >In article <660@rosie.NeXT.COM> jmynatt@ragnarok (Jim Mynatt) writes: > In article <1991May1.142136.19889@sinix.UUCP> dhg@sinix.UUCP (David Griffith) > writes: > > I'm lazy. That's why I like the file browser in Workspace Manager. I > > hate typing "cd, ls, cd... etc". But here's the problem: you've > > browsed your way down a deep directory path and decided you want to > > do something unixy with the files you see. So you'd like to launch > > a terminal window at the current directory. But you can't! It's so > < rambling deleted > > > What Terminal (or Stuart) needs to do is provide a service which expects > a 'thing' (document or directory) and then cd to the appropriate > directory before initing or becoming key (if already running). Then > the file viewer menu would provide something like Services>Terminal>cd > to dir p (or something similar). > > Of course a new app could be written that provides the service > then launches Terminal. I've done this. See below. > <stuff deleted> >ability. For instance, if you could copy the pathname of the >current file from the Workspace, you could then move to (say) >an Open Panel and paste the pathname in there, and it would then >go to the path. I'm sure it could be used in other places (say >you get a reference to a documentation file - copy and paste >it into Workspace to get there). You can indeed copy the filename out of Browser using a service app. <good stuff deleted> The trouble is, once you've got the path out of the WorkSpace, you can't do much with it. You should be able to stick it in the pasteboard enabling you to paste it into other apps (such as Terminal). But for some reason you can stick it into the pasteboard all night long and you'll never be able to paste it back out into another app. I think there is a bug somewhere in NextStep. Workspace is the only app which causes the service to have this behaviour. Other apps interact just fine with this services. Doug Kent Independent NeXT Developer adonis1@nwnexus.wa.com
finn@theory.tn.cornell.edu (Lee Samuel Finn) (05/10/91)
In article <505@nwnexus.WA.COM> adonis1@nwnexus.UUCP (Adonis Corporation (Doug Kent)) writes: > >The trouble is, once you've got the path out of the WorkSpace, you can't >do much with it. You should be able to stick it in the pasteboard >enabling you to paste it into other apps (such as Terminal). But for >some reason you can stick it into the pasteboard all night long and you'll >never be able to paste it back out into another app. I think there >is a bug somewhere in NextStep. Workspace is the only app which causes >the service to have this behaviour. Other apps interact just fine with >this services. > >Doug Kent >Independent NeXT Developer >adonis1@nwnexus.wa.com > Not so. The path goes in to the pasteboard type (I'm not at my next, so am going by memory here) NXFilenamePboardType. This is not generic ascii data, and an app that is asking for generic ascii data won't be able to get it, ie, you will not be able to paste it there. I've written a service (for compressing and uncompressing files) that takes stuff from the Workspace manager in this way all the time. You will also find that selected filenames from open and save panels are also of this type, and will not be available for random pasting in the same way filenames from the workspace manager are not.
scott@nic.gac.edu (Scott Hess) (05/11/91)
In article <665@rosie.NeXT.COM> jmynatt@next.com writes: In article <1991May3.230846.27038@cunixf.cc.columbia.edu> ta-aca@cunixb.cc.columbia.edu (Andrew C. Athan) writes: <cruft deleted> > > It is impotant to understand the difference between Terminal (or > Stuart) [[The App]] and the program that is running in the > Terminal window [[The Shell]]. It is the shell which needs to > "cd" Stuart/Terminal have nothing to do with details of what > the app in the window is doing (besides acting as one end of a pty). > > So ... the problem is communicating the "cd" command to > csh/ksh/bash/whatever. Probably the only generic guranteed to > work solution is to have the Services> item of which you speak > "type" a cd command into the window in question. You, as the > user of the Service, would have to make sure > your shell is at a prompt which can accept the "cd." If I write an app which runs a program such as 'csh/ksh/bash/whatever', I can invoke that program with control. If that means i issue a cd and a clear then so be it. Stuart and Terminal have a lot to do with the details of what the app in the window is doing. Stuart/ Terminal / Whatever then app object is, has complete control and can even do things like monitor what you are typing into the Text object (which sits between the window and the program ) and take appropriate action such as capturing typing rates for data entry applications. Well, sort of. When it comes down to it, though, Stuart and its ilk really do _not_ have much to do with what the subprogram does. The problem is manyfold. For one, you don't know what the subprogram is. Sure, it might be _named_ csh, but that doesn't mean anything - you can rename tcsh csh, and most things will work, but if Stuart makes assumptions about what csh will do, it will crash gloriously. It's even worse if you rename ksh sh, or bash sh, or even emacs vi. Secondly, without sophisticated artificial intelligence algorithms, you aren't going to be able to tell what the subshell is going to do, in general. Figuring out if an arbitrary subprogram is in such a state that a cd makes sense is certainly non-decidable without infinite resources. For instance, consider a subshell in which you ran rlogin to a remote system [a VAX], then hopped to another Unix host and ran emacs. How can Stuart have a chance to know what is and is not possible at this point? It can't. Thus, the user is going to have to have some brains, too (ie, only send the sequence when it makes sense). The user of the Service I was describing is the FileViewer. The Service responder (Stuart or Terminal) recognizes that it has been invoked by a service request (speaker/listener pair) and can get the information needed (directory path) and start up the appropriate program (csh/ksh/bash/whatever) and issue 'cd' commands or whatever. The Stuart/Terminal window opened can be a new one or a existing on (a feature which should be set by the user preferences). It would not be such a problem to open up a new window and do it. I think one could safely assume that the default subprogram will be a shell (sh, csh, or some variation), which would thus be able to accept the 'cd ...' that is sent by Stuart. It's the sending to an existing window that's problematic. Again, the simple solution is the only viable one - just send the damn command, and let the user worry about it. Hope this clears things up a bit. Well :-). This really doesn't clear things up like they could be, though. The best solution would be to have Workspace use the copy/paste stuff for the paths, too, and then there's not really any problem at all (I don't have to write a hack). Basically, right now we're considering fixing Stuart to supply some functionality that would be nice to have in the Workspace itself. But, what happens when we want it in Edit? In the Workspace's Shell window? In Mail? In Terminal? The fix obviously belongs in Workspace (I'm not saying it won't appear in Stuart eventually if it doesn't make the Workspace, just making a point). Hmm . . . consider the case where you don't want to cd to a directory, but you want to include a file's path as part of a command (for instance, as a parameter to a cp or a vi). Then, you just want the pathname, w/o the cd part. Wait! Now that I think of it, that's probably the general case, isn't it. Wow. OK, maybe that _will_ be there soon. Later, -- scott hess scott@gac.edu Independent NeXT Developer GAC Undergrad <almost out!> <I still speak for nobody>