Cocoa mail archive
Re: Notification when switching Spaces?
FROM : Eric Schlegel
DATE : Sun Nov 11 08:01:01 2007
On Nov 10, 2007, at 9:43 PM, The Server Surfer wrote:
> I honestly had no idea that Eric personally worked on Spaces himself.
I don't, actually, but I've worked with the engineers who do, and I've
worked on Spaces support in HIToolbox.framework.
I didn't take offense, but I do think your comment was unwarranted,
since unless you work at Apple you're probably not aware of what other
factors might go into a decision about what capabilities to provide.
> My response stemmed from the fact that it would seem to be fairly
> trivial for Apple to post a notification when a Spaces switch
> occurred, and also fairly typical for them to not do so, which is
> kind of annoying when someone like me wants to play with the new
> hotness too.
It would be trivial, but it's also not clear that it's something we
want to do. Notifications are API just as much as a function call or
method are; once we start posting a notification on Spaces switch, and
apps start depending on it, we have to continue to support that
notification forever. It's entirely possible that a future version of
Mac OS X will have some new UI for Spaces that will make it difficult
to continue to support a simple notification. We also generally prefer
to avoid providing avenues for apps to do arbitrary things in response
to UI effects such as Spaces or Expose, because as soon as one app
starts doing something on a Space switch, lots of other apps will too,
and the end result is that the Space switch stops being an extremely
smooth animation and starts getting jerky and ugly.
In general, we prefer to use data-driven approaches, where you tell us
in advance what you want to do when a space switch happens ("move this
window to the active space", for example), and we take care of doing
it for you. That allows us to keep the space switch animation fast and
fluid, and also allows us to change the space switch behavior in
future releases while still keeping compatibility with what your app
requested.
It's true that this does prevent some developers from doing
interesting and useful things. The bottom line, though, is that when
providing an API, including a notification, we have to think in the
long term - is this something we can support for the next ten years?
That makes us very conservative about providing new API.
What would your code do, if you had a notification of a Space switch?
-eric
DATE : Sun Nov 11 08:01:01 2007
On Nov 10, 2007, at 9:43 PM, The Server Surfer wrote:
> I honestly had no idea that Eric personally worked on Spaces himself.
I don't, actually, but I've worked with the engineers who do, and I've
worked on Spaces support in HIToolbox.framework.
I didn't take offense, but I do think your comment was unwarranted,
since unless you work at Apple you're probably not aware of what other
factors might go into a decision about what capabilities to provide.
> My response stemmed from the fact that it would seem to be fairly
> trivial for Apple to post a notification when a Spaces switch
> occurred, and also fairly typical for them to not do so, which is
> kind of annoying when someone like me wants to play with the new
> hotness too.
It would be trivial, but it's also not clear that it's something we
want to do. Notifications are API just as much as a function call or
method are; once we start posting a notification on Spaces switch, and
apps start depending on it, we have to continue to support that
notification forever. It's entirely possible that a future version of
Mac OS X will have some new UI for Spaces that will make it difficult
to continue to support a simple notification. We also generally prefer
to avoid providing avenues for apps to do arbitrary things in response
to UI effects such as Spaces or Expose, because as soon as one app
starts doing something on a Space switch, lots of other apps will too,
and the end result is that the Space switch stops being an extremely
smooth animation and starts getting jerky and ugly.
In general, we prefer to use data-driven approaches, where you tell us
in advance what you want to do when a space switch happens ("move this
window to the active space", for example), and we take care of doing
it for you. That allows us to keep the space switch animation fast and
fluid, and also allows us to change the space switch behavior in
future releases while still keeping compatibility with what your app
requested.
It's true that this does prevent some developers from doing
interesting and useful things. The bottom line, though, is that when
providing an API, including a notification, we have to think in the
long term - is this something we can support for the next ten years?
That makes us very conservative about providing new API.
What would your code do, if you had a notification of a Space switch?
-eric
