Multi screen printing (Quarter Life Crisis)

Multi screen printing¶

385 words

I just love my Powerbook's dual screen support. It's perfect for running TeX, for example – being able to comfortably view your TeX code and the preview at the same time and still having screen real estate for assorted other windows. It's even nicer to see that many applications deal reasonably graciously with the second screen – remembering window positions, moving your windows back to the main screen when you've removed the second screen &c. In part this seems to be thanks to Cocoa niceness.

One particular issue are dialogue boxes. The intuition about them is that they should appear on the same screen as the window they belong to (in case they do). Of course that problem can easily be resolved by using sheets and not having to worry about the whereabouts of your dialgue boxes at all. However, it seems, that the use of sheets isn't always appropriate or feasible and thus we still see quite a few dialogue boxes around. This is particularly true for print dialogues. Many applications still use them, although they'd be just fine with a sheet.

In case the application is Cocoa, the print dialogue will appear on the screen that contains the majority of the window – try this in Stickies or in TeXShop. For Carbon programming, things seem to be different. I have yet to see a Carbon application that is capable of placing the print dialogue on the second screen. A survey of SimpleText, WorldText, Acrobat Reader and even GraphicConverter showed that every single one of these applications will place the print dialogue on the main screen no matter where its associated window is.

I started wondering about this when I observed that the PDF Plugin would always put its print dialogue on the main screen even though Camino would put its own print dialogues on the second screen. In a brief exchange with the programmer, Manfred Schubert, I learned that plugins are Carbon and that he couldn't find a way to manipulate the screen the dialogue appears on in Carbon.

Thus, I have the suspicion that this less than perfect behaviour of Carbon apps may not be programmer laziness unawareness or lazyness but rather a restriction in Carbon itself. Any hints or bits of hidden documentation on this? Or is it a bug?

July 2, 2003, 20:16

Comments

Comment by Ned Holbrook: ¶

It’s not a restriction of Carbon (the Mac has been quite comfortable with multiple monitors since 1987). I believe the problem is partly with the HIG, which has a section on the correct screen placement for document windows here, but no corresponding information for dialog boxes. It would be nice to have some guidelines for this type of thing.

July 3, 2003, 0:40

Comment by ssp: ¶

I guess I am trying to say that Carbon is less comfortable with multiple monitors than the Mac used to be. I seemed to remember that old-style dialogue resources allow to specify that dialogues should appear on their parent window’s screen. I quick dig around the ancient Inside Macintosh shows that I wasn’t all wrong about this

alertPositionParentWindowScreen - Position the alert or dialog box on the screen containing the frontmost window

July 3, 2003, 3:41

Comment by Ned Holbrook: ¶

The trick is that dialog boxes are simply windows, so in Carbon one simply calls RepositionWindow() with the appropriate positioning method. Plus the old dialog routines still work, so no worries.

July 3, 2003, 3:53

Comment by ssp: ¶

That sounds like it could do the trick.

The question I still see open is how this could be applied to print dialogues. Looking through the Carbon printing documentation, I got the impression, that you don’t get your hands on the print dialogue’s WindowRef, which you’ll need to use RepositionWindow(). Any idea?

Let me just remark that I hardly know Carbon at all and my knowledge of it is very incomplete. The impression I got so far is that the Carbon print manager functions seem to do most of the work for you as far as putting things on screen is concerned and that you can’t interfere much. - Thus I had assumed they would place the dialogue window appropriately as Cocoa does.

July 3, 2003, 14:34

Comment by Ned Holbrook: ¶

As I suggested in my first post, the question is, What is correct dialog placement? Both Carbon and Cocoa are capable of placing a dialog on any screen but the implementers of the standard print dialog for each API set chose a different screen on which to place the dialog. It’s not due to lack of technology but lack of clear HI guidelines.

It’s also possible that the Carbon placement of the print dialog is correct, since the print command is invoked via a menu item in the File menu. Maybe it’s even as complex as whether the command is invoked from the menu or via a keyboard shortcut, I don’t know. The best way to resolve the issue is to file a bug (or two) asking for better guidelines and better application of those guidelines. That way we all win.

July 3, 2003, 19:13

Comment by ssp: ¶

Frankly, I think the rules sketched for those dialogues in the traditional Inside Macintosh documentation are just right: If the dialogue belongs to a window, it should appear on the same screen as that window. Not only does this sound reasonable, but it’s the way it works best.

The reason why I discovered the odd behaviour in the first place was that I chose ‘Print’ from PDF Plugin’s menu and nothing happened… seemingly, because the dialogue box had appeared on the other screen.

Saying that there is no specification sounds a bit like a cheap excuse to me. Also, Apple made (sorry, ‘crafted’) both Carbon and Cocoa, so making the behaviour consistent across both of them is the least we can expect. Of course, throwing in a few guidelines would be nice as well.

I think I’ll just make the trip to bug reporter and see how things work out.

July 3, 2003, 20:16

Comment by Ned Holbrook: ¶

In the example you give, presenting the dialog on the same screen seems eminently reasonable. But should the dialog follow the document or should it follow the command if one uses the print item from the menu bar? I think it’s a fair question and one worth clarifying.

The only “cheap” excuse I have to offer is that time is the most precious of resources. How else can one explain the many other discrepancies between Carbon and Cocoa? Or why bugs exist at all? Although it’s all just software and therefore capable of being fixed, there are still people at the other end pushing those bits around and sometimes there just isn’t enough time. Realize that people care about making things better but everything can’t be perfect all at once.

July 3, 2003, 20:56

Quarter Life Crisis

The world according to Sven-S. Porst