From: Mike H. <mik...@an...> - 2005-11-24 18:16:19
|
I tried to use Find-005 today. Entered a path and a search string, but how do you start the thing going? I tried the look at the settings at it blew it away! Has anyone else succeeded in using this app? If so, how? Thanks, Mike |
From: Peter <sw...@ho...> - 2005-11-24 20:05:56
|
On Thu, 24 Nov 2005 18:16:00 +0000, Mike Hobbs wrote: > I tried to use Find-005 today. Entered a path and a search string, but > how do you start the thing going? > > I tried the look at the settings at it blew it away! > > Has anyone else succeeded in using this app? If so, how? > > Thanks, > Mike > First, it works fine for me. Second, you must have rox-lib > 2. Third, Pattern should be any valid regex Fourth, to search, click the "gears" icon or just press enter after putting in the Files field. Fifth, if it fails again, a little more info about your system, libraries, rox version, etc. would be a help. -- Peter ---- Do not reply to this email address. It is a spam trap and not monitored. If you wish to contact me, please use pet...@no.... Thx. |
From: Mike H. <mik...@an...> - 2005-11-25 09:55:15
|
Peter wrote: >On Thu, 24 Nov 2005 18:16:00 +0000, Mike Hobbs wrote: > > > >>I tried to use Find-005 today. Entered a path and a search string, but >>how do you start the thing going? >> >>I tried the look at the settings at it blew it away! >> >>Has anyone else succeeded in using this app? If so, how? >> >>Thanks, >>Mike >> >> >> >First, it works fine for me. >Second, you must have rox-lib > 2. > > yes, but how do you know and why should it matter? >Third, Pattern should be any valid regex > > yes, I guessed as much. >Fourth, to search, click the "gears" icon or just press enter after >putting in the Files field. > > yes, I guessed this much too, but the gears icon is always greyed out, even when all fields are entered. >Fifth, if it fails again, a little more info about your system, libraries, >rox version, etc. would be a help. > > Rox-Filer 2.3, ROX-Session 0.26, ROX-Lib 2.0.2, Glib 2.4.7, GTK+ 2.4.23 is anything else relevant? Mike |
From: Peter <sw...@ho...> - 2005-11-25 10:34:52
|
On Fri, 25 Nov 2005 09:54:31 +0000, Mike Hobbs wrote: >>Fourth, to search, click the "gears" icon or just press enter after >>putting in the Files field. >> >> > yes, I guessed this much too, but the gears icon is always greyed out, > even when > all fields are entered. > The gears are greyed out when the input of the three fields is incomplete. Something is missing. ---- Do not reply to this email address. It is a spam trap and not monitored. If you wish to contact me, please use pet...@no.... Thx. |
From: Christopher P. <pi...@sd...> - 2005-11-25 18:11:20
|
On Fri, Nov 25, 2005 at 05:31:19AM -0500, Peter wrote: > On Fri, 25 Nov 2005 09:54:31 +0000, Mike Hobbs wrote: > > >>Fourth, to search, click the "gears" icon or just press enter after > >>putting in the Files field. > >> > >> > > yes, I guessed this much too, but the gears icon is always greyed out, > > even when > > all fields are entered. > > > The gears are greyed out when the input of the three fields is incomplete. > Something is missing. I must say that I share Mike Hobbs's experience with Find, namely, that I can't search for anything because the gears icon is always greyed out. Now, if one really has to fill in all three fields to search for something, that's an important detail that might be worth documenting, if I may constructively say so. :-) In any case, thanks for the tip---I'll try this out ASAP (rox is on my home machine). Christopher |
From: Ken H. <ke...@ha...> - 2005-11-25 18:18:31
|
Christopher Pinon wrote: > On Fri, Nov 25, 2005 at 05:31:19AM -0500, Peter wrote: > >>On Fri, 25 Nov 2005 09:54:31 +0000, Mike Hobbs wrote: >> >> >>>>Fourth, to search, click the "gears" icon or just press enter after >>>>putting in the Files field. >>>> >>>> >>> >>>yes, I guessed this much too, but the gears icon is always greyed out, >>>even when >>>all fields are entered. >>> >> >>The gears are greyed out when the input of the three fields is incomplete. >>Something is missing. > > > I must say that I share Mike Hobbs's experience with Find, namely, that > I can't search for anything because the gears icon is always greyed out. > > Now, if one really has to fill in all three fields to search for > something, that's an important detail that might be worth documenting, > if I may constructively say so. :-) What, you couldn't understand that from my blank README file? :) > In any case, thanks for the tip---I'll try this out ASAP (rox is on my > home machine). If it doesn't work, then there's something wrong with: path.connect('changed', self.entry_changed) where path is a wrapper around a gtk.Entry or gtk.ComboBoxEntry depending on your gtk version. If it doesn't work for you please report your gtk version and I'll try to find a workaround. |
From: Christopher P. <pi...@sd...> - 2005-11-25 20:38:24
|
On Fri, Nov 25, 2005 at 10:17:23AM -0800, Ken Hayber wrote: > Christopher Pinon wrote: > >On Fri, Nov 25, 2005 at 05:31:19AM -0500, Peter wrote: > > > >>On Fri, 25 Nov 2005 09:54:31 +0000, Mike Hobbs wrote: > >> > >> > >>>>Fourth, to search, click the "gears" icon or just press enter after > >>>>putting in the Files field. > >>>> > >>>> > >>> > >>>yes, I guessed this much too, but the gears icon is always greyed out, > >>>even when > >>>all fields are entered. > >>> > >> > >>The gears are greyed out when the input of the three fields is incomplete. > >>Something is missing. > > > > > >I must say that I share Mike Hobbs's experience with Find, namely, that > >I can't search for anything because the gears icon is always greyed out. > > > >Now, if one really has to fill in all three fields to search for > >something, that's an important detail that might be worth documenting, > >if I may constructively say so. :-) > > What, you couldn't understand that from my blank README file? :) I've tried Find again, now filling in all of the three fields (path, pattern; files), as Peter suggested, and indeed the gears light up and I can perform a search. So it works. :-) But, as I said earlier above, since it's not at all obvious to the user that he/she _has_ to fill in all three fields, it would be nice to document this. However (and this is another constructive comment), it could be argued that even if this feature were documented, it's still awkward to _require_ the user to specify a pattern to perform a simple search. In many cases, all the user wants to do is to search for a file; in such cases, having to specify a pattern is a nuisance. Ideally, I think that Find should use the pattern if one is specified; otherwise it should just search for the file named. Digging a little further, the following behavior is arguably a bug. If you go into settings and delete that part of the find command beginning with -exec, leaving find "$P" $R -name "$F" you would _expect_ that it should no longer be necessary to specify a pattern, because we have removed $T from the command, right? But no: if you then go back and try to do a search, you still _need_ to put something in the pattern field, even though now it plays no role in the search! :-( Please correct me if I see things incorrectly here. In sum, it seems that having to specify a pattern is "hardwired" into Find, which is a little unfortunate, as far as its usability is concerned. But let me close by thanking you for your efforts with Find. Perhaps the issues above are relatively easy to correct. Christopher |
From: Ken H. <ke...@ha...> - 2005-11-25 20:51:49
|
Christopher Pinon wrote: > On Fri, Nov 25, 2005 at 10:17:23AM -0800, Ken Hayber wrote: > >>Christopher Pinon wrote: >> >>>On Fri, Nov 25, 2005 at 05:31:19AM -0500, Peter wrote: >>> >>> >>>>On Fri, 25 Nov 2005 09:54:31 +0000, Mike Hobbs wrote: >>>> >>>> >>>> >>>>>>Fourth, to search, click the "gears" icon or just press enter after >>>>>>putting in the Files field. >>>>>> >>>>>> >>>>> >>>>>yes, I guessed this much too, but the gears icon is always greyed out, >>>>>even when >>>>>all fields are entered. >>>>> >>>> >>>>The gears are greyed out when the input of the three fields is incomplete. >>>>Something is missing. >>> >>> >>>I must say that I share Mike Hobbs's experience with Find, namely, that >>>I can't search for anything because the gears icon is always greyed out. >>> >>>Now, if one really has to fill in all three fields to search for >>>something, that's an important detail that might be worth documenting, >>>if I may constructively say so. :-) >> >>What, you couldn't understand that from my blank README file? :) > > > I've tried Find again, now filling in all of the three fields (path, > pattern; files), as Peter suggested, and indeed the gears light up and I > can perform a search. So it works. :-) > > But, as I said earlier above, since it's not at all obvious to the user > that he/she _has_ to fill in all three fields, it would be nice to > document this. However (and this is another constructive comment), it > could be argued that even if this feature were documented, it's still > awkward to _require_ the user to specify a pattern to perform a simple > search. In many cases, all the user wants to do is to search for a file; > in such cases, having to specify a pattern is a nuisance. Ideally, I > think that Find should use the pattern if one is specified; otherwise it > should just search for the file named. > > Digging a little further, the following behavior is arguably a bug. If > you go into settings and delete that part of the find command beginning > with -exec, leaving > > find "$P" $R -name "$F" > > you would _expect_ that it should no longer be necessary to specify a > pattern, because we have removed $T from the command, right? But no: if > you then go back and try to do a search, you still _need_ to put > something in the pattern field, even though now it plays no role in the > search! :-( Please correct me if I see things incorrectly here. > > In sum, it seems that having to specify a pattern is "hardwired" into > Find, which is a little unfortunate, as far as its usability is > concerned. > > But let me close by thanking you for your efforts with Find. Perhaps the > issues above are relatively easy to correct. > > Christopher Having to specify a pattern is the MAIN FEATURE of this tool. The whole point is to specify the pattern, see where it exists in each file, and be able to jump to that point in the file easily. There are plenty of other Find utilities out there. This was a feature I have used in some editors that I missed in ROX. I really see it as a programmer's tool. That said, I suppose it wouldn't hurt to generalize things a bit so it could serve both purposes. However, I don't know what I would then do with the 'text' column in the results list. I'll think about it... Ken |
From: Christopher P. <pi...@sd...> - 2005-11-25 22:43:25
|
On Fri, Nov 25, 2005 at 12:50:50PM -0800, Ken Hayber wrote: > > Having to specify a pattern is the MAIN FEATURE of this tool. The whole > point is to specify the pattern, see where it exists in each file, and be > able to jump to that point in the file easily. > > There are plenty of other Find utilities out there. This was a feature I > have used in some editors that I missed in ROX. I really see it as a > programmer's tool. > > That said, I suppose it wouldn't hurt to generalize things a bit so it > could serve both purposes. However, I don't know what I would then do with > the 'text' column in the results list. I'll think about it... OK, fair enough, but w/o documentation it's terribly easy to misunderstand the intended purpose of Find! But, yes, if having to specify a pattern is the main feature, as you say, then it does its job well. :-) (And, yes, the possible generalization would be nice, but that might indeed require a bit of an overhaul ...) Christopher |
From: Peter <sw...@ho...> - 2005-11-25 21:03:36
|
On Fri, 25 Nov 2005 20:38:06 +0000, Christopher Pinon wrote: Remember Christopher, as Ken pointed out, this FIND is a grep-type tool -- to find text in files. It was NOT designed to find files. This facility already exists in ROX (CTRL-F) as well as with the find program. I made the same mistake, "How come I can't find just a file?" If anything, perhaps a simple paragraph in the empty README file will clear things up :) I keep find in my panel and drag directories to it and look for stuff all the time. ---- Do not reply to this email address. It is a spam trap and not monitored. If you wish to contact me, please use pet...@no.... Thx. |
From: Peter <sw...@ho...> - 2005-11-25 18:21:47
|
On Fri, 25 Nov 2005 09:54:31 +0000, Mike Hobbs wrote: > Peter wrote: > >>On Thu, 24 Nov 2005 18:16:00 +0000, Mike Hobbs wrote: >> >> >> >>>I tried to use Find-005 today. Entered a path and a search string, but >>>how do you start the thing going? >>> >>>I tried the look at the settings at it blew it away! >>> >>>Has anyone else succeeded in using this app? If so, how? >>> >>>Thanks, >>>Mike >>> >>> >>> >>First, it works fine for me. >>Second, you must have rox-lib > 2. >> >> > yes, but how do you know and why should it matter? > >>Third, Pattern should be any valid regex >> >> > yes, I guessed as much. > >>Fourth, to search, click the "gears" icon or just press enter after >>putting in the Files field. >> >> > yes, I guessed this much too, but the gears icon is always greyed out, > even when > all fields are entered. > >>Fifth, if it fails again, a little more info about your system, libraries, >>rox version, etc. would be a help. >> >> > Rox-Filer 2.3, ROX-Session 0.26, ROX-Lib 2.0.2, Glib 2.4.7, GTK+ 2.4.23 > is anything else relevant? > > Mike > How about this. What happens if you type [ROXAPPDIR]/Find/AppRun --help at a terminal prompt? DO you get a quick help screen? How about if you just launch Find from a prompt. Perhaps the errors will help you trace where the program is failing. LASTLY, is the find (case sensitive) program in your path? How about grep? Good luck! ---- Do not reply to this email address. It is a spam trap and not monitored. If you wish to contact me, please use pet...@no.... Thx. |
From: Thomas L. <ta...@ec...> - 2005-11-24 20:15:11
|
On Thu, 24 Nov 2005 18:16:00 +0000, Mike Hobbs wrote: > I tried to use Find-005 today. Entered a path and a search string, but > how do you start the thing going? There's a cog in the toolbar you have to click on. Perhaps it would be better to use a button marked 'Find' below the fields instead? PS: Is the Help/README file supposed to be empty? -- Dr Thomas Leonard http://rox.sourceforge.net GPG: 9242 9807 C985 3C07 44A6 8B9A AE07 8280 59A5 3CC1 |
From: Ken H. <ke...@ha...> - 2005-11-25 01:07:40
|
Thomas Leonard wrote: > On Thu, 24 Nov 2005 18:16:00 +0000, Mike Hobbs wrote: > > >>I tried to use Find-005 today. Entered a path and a search string, but >>how do you start the thing going? > > > There's a cog in the toolbar you have to click on. Perhaps it would be > better to use a button marked 'Find' below the fields instead? How about I remove the line that says: toolbar.set_style(gtk.TOOLBAR_ICONS) and let the user choose the toolbar style they like (using the Toolbars and Menus configlet)? > PS: Is the Help/README file supposed to be empty? Not really. It is supposed to say "This file intentionally left blank" :) |
From: Thomas L. <ta...@ec...> - 2005-11-26 14:10:45
Attachments:
find.patch
|
On 11/25/05, Ken Hayber <ke...@ha...> wrote: > Thomas Leonard wrote: [ Find ] > > There's a cog in the toolbar you have to click on. Perhaps it would be > > better to use a button marked 'Find' below the fields instead? > > How about I remove the line that says: > toolbar.set_style(gtk.TOOLBAR_ICONS) I'm not sure that helps. I just expect to see a button below the fields, not in the toolbar for some reason. Here's a patch that changes the UI a bit. It might contain a few bugs... just trying out ideas. Changes are: - Removed the toolbar. - Moved the close, clear and start buttons to the bottom (dialog style). - Added a Help button there too. - Moved preferences next to the other options (mainly because it didn't fit at the bottom) - Removed the Stop button. Instead, Find stays popped in during searching and you click it again to stop. - Removed the Up button. Double-click on a filename in the results to show the file (or double-click in the line or text columns to open in a text editor, as before). Does this improve things? I didn't do anything to make it obvious why Find is shaded. We need that, though. The README is still blank ;-) -- Dr Thomas Leonard=09=09http://rox.sourceforge.net GPG: 9242 9807 C985 3C07 44A6 8B9A AE07 8280 59A5 3CC1 |
From: Ken H. <ke...@ha...> - 2005-11-26 16:55:58
|
Thomas Leonard wrote: > On 11/25/05, Ken Hayber <ke...@ha...> wrote: > >>Thomas Leonard wrote: > > [ Find ] > >>>There's a cog in the toolbar you have to click on. Perhaps it would be >>>better to use a button marked 'Find' below the fields instead? >> >>How about I remove the line that says: >> toolbar.set_style(gtk.TOOLBAR_ICONS) > > > I'm not sure that helps. I just expect to see a button below the > fields, not in the toolbar for some reason. Here's a patch that > changes the UI a bit. It might contain a few bugs... just trying out > ideas. Changes are: > > - Removed the toolbar. > - Moved the close, clear and start buttons to the bottom (dialog style). > - Added a Help button there too. > - Moved preferences next to the other options (mainly because it > didn't fit at the bottom) > - Removed the Stop button. Instead, Find stays popped in during > searching and you click it again to stop. > - Removed the Up button. Double-click on a filename in the results to > show the file (or double-click in the line or text columns to open in > a text editor, as before). > > Does this improve things? I didn't do anything to make it obvious why > Find is shaded. We need that, though. The README is still blank ;-) I put before.png and after.png screenshots in http://www.hayber.us/rox/find Opinions welcome. Basically I like it. Cancelling the Find doesn't work for me. And the 'Open in a Filer Window' button is gone (maybe I'll put that in a popup menu for each found item?) I'm also adding support for '~' in the path and need to figure out why symlinks don't work when used for the path. |
From: Ken H. <ke...@ha...> - 2005-11-27 00:57:13
|
Ken Hayber wrote: > Thomas Leonard wrote: > >> Here's a patch that >> changes the UI a bit. It might contain a few bugs... just trying out >> ideas. Changes are: >> >> - Removed the toolbar. >> - Moved the close, clear and start buttons to the bottom (dialog style). >> - Added a Help button there too. >> - Moved preferences next to the other options (mainly because it >> didn't fit at the bottom) >> - Removed the Stop button. Instead, Find stays popped in during >> searching and you click it again to stop. >> - Removed the Up button. Double-click on a filename in the results to >> show the file (or double-click in the line or text columns to open in >> a text editor, as before). >> >> Does this improve things? I didn't do anything to make it obvious why >> Find is shaded. We need that, though. The README is still blank ;-) > > > I put before.png and after.png screenshots in http://www.hayber.us/rox/find > Opinions welcome. > > Basically I like it. Cancelling the Find doesn't work for me. And the > 'Open in a Filer Window' button is gone (maybe I'll put that in a popup > menu for each found item?) > > I'm also adding support for '~' in the path and need to figure out why > symlinks don't work when used for the path. OK, having waited not-at-all-a-long-time-with-no-feedback :), I decided to go ahead with this and released 006. I reverted some of the process-management changes and now Cancel works again. I banged on it quite a bit and didn't see anything anomalous. I like how you (Thomas) improved the keyboard use: Enter now moves from field to field until all 3 are filled and then a Find is started. And I discovered how you kept the 'Open in a Filer Window' option. (double-click in the Filename column instead of the Text column) Subtle, but nice. Oh, and I didn't like having a new Find automatically clear the old one. I'm used to having cumulative results - it makes debugging easier when you search for one thing, see something else interesting, but then want to go back to the original search without having to actually search for it again. Please review the README file! :) The Find web page has the same content now too. (http://www.hayber.us/rox/Find) HTH, Ken |
From: Thomas L. <ta...@ec...> - 2005-11-27 13:07:41
|
On Sat, 26 Nov 2005 16:56:55 -0800, Ken Hayber wrote: > Ken Hayber wrote: >> [quoted text muted] > > OK, having waited not-at-all-a-long-time-with-no-feedback :), I decided to > go ahead with this and released 006. > > I reverted some of the process-management changes and now Cancel works > again. I banged on it quite a bit and didn't see anything anomalous. The reason I changed the Cancel code was that the old code didn't actually kill the process until it produced some output. Try searching '/' for 'some unlikely string' in '*' and then try to cancel. The find process just keeps running. > Oh, and I didn't like having a new Find automatically clear the old one. > I'm used to having cumulative results - it makes debugging easier when you > search for one thing, see something else interesting, but then want to go > back to the original search without having to actually search for it > again. I'd forgotten about that change. I was actually thinking of removing the Clear button, as it isn't useful with automatic clearing. If you're going to keep old results though, perhaps it should add some kind of separator to the results list? > Please review the README file! :) > The Find web page has the same content now too. > (http://www.hayber.us/rox/Find) 0launch? http://www.hayber.us/0install/Find -- Dr Thomas Leonard http://rox.sourceforge.net GPG: 9242 9807 C985 3C07 44A6 8B9A AE07 8280 59A5 3CC1 |
From: Ken H. <ke...@ha...> - 2005-11-28 05:53:55
|
Well, another day, another release. Find 007 is out there. This time I updated 0install too. Changes from 006: * Cancel works even when find|grep returns no results (reported by Dr. Leonard) * Closing the window with the Window Manager's close button properly cancels the find and saves the history. * Errors from the find|grep command are not displayed in the results area. * Multiple searches (without clearing) are separated by a TreeView row that allows collapse/expand of each section, and shows the original criteria for that search. * New searches scroll the results display to the starting point of the new results. Search and Destroy! |
From: Peter <sw...@ho...> - 2005-11-28 11:33:10
|
On Sun, 27 Nov 2005 21:53:41 -0800, Ken Hayber wrote: > Well, another day, another release. > > Find 007 is out there. This time I updated 0install too. > > Changes from 006: > * Cancel works even when find|grep returns no results (reported by Dr. > Leonard) > * Closing the window with the Window Manager's close button properly > cancels the find and saves the history. > * Errors from the find|grep command are not displayed in the results > area. > * Multiple searches (without clearing) are separated by a TreeView row > that allows collapse/expand of each section, and shows the original > criteria for that search. > * New searches scroll the results display to the starting point of the > new results. > > > > Search and Destroy! > I think I liked the top line menu icons better. Now, after typing in stuff, I have to traverse across the whole app frame to get to buttons. I like it when all the controls are together -- entry boxes, buttons, preferences. This model is similar to spreadsheets, evolution, and many programs where all the icons and menus are together at the top. Also, I hope this applet does not get any bigger because it's terrific when small applets accomplish one function and do it well. -- Do not reply to this email address. It is a spam trap and not monitored. If you wish to contact me, please use pete4abw at comcast dot net. |
From: Peter P. <pi...@wg...> - 2005-11-28 14:03:12
|
Ken Hayber wrote: > Well, another day, another release. > > Find 007 is out there. This time I updated 0install too. > > Changes from 006: > * Cancel works even when find|grep returns no results (reported by > Dr. Leonard) > * Closing the window with the Window Manager's close button properly > cancels the find and saves the history. > * Errors from the find|grep command are not displayed in the results > area. > * Multiple searches (without clearing) are separated by a TreeView > row that allows collapse/expand of each section, and shows the > original criteria for that search. > * New searches scroll the results display to the starting point of > the new results. Works fine (via injector) here. Only annoying thing is that I cannot remove searches selectively from the result set but only wipe out the whole list. I wanted to do this because i forgot to escape a quotation mark and got a useless broken search with 0 results hanging around. Not a big deal, but i would consider it quite useful. A little different, but maybe the real thing that i want is to search through the result set or filter it (like in rox). On the command line, i handle it by piping the output into my editor. I tried to drag everything that looked suspicious to the filer, but Find does not seem to have drag and save :) Maybe the easiest solution would is to allow dragging the search result element to the filer. That would at least keep Find a small special tool. Example use cases: * My search was rather fuzzy. I'd like to remove some unwanted hits (aka manually apply a filter to the result set). For huge trees, this is often much faster than a new search. * I tend to use the results as a todo list and remove fixed things as i go. I wonder what would happen if i drag the result set onto memo, which provides all the needed hide/unhide lists ;) What I intuitively expected: * first: right-click/delete entry * then: clicking "clear" will certainly only remove selected items Category dreaming... t.i. I'm already really a fan of the tool as it is |
From: Bungee <bu...@er...> - 2005-11-28 23:45:32
|
Ken Hayber <ke...@ha...> wrote: > Well, another day, another release. > > Find 007 is out there. This time I updated 0install too. > > Changes from 006: > * Cancel works even when find|grep returns no results (reported by Dr. > Leonard) > * Closing the window with the Window Manager's close button properly > cancels the find and saves the history. > * Errors from the find|grep command are not displayed in the results > area. > * Multiple searches (without clearing) are separated by a TreeView row > that allows collapse/expand of each section, and shows the original > criteria for that search. > * New searches scroll the results display to the starting point of the > new results. > > > > Search and Destroy! V6 and 7 don't seem to be able to throwback to Edit (V5 does) I seem to have difficulty getting entries in fields accepted when typed in. They don't seem to be accpeted unless at least one of them is entered by clicking on the menu tab. Where does Find store the history file? I want to be able to get rid of it! Using rox-2.2.0, rox-lib-2.0.1 on Mdk 10.1 -- Bungee |
From: federico <xa...@in...> - 2005-11-27 13:22:25
|
thanks, this version looks better :) however find should not report errors, or should report them elsewere. if i do a search, i gent into the results: grep: xxx: No such device or address grep: xxx: No such file or directory and so on.... > OK, having waited not-at-all-a-long-time-with-no-feedback :), > I decided to go ahead with this and released 006. > > I reverted some of the process-management changes and now Cancel works > again. I banged on it quite a bit and didn't see anything anomalous. > > I like how you (Thomas) improved the keyboard use: Enter now moves > from field to field until all 3 are filled and then a Find is started. > > And I discovered how you kept the 'Open in a Filer Window' option. > (double-click in the Filename column instead of the Text column) > Subtle, but nice. > > Oh, and I didn't like having a new Find automatically clear the old > one. I'm used to having cumulative results - it makes debugging > easier when you search for one thing, see something else interesting, > but then want to go back to the original search without having to > actually search for it again. > > Please review the README file! :) > The Find web page has the same content now too. > (http://www.hayber.us/rox/Find) > > HTH, > > Ken > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log > files > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click > _______________________________________________ > rox-users mailing list > rox...@li... > https://lists.sourceforge.net/lists/listinfo/rox-users > |
From: Ken H. <ke...@ha...> - 2005-11-27 15:40:29
|
federico wrote: > thanks, > this version looks better :) > > however find should not report errors, or should report them elsewere. > if i do a search, i gent into the results: > grep: xxx: No such device or address > grep: xxx: No such file or directory > and so on.... Yeah, I guess I could separate stdout from stderr for that. I'll see what I can do. But I'm not sure that would be altogether good. What if certain files are inaccessible (e.g. due to permissions). Wouldn't you want that listed in the output with the other results? |
From: Ken H. <ke...@ha...> - 2005-11-27 18:12:05
|
federico wrote: > >>> thanks, >>> this version looks better :) >>> >>> however find should not report errors, or should report them elsewere. >>> if i do a search, i gent into the results: >>> grep: xxx: No such device or address >>> grep: xxx: No such file or directory >>> and so on.... >> >> >> >> Yeah, I guess I could separate stdout from stderr for that. I'll see >> what I can do. >> >> But I'm not sure that would be altogether good. What if certain files >> are inaccessible (e.g. due to permissions). Wouldn't you want that >> listed in the output with the other results? > > > uhm... if i am search *into* files, i wouldn't care of inaccessible or > inexistent files. (imho) > a checkbox to add a '2>/dev/null' would be nice ;) Well, that won't work because we're not running find in a shell. Changing: self.find_process = popen2.Popen4(cmd) to: self.find_process = popen2.Popen3(cmd) works though. Now I just have to decide what, if anything to do with the errors. I could do: (self.find_process, self.find_errors) = popen2.Popen3(cmd) and then report the error text upon receiving a bad error code. |
From: Christopher A. <chr...@we...> - 2005-11-27 19:49:21
|
Ken Hayber schrieb: > Well, that won't work because we're not running find in a shell. > Changing: > self.find_process = popen2.Popen4(cmd) > to: > self.find_process = popen2.Popen3(cmd) > works though. > > Now I just have to decide what, if anything to do with the errors. > I could do: > (self.find_process, self.find_errors) = popen2.Popen3(cmd) > > and then report the error text upon receiving a bad error code. How about just dynamically adding a text console under the list of results and write out errors there if there are any? Chris |