leue@galen.crd.ge.com (Bill Leue) (03/13/91)
No, of course there is no such product yet! However, now that I've got your attention, isn't it about time that we in the HC user/developer community started making our desires for new features known? If Claris runs true to form, there should be a 'Pro' version of HC out in 1-2 years. Let's start a good thread going and perhaps we can influence the feature set of the next version. Here's my personal wishlist: 1. Better Color support, including color drawing tools and color properties for objects, e.g., color fonts properties for buttons and fields. This is the only missing feature that really separates HC from Supercard, IMHO. 2. User-defined "first-class" objects, with user-defined Properties. I believe that a feature like this was thought about for the 2.0 release but eventually dropped. "First-class" objects would be like buttons, fields, etc: capable of originating and receiving messages, being sources of value, being draggable, resizable, etc., and having Properties which can interact with "set" and "get" like other HC properties. Such user-defined objects would almost certainly have to be written in some external language, rather than Hypertalk. Perhaps we can add 'ODEFS' (Object definitions) to XCMD's and XFCN's. 3. Better printing support, including Hypertalk properties and commands for setting parameters normally determined in Print and Page Setup dialogs. This may be a tough one until the new Apple printing architecture is released, as most of these parameters are currently "owned" by the print drivers. 4. A set of Claris-supported XCMD`s and XFCN's for device interfaces: a serial port interface library, network library, and file system interface library come to mind immediately. I'm sure that there are many others out there with good ideas. How about some chit-chat on this topic? (BTW, just because I say "Claris" in this note, that doesn't mean that I'm ignoring the excellent support that the Apple HC team has been giving to people over this net. Are you all going to be working for Claris some day? No, forget I asked :-)) -Bill Leue leue@crd.ge.com
johnston@oscar.ccm.udel.edu (Bill Johnston) (03/15/91)
In article <17537@crdgw1.crd.ge.com>, leue@galen.crd.ge.com (Bill Leue) writes... >No, of course there is no such product yet! However, now that I've got your >attention, isn't it about time that we in the HC user/developer >community started making our desires for new features known? If Claris >runs true to form, there should be a 'Pro' version of HC out in 1-2 >years. Let's start a good thread going and perhaps we can influence >the feature set of the next version. Why not? If I were a "Pro" or (even a greedy amateur) what I would want is a way to create double-clickable run-time versions of stacks. Stacks are hard to sell, even if one puts alot of work into a highly specialized solution to a real problem. >1. Better Color support, including color drawing tools and >color properties for objects, e.g., color fonts properties for >buttons and fields. This is the only missing feature that really >separates HC from Supercard, IMHO. Yes, and color is what will separate most Mac users from the stacks that rely on it. HyperCard is mostly a black and white 72-dpi bitmap ditty that works in the same clean, predictable way for everybody. I don't mind that it takes effort for people to write stacks that won't run on my Mac -- I even LIKE that fact. 4-bit, 8-bit, 24-bit? Do we bundle video cards with our stacks? Simple is nice sometimes. >4. A set of Claris-supported XCMD`s and XFCN's for device interfaces: >a serial port interface library, network library, and file system interface >library come to mind immediately. In my opinion, asking for Claris support would be tantamount to killing the goose that lays the golden egg. Much of the good stuff comes from Apple (directly or indirectly) anyway -- if the stuff had to be supported by Claris we'd end up getting less and have to jump through more hoops to use it. The guys responsible for the serial port toolkit, the appleshare toolkit, the Support Tools externals, and the TCP/IP stuff would be less willing to kick in if they know that they are going to end up having to answer to Claris if a user needs to know why xyz xcmd won't work with his or her stack. It might be nice if that stuff could be collected and distributed on a "buyer beware" basis by somebody besides APDA, but official support -- no thank you! Such a collection of externals would be a good addition to the vaporware $199 development version of HyperCard 2. Yes, I know that the $199 version is for Exxon who won't buy a product unless it's suitably expensive. But a collection that merely put together the externals that are currently available by anonymous ftp might save that much in modeming fees (or time, if anybody were foolish enough to admit to what's eaten by ftp and netnewsing.). -- Bill Johnston (johnston@oscar.ccm.udel.edu) -- 38 Chambers St.; Newark, DE 19711; (302)368-1949
cohill@vtserf.cc.vt.edu (Andrew M. Cohill) (03/15/91)
In article <17537@crdgw1.crd.ge.com> leue@galen.crd.ge.com (Bill Leue) writes: >No, of course there is no such product yet! However, now that I've got your >attention, isn't it about time that we in the HC user/developer >community started making our desires for new features known? If Claris >runs true to form, there should be a 'Pro' version of HC out in 1-2 >years. I have a couple of items: 1) Object-oriented drawing. The perfect example for a use of this feature is to provide users with a map of the stack. In any kind of stack that grows and develops new links and nodes, keeping the map up to date with bitmap graphics is excruciating work. All I want is basic geometric shapes and the ability to connect them with rubber band lines (i.e. if I move the object, the line stays connected to it). Actually, if you could just come up with a line object that you could connect to fields and buttons, the geometric object would hardly be necessary. 2) Teach the report generator to span pages. Right now, if you have a field attached to a 'report field' in a report, if the text in the field exceeds the space allotted to it, it just gets cut off, no questions asked. This makes it very difficult, if not impossible, to design reports to print cards with scrolling fields of text, unless you can guarantee that you will never have more text in the field than will fit on a single page. -- | ...we have to look for routes of power our teachers never | imagined, or were encouraged to avoid. T. Pynchon | |Andy Cohill cohill@vtserf.cc.vt.edu VPI&SU
px@fct.unl.pt (Joaquim Baptista [pxQuim]) (03/16/91)
I have only one wish. Make hypercard FAST. If the underlying machinery is fast and general, you can program EVERYTHING yourself. Right now, one just has to avoid loops, since the overhead of interpretation is so large that any loop which executes 10 or 20 cicles takes seconds to complete. I gained interesting insight into this by trying to write the fastest "count words in file" program. I started with an obvious read-line-by-line version and ended up with a read-chunk-and-call-a- language-primitive version (the primitive being "the number of words of ..."). Now, I know the primitive is there but, as clarivident as the designers of Hypertalk may be, I will always need some thing that they did not think about, even if they are willing to put everything into Hypercard. So MAKE IT FAST, and I'll make the rest. -- Joaquim Manuel Soares Baptista, aka px@fct.unl.pt, px@unl.uucp Snail: CRIA, UNINOVA, FCT/UNL, 2825 Mt Caparica, Portugal So long, and thanks for all the fish.
tonyrich@titanic.cs.wisc.edu (Anthony Rich) (03/16/91)
On my wishlist: I'd like LESS! I don't like that there are buttons AND fields; I'm forever trying to make one act like the other. How about getting rid of both and just having ONE more-general kind of thing, the "object", which has a variety of visual representations: graphics, text, icon, button, line, polygon, scrolling list, whatever. It might be nice if several representations could be displayed simultaneously, (at least text and graphics; maybe a geometric figure, too), so that you could have a single object that displays text over a graphic -- like a state in a map of the United States, for example, or a line that carries a text label along its length no matter which way the object was rotated. That way there's only ONE object to script and ONE object to handle a click, not multiple overlapping objects. Each visual representation should be modifiable separately, so one could lock the graphics displayed but still allow displayed text to be edited, for example. Basically, I'd like HyperCard Pro to be something like a drawing program like Canvas, except that every object has a script. It would be nice if objects could be grouped and ungrouped for dragging and animation purposes. To really make it fancy, you might be able to define special relationships between objects, like "joined at a pivot point", or "connected by a rubber band object". I'd also like to dump the idea of referring to objects as "background" or "foreground". If a script in one stack refers to an object in some other stack, it shouldn't have to know or care whether that remote object happens to be in the background or foreground of its card. The name or ID of the object should be enough to identify it. That way scripts wouldn't have to be changed every time the objects they refer to are moved from the foreground to the background or vice versa. One thing I'd like ADDED is a "rectangular grid of scrolling cells" object. Then we can all stop trying to fake it with those awkward scripts that make parallel fields scroll simultaneously. I think tables are common enough that they should be directly supported. Or should be a "rectangular grid of scrolling objects" object...? (Hmmm. Then we could call it "Finder". ;^) It seems like drawing programs, HyperCard, word processors, databases, and spreadsheet programs are all inching toward the same common set of features. I wish someone would just skip ahead and put them all together; then we could skip all the endless little updates as the separate programs converge. -- Tony -- ----------------------------------------------------------------------- | EMAIL: tonyrich@cs.wisc.edu | The essence of learning is | | Disclaimer: I speak only for myself. | repetition, repetition! | -----------------------------------------------------------------------
guzdial@zug.csmil.umich.edu (Mark Guzdial) (03/18/91)
One of the things on my wishlist is some control over what happens when the user is in button or field tool mode. I don't necessarily need all the control that SuperCard gives me (though that would certainly be nice.) I'd just like to catch some of the automatic things that would be easily caught. For example, when double-clicking on a button or field, I'd like it if the info dialog box came up through doing a DoMenu "Button Info" so that I could replace it with my own dialog box if I wanted. Unfortunately, that tie between double-clicking and the info box is currently hard-wired, which makes it hard to (for example) create friendlier dialogs for elementary school students learning to program in HyperCard. Mark Guzdial guzdial@csmil.umich.edu
mike@pyrite.SOM.CWRU.Edu (Michael Kerner) (03/18/91)
What about hot links? I don't know if SYSTEM 7 does this in HC (I prefer to wait 6-9 months before putting the developer version of anything on - just LOVE discovering bugs in the middle of a prototype - is it my logic or the environment? Anyhow, howabout having cards/fields linked with something like the subscribe or edition functions from 7.0? I change a field, and the change is noted everywhere. Actually, I think there are a couple of features that could be stolen from 4th Dimension like stack links. I think HC can steal the standard for being a real OODBMS, but REAL object definition and linking would be important to me. Oh, one other thing - make stacks multi-user. I can't complain too much, though - $800 per copy for 4th Dimension to get these features is a far cry from $50 - but HC does have a HUGE jump on everything else in terms of time. So while some of that may have been lost, HC is still mentioned in OODBMS and OOP articles...another reason to keep my SE and IIcx instead of getting a NeXT (with Improv free!) Mikey. Mike@pyrite.som.cwru.edu
carlc@hubcap.clemson.edu (Bobby Clark) (03/18/91)
In article <17537@crdgw1.crd.ge.com> leue@galen.crd.ge.com (Bill Leue) writes: >No, of course there is no such product yet! However, now that I've got your >attention, isn't it about time that we in the HC user/developer >community started making our desires for new features known? If Claris >runs true to form, there should be a 'Pro' version of HC out in 1-2 >years. Let's start a good thread going and perhaps we can influence >the feature set of the next version. >-Bill Leue >leue@crd.ge.com > Since you asked... How about adding better multiuser-support for stacks on file server, like AppleShare? Specifically, I want record-locking (or maybe "card-locking" is a better term) so multiple-users can have write-access to different cards in the same stack. Currently (I believe) HC limits access to users at the stack level. Even better (error) messaging to scripts that try to access busy stacks would be a help. Anybody agree? Otherwise, ditto to some of the other features listed in previous postings. Especially, the ones about creating run-time versions that could run without HC present, and faster executing code. Claris, are you listening?
marti@saturn.ucsc.edu (Marti Atkinson) (03/21/91)
Ditto to all of the previous comments. I have two main gripes:
1) more control over defining my own classes and subclasses of objects...
for example, sub classes of buttons that behave in certain ways
2) multi-user, multi-launch stacks. We have networked labs and its a
real pain not to be able to run stacks for classroom use via the network
Marti Atkinson
University of Calif. at Santa Cruz
marti@saturn.ucsc.edu
marti@uccrls.BITNET
..!ucbvax!ucscc!saturn!martibayes@hplvec.LVLD.HP.COM (Scott Bayes) (03/22/91)
> I'd like LESS! I don't like that there are buttons AND fields; I'm > forever trying to make one act like the other. How about getting rid of > both and just having ONE more-general kind of thing, the "object", > which has a variety of visual representations: graphics, text, icon, > button, line, polygon, scrolling list, whatever. And a bit more for me. Currently buttons are not containers for user data, but fields are. However, fields must either be hidden or must display their data to the user (I won't mention horrible kluges with "the scroll", etc). They usually contain the user's data (either just for viewing, or for editing), not the programmer's data. I'd like all objects to be able to display user text (like the contents of a field, or the name of a button) as well as having their own containers: "the data". I'd like to be able to "edit the data of object x", "get the data of object x", "set the data of object x". Look at the scripts in the Tools (?) stack; they often start out with a function commented "don't move this fcn", whose sole job is to return some data for use by handlers. How much simpler not to have to store data as source, but instead to say "set the data of card button "xyzzy" to avalue"! No hidden fields, etc. In HC, data meant to be available at startup is too often stored as code, unless you want to put up with hidden fields, etc. Globals don't provide the functionality of "the data of x", as they do not survive Quitting HC. In 2.0, bkgnd fields already have shared and non-shared text, but I'd much rather have a regular design. Also, I don't want to preempt the shared data to my own evil purposes: it confuses other programmers. Scott Bayes