SCHOMAKE@HNYKUN53.BITNET (Lambert Schomaker) (02/24/88)
[] About the recent requests about fsel_input. Wouldn't it be nice to re-design the selecting of files, instead of modifying the existing fsel_input? In my opinion, opening files should be done by means of the standard double-clicking procedure on the desktop. The scenario: 1) Double-click on a .PRG file icon and the program starts, 2) but the desktop stays intact containing all windows. Only, the menu_bar changes into a program title bar, now containing a prompt, (e.g.): ------------------------------------------------------------------------- | MYPROGR Input file? ________.___ | ------------------------------------------------------------------------- | --- --- --- --- --- --- --- --- --- --- | | | | | | | | | | | | | | | | | | | | | | | | |fil| |dta| |etc| |foo| | | | | | | | | | | | | | | --- --- --- --- --- --- --- --- --- --- | | | After a single click on a file icon, the selected file name appears in the bar, clearly visible in system font. D-clicking on a file opens it. Characters typed from the keyboard appear in the bar if manual input is preferred by the user. All Gem desktop manipulations (apart from the drop-down menu's) such as resizing, opening windows etc. are possible. 3) This is repeated for all required input and output files, the prompt changing accordingly. 4) The desktop dissappears and the program starts with its own desktop and menu_bar. 5) Intermediate file saving etc. is handled likewise: the Gem desktop pops up "from under", to give the user a broad overview and desktop control as opposed to the limited fsel_input dialog box. A similar approach could be used in place of the .TTP dialog box, e.g., the user types "<" and selects an input file, types " >" and selects an output file, possibly followed by some typed options. Characters appear in the program title bar, as above. Lambert Schomaker, SCHOMAKER@HNYKUN53.BITNET
braner@batcomputer.tn.cornell.edu (braner) (03/07/88)
[]
Lambert Schomaker posted some ideas on how file selection could be done
in a completely different manner from the "fsel" dialog box.
Another example is the file selector box in the Laser C shell, which is not
at all the standard GEM box. It has a small window with the filenames listed
in it. Directory names have an "open" button next to them, just like they way
they appear in the desktop when one chooses "view in text". Double-clicking
on a directory entry opens the directory. Clicking on a "close" button at the
top left corner of the window closes a directory, returning to it's parent.
If the directory displayed is the root directory of the drive, clicking on
the "close" button displays a directory of drives, like this:
<> A:
<> B:
...
(The <> is supposed to mean the standard "open" button.)
I like this arrangement since the whole thing is compact, and operates
in the same conceptual way the desktop does.
In contrast, two alternative fsel boxes posted recently (under the names
"filefix" and "itembox") add a button for each drive. That's just clutter
in my view. I do like the nice touch of requiring only one click (not a
double-click) on directory names to open them. The PD one of the two
("filefix") is buggy, though: it works fine the first time, bombs on the
second (at least if anything unusual happenned the first time).
My biggest complaints about the GEM fsel box have NOT been addressed by
the posted alternatives. Here is my wish list, if anybody who's into
writing such things wants ideas...
The drive:\directory\subdirectory\*.* entry drives me nuts.
For one thing, the "*.*" should be the default, without the need
to type it. Then there's the very limited editing of that string.
If it says "A:\*.*" and I just want to change the 'A' to 'B', I have
to press ESC to clear it all, then retype the whole mess. Why can't
I position the cursor anywhere in the string with the mouse, Mac style?
(yeah, I know, Apple's lawyers would get mad...) If the "*.*" was
implicit it wouldn't be so bad.
Then comes the worst part. After laboriously typing in the path, I
ALWAYS, automatically, without any thought, hit RETURN. Which kicks
me out of the fsel box, and I have to start all over again. Why, oh why,
can't RETURN, at that point, be equivalent to clicking inside the directory
list? After all, at that point I already have the fingers on the keyboard!
Other suggestions: can't I be a masochist (?) and simply type the full
pathname, including the file name, into ONE text-edit input field, if I so
prefer? Why can't the thing remember where I was last time around (the
application, really, should do that) (well, "filefix" tries to do that, but
if my last attempt involved typing in a nonexistant path, it refuses to let
me in at all the next time).
Enough bitching. I'll sign off and return to the UNIX shell... :-)
- Moshe Branerdale@slovax.UUCP (Dale L. Thomas) (03/08/88)
> My biggest complaints about the GEM fsel box have NOT been addressed by > the posted alternatives. Here is my wish list, if anybody who's into > writing such things wants ideas... > > The drive:\directory\subdirectory\*.* entry drives me nuts. > For one thing, the "*.*" should be the default, without the need > to type it. Then there's the very limited editing of that string. > If it says "A:\*.*" and I just want to change the 'A' to 'B', I have > to press ESC to clear it all, then retype the whole mess. Why can't > I position the cursor anywhere in the string with the mouse, Mac style? > (yeah, I know, Apple's lawyers would get mad...) If the "*.*" was > implicit it wouldn't be so bad. > On editing the drive directory line: You can use the arrow keys to edit the drive directory line. To change the A to B move the cursor over the A, hit DELETE and type in the B. I do this all the time. I do agree with you on the other points. Fsel_input is brain dead. It took me a long time to get myself not to hit return after typing in the drive spec. -- {psivax,ism780}!logico!slovax!dale : {hplsla,uw-beaver}!tikal!slovax!dale Dale Thomas R & D Associates,3625 Perkins Lane SW,Tacoma,Wa 98499,206-581-1322
federico@actisb.UUCP (Federico Heinz) (03/09/88)
In article <3951@batcomputer.tn.cornell.edu> braner@tcgould.tn.cornell.edu (braner) writes: >[] > [text deleted] >The drive:\directory\subdirectory\*.* entry drives me nuts. >[...] Then there's the very limited editing of that string. >If it says "A:\*.*" and I just want to change the 'A' to 'B', I have >to press ESC to clear it all, then retype the whole mess. You don't need to clear the whole string. You can position your cursor using the arrow keys (cursor back and cursor forward only, since cursor up/down will take you to the next/previous field - or the other way around). The arrow keys are nondestructive and allow you to change the drive spec without killing the whole line. It's not very elegant (as a matter of fact I hate it) but it's possible. -- Federico Heinz "In Dubio Pro Libido" BIX: fheinz | Beusselstr. 21 UUCP: ...!unido!tub!actisb!federico | 1000 Berlin 21 Tel: (030) 396 77 92 | F.R. Germany.
c162-br@zooey.Berkeley.EDU (Warner Young) (03/09/88)
In article <3951@batcomputer.tn.cornell.edu> braner@tcgould.tn.cornell.edu (braner) writes: >[] >My biggest complaints about the GEM fsel box have NOT been addressed by >the posted alternatives. Here is my wish list, if anybody who's into >writing such things wants ideas... >The drive:\directory\subdirectory\*.* entry drives me nuts. >For one thing, the "*.*" should be the default, without the need >to type it. Then there's the very limited editing of that string. >If it says "A:\*.*" and I just want to change the 'A' to 'B', I have >to press ESC to clear it all, then retype the whole mess. Why can't >I position the cursor anywhere in the string with the mouse, Mac style? >(yeah, I know, Apple's lawyers would get mad...) If the "*.*" was >implicit it wouldn't be so bad. >Then comes the worst part. After laboriously typing in the path, I >ALWAYS, automatically, without any thought, hit RETURN. Which kicks >me out of the fsel box, and I have to start all over again. Why, oh why, >can't RETURN, at that point, be equivalent to clicking inside the directory >list? After all, at that point I already have the fingers on the keyboard! >Other suggestions: can't I be a masochist (?) and simply type the full >pathname, including the file name, into ONE text-edit input field, if I so >prefer? Why can't the thing remember where I was last time around (the >application, really, should do that) (well, "filefix" tries to do that, but >if my last attempt involved typing in a nonexistant path, it refuses to let >me in at all the next time). >- Moshe Braner Okay, I am currently at work on a new fsel_input routine. There are some things that I've done which I doubt I'll change, like: This will be a completely new fsel_input. It takes a few more arguments than the old one, so there's really no way to trap for the old one and pop up this one. Which means, that you can use it in your own programs, but existing ones still suffer. I will include a string for a title (eg. Delete Junk), so you know what you're doing. There will be an option to sort the files in several ways, mostly like the Desktop does. Re-selecting the drive letter will be handled through two arrow buttons (up and down through the alphabet). Aside from that, since I'm not yet done, I'm open to suggestions. I'll try to work in as much as possible, while keeping it compact. When I'm done, I'll be glad to release the source. BTW, I am using Alcyon 4.14, just in case those of you with different C compilers need to know. Email me your suggestions, and we'll see what happens... \ /arner - Writer of the dreaded Safety Seal Reviews \ / / - Owner of the vaporware group Safety Seal Software \/ \_/oung | - Disclaimer: I'm not associated with any of the companies \_| above, in any way except (possibly) as a customer.
fireplace@cup.portal.com (03/09/88)
In a previous article, braner@batcomputer.tn.cornell.edu writes: >For one thing, the "*.*" should be the default, without the need to type it. To my knowledge, if you click on the bar at the top of the directory list (instead of in the list), it automatically defaults to "*.*". It's one of those nifty "hidden" features. I could of been dreaming this. 8-) You mean you really still like the ATARI 8-bit? <----- fireplace@cup.portal.com <------------------------------------------ sun!portal!cup.portal.com!fireplace
fireplace@cup.portal.com (03/09/88)
Remember, there is a wonderful replacement file selector called the "Universal File Selector". You simply put in in the AUTO folder and forget about it. It adds a click-on drive selector plus Format, Create Folder, Move, Copy, Rename, Delete, Disk Info, Print Directory, Protect and Unprotect. It is well worth it's outrageous price of $15 - I suggest you check it out.
martin@lakesys.UUCP (Martin Wiedmeyer) (03/11/88)
In article <3768@cup.portal.com> fireplace@cup.portal.com writes: >Remember, there is a wonderful replacement file selector called the "Universal >File Selector". You simply put in in the AUTO folder and forget about it. It >adds a click-on drive selector plus Format, Create Folder, Move, Copy, Rename, >Delete, Disk Info, Print Directory, Protect and Unprotect. It is well worth >it's outrageous price of $15 - I suggest you check it out. I recommend it too from what I've seen of the demo which was posted here. The only thing that I'd like to see added is user definable masks of showing *.PRG, or *.C or *.DOC files, instead of typing the blasted things in. Other than that, it's a fine job. -- | Marty Wiedmeyer | | Lake Systems, Milwaukee, WI | | UUCP: {ihnp4,uwvax}!uwmcsd1!lakesys!martin | | Disclaimer: I take the heat for my own (mis)statements..... |
vxp6840@ritcv.UUCP (-Vitas P.-) (03/13/88)
In article <2877@slovax.UUCP> you write: >> My biggest complaints about the GEM fsel box have NOT been addressed by >> the posted alternatives. Here is my wish list, if anybody who's into >> writing such things wants ideas... >> >> The drive:\directory\subdirectory\*.* entry drives me nuts. >> For one thing, the "*.*" should be the default, without the need >> to type it. Then there's the very limited editing of that string. >> If it says "A:\*.*" and I just want to change the 'A' to 'B', I have >> to press ESC to clear it all, then retype the whole mess. Why can't >> I position the cursor anywhere in the string with the mouse, Mac style? >> (yeah, I know, Apple's lawyers would get mad...) If the "*.*" was >> implicit it wouldn't be so bad. >> > >On editing the drive directory line: > >You can use the arrow keys to edit the drive directory line. To change the >A to B move the cursor over the A, hit DELETE and type in the B. I do this >all the time. I do agree with you on the other points. Fsel_input is brain dead. >It took me a long time to get myself not to hit return after typing in the >drive spec. > >-- >{psivax,ism780}!logico!slovax!dale : {hplsla,uw-beaver}!tikal!slovax!dale >Dale Thomas R & D Associates,3625 Perkins Lane SW,Tacoma,Wa 98499,206-581-1322 Also, if you want to change from drive A: to drive C:, simply press escape type c: then point your mouse at the bar over the filenames ( you know: ===== *.* ===== ) and press the left mouse button. This will change the default to drive C:, change the drive ID to C:\*.* and do a re-directory! It works and is faster than retyping C:\*.* everytime. -Vitas P.- ...!rochester!ritcv!vxp6840
federico@actisb.UUCP (Federico Heinz) (03/14/88)
As a first excercise in GEM programming, and since it has been brought up recently in this newsgroup, I decided to take a hack at yet-another-fsel- -replacement. Not that the world is starving for one (I have FILEFIX and I like it a lot), but it seemed a nice way to learn to use buttons, sliders, etc. Of course, I decided to make the thing as a function (I'm doing it in C) first, then see how to tie it to the AES call. I started to work on the support code (which should better work unchanged when I go memory-resident), when I noticed the memory allocation problem. However I do it, I need to keep a list of all matching files in memory in order to sort it, go forward and backward through it, etc. I could reserve some static amount of memory and hope the user will never overflow it, but it seems a waste to me. I tried to determine whether FILEFIX goes this way by creating a directory with about 250 files, and it didn't overflow. It behaved somewhat funny (the "elevator" started to appear in very strange places), but it didn't crash. I suppose 250 is above any sensible heuristic amount one would want to statically allocate, so I assume that FILEFIX allocates memory dynamically. There again, I've repeatedly read in the net that Malloc is buggy, and that a certain amount of Malloc/Mfree calls per process fully messes up the system. Since such an add-on belongs to the caller process but cannot use the same memory pool, I must make at least one Malloc call per dialog and a later Mfree for it. This means that if the user calls my file selector often enough, he might crash the machine. Now tell me, how is it done? I had expected the user interface to be the "difficult" part (because I'm new to it). But, as usual, the environment bugs are taking the lion's share of my programming effort. By the way, would the author of FILEFIX contact me? I've got a bug report to do (and a few questions to ask). -- Federico Heinz "In Dubio Pro Libido" BIX: fheinz | Beusselstr. 21 UUCP: ...!unido!tub!actisb!federico | 1000 Berlin 21 Tel: (030) 396 77 92 | F.R. Germany.
uace0@uhnix2.UUCP (Michael B. Vederman) (03/15/88)
If your new fsel_input routine keeps the same first parameter, and all other
parameters are extraneous extras, then you can make it compatible with the
current system call. Just make sure you check for legit parameter passing.
- Mike
--
for (;;) : Use ATARINET, send an interactive
do_it(c_programmers); : message such as:
: Tell UH-INFO at UHUPVM1 ATARINET HELP
University Atari Computer Enthusiasts : University of Houston UACEwes@obie.UUCP (Barnacle Wes) (03/23/88)
In article <194@actisb.UUCP>, federico@actisb.UUCP (Federico Heinz) writes: > There again, I've repeatedly read in the net that Malloc is buggy, and that > a certain amount of Malloc/Mfree calls per process fully messes up the > system. Yah, that's a little bit of brain damage GEMDOS inherited from MeSS-DOS: the Malloc/Mfree system uses "memory handles" to store information on the Malloc'd blocks, and there seem to be about 20 handles per process (makes sense, that's how many file handles there are). There were ways of getting around this in MS-DOS, but GEMDOS does not seem to use exactly the same scheme, and the work-arounds don't work. The usual way to get around this is to write your own malloc/free routines. The start-up file checks to see how much memory is available (use Malloc(-1L)) and divides it into 20 chunks. When you call malloc, it looks to see how much is available, if not enough, it calls Malloc to get another 1/20th of available memory, and allocates it out of that. If you use MWC, this is already done for you. Of course, that makes your fsel_input MWC specific. You win a few, you loose a dozen. Wes -- /\ - "Against Stupidity, - {backbones}! /\/\ . /\ - The Gods Themselves - utah-cs!utah-gr! / \/ \/\/ \ - Contend in Vain." - uplherc!sp7040! / U i n T e c h \ - Schiller - obie!wes