oliver@thelink.UUCP (Joel Sumner) (06/29/88)
have a Toolbox question.. In Applications such as DeluxePaint II, clicking the mouse in the tools (to select, say the pen) does not deactivate other windows (i.e. It does not 'activate' the tool window. When I say this, I mean that it was stated that when a user clicks on an inactive window, it only becomes active and the mouse click has no effect on the window other than making it active.) How is this accomplished? In the example programs to TML Pascal (Standalone), a drawing program is included that allows you to 'draw'. The thing that I notice in that program is that you must first 'activate' the tool window before selecting a tool and then 'activate' the drawing window before drawing. How can this be avoided? This could be beneficial in say, a Calculator NDA so that it does not require a window to be deactivated just to make a quick computations (The IIgs manipulated Windows too quickly, I was jealous when I saw the MAC finder as opposed to the IIgs finder) ---------------------------------------------------------------------------| | oliver@thelink.UUCP |AT&T (219) 291-8343| GEnie K.SUMNER [Joel] | | (Joel Sumner) |----------------------------------------------------| |USnail 1505 Sheffield Ct. | It is always darkest before the lights go out | | South Bend, IN 46614| | !--------------------------------------------------------------------------! ZZA
keith@Apple.COM (Keith Rollin) (06/29/88)
In article <148@thelink.UUCP> oliver@thelink.UUCP (Joel Sumner) writes: > > have a Toolbox question.. In Applications such as DeluxePaint II, >clicking the mouse in the tools (to select, say the pen) does not deactivate >other windows (i.e. It does not 'activate' the tool window. When I say this, >I mean that it was stated that when a user clicks on an inactive window, it >only becomes active and the mouse click has no effect on the window other >than making it active.) How is this accomplished? In the example programs >to TML Pascal (Standalone), a drawing program is included that allows you to >'draw'. The thing that I notice in that program is that you must first >'activate' the tool window before selecting a tool and then 'activate' the >drawing window before drawing. How can this be avoided? This could be Doing what you want should be very easy. Windows are only brought to front on (I think) 2 calls: SelectWindow and BringToFront. If neither of these calls are made when a window is clicked on, then it won't be brought to front. TML's Pascal sample program probably works the way it does because it uses TaskMaster to perform a lot of operations. When writing a quickie sample program, it is very tempting to simply set the TaskMask to $0000FFFF and leave your worries behind. However, TaskMaster will automatically call SelectWindow if its call to FindWindow detects a click on an incactive window. That is why many programs do not use windows that float in the background all the time (because they use TaskMaster). You can get around this in several ways. 1) Don't use TaskMaster. This is a pain and not really necessary. 2) Don't set the tmFindW bit in the TaskMask. This will cause TaskMaster to return to you immediately after a mouse click. 3) Clear bits tmDragW, tmContent, and tmInfo in the TaskMask (you may have to fiddle with the last bit...I think the documentation is wrong that you have to SET it in order to get TaskMaster to ignore clicks in the infobar...). Anyway, this last option seems to be the best in terms of getting TaskMaster to do everything except activate windows. I hope that there are no problems with this; the last time I tried it, it didn't work, but that was with some unreleased System Software -- I have been assured that it has been fixed (knock on wood!). Keith Rollin amdahl\ Developer Technical Support pyramid!sun !apple!keith Apple Computer decwrl/ "You can do what you want to me, but leave my computer alone!"
oliver@thelink.UUCP (Joel Sumner) (07/01/88)
Keith Rollin writes.... >Joel Sumner Writes >>I have a Toolbox question.. In Applications such as DeluxePaint II, >>clicking the mouse in the tools (to select, say the pen) does not deactivate >>other windows How is this accomplished? > When writing a quickie sample >program, it is very tempting to simply set the TaskMask to $0000FFFF and >leave your worries behind. (Isn't the TaskMask $1FFF? That is the way I see it in TML but they may not be setting a bit or two) >However, TaskMaster will automatically call >SelectWindow if its call to FindWindow detects a click on an incactive window. >That is why many programs do not use windows that float in the background all >the time (because they use TaskMaster). >You can get around this in several ways. 1) Don't use TaskMaster. This is >a pain and not really necessary. 2) Don't set the tmFindW bit in the >TaskMask. This will cause TaskMaster to return to you immediately after a >mouse click. 3) Clear bits tmDragW, tmContent, and tmInfo in the TaskMask >(you may have to fiddle with the last bit...I think the documentation is >wrong that you have to SET it in order to get TaskMaster to ignore clicks >in the infobar...). >Anyway, this last option seems to be the best in terms of getting >TaskMaster to do everything except activate windows. I hope that there are >no problems with this; the last time I tried it, it didn't work, but that >was with some unreleased System Software -- I have been assured that it has >been fixed (knock on wood!). I will keep this in mind... I was also thinking that GetNextEvent would work fine also. My main idea was to make an NDA to take advantage of the unactivated window usage. Since the Task Master manipulates the windows, it sounds like it would be impossible to make an NDA stay in the backround but still perform since the NDA has no control whatsoever over the program that it is running under. Though you could create an Application that allows the windows not to me "brought forward" but then you get into trouble if you activate other NDA's that do not benefit from this 'feature'. Oh well, it was just another thought (anyone want to try this one? If not, it will go into the "old ideas" box.) >Keith Rollin amdahl\ >Developer Technical Support pyramid!sun !apple!keith >Apple Computer decwrl/ >"You can do what you want to me, but leave my computer alone!" ---------------------------------------------------------------------------| | oliver@thelink.UUCP |AT&T (219) 291-8343| GEnie K.SUMNER [Joel] | | (Joel Sumner) |----------------------------------------------------| |USnail 1505 Sheffield Ct. | It is always darkest before the lights go out | | South Bend, IN 46614| | !--------------------------------------------------------------------------!
keith@Apple.COM (Keith Rollin) (07/02/88)
In article <152@thelink.UUCP> oliver@thelink.UUCP (Joel Sumner) writes: > >(Isn't the TaskMask $1FFF? That is the way I see it in TML but they may not >be setting a bit or two) > There are currently 16 defined bits in the TaskMask. There is probably a lot of confusion in this area, as APDA used to distribute versions of the ToolBox manual that defined on 13 or 14 bits, and developers (such as TML) got versions that defined even less of them. However, the final hardbound version of the Toolbox manual lists all of the bits that are currently defined. Keith Rollin amdahl\ Developer Technical Support pyramid!sun !apple!keith Apple Computer decwrl/ "You can do what you want to me, but leave my computer alone!"
jb211@UXF.CSO.UIUC.EDU (Jawaid Bazyar) (04/03/89)
As far as I know, no such project has ever been done for a ][ (pre-gs). The GS's windowing system works much as you have described yours. You might want to get the GS Toolbox Reference manual (vol.2 would be sufficient) and see just how Apple went about the problem. Obviously the Text Window routines will be much simpler (and faster) because they won't have to worry about color, half-byte pixels, etc. etc. Jawaid Bazyar jb10320@uxa.cso.uiuc.edu
GREYELF@WPI.BITNET (04/04/89)
People who have expressed an interest: ggray@wpi.wpi.com greyelf@wpi.wpi.com nakada@HUSC4.HARVARD.EDU Geva_Apple-Maniac_Patz@cup.portal.com Key: >> Geva > Paul Nakada The rest are my humble opinions. >> * 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. >mouse text is a must, though, for //e's ... Anybody know of a way to tell from software if the mouse text set is available? I think that trying to implement mousetext through graphics is a losing proposition, it even slows macs down too much. And to tell the truth I'm not overwhelmed by mousetext to begin with. I think we should start simple, little things like managing memory for where to store the hidden screen will pose enough problems without worrying about bells and whistles at this point. >> * 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... The MLI approach is very good, it does allow for a much greater flexibility of calls, with much less for the programmer to memorize. It is only mildly harder to code. This brings up a new question, how (where) should we set the entry point so routines will know where to find it? >> * 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) Making the mouse essential is a bad move, it is possible to tell from software whether or not a mouse is currently connected, not just whether a mouse card is present. As for mouse movement, the card will handle that itseelf, once interrupts are activated. Keypresses should be handled by the normal call to the Applesoft GET routine to avoid problems with buffer programs (Did I mention SOFTKB yet?). I could write a specific interrupt driver for the mouse to handle screen positioning if it would help. >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. It is possible (and fairly easy) to allow both mouse and keyboard drivers, like in BLU 2.28, and have them designed to work together. >> * 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.. I would say high-level calls. Like MLI, it is not convenient to try to pass variables from basic, rather it is easier to poke the appropriate values into memory and call a driver. This driver would be very easy to write (Okay, I voulenteer). >> * Are uppercase-only systems, 40-column systems, etc. going to be supported? Is it possible to test for these systems from software? If not, I wouldn't worry about it, it should be easy enough to add an option for upper case only. We could even create an installer program to set the options for you (as seen in Kermit-65). >> * 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.. Aux memory is not available on 64K apples, and they do run Prodos just fine. Relocatable is a good idea, but there must exist a way to find the entry point. We could install our own vector in page 3, in one of the open spaces, or we could claim two bytes from page 0, the one least likely to cause a problem is claiming a vector in page 3. I agree it should be binary. We could lay claim to two bytes in memory in Prodos or Basic.system, if we choose. >> 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 Pauls signiature deleted (the message is already long enough) I've got a question, are we deciding on Prodos compatibility only? I think that a 128K standard is a BAD idea, but there is some free memory in one of the banks of the language card that Prodos doesn't use (if memory serves). I'll have to look that up. Now we should decide on some standard calls. If you have any more long messages, like this one, why not send them to me dirctly, and I'll send them out to people that appear interested. If you want to get on the mailing list, send mail as well. -- 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.
crimmins@csli.STANFORD.EDU (Mark Crimmins) (04/04/89)
In article <8904031232.AA10738@uxf.cso.uiuc.edu> jb211@UXF.CSO.UIUC.EDU (Jawaid Bazyar) writes: > > As far as I know, no such project has ever been done for a ][ (pre-gs). >The GS's windowing system works much as you have described yours. You might >want to get the GS Toolbox Reference manual (vol.2 would be sufficient) >and see just how Apple went about the problem. Obviously the Text Window >routines will be much simpler (and faster) because they won't have to worry >about color, half-byte pixels, etc. etc. > >Jawaid Bazyar >jb10320@uxa.cso.uiuc.edu I'm not entirely sure what's being demanded of such a project, but Apple does have a set of routines for text-screen windows, with mouse support, scroll-bars and that sort of stuff. It's available from APDA, and it's called the Apple II Desktop Toolkit. Acctually, this package includes routines for a HighRes version of the same thing too. It works like the MLI stuff, I think, in case you're interested. Actually, if someone wants my unused copy (with extensive documentation, sources, etc.), I'd be willing to sell it for peanuts ($15). Mark (crimmins@csli.stanford.edu)
GREYELF@WPI.BITNET (04/04/89)
>I'm not entirely sure what's being demanded of such a project, but >Apple does have a set of routines for text-screen windows, with mouse >support, scroll-bars and that sort of stuff. It's available from >APDA, and it's called the Apple II Desktop Toolkit. Acctually, this >package includes routines for a HighRes version of the same thing too. >It works like the MLI stuff, I think, in case you're interested. >Actually, if someone wants my unused copy (with extensive >documentation, sources, etc.), I'd be willing to sell it for peanuts >($15). >Mark >(crimmins@csli.stanford.edu) Many commercial packages are available to do just that, but a freeware window set is necessary for developers of software in order to make our own software, and not have to license parts of it from someone else. -- 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.
blume@netmbx.UUCP (Heiko Blume) (04/06/89)
a german company here published a complete windowing sys for hires and double hires running under ucsd. it had everything, ie mousestuff etc. since they went out of business it might be possible to get the sources. i have this thing and its really good, text output in dhr is only 50% slower than on the text screen. i'll probably send a letter to the author.. -- Heiko Blume,Seekorso 29,D-1000 Berlin 22,VOICE=(+49 30)365 55 71,BBS=()365 75 01 TELEX=184174 intro d,FAX=()882 50 65|ARPA =crash!pnet01!pro-cess!blume@nosc.mil PSI =PSI%45300043109::netmbx:blume |BITNET=pro-cess.UUCP!blume@PSUVAX1 UUCP =blume@netmbx.UUCP |INET =blume@pro-cess.cts.com
greyelf@wpi.wpi.edu (Michael J Pender) (02/12/90)
To all the people that offered to help me find the nasty little memory-eating bug in my windows routines: Thanks anyways, I found it and killed the little bug already. One little ROR should have been an LSR. The semi-random interference from the Carry bit was causing the window routines to stray into the BASIC program space and trash the program. Now all I need to do is improve some of the memory management/protection software, and I should be able to release it... --- Michael J Pender Jr Box 1942 c/o W.P.I. W.O.S. is not dead. greyelf@wpi.bitnet 100 Institute Rd. ...its time to get started, greyelf@wpi.wpi.edu Worcester, Ma 01609 there is much to be done. If my next computer isn't a IIgs, it won't be an apple... Me.