rj0z+@andrew.cmu.edu (Robert George Johnston, Jr.) (09/19/88)
Centering alert and dialog boxes is relative straight forward
on a single screen system, but what do you do when there are two or
more screens connected to the system? I tried to find some mention
of how this should be handled in IM, but did not.
There are several ways this could be done: (1) Center over
ScreenBits.Bounds, which would probably put the dialog between screens.
(2) Always center on the main screen (the one with the menu bar). (3)
Try to locate the screen with the frontmost window, and center on it.
(4) Center the dialog on the screen that the cursor is currently
pointing on.
The problem is that I only have one screen, and want my programs
to work correctly on bigger systems. I have already implemented the
fourth (4) method. Anyone think that it should be done differently or
have any other methods?
Rob Johnston.nopuklic@ndsuvax.UUCP (Blayne Puklich) (09/20/88)
In article <UXB0Pey00Uw9AdGUhj@andrew.cmu.edu> rj0z+@andrew.cmu.edu (Robert George Johnston, Jr.) writes: > > Centering alert and dialog boxes is relative straight forward >on a single screen system, but what do you do when there are two or >more screens connected to the system? I tried to find some mention >of how this should be handled in IM, but did not. > There are several ways this could be done: (1) Center over >ScreenBits.Bounds, which would probably put the dialog between screens. >(2) Always center on the main screen (the one with the menu bar). (3) >Try to locate the screen with the frontmost window, and center on it. >(4) Center the dialog on the screen that the cursor is currently >pointing on. > The problem is that I only have one screen, and want my programs >to work correctly on bigger systems. I have already implemented the >fourth (4) method. Anyone think that it should be done differently or >have any other methods? > > Rob Johnston. IM volume V says that one should use the global GrayRgn (on page 121) for pinning and such. However, I think you're right that it should be centered on the screen where the cursor is. That would sure help the user out somewhat since less mouse travel would be required. On the other hand, it might be more appropriate to center the dialog on the screen where the menu bar is, since the user needs to use the menu bar to make a dialog appear generally. That would mean the cursor would be on the screen with the menu bar, and would alleviate your problem of which screen to center on. This would be meaningless, of course, if your application brought dialogs up for button/icon hits in any window on another screen. What may be the actual solution might depend on where the dialog gets invoked from. If it is a result of a menu command, I'd think that it would be more appropriate to center it where the menu bar was. If it was the result of a button hit, center it where the button is. Of course this is my own strange and sometimes wrong inter- pretation of the problem, but I think it makes sense. Hope this helps fuel discussion, because this may become a problem for some of us in the future. ||+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++|| || Blayne Puklich nopuklic@plains.NoDak.edu || || NDSU Student ACM NU087763@NDSUVM1.bitnet || || Chairperson North Dakota State University, Fargo, ND || || || || "Everyone should have a Corvette, I think." || || NOTE: If nopuklic@plains.NoDak.edu bounces, revert to || || nopuklic@ndsuvax.BITNET. || ||-------------------------------------------------------------------------||
bob@eecs.nwu.edu (Bob Hablutzel) (09/20/88)
> Centering alert and dialog boxes is relative straight forward > on a single screen system, but what do you do when there are two or > more screens connected to the system? I tried to find some mention > of how this should be handled in IM, but did not. > There are several ways this could be done: (1) Center over > ScreenBits.Bounds, which would probably put the dialog between screens. > (2) Always center on the main screen (the one with the menu bar). (3) > Try to locate the screen with the frontmost window, and center on it. > (4) Center the dialog on the screen that the cursor is currently > pointing on. > The problem is that I only have one screen, and want my programs > to work correctly on bigger systems. I have already implemented the > fourth (4) method. Anyone think that it should be done differently or > have any other methods? To my mind, (1) is the best. This does _not_ center the dialog between screens. I've got two screens on my Mac, and I just wrote the following code to test my theory: Program Test; Uses MemTypes, QuickDraw; Var OurPort : GrafPort; Begin InitGraf( @thePort ); OpenPort( @OurPort ); EraseRect( OurPort.PortRect.Bounds ); End. This code erases _only_ the screen with the menu bar. (This is true even if that screen is not the startup screen). Therefore centering on screenBits.Bounds (which is the same as OurPort.PortRect.Bounds in this example) will give the desired results. BTW - this seems to be what most people are doing. Whether this is some grand scheme I am unaware of, or happy accident, I cannot say. I suspect happy accidents, however. > Rob Johnston. > ---------- Bob Hablutzel BOB@NUACC.ACNS.NWU.EDU Disclaimer: Programming is an empirical science.
singer@endor.harvard.edu (Rich Siegel) (09/20/88)
In article <UXB0Pey00Uw9AdGUhj@andrew.cmu.edu> rj0z+@andrew.cmu.edu (Robert George Johnston, Jr.) writes:
The cheap and easy solution is to center over ScreenBits.bounds - this
correspontds to the main screen, and will not overlap multiple screans.
R.
Rich Siegel
Staff Software Developer
THINK Technologies Division, Symantec Corp.
Internet: singer@endor.harvard.edu
UUCP: ..harvard!endor!singer
Phone: (617) 275-4800 x305
Any opinions stated in this article do not necessarily reflect the views
or policies of Symantec Corporation or its employees.dorner@uxc.cso.uiuc.edu (Steve Dorner) (09/20/88)
I would suggest centering dialogs on the screen that currently contains
the frontmost window. If there are now windows, then use the screen
with the menu bar. This should get your dialog box at the current center
of attention; the mouse cursor may not be on the right screen at all.
--
Steve Dorner, U of Illinois Computing Services Office
Internet: dorner@garcon.cso.uiuc.edu UUCP: {convex,uunet}!uiucuxc!dorner
IfUMust: (217) 244-1765john@trigraph.UUCP (John Chew) (09/20/88)
In article <UXB0Pey00Uw9AdGUhj@andrew.cmu.edu> rj0z+@andrew.cmu.edu (Robert George Johnston, Jr.) writes: > Centering alert and dialog boxes is relative straight forward >on a single screen system, but what do you do when there are two or >more screens connected to the system? I tried to find some mention >of how this should be handled in IM, but did not. I've seen this mentioned before here, and your suggestion (centred on the screen containing the mouse) seems the most reasonable, but since you ask for alternatives, how about this for brain-damaged? The first time your application is run, obtain the size of the main (menu bar) screen and store it in a configuration file. Thereafter, refer to that file for screen size information, even if the physical monitor configuration changes. Who would do such a thing? I don't want to name names, but I must say I get tired of having to re-build configuration files for a well- known MICROcomputer SOFTware house's WORD-processing package... (I apologize for the reference to the above-unmentioned software and fervently hope that this does not trigger another futile discussion of its merits and faults....) John Chew -- john j. chew, iii poslfit@utorgpu.bitnet trigraph, inc. poslfit@gpu.utcs.toronto.edu toronto, canada {uunet!mnetor!utzoo,utgpu,utcsri}!trigraph!john [it is my opinion that these are solely my opinions.]
wilson@csli.STANFORD.EDU (Nathan Wilson) (09/21/88)
In article <10050018@eecs.nwu.edu> bob@eecs.nwu.edu (Bob Hablutzel) writes: >> There are several ways ['centering' a window on multlple screen >> Mac] could be done: (1) Center over >> ScreenBits.Bounds, which would probably put the dialog between screens. > To my mind, (1) is the best. This does _not_ center the dialog between >screens. >BTW - this seems to be what most people are doing. Whether this is some >grand scheme I am unaware of, or happy accident, I cannot say. I suspect >happy accidents, however. Actually there is at least a bit of a 'grand scheme' around this method. screenBits.bounds is set to boundary of the window with the menu bar, but some traps have been adjusted in IM-V so they will continue to 'do the right thing' even when passed this value. E.g. MoveWindow, and DragGrayRgn look to see if their limits are close to the values of screenBits.bounds and if they are will substitute the appropriate values from GrayRgn's bounding box. This is definitely a hack but it seems like a reasonable way to maintain the semantics of screenBits.bounds. Nathan Wilson
erics@eleazar.dartmouth.edu (Eric Schlegel) (09/21/88)
In article <UXB0Pey00Uw9AdGUhj@andrew.cmu.edu> rj0z+@andrew.cmu.edu (Robert George Johnston, Jr.) writes: > > Centering alert and dialog boxes is relative straight forward >on a single screen system, but what do you do when there are two or >more screens connected to the system? I tried to find some mention >of how this should be handled in IM, but did not. > There are several ways this could be done: (1) Center over >ScreenBits.Bounds, which would probably put the dialog between screens. >(2) Always center on the main screen (the one with the menu bar). (3) >Try to locate the screen with the frontmost window, and center on it. >(4) Center the dialog on the screen that the cursor is currently >pointing on. I would use either 2 or 4; probably 2, since it seems to me that stuff like dialogs should come up on the main screen; but I don't have two screens, and if the cursor were on another screen perhaps this would be inconvenient. Just a personal opinion...what do others think? ------ Eric Schlegel | DISCLAIMER: I'm just a poor college student, eric.schlegel@dartmouth.edu | which means I'm not responsible for what I | say and I can't pay you if you sue me anyway.
borton@uva.UUCP (Chris Borton) (09/21/88)
In article <UXB0Pey00Uw9AdGUhj@andrew.cmu.edu> rj0z+@andrew.cmu.edu (Robert George Johnston, Jr.) writes: > There are several ways this could be done: (1) Center over >ScreenBits.Bounds, which would probably put the dialog between screens. >(2) Always center on the main screen (the one with the menu bar). (3) >... >(4) Center the dialog on the screen that the cursor is currently >pointing on. We discussed this at Paragon in the development of Nisus and concluded on (4). Several people with large setups, such as 3 x 19" screens, found it very pleasant once implemented. I agree, however, that it _may_ be more correct to center over the frontmost window. Anyone have _experience_ with both? (I don't know of any other programs right now that do these things!) -cbb -- Chris Borton borton%uva@mcvax.{nl,bitnet,uucp} Rotary Scholar, University of Amsterdam CS "MesS-DOS programmers did it yesterday. Mac programmers do it today. OS/2 programmers claim they will do it tomorrow. [I don't believe them :-)]"
emb1354@uxf.cso.uiuc.edu (09/21/88)
Count one more vote for centering over ScreenBits.bounds. It seems that the system maintains this in accordance with the main GDevice on the MacII (that is the one with the menu bar). Centering on that device is presumably what the user has asked for by selecting that screen as the main device in the first place, so why put it elsewhere?
mikem@uhccux.uhcc.hawaii.edu (Mike Morton) (09/23/88)
In article <537@uva.UUCP> borton@uva.UUCP (Chris Borton) writes that at
Paragon, they concluded that it was best to center a dialog over the
screen that the cursor is currently on.
Especially for dialogs invoked with the keyboard (including command-key
equivalents, but also alerts in response to Clear, Backspace, etc.), this
makes the dialog location seem non-deterministic to a user who hasn't
yet psyched out your scheme. ("Look, Irma, now the dang thing's over
in THAT one!"...)
Anyone at Apple care to tell us if the High Priests of the User Interface
have blessed a solution to this problem?
-- Mike Morton // P.O. Box 11378, Honolulu, HI 96828, (808) 456-8455 HST
Internet: msm@ceta.ics.hawaii.edu
(anagrams): Mr. Machine Tool; Ethical Mormon; Chosen Immortal; etc.oster@dewey.soe.berkeley.edu (David Phillip Oster) (09/23/88)
I've reached the conclusion that you should never use modal dialogs. If
you always use modeless dialogs, and you store in a config file where the
user left them, and when the user runs the program again, you put them
back where they were (if that spot still exists, people do remove
video cards occasionally.), then the user can do what he wants.
If you must use modeless dialogs, then they probably refer to some
document and should come up "centered" on that document's window. (they
might be centered left and right, but not top and bottom.)
As a last resort, center with respect to the screen with the menu bar.
i.e. screenBits.bounds.
Conclusion: it really is better to let the user put the dialogs where he
wants them.
--- David Phillip Oster --When you asked me to live in sin with you
Arpa: oster@dewey.soe.berkeley.edu --I didn't know you meant sloth.
Uucp: {uwvax,decvax,ihnp4}!ucbvax!oster%dewey.soe.berkeley.edulsr@Apple.COM (Larry Rosenstein) (09/23/88)
In article <2411@uhccux.uhcc.hawaii.edu> mikem@uhccux.UUCP (Mike Morton) writes: > >Especially for dialogs invoked with the keyboard (including command-key >equivalents, but also alerts in response to Clear, Backspace, etc.), this >makes the dialog location seem non-deterministic to a user who hasn't >yet psyched out your scheme. ("Look, Irma, now the dang thing's over The short answer to this issue is to do some user testing. Gut feelings are often not correct. Nevertheless, my gut feeling would be that centering it on the window containing the cursor would be confusing until it was explained to the user. I seem to recall a recommendation that alerts appear in a consistent place all the time. (Doesn't Microsoft do this?) I think it would be acceptable to center on the main screen, because that is likely to be a focus of attention since the menu bar is there. Even if the dialog appears as a result of a keyboard command, the user probably will tend to have the main screen right in front of him/herself. This also has the advantage of being easy to do, and consistent with a lot of other programs (since it is easy to do, most programmers are likely to do this). Centering it on the screen containing the active window is a good idea. One problem is that you may end up obscuring the very information that is needed. (The user may have moved the window over there, explicitly to get away from new windows popping up on the main screen.) Conversely, FullWrite places its Spell Checking dialog on a different screen from the document being checked, so as not to obscure anything important. (As someone pointed out, however, if that screen is off, the user is in trouble.) One suggestion that hasn't been mentioned is to let the user choose the position. I tried a demo of a program called JonathanDraw that draw a black rectangle the size of the dialog, and waited for you to click to position it. I found this to be annoying since it required extra work on my part. Fortunately, this was an option that you could customize. Larry Rosenstein, Object Specialist Apple Computer, Inc. 20525 Mariani Ave, MS 46-B Cupertino, CA 95014 AppleLink:Rosenstein1 domain:lsr@Apple.COM UUCP:{sun,voder,nsc,decwrl}!apple!lsr
dorner@uxc.cso.uiuc.edu (Steve Dorner) (09/23/88)
In article <17588@apple.Apple.COM> lsr@apple.com.UUCP (Larry Rosenstein) writes: ... >I think it would be acceptable to center on the main screen, because that is >likely to be a focus of attention since the menu bar is there. Even if >the dialog appears as a result of a keyboard command, the user probably will >tend to have the main screen right in front of him/herself. Having been annoyed by this behavior recently, I'd like to interject. For interference reasons, my SE and my large-screen monitor have to be kept about a foot apart. It turns out that this arrangement is very happy; it gives me room for notes, pencils, etc between the screens. Anyway, I use Acta on the SE screen, so it doesn't get in the way of other stuff. But woe is me if I want to change a typestyle; oooover to the other screen I go, where the dialog box appears. Then allllll the way back to Acta. It's annoying. But maybe my setup is unique; I sure ain't using the same ``multi-screen'' management as on a Mac II. -- Steve Dorner, U of Illinois Computing Services Office Internet: dorner@garcon.cso.uiuc.edu UUCP: {convex,uunet}!uiucuxc!dorner IfUMust: (217) 244-1765
casseres@Apple.COM (David Casseres) (09/24/88)
In article <26201@ucbvax.BERKELEY.EDU> oster@dewey.soe.berkeley.edu.UUCP (David Phillip Oster) writes: >If you must use modeless dialogs, then they probably refer to some >document and should come up "centered" on that document's window. (they >might be centered left and right, but not top and bottom.) But what if the document's window is partly offscreen? That may sound weird but with some applications this could happen. >As a last resort, center with respect to the screen with the menu bar. >i.e. screenBits.bounds. I think this should be the "normal" way to do it, even with modeless dialogs. It seems better to me if the dialog always comes up in the same place. (Disclaimer: Apple is always telling me "that's just your opinion.") >Conclusion: it really is better to let the user put the dialogs where he >wants them. Only if the user explicitly tells you where he wants them! David Casseres
tim@hoptoad.uucp (Tim Maroney) (09/26/88)
So if the drag rectangle is near screenBits.bounds, it is interpreted to mean "over all screens". It sounds like a nice hack, but there's a problem with sub-windows, isn't there? There are lots of reasons to have a window that is constrained to always be in front of another window (help, footnotes, post-its, etc.). But suppose you zoom the main window, then drag the sub- window. Suddenly the sub-window isn't bound to its window any more. Is there some equally clever hack in the system to catch this, or is there are a work-around, or are sub-window software developers just screwed? -- Tim Maroney, Consultant, Eclectic Software, sun!hoptoad!tim "The Diabolonian position is new to the London playgoer of today, but not to lovers of serious literature. From Prometheus to the Wagnerian Siegfried, some enemy of the gods, unterrified champion of those oppressed by them, has always towered among the heroes of the loftiest poetry. Our newest idol, the Superman, celebrating the death of godhead, may be younger than the hills; but he is as old as the shepherds." - Shaw, "On Diabolonian Ethics"
chrisj@ut-emx.UUCP (Chris Johnson) (09/27/88)
I have my own idea for how dialogs should be centered and since I haven't seen anything quite like it suggested, here goes: Center the dialog on the current position of the mouse pointer - almost. To make this method work, it'll be necessary to check the would-be position for the window against GrayRgn to make certain that the entire window will be visible on the screen and to adjust it accordingly. It would also be necessary to have dialogs that appear on-top of existing modal dialogs center themselves relative to the previous modal dialog to avoid "dialog drift" - in other words if a series of modal dialogs which had their OK buttons in (for example) the lower left corner of the dialog appeared one after another then centering them on the mouse coordinates would generally be the same as centering them on the coordinates of those buttons in the lower left corner and the resulting series of dialogs would drift down and to the left until the progression ran into the edge of the screen. It seems to me that this approach will generally be most convenient for the user. It doesn't matter what screen the dialog shows up on, since it will always show up in the place most convenient for the user to interact with it - the place where the mouse is. If the dialog appears in response to a menu selection (and the selection is made with the mouse) the dialog will appear at the top of the screen, just beneath the menu bar - the user will scarcely have to move the mouse to begin interacting with the dialog. If the dialog appears in response to an errant click or an invalid edit of some sort in some obscure corner of a distant screen, the dialog will still be in the most convenient possible place for the user - both at what is most likely to be the center of his attention, and at the place he can most readily get to with the mouse. Anyway, it makes sense to me. ----Chris Johnson
mfm@bti.UUCP (Merle F. McClelland) (09/28/88)
> It seems to me that this approach will generally be most convenient for the > user. It doesn't matter what screen the dialog shows up on, since it will > always show up in the place most convenient for the user to interact with > it - the place where the mouse is. If the dialog appears in response to a > menu selection (and the selection is made with the mouse) the dialog will > There is an INIT available in the Public Domain called "Front&Center" that does just this. Its by Pete Helme (eelpout software systems). -- | "Everything you | All opinions expressed are mine, all mine! | | know | So, don't go blaming BTi for my incoherent | | is wrong!" | ramblings... | | - FST | ncr-sd!bti!mfm |