Text 7309, 212 rader
Skriven 2006-11-05 12:41:42 av Ian Hoare (1:275/311)
Kommentar till en text av Sean Dennis
Ärende: Re: Behind!
===================
Hi Sean,
on Fri, 03 Nov 2006 21:09:42 -0500, you said:-
>You must remember something: I am developing this on an OS/2 platform (I do
not run Windows myself).
Ah yes, I'd forgotten that. Sorry.
>This program I am planning on is not going to be chock full of features. It
>will have a few good ones that it does well and that's that.
> I may just write my own from scratch and figure out how MM stores its indices
from there.
Do you intend the program to be able to read MM files directly then? As
stored by MM, I mean?
I've just had a VERY brief look and it's fairly easy to work out most of it.
If that's what you want to do. I'd have been more inclined to store the
information "your" way and maybe be able to convert either from MM exported
format files, which you're going to have to be able to do anyway, or
directly from the 4/5 .mme files.
> IH> Do you know Eudora or Agent?
>Yes, I know what they are.
That's not what I asked, with respect. As you use OS/2, I guess you won't
have used them, so you won't necessarily have seen the way in which most of
the options can be set via menus, but show up in a text based .ini file.
Basic configuration is FAR easier than say Golded or some of the Dos based
BBS programs. BUT you can edit them to set advanced (as well as basic)
options. It's an excellent method of making the program very flexible yet
easy to set up for relative beginners.
> IH> Do you see this as being a program that runs as a dos style prog in
> IH> a dos style window under windows
>This program will run as a CLI-mode program.
Okay, I've looked that up. The equivalent of a Dos box, like Mealmaster
then.
> IH> I have a REAL horror of using function keys to do things.
>
>F1 is a standard key for help, as is ESC to exit the program. Remember that I
>normally work with CLI/VIO mode programs and do not use "Windows" standard
>keys.
Then you'll need help so you know what these standard commands are. Im not
saying they're better, but about 90% or more of the world's computer users
will know them and will look to use them - which saves extensive help files,
and dumb user error.
An example. Throughout Windows, CTRL-S means "Save" . In NYC, it doesn't,
and if you are in a recipe editing window, and have finished, it is
absolutely automatic to press CTRL-S, rather than take your hands off the
keyboards to go looking for the mouse to press the "save" button. Absolutely
maddening.
>Again, I am not going to load this thing with bells and whistles.
What do you envisage it being able to do that MM can't? (see below)
>I will impliment Jim's idea of a "subsearch" (search within results).
Yes that would be a major plus. It was one of the things I have _always_
pressed for.
>haven't done it before, but I know that I have enough code from SWAG and other
>places that I could learn how to do it directly.
It wouldn't be hard, you merely have to engage in some lateral thinking. The
user would think they're selecting a subset, what the code would do is to
_unselect_ recipes NOT matching the subset. Simple. Actually, I do hope you
implement the "absent" search with - it's one of the features whereby MM
still outperforms NYC, IMO.
>This will be a strictly text-based program.
Okay.
>However, as per your fear (!) of function keys,
It's not fear, I just think they're user hostile, there's no intuitive link
between the keystroke and the function. Look, I'll give an example. We've
got arrow keys right? NOT to use them but to use f7 and f8 to move backwards
and forwards between successive selected records would be positively
perverse. In menus, the up and down arrows are a logical choice, it would
again be positively perverse to use anything else. I'm not saying you would,
but there are CTRL-key combinations that are almost AS intuitive as the use
of the arrow keys. CTRL-P for print, CTRL-O to open (if you're going to
implement multiple cookbooks in different subdirectories as MM does (which
isn't a bad solution) or to use different files in the same sub directory
(as NYC does). CTRL to Save (if that's needed).
>However, if you start doing GUI stuff, you immediately cut out the DOS, Linux
and OS/2 users, which
>is something I don't want to do.
Ah... I had thought that with modern compilers, they understood the
different GUIs of Linux and Windows at the least. I don't understand about
Dos. Didn't you say that it wouldn't work with 16 bit O/S? Will you
therefore be restricting the prog to 32 bit dos? Or have I misunderstood?
If the total number of PC users of a 32 bit DOS who don't have Windows
exceeds 100 I'll eat my socks. Come to that, I'll eat yours as well!
>I am more interested in having a good working program than one that's full of
>pretty pictures.
An icon - with respect - is not a pretty picture, it takes up far less space
on the screen, that's its major advantage - if you ever manage to work out
what it stands for! As I type this in Agent, I've got 8 text based menu
options and 21 icons, they _almost_ take up the same space. However I'm
happy enough with text only menus. It would still be good to have a menu of
options across the top ALA Agent or Eudora though.
>The database structure will be similar to MM's, however, mine will be
extended.
Meaning? More records presumably, and more and larger field?
> - Conversions: I know all about going from "English" to metric
Do you? So when a US recipe calls for 1 stick (are we going to have sticks
of butter, as a legitimate unit?) of butter, or 1/3 cup of chopped celery,
converting to metric will correctly know that 1/3 cup of chopped celery
weighs 40 gms? I'm not talking about the trivial conversions of 28 gms/ounce
450 gms per pound 15 mls per tbs and so on. I'm talking about intelligent
conversions. Nothing does that yet, and while the US persists in using a
variant of the avoirdupois measurement system, and an idiosyncratic method
of measuring solids, that will be a fairly major problem. What do you
envisage about "recognising" that a recipe is using UK pints/cups and so on
rather than US ones? One of MM's weaknesses is that it only accepts 2
character unit names, and furthermore cannot have have additions programmed
in - with equivalences.
I'd drop several MM units, like the lunatic cl (and dl) for the virtually
unused centilitre (and decilitre) and standardise on ml and ltr BUT I would
recognise internally that mls and ml are the same, that tb, tb, tbl, tbsp
and their plurals are all the same and all mean 15 mls AND 3 (ts tsp tsps)
as well as 1/2 fl, floz and so on again.
> - Cycling: Not sure by what you mean.
CTRL U on a higlighted ingredient will cycle through all the equivalent
units.
Take a recipe with 150 mls of cream.
CTRL-U will cycle through 30 ts, 10 tbs, 5 fl, 5/8 US cups 1/2 UK cup, and
perhaps even be bright enough to look up the density in practical terms and
go through 150 gms, 5oz 5/16 lb and so on. I'd certainly like that to be
parametrisable in an ini file - Extended unit conversion - y/n?
Or - a better example. Take a recipe that has 1 1/2 cups of chopped onion.
CTRL-U would first of all cycle through the US/avoirdupois equivalents, of
12 fl, 3/4 US pint, 0.6 UK pints 1.2 UK cups 24 tbs etc but then convert
that to weight and continue cycling through 180 gms, 6 oz, 3/8 lbs and so
on, because it would have an internal database such as is shown here:-
http://www.recipes4us.co.uk/us_cups_to_weight.htm
CTRL M would convert the entire recipe to metric in the recipe editing
"window". CTRL A to American Avoirdupois, CTRL I to imperial. (I chose these
keypresses completely off the top of my head, by the way). However it might
be arguably better to use CTRL I to insert an empty line in the ingredients,
before or after the highlighted line, and CTRL-D to delete the highlighted
ingredients. CTRL -UP would move the ingredient up the list and CTRL-down
would move it down, by the way.
> - Doubling/tripling: I'd have to write the math logic into it to do so. It'd
>take time but I can do it.
Surely that's trivial, isn't it? IF you have a look up table giving
equivalents between tbs and floz, and oz & lbs.
What NYC does which is kinda neat, is that you can either multiply/divide by
anything, or you can resize by the units of the serving size. So in fact,
for my bulk pates, under serving portions I give a weight in grams of the
total mix. Then I can resize so that the weight of one of the ingredients -
say lean pork meat - corresponds to what I've actually got (normally only
takes a couple of shots) and then I have ALL the other ingredients present
in proportion.
However, the way in which NYC deals with resized recipes is clunky, in that
it doesn't like printing a resized recipe without saving it first, which is
a PITA. MM is better in this respect.
>Right now, my goal is to get a basic program that will do the following:
I see. So, I ask again, what do you envisage it doing that MM doesn't? Seems
to me that's the question then. MM works well in a Dos window, though only
if you can cobble together a printer driver for it. But if the main weakness
of MM is in its lack of printer drivers, and your clone would have no way of
driving about 60% of the newer printers on the market because it has no USB
support.... Do I need to say more?
And yes, I DO have very definite ideas about what a recipe program should
do. I wrote my own back in 1984 or so for the Spectrum, which got into the
best seller charts, and have frequently havered over the idea of doing it
again, but there are so many on the market nowadays (which shows there's no
clear market leader - with the implications that has) and programming a PC
is such a different affair to what programming a spectrum in basic and
machine code 20+ years ago, that I've chickened out.
Grin!! I think I should shut up.
Bon appetit
Ian in Forges
--- Platinum Xpress/Win/WINServer v3.0pr5a
* Origin: FidoTel & QWK on the Web! www.fidotel.com (1:275/311)
|