ranson@crcge1.UUCP (05/06/87)
Apple has issued several technotes about machine independence. TN#117
was particularly useful. But I think that some issues have not been
discussed yet:
- How does one lay out windows on the screen(s)? WIND templates
do not help, since they are screen-size dependent. You can get
screen geometrics from QuickDraw, but how does one deal with
multiple screens making a non-rectangular desktop? Another problem
is that one creates a window giving 'interior' dimensions. Is it
possible to determine the size of the window drag bar (which might
change if the system font is changed in certain scripts)?
- How does one use QuickDraw globals if you are not the one that
initialised it? (eg. from a DA). I have found at least 2 popular
way to set up these globals, at 0(a5) and at -4(a5). This makes
some DAs fail in the Finder.
Another (unrelated) question: Does the new TextEdit support tabs?
The APDA draft of IMv5 does not say anything about it. Since TextEdit
is most useful in non-word processing applications like programming
langages, I think tabs are much more important than multiple styles.
Daniel Ranson
Centre National d'Etudes des Telecommunications
LANNION, FRANCE
...!seismo!mcvax!inria!{crcge1,cnetlu}!ransonmrh@Shasta.STANFORD.EDU (Marc Hannah) (05/07/87)
In article <2227@crcge1.UUCP>, ranson@crcge1.UUCP writes: > Another (unrelated) question: Does the new TextEdit support tabs? > Daniel Ranson Unfortunately TextEdit doesn't support tabs in the new release. Too bad. I was wondering about another problem...The latest issue of MacTutor has an article by Dan Weston about handling the new screens. One thing I saw was that he passed the screenbits.bounds rectangle to his call to dragwindow. I assume that this effectively PREVENTS a window from being dragged from screen to screen in a multiple screen environment. I believe that the screenbits.bounds rectangle corresponds to the size of the 'default' screen. Do the WindowManager calls handle this properly or will this kind of code cripple an application in a multiple screen environment? David Gelphman daveg%slacvm.bitnet@forsythe.stanford.edu
dgold@apple.UUCP (David Goldsmith) (05/08/87)
In article <1583@Shasta.STANFORD.EDU> mrh@Shasta.STANFORD.EDU (Marc Hannah) writes: > I was wondering about another problem...The latest issue of MacTutor >has an article by Dan Weston about handling the new screens. One thing >I saw was that he passed the screenbits.bounds rectangle to his call to >dragwindow. I assume that this effectively PREVENTS a window from being >dragged from screen to screen in a multiple screen environment. I believe >that the screenbits.bounds rectangle corresponds to the size of the >'default' screen. Do the WindowManager calls handle this properly or will >this kind of code cripple an application in a multiple screen environment? The window manager on the Mac II uses a heuristic to decide whether you meant "this specific rectangle" or "the screen" for your drag bounds. I believe that if the drag bounds are the same as those suggested in Inside Mac (inset four pixels from the edges of the screen and the menu bar) it assumes you meant "the desktop" and acts accordingly. -- David Goldsmith Apple Computer, Inc. MacApp Group AppleLink: GOLDSMITH1 UUCP: {nsc,dual,sun,voder,ucbvax!mtxinu}!apple!dgold CSNET: dgold@apple.CSNET, dgold%apple@CSNET-RELAY BIX: dgoldsmith
jww@sdcsvax.UCSD.EDU (Joel West) (05/08/87)
The whole idea of a multiple-screen environment as a single
port (GetWMgrPort) is pretty sick if you ask me. The toplogical
combinations are, unfortunately, limitless.
Each screen should have been a separate port, but I guess it's
too late now.
Why prevent the guy from dragging it off in the first place? I
would just have an option to get it back from the window menu--
when the window is activated and it's not within the port, nudge
it in till it is.
--
Joel West
{ucbvax,ihnp4}!sdcsvax!jww (ihnp4!gould9!joel if I ever fix news)
jww@sdcsvax.ucsd.edu if you must