wbnsnsr@nmtsun.nmt.edu (William Norris) (10/19/88)
Commodore-Amiga has never imposed guidelines for the ``look-and-feel''
(tm Apple--I wouldn't wan't to be sued :-) Although creativity should be
encouraged, I feel that the time has come to standardize interfaces.
The Amiga has been around for 3 years and I think we can produce
specifications for the ``Amiga Interface.'' We need standard file requesters,
dialog boxes, standard menus (where's the About... requester, Cut/Paste
opetations, programs that can handle many fonts, etc.)
(-: Not even commerical programs like Photon Paint or examples from Commodore
like Fed can handle a large number of fonts :-)
I think that many programs do not take these things into account is because:
1) It's pretty advanced stuff, or
2) Even if you understand it all, producing these resuts
take considerable amount of coding and time.
Maybe include these things in a library, document the calling procedures,
and hopefully we'll see a dramatic improvement in the quality of software?!?
Especially PD/Shareware.
I have started taking notes and designing the required objects. Should
I continue with this? Anybody want to help? Want more specs?dp1g+@andrew.cmu.edu (Demetri Patukas) (10/19/88)
Excerpts from ext.nn.comp.sys.amiga: 19-Oct-88 Standardization William
Norris@nmtsun.nm (1156)
... We need standard file requesters,
dialog boxes, standard menus (where's the About... requester, Cut/Paste
opetations, programs that can handle many fonts, etc.) ...
I agree! I have long since thought that WE NEED STANDARDIZED FILE REQUESTERS,
which would make life easier for both users and programmers, and would even help
make programs smaller. The other things you mention sound good too. I am
interested in seeing your whatever nots or thoughts you have on this.
dp1g @ andrew.cmu.edubarrett@ektools.UUCP (Chris Barrett) (10/20/88)
How about use of the clipboard device! I would be nice to be able to transfer speradsheet to word processor etc... Like the MAC, yea, that's it! Chris. rochester!kodak!ektools!barrett
chimelis@boulder.Colorado.EDU (Chris Chimelis) (10/20/88)
In article <cXLA3Oy00V4D489Esw@andrew.cmu.edu> dp1g+@andrew.cmu.edu (Demetri Patukas) writes: > >I agree! I have long since thought that WE NEED STANDARDIZED FILE REQUESTERS, >which would make life easier for both users and programmers, and would even help >make programs smaller. The other things you mention sound good too. I am >interested in seeing your whatever nots or thoughts you have on this. > I disagree. I think that even if we propose a "soft standard" or a verbal standard, that it would severly limit software authors. Sure, it may reduce software size, costs, etc, but it will stifle the creativity of authors and prevent such great file requesters as those available with Access! and several other programs. Plus, if you do give in to "standardisation", you will also be proving that Apple structure is superior to Amiga flexibility. Chris Chimelis chimelis@refuge.colorado.edu ncar!boulder!refuge!chimelis chimelis%boulder@colorado.bitnet
mp1u+@andrew.cmu.edu (Michael Portuesi) (10/20/88)
> *Excerpts from ext.nn.comp.sys.amiga: 19-Oct-88 Re: Standardization Chris* > *Chimelis@boulder.C (966)* > I disagree. I think that even if we propose a "soft standard" or a verbal > standard, that it > would severly limit software authors. Sure, it may reduce software size, > costs, etc, but it > will stifle the creativity of authors and prevent such great file requesters > as those available > with Access! and several other programs. Plus, if you do give in to > "standardisation", you will > also be proving that Apple structure is superior to Amiga flexibility. I used to think that way, but I am getting tired of seeing programs with half-functional user interfaces because the author is too lazy (or too brain-damaged) to do things right, and as a programmer I would rather have "canned" file requestors, menus, and cut/paste operation in a shareable library somewhere where I wouldn't have to do the work to create the stuff and I wouldn't have to link in a copy of it with every program I write. Perhaps Apple's structure is superior to Amiga's flexibility. The X Window System is even more flexible than the Amiga, and personally I think it sucks the big one as far as user interfaces go. --M Michael Portuesi / Information Technology Center / Carnegie Mellon University ARPA/UUCP: mp1u+@andrew.cmu.edu BITNET: rainwalker@drycas "my friends say she's a dumb blonde, but they don't know she dyes her hair"
wbnsnsr@nmtsun.nmt.edu (William Norris) (10/20/88)
NOTE ON GROUP: Although I believe this correctly belongs in comp.sys.amiga.tech, I receive no response in that group. However, I received several responses in comp.sys.amiga. Here goes... First, I will post the MENU system which I have been working on. This is what I've been working on the most, and is the most complete. I will eventually post ideas about FileRequesters, Requesters (in general), Cursors, String Gadgets, etc. PROPOSED STANDARD MENUS ----------------------- Boing (Hopefully a ball, but currently the (c) symbol) About... ? About box for program -------------------- Help Help for this program (also HELP key) -------------------- Preferences Run preferences * How about the possibility of letting users add to the end of this menu * names of programs. Selecting the item would run that program. File New N Open... O Will post standard file requester later. Close W Save S \ Will post standard file Save As... A / requester for save later. Delete... D -------------------- Print... P Also, print-related options should go in this section. -------------------- Quit Q Programs should inform the user that everything has not been saved, and if he really wants to quit. Information on requester boxes will come later. Edit Undo Z (Redo after Undo has been done) -------------------- Cut X \ Copy C | Save information to clipboard 0 Paste P / Clear * Cut... Copy... Paste... could be used if program allows saving * to other clipboards. The font menu * First, programs should check how many lines are on the screen * Longer menus can be created on an interlaced screen and when * WB 1.4 is here, overscan. * Font names should be listed alphabetically as menuitems * Font sizes should be listed numerically as subitems (menumenuitem) * If you want to get fancy, include a `?' at the bottom of the sizes * to allow the user to enter any allowable font size, and scale * an existing font. This routine will be provided in the library. * Read: Hardly any extra code to implement, but many advantages! * Question: Should the font menu be arranged 1) across several columns * if there are that many fonts or 2) with a down arrow * at the bottom of the menu and scroll down the menu for * the additional columns?
bradch@microsoft.UUCP (Bradford Christian ms1) (10/20/88)
So, I've been lurking about this news thing for about a month now, and figgure it's about time to try to make a contribution... I agree that there is a great need for a standard file requestor, but I also do not necessarily want the same requestor as Joe Blow. Rather than speccing standard file requestors, we'd all be better off if a standard application interface to a file requestor were specified (and endorsed by C-A, of course). Then, file requestors could be created as exec libraries and dynamicly linked with the applications that need them. This would allow everyone to have their own "standard" file requestor. I'm sure there are enough people out there who think they can create the ultimate file requestor, and some of them will put their creations in the public domain. This idea applys to many other objects that appear in various applications. Color requestors immediatly come to mind. Wouldn't it be great if you could use your favorite color requestor in EVERY program that let you pick a color? BradCh _ /) My opinions are not usually the same as my employers'. \`o_O' (But then, whose are...) =( )= Ack! U
chimelis@boulder.Colorado.EDU (Chris Chimelis) (10/20/88)
In article <8XLHINy00VsfM0Z1FF@andrew.cmu.edu> mp1u+@andrew.cmu.edu (Michael Portuesi) writes: >> I disagree. I think that even if we propose a "soft standard" or a verbal >> standard, that it >> would severly limit software authors. Sure, it may reduce software size, >> costs, etc, but it > >somewhere where I wouldn't have to do the work to create the stuff and I >wouldn't have to link in a copy of it with every program I write. > You could put out a 'generic file requester' and other generic gadgets, but I wouldn't FORCE programmers to conform to a standard. Instead of standard- isation, I would suggest introducing a generic system of tools that, if the programmer was 'too lazy', he could link to his/her programmes. This would allow flexibilty for programmers motivated to write extended requesters, but a mechanism to fall back upon if they are 'lazy'. I DO, however, support a global cut/paste/edit system that could exist and function under all software. This would greatly increase the flexibility of the Amiga Workbench OS Interface. Don't take this as a flame. I'm just expressing my views as a creative programmer, an artist, and an individual. Chris Chimelis chimelis@refuge.colorado.edu Internet ncar!boulder!refuge!chimelis UUCP chimelis%boulder@colorado.bitnet Bitnet
peter@sugar.uu.net (Peter da Silva) (10/20/88)
In article <1077@microsoft.UUCP>, bradch@microsoft.UUCP (Bradford Christian ms1) writes: > I agree that there is a great need for a standard file requestor, but I > also do not necessarily want the same requestor as Joe Blow. Rather than > speccing standard file requestors, we'd all be better off if a standard > application interface to a file requestor were specified (and endorsed by > C-A, of course). Well, I suggested one in my original articles on PPIPC. It went over like a lead balloon. If I ever get off my lazy butt and kick Browser 1.5 beta 3 into shape I'm planning to have an AREXX port with the following request: REQUEST default-directory label Which will eventually return with the response string containing a file name (or maybe a space-seperated list of file names), when the user pulls down and selects "label" from the menu where it magically appears. You can easily see that a standalone program could do the same thing. -- Peter da Silva `-_-' peter@sugar.uu.net Have you hugged U your wolf today? Disclaimer: I accept full responsibility for my own typos.
eric@hector.UUCP (Eric Lavitsky) (10/20/88)
In article <1314@nmtsun.nmt.edu> wbnsnsr@nmtsun.nmt.edu (William Norris) writes:
<...
<PROPOSED STANDARD MENUS
<-----------------------
<
<Boing (Hopefully a ball, but currently the (c) symbol)
< About... ? About box for program
< --------------------
< Help Help for this program (also HELP key)
< --------------------
< Preferences Run preferences
<* How about the possibility of letting users add to the end of this menu
<* names of programs. Selecting the item would run that program.
I see no point to have the names of other programs to run in a standard
application menu. This is what the WorkBench/CLI is for. This one would
be near and dear to Randy Spencer's heart. He tried putting a "boing"
ball menu up and got burned a little because while it's possible to
have imagery in a menu item, you can't have it in a menu strip. If it
doesn't take much code to do, having images in menu strips might be a
resonable enhancement for Intuition.
<File
< New N
< Open... O Will post standard file requester later.
< Close W
< Save S \ Will post standard file
< Save As... A / requester for save later.
< Delete... D
< --------------------
< Print... P Also, print-related options should go in
< this section.
< --------------------
< Quit Q Programs should inform the user that everything
< has not been saved, and if he really wants to
< quit. Information on requester boxes will come
< later.
Delete doesn't belong here - use the WorkBench/CLI.
<Edit
< Undo Z (Redo after Undo has been done)
< --------------------
< Cut X \
< Copy C | Save information to clipboard 0
< Paste P /
< Clear
<* Cut... Copy... Paste... could be used if program allows saving
<* to other clipboards.
Looks fine to me except you have two menu selections now with Amiga-P
as the key shortcut. Perhaps Amiga-I (for "Insert") would be more
appropriate for paste?
<The font menu
<* First, programs should check how many lines are on the screen
<* Longer menus can be created on an interlaced screen and when
<* WB 1.4 is here, overscan.
<
<* Font names should be listed alphabetically as menuitems
<* Font sizes should be listed numerically as subitems (menumenuitem)
<* If you want to get fancy, include a `?' at the bottom of the sizes
<* to allow the user to enter any allowable font size, and scale
<* an existing font. This routine will be provided in the library.
<* Read: Hardly any extra code to implement, but many advantages!
<
<* Question: Should the font menu be arranged 1) across several columns
<* if there are that many fonts or 2) with a down arrow
<* at the bottom of the menu and scroll down the menu for
<* the additional columns?
There should not be a seperate font menu - there will always be systems
with more font names than can fit nicely into one menu, unless one
implements scrollable menus/submenus (like on my 630MTG or the Mac/Too).
The font selection should be offered as a menu thusly:
Font... F
under the edit menu perhaps since changing the font can be thought of
as an edit operation. Selecting this should bring up a requester with
a scrollable list of font choices. I think ProWrite from New Horizons
is a good example of how to do this. In fact, any menu selection that
runs the risk of having too many entries should do this, or it should
fill the menu with as many as it can for quick selection and provide
a "More..." selection at the bottom that brings up a requester with
a complete list.
-Eric
ARPA: eric@topaz.rutgers.edu or eric@ulysses.att.com
UUCP: {att,ucbvax}!ulysses!eric or {wherever!}rutgers!topaz!eric
SNAIL: 34 Maplehurst Ln, Piscataway, NJ 08854
"To err is human; To really f*ck up requires the root password."bader+@andrew.cmu.edu (Miles Bader) (10/21/88)
wbnsnsr@nmtsun.nmt.edu (William Norris) writes: > Close W I think that (amiga) Z would be a better keybinding (you know, end of the alphabet, finality), since C isn't available. > Undo Z (Redo after Undo has been done) What about (amiga) U (or does that make too much sense)? Where on earth does Z come from? > Cut X Does X mean anything? I like W better, but that's just 'cause I like emacs... -Miles ----------------
papa@pollux.usc.edu (Marco Papa) (10/21/88)
In article <1314@nmtsun.nmt.edu> wbnsnsr@nmtsun.nmt.edu (William Norris) writes: |First, I will post the MENU system which I have been working on. ^^^^ |This is what I've been working on the most, and is the most complete. |I will eventually post ideas about FileRequesters, Requesters (in general), |Cursors, String Gadgets, etc. Do NOT post to comp.sys.amiga or comp.sys.amiga.tech. Use comp.sources.amiga instead. As anybody can see, Bob is already pretty active. -- Marco Papa 'Doc' -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= uucp:...!pollux!papa BIX:papa ARPAnet:pollux!papa@oberon.usc.edu "There's Alpha, Beta, Gamma and Diga!" -- Leo Schwab [quoting Rick Unland] -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
dillon@CORY.BERKELEY.EDU (Matt Dillon) (10/21/88)
:You could put out a 'generic file requester' and other generic gadgets, but :I wouldn't FORCE programmers to conform to a standard. Instead of standard- :isation, I would suggest introducing a generic system of tools that, if the :programmer was 'too lazy', he could link to his/her programmes. This would All we need is a standard library call (add a new call to the dos.library in 1.4 since the filerequester needs dos to work anyway). The call would standardize the input and output parameters as well. If you don't like it, simply change the library vector. -Matt
ejkst@cisunx.UUCP (Eric J. Kennedy) (10/21/88)
In article <1304@nmtsun.nmt.edu> wbnsnsr@nmtsun.nmt.edu (William Norris) writes: >Commodore-Amiga has never imposed guidelines for the ``look-and-feel'' >(tm Apple--I wouldn't wan't to be sued :-) Although creativity should be >encouraged, I feel that the time has come to standardize interfaces. >The Amiga has been around for 3 years and I think we can produce >specifications for the ``Amiga Interface.'' We need standard file requesters, ... >Maybe include these things in a library, document the calling procedures, >and hopefully we'll see a dramatic improvement in the quality of software?!? >Especially PD/Shareware. I think ARP is a good step in the right direction for some of this, or example, the file requester. (You can even use the thing in ARexx scripts) Of course, Charlie Heath and company can't have the entire effort dropped on them, but maybe some cooperative effort can be worked out. My point is that I think ARP is a good foundation. >I have started taking notes and designing the required objects. Should >I continue with this? Anybody want to help? Want more specs? Yes! -- +-=-=-=-=-=-=-=-=-+ Eric Kennedy | Bush & | ejkst@cisunx.UUCP | Bentsen '88 !! | +-=-=-=-=-=-=-=-=-+
peter@sugar.uu.net (Peter da Silva) (10/21/88)
My comment is... you're too specific. Standard menus shouldn't, at least at
this point, be specified any deeper than:
Title: Jammed closely together, with anout 1.5 character positions
between them. There's no need for extra space.
Implementation:
menu = AddMenu(menubar, newmenuname)
Top level: Text, offset a little to make them look good when hilighted.
Stacked vertically until the bottom of the screen, then
continue on in even, even-height columns. Menu title should
be jammed closely together... let the menus overlap, since
they're not going to be displayed.
Implementation:
menuitem = Additem(menu, itemname)
For grouping a half-character blank space will be left between
groups:
Implementation:
menuitem = Addblank(menu, drawline);
Drawline is true if a line will be drawn. This can be
implemented as a short unselectable item (zero width, not
ghosted, to avoid a dotted line).
Next level: All checkmarked menus here. Offset to the right of the
item they're attached to. Again, take them to the bottom
of the screen then switch to multiple even, even-height
columns.
Implementation:
subitem = Addsubitem(menuitem, subname, checked, mask);
Checked is true if this is checked by default. Mask
is a bitmask of other subitems in the same menu that
are mutually exclusive. If none listed this will be
a toggle.
This will let you build fairly nice looking if bland menus. I use an even
simpler version of this in Browser. I'll post that if you like, but I'm not
going to implement the whole thing. Menus are easy.
How do you define a standard for a scrolling list of text items? For an
editable text pane? For a set of radio buttons? These are the sort of objects
that need to be implemented. With a simple programmer interface...
win = OpenWindow(...);
wwin = NewWidgetWindow(win); /* build extended structure around win */
UseDefaultBorder(wwin);
pane = AddTextPane(wwin, 2, 1, 40, 4); /* Add a 40 by 4 text pane,
resize window to fit if
necessary */
bar = AddRadioBar(wwin, 2, Below(pane)+1, 40, 1,
"Bunch|Of|Button|Labels");
/* Add a radio bar below the pane, with a 1 scanline
gap. The bar is 40 characters wide and one deep,
and contains 4 buttons: BUNCH, Of, Button, and
Labels. Resize window if necessary. */
Show(win); /* Window was created backdrop behind the workbench
window. This brings it to the front and turns odd
the backdrop flag. */
Wait(win->UserPort.mp_SigBits);
while(widgetevent = GetWidgetEvent(wwin)) {
if(widgetevent->widget == bar) {
switch(bar->button) {
...
}
} ...
RecycleWidgetEvent(widgetevent);
}
And so on. This would be way easier than the current setup. You wouldn't need
to count scanlines or guess. You could create new widgets (they're supposed to
be object-oriented, if you hadn't guessed)...
Anyone up for comp.sys.amiga Project #n?
--
Peter da Silva `-_-' peter@sugar.uu.net
Have you hugged U your wolf today?
Disclaimer: I accept full responsibility for my own typos.wbnsnsr@nmtsun.nmt.edu (William Norris) (10/21/88)
In article <10744@ulysses.homer.nj.att.com> eric@hector.UUCP writes: >I see no point to have the names of other programs to run in a standard >application menu. This is what the WorkBench/CLI is for. OK, I agree. I just wanted to see what the responses I would get about including this ``feature''. No one seems to want it. Should we add a color palette requester? On this menu? Somewhere else? File Menu >Delete doesn't belong here - use the WorkBench/CLI. OK, but then applications shouldn't close WorkBench. Edit Menu >Looks fine to me except you have two menu selections now with Amiga-P >as the key shortcut. Perhaps Amiga-I (for "Insert") would be more >appropriate for paste? Oops, my mistake. Paste should have been Amiga-V. The reason for X (Cut) C (Copy) V (Paste) is because these three keys are in a line together. You can quickly do these three operations without removing your hand from the Amiga key while at the same time move your mouse around easily. Font Menu >There should not be a seperate font menu - there will always be systems >with more font names than can fit nicely into one menu, unless one >implements scrollable menus/submenus (like on my 630MTG or the Mac/Too). Does anybody know how to implement scrollable menus? If not, then I think it should be moved. For those people who have asked where these key combinations come from, the Macintrash. For those people who expressed concerns about the file requesters, more information will be prepared this weekend. However, I plan on implementing some ``hooks'' for applications to customize/enhance the requester for their specific application. The main purpose of providing these requesters is for those applications which simply present a string gadget and say, ``Type in the filename: '' William B. Norris IV wbnsnsr@nmtsun.nmt.edu (William Norris) | /// Seulement ``It'll be out RSN.'' |\\ /// l'Amiga peut -- ANY hardware manufacturer/software publisher. | \\// vous l'offrir.
coco@sfsup.UUCP (+Lugo F.) (10/21/88)
How about designing a standard set of functions which every file
requester should have (i.e. a minimum set.) For example:
o multitask while scanning for files,
o access to available devices and volumes, not pre-defined
gadgets with device names
o scroll bar, arrow gadgets, double click selection,
o keyboard shortcuts (i.e. use arrow keys to scroll file list,
ALT+arrows to go to the top/bottom files, SHIFT+arrows to
scroll by pages, Ok/CANCEL shortcuts, etc.
o pattern specifications (*, ?, ranges, etc.)
o PARENT directory gadget (with keyboard shortcut).
o RESTART gadget for restarting file scanning
o single file name string gadget
o any other I may be missing
Let's face it, some people have better things to do than spend their
time developing/testing simple file requesters.
Others can just create their own designs as long as they start with
this minimum set.
Other standards: CUT/PASTE, how about pop-up menus (don't you get
tired of going to the top for menu operations.), window iconizing
(with true image icons, not window fakes), Virtual screens, color
requesters which adjust to screen's type/resolution, more, morE, moRE,
mORE, MORE, MORE, MORE, ... 8*)
//
--Coco \X/
__________________________________________________________
E-Mail: coco@attunix.att.com
Real:
AT&T Bell Laboratories
c/o Felix A. Lugo
190 River Road
Rm. 1-139
Summit, NJ 07901
Tel. (201) 522-5098peter@sugar.uu.net (Peter da Silva) (10/21/88)
If you're going to do this, XCV seems to be the standard triplet to use for cut/copy/paste. I've run into it on a few programs. X X-out/cut C Copy to cut buffer, don't delete. V It's next to X and C, paste cut buffer. -- Peter da Silva `-_-' peter@sugar.uu.net Have you hugged U your wolf today? Disclaimer: I accept full responsibility for my own typos.
rap@ardent.UUCP (Rob Peck) (10/22/88)
In article <2872@sugar.uu.net>, peter@sugar.uu.net (Peter da Silva) writes: > My comment is... you're too specific. Standard menus shouldn't, at least at > this point, be specified any deeper than: > > Title: Jammed closely together, with anout 1.5 character positions > between them. There's no need for extra space. > > Implementation: > menu = AddMenu(menubar, newmenuname) > > Top level: Text, offset a little to make them look good when hilighted. > Stacked vertically until the bottom of the screen, then > continue on in even, even-height columns. Menu title should > be jammed closely together... let the menus overlap, since > they're not going to be displayed. > > Implementation: > menuitem = Additem(menu, itemname) (REST DELETED TO SAVE NET BANDWIDTH) Sounds like Peter is proposing we adopt something VERY VERY close to what already exists as a tool package in "PDTERM", on Fish Disk either 12 or 14 as I recall. In the January 88 issue of AmigaWorld article on PD software, I pointed this out. YES, I think something like this is a reasonable idea. But in an object-oriented bent -- I would also suggest that there be a manager function that would manage global defaults for how a menu item would appear. Thus one might send a message to the global manager to "push current default values", change a parameter, make a few menu items, "pop current default values", then go on to do other menu items using the original defaults. Take another look at PDTERM's source. It may give additional ideas. Rob Peck . . . . . . . . . . .sig='Mud's Women Film Festival - 24 hours of the same episode -> Star Drek'
keithd@cadovax.UUCP (Keith Doyle) (10/22/88)
In article <1077@microsoft.UUCP> bradch@microsoft.UUCP (Bradford Christian ms1) writes: >This idea applys to many other objects that appear in various applications. >Color requestors immediatly come to mind. Wouldn't it be great if you >could use your favorite color requestor in EVERY program that let you >pick a color? I got it! Let's call them "Desk Accessories" and reserve the first menu item in every application to be extensible allowing configurable access to them. Color requesters, screen savers/loaders etc. can all go in there, and developers won't have to write them all themselves. :-) Keith Doyle # {ucbvax,decvax}!trwrb!cadovax!keithd Contel Business Systems 213-323-8170
keithd@cadovax.UUCP (Keith Doyle) (10/22/88)
In article <1314@nmtsun.nmt.edu> wbnsnsr@nmtsun.nmt.edu (William Norris) writes: >* Question: Should the font menu be arranged 1) across several columns >* if there are that many fonts or 2) with a down arrow >* at the bottom of the menu and scroll down the menu for >* the additional columns? Fonts should be in a scrollable requester and not completely contained in a menu bar item. Font selection is generally not a simple canned 'set the flag' operation, a requester can also allow you to preview the font within the requester, select an alternate font directory etc. It's use can be made to be consistant with file requester operation, and may be able to share some common code. One problem I have been struggling with somewhat with file requesters is that I would like to keep the file list around, but if you have multiple file requesters for different file operations, how many lists of files should you actually maintain? Take a typical paint program that has image load/save, brush load/save etc. Should load and save always use the same list? This assumes that you usually load and save to the same directory, and not differing directories. Should load and save be "smart" and use the same list until the user makes one of them different? What about brushes? Should the brush load use the same list as the image load? This business of defaulting to a directory called "brush" is bogus, I've never wanted to put all my brushes in a directory called "brush", as it usually doesn't exist. I suppose if it was automatically created it would be a little more useful, but even then I don't feel the need to put all my images in "brush", "lo-res" or "interlace", I usually prefer to group them all together regardless of resolution. Should file requesters always be "smart" and use the same list until the user selects a new directory (prompting for creation or even new-disk formatting), then automatically build a new list (just for that directory on that particular load/save selection)? If so, when do you decide to free up an old list, or do you just carry around 6 or 7 lists one for each of the image/brush load/save's you've done since starting the program? Keith Doyle # {ucbvax,decvax}!trwrb!cadovax!keithd Contel Business Systems 213-323-8170
pds@quintus.uucp (Peter Schachte) (10/22/88)
In article <10744@ulysses.homer.nj.att.com> eric@hector.UUCP (Eric Lavitsky) writes: >< Cut X \ >< Copy C | Save information to clipboard 0 >< Paste P / >Looks fine to me except you have two menu selections now with Amiga-P >as the key shortcut. Perhaps Amiga-I (for "Insert") would be more appropriate ProWrite (and I believe other prog's as well) uses Amiga-V for paste. I can't think of a mnemonic for this, but X, C, and V are right in a row on a QWERTY keyboard (sorry Dvorak users). I think the Intuition manual contains a section on style suggestions that recommends shortcut keys for common menu items. You might look at this. -Peter Schachte "Clean water? I'm for clean water." pds@quintus.uucp -George Bush ..!sun!quintus!pds
peter@sugar.uu.net (Peter da Silva) (10/22/88)
In article <653@ardent.UUCP>, rap@ardent.UUCP (Rob Peck) writes: > In article <2872@sugar.uu.net>, peter@sugar.uu.net (Peter da Silva) writes: > > My comment is... you're too specific. Standard menus shouldn't, at least at > > this point, be specified any deeper than: [deleted to save bandwidth] > Sounds like Peter is proposing we adopt something VERY VERY close to what > already exists as a tool package in "PDTERM", on Fish Disk either 12 or 14 > as I recall. In the January 88 issue of AmigaWorld article on PD software, > I pointed this out. I've put something equivalent to this in the public domain too. That's one of the main points of my message... it's easy and it's been done. The important part of my message scrtached the surface of an object-oriented metagadget idea. MUCH more important... -- Peter da Silva `-_-' peter@sugar.uu.net Have you hugged U your wolf today? Disclaimer: I accept full responsibility for my own typos.
ejkst@cisunx.UUCP (Eric J. Kennedy) (10/22/88)
In article <2877@sugar.uu.net> peter@sugar.uu.net (Peter da Silva) writes: > X X-out/cut > C Copy to cut buffer, don't delete. > V It's next to X and C, paste cut buffer. V also is an arrow pointing down--"Paste it right *here*." -- +-=-=-=-=-=-=-=-=-+ Eric Kennedy | Bush & | ejkst@cisunx.UUCP | Bentsen '88 !! | +-=-=-=-=-=-=-=-=-+
peter@sugar.uu.net (Peter da Silva) (10/23/88)
In article <13308@cisunx.UUCP>, ejkst@cisunx.UUCP (Eric J. Kennedy) writes: > In article <2877@sugar.uu.net> peter@sugar.uu.net (Peter da Silva) writes: > > X X-out/cut > > C Copy to cut buffer, don't delete. > > V It's next to X and C, paste cut buffer. > V also is an arrow pointing down--"Paste it right *here*." (puzzled look) But why would I want to paste it on the space bar? -- Peter da Silva `-_-' peter@sugar.uu.net Have you hugged U your wolf today? Disclaimer: I accept full responsibility for my own typos.
mlelstv@faui44.informatik.uni-erlangen.de (Michael van Elst ) (10/28/88)
In article <1314@nmtsun.nmt.edu> wbnsnsr@nmtsun.nmt.edu (William Norris) writes: >* Question: Should the font menu be arranged 1) across several columns >* if there are that many fonts or 2) with a down arrow >* at the bottom of the menu and scroll down the menu for >* the additional columns? Several columns want be enough, I have about 500 fonts on my (hard) disk. What about a hierarchy of fonts. Then you could have one menu with all fonts of a family, another menu with the last five font families selected, and one selection point that opens a requester to select other fonts. It's just an idea. Michael van Elst E-mail: UUCP: ...uunet!unido!fauern!faui44!mlelstv