• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Tell Blocks Considered Harmful (was Re: open for access)
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Tell Blocks Considered Harmful (was Re: open for access)


  • Subject: Re: Tell Blocks Considered Harmful (was Re: open for access)
  • From: Philip Aker <email@hidden>
  • Date: Tue, 16 Dec 2008 06:54:32 -0800

On 2008-12-16, at 06:08:39, Luther Fuller wrote:

An interesting thread. I was thinking of commenting, but first I wanted to verify that I knew the meaning of 'modal'. (And I do.) So, I looked it up. And I found lots of documents that used phrases like 'document modal' and 'application modal' and such.

I am now reduced to confusion and total ignorance. What is 'modal'?

In Carbon, it's possible to request kWindowModalityNone, kWindowModalitySystemModal, kWindowModalityAppModal, or kWindowModalityWindowModal.


The modality of a window refers to the constraint of events bound for its "container" or "parent". I will describe the Carbon notion.

When a window is 'window modal' then it's form might be that of a sheet window (like a print sheet dropping down from the title bar). Most classes of events are barred from its containing window because you can't alter it's contents. However you can move the parent around on screen because that action doesn't alter its content. Keyboard events like typing are directed to the sheet because its purpose is to supply parameters to the print job. You may interact in other ways with the application though and even create new windows and type into them. When you click in the window with the sheet, then the typing again becomes constrained to the sheet.

When a window is app modal, then the app can't do much except get hidden and shown. IOW, most events sent to the 'container' or 'parent' (i.e. the hosting application) of an app modal window get ignored except for those which the modal window can handle -- normally typing, clicks, and drags. The user will probably be constrained to using only a subset of items in the 'Edit' menu.

When a window is system modal, like a login window, then the actions available are slim. The intent is that the user _must_ deal with the choices presented before proceeding and not allowed to do much else that would affect the system or even interact with another application.

When a window has no modality specified, then it usually takes the form of a floating window (like a tool palette) and the user is able to interact with all applications and menus. These types of windows are also specified as being in the 'utility' window class, and may be optionally hidden when their parent application is not frontmost.


Philip Aker echo email@hidden@nl | tr a-z@. p-za-o.@

Democracy: Two wolves and a sheep voting on lunch.

_______________________________________________
Do not post admin requests to the list. They will be ignored.
AppleScript-Users mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:
Archives: http://lists.apple.com/archives/applescript-users

This email sent to email@hidden
  • Follow-Ups:
    • Full Frontal Dialogs
      • From: Luther Fuller <email@hidden>
References: 
 >Re: open for access (From: "Nigel Garvey" <email@hidden>)
 >Tell Blocks Considered Harmful (was Re: open for access) (From: Chris Page <email@hidden>)
 >Re: Tell Blocks Considered Harmful (was Re: open for access) (From: Luther Fuller <email@hidden>)

  • Prev by Date: Re: Tell Blocks Considered Harmful (was Re: open for access)
  • Next by Date: Re: Tell Blocks Considered Harmful (was Re: open for access)
  • Previous by thread: Re: Tell Blocks Considered Harmful (was Re: open for access)
  • Next by thread: Full Frontal Dialogs
  • Index(es):
    • Date
    • Thread