GREYELF@WPI.BITNET (04/01/89)
>From Andrew.Lionel.Dalrymple Fri Mar 31 16:45:37 1989 >On this - you might bring up the multitasking of DIVERSI-DIAL. >This program handles something like 8 ports at 300baud. Sorry, haven't seen it, and probably can't afford it. One question, has anyone started on the project to create a window interface for everyone's (free) use? When I make the task manager program I want something spiffy for control, and the mouse interface is a good choice, since Daemon (as it currently stands) requires a mouse card anyway. That and the fact the mouse can be set to generate an interrupt when moved, or when the button is pressed. -- Michael J Pender Jr Box 1942 c/o W.P.I. I wrote SHELL and Daemon, greyelf@wpi.bitnet 100 Institute Rd. send bug reports, suggestions, greyelf@wpi.wpi.com Worcester, Ma 01609 checks to me. People keep asking me if Shell or Daemon are compatible with the IIc, IIe. YES, I wrote them on my Laser 128. I mean, what would be the challenge to multitasking on a IIgs? I'll start writing dedicated gs programs when somebody sends me one in the mail.
Geva_Apple-Maniac_Patz@cup.portal.com (04/02/89)
All right, I have waited all of 2 days and NOBODY has rushed to implement the standard, PD, windows library for the // series. Thus, I will take said task upon myself. Now, before I rush into it, I want lots of feedback on what people want to see in such a toolbox. Questions which spring to mind are: * Mousetext: Should the system use Mousetext, in which event it would not work on ][+'s or older //es, or should it use the Graphics screen, which would obviously make the package bigger and slower. * Calling procedure: How are the routines actually called? Do we want something akin to the GS toolbox procedure, something like the ProDOS MLI, or something completely different? * Mouse support: Will a mouse be unsupported, essential, or will the toolbox use 'pseudo-mouse' functions (i.e. allow the keyboard and joystick to emulate a mouse) * Level: Should the toolbox allow high-level calls [create dialog box, create menus, etc.], low-level calls [clear screen section, save screen section, etc.] or both? * Are uppercase-only systems, 40-column systems, etc. going to be supported? * Form: What form is the ultimate library going to take? Will it be a run-time library? Will it support BASIC? Assembler? C? Pascal? I'm sure there are lots of others, but these are all that I can come up with off the top of my head. I look forward to hearing your response... %%%% Geva %%%%
nakada@husc4.HARVARD.EDU (Paul Nakada) (04/03/89)
From article <16588@cup.portal.com>, by Geva_Apple-Maniac_Patz@cup.portal.com: > All right, > > I have waited all of 2 days and NOBODY has rushed to implement the > standard, PD, windows library for the // series. Thus, I will take said > task upon myself. Now, before I rush into it, I want lots of feedback > on what people want to see in such a toolbox. Questions which spring > to mind are: I'm also throwing some ideas around in my head.. we'll ahve to see about implementation later.. > > * Mousetext: Should the system use Mousetext, in which event it would not > work on ][+'s or older //es, or should it use the Graphics screen, which > would obviously make the package bigger and slower. I'm thinking enough flexibility to allow for videx videoterm compatibility.. I'm not sure of the specific abilities of these cards, but it should not be tough to substitute charcters (a table maybe) for non mouse text displays.... mouse text is a must, though, for //e's ... > > * Calling procedure: How are the routines actually called? Do we want something > akin to the GS toolbox procedure, something like the ProDOS MLI, or something > completely different? I see the MLI approach as the best.. no clock cycles used to set up the paramater lists, no stack space used... a fairly good approach... > > * Mouse support: Will a mouse be unsupported, essential, or will the > toolbox use 'pseudo-mouse' functions (i.e. allow the keyboard and > joystick to emulate a mouse) As i see it, we need something akin to the X window event loop... This would be something that the programmer could choose to use or not.. Here's what we need... some type of mask to determine what events need to be watched for.. events: mouse movement mouse down mouse up keypress (including both apple combos) I don't really see a need for the point and click aspect of mouse use (as with the macintosh) With the text display, i find pointing a pain, and would much rather use the keyboard much like shrinkit, and proterm do. A better soultion would allow for mouse movement as done in the ProSel utilities where mousemovement basically translates to keypresses. > > * Level: Should the toolbox allow high-level calls [create dialog box, > create menus, etc.], low-level calls [clear screen section, save screen > section, etc.] or both? Here, for flexibility, i would say both.. two key routines that io feel are a must to standardize are the selection of prefixes and filenames.. > > * Are uppercase-only systems, 40-column systems, etc. going to be supported? ??? > > * Form: What form is the ultimate library going to take? Will it be a > run-time library? Will it support BASIC? Assembler? C? Pascal? It has to be in a binary library (possibly relocatable).. it should use aux memory as much as possible to allow for additional application space.. > > I'm sure there are lots of others, but these are all that I can come up > with off the top of my head. I look forward to hearing your response... > > %%%% > Geva > %%%% What we have is that making of a pretty large and flexible library... The only problems i can see are those relateed to speed.. My ersonal feeling here is that if speed becomes a problem, become more specific to the enhanced //e standard... and maybe develop differnt libs for each platform.... enough rambling... let's here some more comments.!!!! -paul __ | Paul Nakada '89 #8-) | North House | nakada@husc4.HARVARD.EDU Harvard College | seismo>!harvard!husc4!nakada.UUCP Cambridge, MA 02138 | rutgers/ nakada@husc4.BITNET 617/498-6255 || 6264 | __|