t-jondu@microsoft.UUCP (Jonathan Dubman) (08/11/89)
Is it possible to configure the Browser to automatically update whenever there is a change in any of its directories? Manually updating is a pain. Clearly this is not the ideal situation. One solution is to update the Browser panel whenever it is activated, but this is inadequate- I want the Browser at all times to display the current contents of its directories. The proper way to do this, it seems to me, is not to have a busy-loop constantly updating the directory, but rather to request for each of the directory objects to notify the browser whenever they modify themselves. If this is not possible under the NeXT OS, it strikes me that there is something wrong with the OS. Conceivably it could be an option, depending on just how much overhead there is. Comments? Jonathan Dubman
mdeale@cosmos.acs.calpoly.edu (Myron Deale) (08/11/89)
In article <7324@microsoft.UUCP> t-jondu@microsoft.UUCP (Jonathan Dubman) writes: >Is it possible to configure the Browser to automatically update whenever there >is a change in any of its directories? Manually updating is a pain. what's wrong with typing cmd-u ? > >One solution is to update the Browser panel whenever it is activated, but this ... gosh, even better. > ... >Conceivably it could be an option, depending on just how much overhead there > >Jonathan Dubman possibly something to look forward to in the *future*. Maybe if NeXT ships sources ... ? :) -Myron // mdeale@cosmos.acs.calpoly.edu
dorner@pequod.cso.uiuc.edu (Steve Dorner) (08/12/89)
In article <7324@microsoft.UUCP> t-jondu@microsoft.UUCP (Jonathan Dubman) writes: >Is it possible to configure the Browser to automatically update whenever there >is a change in any of its directories? Manually updating is a pain. >Clearly this is not the ideal situation. The browser already does a reasonable job of discovering that what it is displaying is not conformant with filesystem reality. (How's that for a sentence?) I vote for a workspace default that tells the browser not to change its title, but rather to update itself when it notices that things have gone bump in the night. That way, we have the best of both worlds. -- Steve Dorner, U of Illinois Computing Services Office Internet: s-dorner@uiuc.edu UUCP: {convex,uunet}!uiucuxc!dorner IfUMust: (217) 244-1765
carlson@mrcnext.cso.uiuc.edu (08/12/89)
The catch is that **ANY** program could create/destroy files. I don't know if you have a machine with many users. The solution is 1. Have EVERY Unix program send an UPDATE message to the window server or browser. (Yeah, right!) 1a. Put such code into the open() and creat() library calls. OR 2. Change the kernal so that _it_ sends an UPDATE message to the window server EVERYTIME a file is created/destroyed. Clearly, any method to notify processes of filesystem changes is going to be messy and consume CPU cycles. I belive that Multifinder on the Mac sort of does this. Does anyone know the details? -------------------- Brad Carlson <carlson@mrcnext.cso.uiuc.edu> or <brad-carlson@uiuc.edu> University of Illinos--Micro Resource Center--NeXT guru
jgreely@oz.cis.ohio-state.edu (J Greely) (08/14/89)
Should I mention that any attempt to add this to the system would result in my deep-sixing it faster than you can say "Design Philosophy"? I am not fundamentally opposed to having the Browser update itself when I select it, as long as it doesn't prevent me from logging out when it hangs on an NFS file system, but anything more is, IMHO, crossing the line. Absolute accuracy would involve deep ugly hacking, and would give the kernel knowledge about the one true window system (assuming it doesn't (*brrrr*) already). Nasty, unfriendly thing to do. -=- J Greely (jgreely@cis.ohio-state.edu; osu-cis!jgreely)
dschuetz@umd5.umd.edu (David Schuetz) (08/15/89)
>In article <7324@microsoft.UUCP> t-jondu@microsoft.UUCP (Jonathan Dubman) writes: >Is it possible to configure the Browser to automatically update whenever there >is a change in any of its directories? Manually updating is a pain. Maybe everytime you click the mouse in the Browser panel, that is, every time you bring it to the foreground. I mean, if you're going to look at it, you ought at least to be so polite as to *tell* it that you're looking at it. But I agree, it should in return be so kind as to tell you what's really there, without being lazy and just telling you "well, these were here five minutes ago..." dschuetz@umd5.umd.edu
t-jondu@microsoft.UUCP (Jonathan Dubman) (08/15/89)
In article <JGREELY.89Aug14043551@oz.cis.ohio-state.edu> J Greely <jgreely@cis.ohio-state.edu> writes: >Should I mention that any attempt to add this to the system would >result in my deep-sixing it faster than you can say "Design >Philosophy"? > > I am not fundamentally opposed to having the Browser update itself >when I select it, as long as it doesn't prevent me from logging out >when it hangs on an NFS file system, but anything more is, IMHO, >crossing the line. Absolute accuracy would involve deep ugly hacking, >and would give the kernel knowledge about the one true window system >(assuming it doesn't (*brrrr*) already). Nasty, unfriendly thing to >do. > I understand your position... I anticipated an answer like this. As the person who started this discussion, my philosophy, from the user's standpoint, is that it would be ideal to have the Browser always display the current status of the file system. If doing so screws something else up, then ok, forget it, but I think there's a compromise in there somewhere. I agree that the kernel should have no knowledge of the Browser. But it should allow for dynamic "extensions"- I should be able to insert a "wedge" in a kernel object that sends me a message whenever it does such-and-such. Now I'm not a kernel hacker, but I imagine there's some set of low-level functions that create, modify, and delete all files. (A basis for the operator space, if you will.) Do these functions overlap with pipes and sockets and so forth? If so, then I see we have an efficency problem if we insert a wedge at that level, and it should go somewhere else. Is the NeXT object-oriented enough to handle this or is this just a PIPE DREAM? :-) >-=- >J Greely (jgreely@cis.ohio-state.edu; osu-cis!jgreely) Jonathan Dubman
dorner@pequod.cso.uiuc.edu (Steve Dorner) (08/15/89)
In article <800018@mrcnext.cso.uiuc.edu> carlson@mrcnext.cso.uiuc.edu writes: >... >1. Have EVERY Unix program send an UPDATE message to the window >... >2. Change the kernal so that _it_ sends an UPDATE message to >... >Clearly, any method to notify processes of filesystem changes >is going to be messy and consume CPU cycles. I belive that Multifinder >on the Mac sort of does this. Does anyone know the details? I really think this issue is much simpler than all this. First, let me make a guess: Both the NeXT browser and the Mac Finder notice when files have been created or destroyed by POLLING THE MODIFY TIME of the directories they display; every n seconds, they look at the modify time on any displayed directory. The Finder then displays (or removes) any file name or icon that has been created (or destroyed). The Browser just changes its title. I stick by my suggestion to add a default to the Browser that, if set by the user, would make the browser update its views when its normal polling behavior detects a change. CPU cost? To those of you who leave it turned off, enough cycles to check a flag once every n seconds, given that the Browser is already doing stat calls every n seconds anyway. To those of us who turn it on, however long it takes to update the Browser, when the Browser is running and notices a change in one of its displayed directorie s. All this talk about patching the kernel or libraries is, as someone mentioned, over the line. I realize that there are changes to files that do not involve changing the modify times on directories, such as file size changes. The macintosh Finder ignores these, and I don't think that's a bad policy; after all, the important thing is that the darn files show up and can be manipulated. -- Steve Dorner, U of Illinois Computing Services Office Internet: s-dorner@uiuc.edu UUCP: {convex,uunet}!uiucuxc!dorner IfUMust: (217) 244-1765
dorner@pequod.cso.uiuc.edu (Steve Dorner) (08/15/89)
In article <800018@mrcnext.cso.uiuc.edu> carlson@mrcnext.cso.uiuc.edu writes: >... >1. Have EVERY Unix program send an UPDATE message to the window >... >2. Change the kernal so that _it_ sends an UPDATE message to >... >Clearly, any method to notify processes of filesystem changes >is going to be messy and consume CPU cycles. I belive that Multifinder >on the Mac sort of does this. Does anyone know the details? All this talk about patching the kernel or libraries is, as someone mentioned, over the line. I really think this issue is much simpler than all this. First, let me make a guess: GUESS: Both the NeXT browser and the Mac Finder notice when files have been created or destroyed by POLLING THE MODIFY TIME of the directories they display; every n seconds, they look at the modify time on any displayed directory. The Finder then displays (or removes) any file name or icon that has been created (or destroyed). The Browser just changes its title. I stick by my suggestion to add a default to the Browser that, if set by the user, would make the browser update its views when its normal polling behavior detects a change. CPU cost? To those of you who leave it turned off, enough cycles to check a flag once every n seconds, given that the Browser is already doing stat calls every n seconds anyway. To those of us who turn it on, however long it takes to update the Browser, when the Browser is running and notices a change in one of its displayed directories. I realize that there are changes to files that do not involve changing the modify times on directories, such as file size changes. The macintosh Finder ignores these, and I don't think that's a bad policy; after all, the important thing is that the darn files show up and can be manipulated. -- Steve Dorner, U of Illinois Computing Services Office Internet: s-dorner@uiuc.edu UUCP: {convex,uunet}!uiucuxc!dorner IfUMust: (217) 244-1765
epsilon@wet.UUCP (Eric P. Scott) (08/16/89)
I've seen systems where processes could receive "file created in directory" signals. If you implement a sufficiently general facility, no one will mistake it for a kludge. :-) -=EPS=-