How to improve request-file ?

[1/6] from: jason::cunliffe::verizon::net at: 21-Jan-2002 21:05

Apologies if this is becoming a FAQ.. Q: How can I improve request-file? features drivin me nuts + wishlist: a. I can't resize it .. and it truncate filenames :-(( b. /file option is handy but I need it to default to open in specified directory, but where I do not know the names of any files there in advance. ie: I need /folder option c. Dir: window is *pathetically* small and cannot be resized. Unbelievable to me in 2002 that anyone creates an interface this primitive for something so basic. d: Does not respond to the mouse-wheel [I know that's an cross OS problem, but is there any way to make it work in some systems??] e. There is no doubleclicking on filenames. Users have to click first on filename to 'select it' then again on OPEN, SAVE or whatver one names the action button. f. I want to add a 'rotate' type button next to the top path field near wher it says "parent". This would allow one to cycle though the previous N path entries. /path option would be a block one could preload. This could make it very userfriendly epsecially if one coudl cotrnol the text label easily on teh rotate button. g. No history... I really want a popup selector with access to request-file history. This would extend the very useful /keep refinement, making it more like FileEx dialog tool for Win32 or others which offer rich history shortcuts: recent files, recent folders, favorite files, favorite folders etc. When doing intensive and repetitive multimedia transfer operations, these are incredible timesavers. h. Visited indication. Styled text: color text with highlight background tint as required. This is sort of a byproduct of history. Files which have been accessed before [since whenever history was defined to start] will be styled differently just like a:link, a:hover, a:visited, in CSS thanks ./Jason

[2/6] from: greggirwin:mindspring at: 22-Jan-2002 11:37

Hi Jason, << Q: How can I improve request-file? >> I started on one of my own, before I knew that request-file existed. I would like a better file requestor as well but it hasn't gotten back up to the top of my priority list yet. Some of the newer stuff RT is doing uses the OS file requestor (at least under Windows) which gives you good functionality, but doesn't match the look of the natvie REBOL UI components. I think lots of people would love to have a file requestor with all the features you mention, but request-file isn't so horrid that anyone has taken the time to write a robust, and greatly enhanced, replacement for it. It's on *my* list, though, along with about 1000 other ideas. :) --Gregg

[3/6] from: petr:krenzelok:trz:cz at: 22-Jan-2002 19:43

Hi, the situation is as follows - there used to be some project dedicated to creation of configurable fm. But it died imo. Let's answer one of your questions and then state one final note :-) Jason Cunliffe wrote:

>Apologies if this is becoming a FAQ.. > >d: Does not respond to the mouse-wheel [I know that's an cross OS problem, >but is there any way to make it work in some systems??] >

not directly related to file-requester, but you have to explicitly support mouse-wheel in your VID design, but it is already achievable. The problem is, RT has not set mouse-wheel events for certain styles as default ... As for file-requester in Rebol - I think it is doable. "Problem" of load function upon directory is, that it returns mixture of files and directories, and first thing you have to do in interpreter level is, you have to sort the block, and choose what is directory and what is ordinary file. Time consuming for dirs containing lots of stuff ... One refinement could solve the situation: load/dir %. - [[dir1/ dir/2 dir/3] [file1 file2 .... fileX]] ... it's unlikely thought that RT will add something like that, in regard to following good/bad news - judge for yourself: Rebol based file requester is gone with IOS. It was replaced by platform native one. I really don't like it, but it is imo thing most not die-hard rebol users will welcome. On the other hand it limits Rebol usage from the embedded area. The same goes for inability to hide mouse pointer. Having current file-requestor with limitations you described, then even I prefer native one ... -pekr-

[4/6] from: ryanc:iesco-dms at: 22-Jan-2002 12:32

> load/dir %. - [[dir1/ dir/2 dir/3] [file1 file2 .... fileX]]

Dont let that stop anybody. There is more than one way to skin a cat. dir-split: func [contents [block!] /local blk][ blk: copy/deep [[] []] foreach name contents [append either #"/" = last name [blk/1] [blk/2] name] return blk ] How fast?

>> t: now/time loop 1000 [dir-split read %.] now/time - t

== 0:00:04

>> length? read %.

== 79

Thats was running on a 450 Mhz box, but still a blink of an eye even on a 100 Mhz box. --Ryan

[5/6] from: petr:krenzelok:trz:cz at: 23-Jan-2002 6:00

Ryan Cole wrote:

> > > > load/dir %. - [[dir1/ dir/2 dir/3] [file1 file2 .... fileX]]

<<quoted lines omitted: 12>>

> Thats was running on a 450 Mhz box, but still a blink of an eye even on a 100 > Mhz box.

Hmm, then maybe I was confused because of load/read time itself. I tried some > 700 file directory on our network. Now it seems to me that 'foreach loop is only a fraction of total dir load time .... thanks a lot ... btw: I would welcome functions like split-dir (we have already split-path), clone (deep copied objects, non shared sub-objects) becoming mezzanine level functions default for everybody ... -pekr-

[6/6] from: ryanc:iesco-dms at: 23-Jan-2002 9:19

Petr Krenzelok wrote:

> Hmm, then maybe I was confused because of load/read time itself. I tried some > 700 > file directory on our network. Now it seems to me that 'foreach loop is only a > fraction of total dir load time .... thanks a lot ... >

Good point, I was really trying to test only the splitting portion. According to the following test, it is actually in the single millisecond range.

>> blk: read %.

== [%cgi-scan.r %REBOL.lnk %win.r %bin-clean.r %Factory Fire/ %xo/ %Internet Explorer.lnk %temp/ %Tune.sfa %tune.txt %user-list...

>> t: now/time loop 1000 [dir-split blk] now/time - t

== 0:00:01

> btw: I would welcome functions like split-dir (we have already split-path), clone > (deep copied objects, non shared sub-objects) becoming mezzanine level functions > default for everybody ... > > -pekr-

I would'nt mind seeing split-dir as part of file orientated module--whenever RT gets around to adding support for modules. I am also reluctant to add more functions to /Core. Take care, --Ryan

Notes

Quoted lines have been omitted from some messages.
View the message alone to see the lines that have been omitted