WWDC2000 Session 148

Transcript

Kind: captions Language: en good morning all right Wow the home stretch the last day well as you can see again I was you saying this with mac OS 10 carbon the theme of this week we are so excited about how much progress we've made and how much progress we've made helping you get on the platform as fast as possible this session about carving enhancements to the high level toolbox is going to go further into depth about ways that your process of carbonizing your application is affected it's really good stuff to know so without delay i'm just going to bring up piquant here from the high level toolbox team please welcome Pete so I hope you had a chance to check out the carbon enhancements one session this is going to be a session very similar in theme we've been doing so much work on not only on aqua but on the toolbox in general that we had to do two sessions to fit it all in this session will have basically the same structure as the last session we're going to do a big section on architectural changes which are things that you pretty much have to do in order to come up on carbon and the ones that we'll talk about in this session are the fact that you can no longer draw directly the window manager port there's a small change the way control indicator action procedures are called there are some changes you will need to make to control and window definitions not anything too radical there is a change in the way you need to instantiate custom control window and other definitions and then of course there are some new dialog item lists accessors that you'll want to use because of dialogue opacity then we'll move on to the stuff that you don't have to do but the stuff that you will probably want to do as soon as you hear about it there's unicode support in the toolbox everywhere we've added drag-and-drop support for controlled and then we've added the usual collection of new control manager api's and then finally we'll talk a little bit about carbon in the toolbox not too much because there were two hold sessions on carbon events sessions 121 and 122 and those are already passed but I wanted to mention them just to emphasize the fact that if you get a chance to pull down webcast or videotape you definitely should prioritize 121 and 122 because carbon events are really important so let's talk about the window manager port Mac os10 is as you've heard a pre-emptive operating system and the screen buffer is basically a huge global shared resource and for performance reasons we have not yet solved the problem of letting you draw to it in the general case it would be a mess if we didn't control the access to it and controlling the access to it is actually more difficult than it sounds so we're still working on that issue now you may find through experimentation that you actually can kind of sort of draw to what seems to be the window manager port under DP for and hopefully that will only happen by accident because you don't definitely don't want to have code that expects to draw to the window manager port on purpose because soon after DP for we're going to make be making some changes that will make it basically impossible but the news isn't all bad we have provided a few replacement services that cover the common cases that most people needed to draw to the window manager port for the first of those cases is custom window dragging instead of rolling your own window dragging code we really need you to use the drag window system call now it's basically not only do you get live dragging which is a nice wizzy effect for users but if it's the excuse me drag window is now sufficiently customizable that you really shouldn't have any problem figuring out how to get the constraining and gridding and the other custom behavior that that you need and and this is part of the whole carbon events thing basically we send you carbon event during window dragging and you can decide what to do with them we send you such things as the rectangle the window would be in if if you were to not change it and then you have the choice of changing it or not so that you get the little greeting effect that you need I believe in the carbon event session there was a demo where we showed sort of docking behavior during window dragging where windows were docked against the edge of the screen and docked against each other and I guess I should also point out that drag window now supports layering in the sense that the outline that's dragged around the screw scuze me be a window that's dragged around the screen is uh is cliff according to the windows that are actually in front of it so you don't have to override drag window just to make it look decent the next case is grow window basically if you use the system's grow windows service that enables us to provide live growing which is basically the window content redraw as the user grows the window so if user become if the window becomes bigger the image in the window can be drawn by the system more or less interactively and of course there are the usual ways to customize window growing again locally based on carbon event but there's one there's one method you can use by overriding a window definition method message and that is of course the get grow image region message and the reason we mention this even though it's not a carbon event sort of facility is that it's basically your only option if you need to do this for carbon with 102 or 103 104 I guess I should say but the more preferred methods are to override the corresponding carbon event and then of course the best method would be to override the window size change carbon event and the difference there is that one of these msgs hands you a region and one of them hands you a rectangle so if you really really really need to change the visual appearance of the growing process then you're probably going to get stuck overriding the region version but it's much better if you stick with the rectangle version because I believe if you override the region version that that prevents us from doing the live growing so some developers were rolling their own dragging and and it would draw into the window manager port and the primary reason they were rolling their own dragging was that the drag manager wasn't versatile enough so what we did was we added a funk excuse me an API to change an arbitrary drag reference so that you can turn off the zoom back animation for an unsuccessful drag and of course this API changed drag behaviors can expand in the future for us to add more flags that you can turn on or off on a drag by drag basis and basically the way you would use this facility is you would create a drag reference just like you would for any other interaction with the drag manager and turn off it it's zoom back animation and then either add no flavors and maintain all the state within your application or add some flavors that tell you what to do and mark them all sender only flavors so that you don't get windows in other applications highlighting as if they're going to accept the drag and so the way we sort of the usage scenario that we sort of entertained was people who need to drag out of a window some object out of a window and then let the user more or less drop it in the middle of nowhere and have something appear there where you where there used to be nothing so the last scenario we have a good explanation for is is people who need to sample the pixels on the screen and of course you can still sample pixels right out of your own windows because we have a per window buffer that you see you will you'll be sampling out of the problem case is sampling pixels that are outside any of your windows in order to in order to work well with the preemptive window manager that underlies the carbon window manager we have a very window centric outlook and we're working on ways to overcome that but basically let me thanks here ah basically we what we think is going to happen is that there will probably never be a platform-independent way to peek at pixels outside of your windows and I guess we'll talk a little bit more about that on the next slide but once again we have the caveat of there are things that work in vp for that you can discover on your own and in this case you can create a port and then sort of look at it to take pics Matt handle and sample pixels out of it that way and that's one of those things that very soon after DP for we're going to change that it doesn't work anymore and then the final thing to keep in mind of course is rather than grabbing video ram directly you should definitely use copy bits for a number of reasons so the plain old drawing case is the most general case and of course there's not a lot of sort of semantic opportunity for us to provide other services when you when you consider the problem in such a general way sometimes developers need to draw to directly to the screen or sometimes developers draw directly to the screen just because they want to take over the whole screen and of course you can still do that but you're going to do a little work ahead of time in order to make that happen basic idea is to create a window that covers the whole screen and you can do that your own on your own by hiding the menu bar or you can do that by passing quicktime or games boxes to do do it for you and I sort of tend towards asking quicktime or game sprockets to take care of it for you because they also know about things like hiding the control strip and I imagine that eventually they'll be wired up to hide the doc as well so you don't have to worry about all those extra details and then of course the obvious alternative is to start thinking about ways to provide the same functionality that your application was providing by drawing directly on the screen in some other way and we realized that probably involves thinking about a little bit of a redesign but there's not really an alternative we have to present today to solve that problem and as I said there may eventually be some kind of platform dependent way to do this right now there's not but we expect there probably won't be a platform-independent way we're still looking at this problem but we're not able to commit to anything right now so control indicator action procedures have changed a little bit and it all has to do with performance you have to be the case that the control manager would call your control indicator action procedure basically as fast as it could and so if your proc needed idle time all you had to do was wait for some of these excessive calls and call movies task or whatever else it was that you needed to call at idle time and in order to provide more blocking behavior to allow other processes to have more processor the control manager will now only call your control indicator action crock when the mouse actually moved so if you need idle time at this time you should install a timer and again the carbon event session went to detail about timers but basically a timer is a callback that gets called at various time by the toolbox and one of those times is during the krona during control drag tracking or i should say control tracking and you can pretty much do whatever you like inside that timer it's not a sort of a time manager sort of situation where you're at quasi interrupt time so definitely look at adopting timers in order to get I'll time during control tracking so some of the definition functions in the toolbox are changing a little bit for the most part you're probably not going to notice a whole lot of difference we've done a fair amount of work building compatibility shins into the control manager in the window manager so that old control definitions continue to work even though in general definitions are carbon event-driven now you can now write a carbon event-driven control definition our window definition but you don't absolutely have to and of course you can't if you need to shift on to carbon libs 10 for control definition to now take an initialize message and the initialize message one of the parameters to the initialized message is a collection manager collection and this sort of replaces all the nasty overriding that you might have had to do in the past you can basically associate data with tags in a collection manager collection and then the control definition can pull the data out of that collection and the tags will actually make sense instead of being the minimum and the maximum and the rest con and they really mean something else control initialization messages also can return an OS status so that if something goes wrong during the creation of the control the definition can actually report what went wrong instead of just mindlessly fail and this will allow ultimately the application to figure out okay and not only did something go but here's a hint as to what went wrong so maybe you can work around it or present an error to the to the user and let the user work around it the region calculation messages for control definitions have a long nasty history for a number of years they were what we would call a 32-bit dirty in that they sort of over Road some pointer values and set some flags in the high bit and we used to for compatibility preserve support for those messages in certain cases but in carbon it just doesn't make any sense anymore so we've gotten rid of those control those control region messages and what we'd like you to respond to instead now is message called get region which has been around for a while and it's basically a query to you to provide a particular region and on the control manager decides how to associate that region with your control with window definitions the story is pretty much the same we have a carbon event-driven model for window definitions with a compatibility shim for old messages and there are some changes to the old messages as well there's also there's a window method to get region which is pretty much works pretty much the same we ask you for a specific part of the window and you returned to us a region and then we decide how to associate that region with the window w calc reaches is pretty much gone away because it well it was not only not it was not only insufficiently versatile but basically required you to poke around inside the window record and since we want the window record to be opaque even to window with definitions that simply wasn't a workable model anymore and then of course as I said there's no drawing into the window manager port you would expect if anything went draw directly into the window manager port it would be a window definition but we can't even allow it for window definitions so we've done is we've made sure that when your window definition is called the current pork is already set up to something it can draw into so you don't need to explicitly get the window manager port you can just assume that the port is set correctly when you're called so even if you don't write a custom control definition you still often need to instantiate them and basically we've added some functions which allow you to more easily create custom custom tool box objects and they're basically analogs between the old classic api's and the new AAP is you're not required to excuse me you're not required to use the new AP is in all cases the old API eyes are still there but for the custom definition case you probably want to use the new AP is one of those new API is create custom control and basically the purpose of these api is in general is to give you a new way to specify where the code for the custom custom definition lives and as you can see the controlled def specs record basically contains a upp and it also contains a field which tells us what kind of what kind of feel to expect in the Union and in this slide you see the the union is has only one member so it might seem like the desk type field is basically redundant but we've set this up for future expansion and I believe in the carbon events section they talked about some of that expansion anyway when you create a custom control you pass to interesting parameters one is the control desk back i just described and the other is the collection and you may remember i talked about a control definitions initialized message now takes a collection well here's where the application creates that collection and passes it in to create custom control and the control manager figures out how to make sure it gets to the control definition so given that we have this new control depth back record and it's all about function pointers and you pee pees you may be wondering well what happens if I have a control definition stored in a resource or another definition for that matter and it is definitely the case that putting control definitions and resources is no longer the right thing to do however that doesn't mean you have to throw out all of your client code basically we have a map which maps your old resource IDs ultimately to control definition functions so if you have a cntl resource for example which specifies that control definition excuse me that which specifies control proc ID 2064 that ultimately maps to control definition resource ID of 129 and then the control manager has a map that knows to map 129 to your function are actually to your control desk fact and I call this a sort of a virtual resource ID because the cntl resource stinks there's a control definition which has a certain which has a certain resource ID but in fact that control different definition doesn't exist as a resource that only exists as a mass entry and the control manager knows that when somebody asks for that control definition resource ID that should relate it back to your control desk back which you registered earlier so here's the function you use to register a control definition excuse me yes okay at the bottom of screen let's just start with the beginning basically when you register a control definition you not only provide a control desk back and a seed if or I should say a virtual CDF resource ID but you also provide a callback which allows you to translate the fields that we're in the cntl resource into either excuse me into a collection so that the control definition when it's initialized message gets called it can extract parameters from the collection in a tags format instead of knowing about all those weird overridden semantically confusing parameters that used to have to deal with and that mechanism is obviously still needs to be there because cntl resources are in a certain format and they have certain fields and we can't really make that go away so at some level you do know you do have to know that that for example of the maximum and minimum field meet really mean something else but at least your control definition doesn't really have to know and if you play your cards right your client code for the most part doesn't have to know so yet another instance in the series of toolbox object opacity is that dialogue item lists are of course opaque and and when we analyze what kind of problems that was going to cause developers we found hella cases where developers were actually pulling individual items out of a dialogue item list or inserting new ones into a dialogue item list and so we've got now to AP is which allow you to do this in a controlled supportable way and I guess the only sort of non-obvious part of these api's is the second dialogue item index parameter to remove dialogue Adam you're not forced to just remove one you can remove two or three in the middle of the list if you feel like it now we're getting into the section of stuff that you may want to do once you find out about it basically all the toolbox objects now support Unicode and they support it not only in the API but also internally we still have the Pascal string api's but basically what they do is create a CF string graph which is the object in core foundation which supports unicode as well as several other encoding internally and then we from there on the string stays CS string forever so if you use CF string api's you can pretty much be guaranteed that if you the string that you set into a control will come back with one hundred percent round-trip fidelity if you use the pascal string api's then we may or may not be forced to do some conversion and you might lose a little bit of fidelity so that's one reason you might want to adopt the cs string api's there's no there's no sort of what's the word I'm looking for there's no requirement that you adopt them but over the long run it's probably in your best interest and I want to emphasize that internally we're working with CF string completely so we're not just sort of paying lip service to the Unicode thing it's really down into the core of the toolbox finally I want to talk about see if string raft semantics just a little bit in brief corefoundation introduces this new concept of retaining release semantics and we of course support those and what that means is in some cases we will not actually make a copy of the string from the toolbox object we may effectively increment the ref count of that string instead of making an actual bike copy of it and basically you don't need to worry too much about that except that we wanted to bring it up to point out that that that if in some cases will be a performance win and you should probably read up on CF string rafts and retain release semantics to understand that fully now in appearance I think in in Mac OS 8 we introduced a new API to deactivate a control but usually when developers need to disable a control they resort to highlight control which is one another one of these functions with overloaded semantics so now we've introduced a function called disable an explicit function we call disable control and not only is there sort of a semantic cleanup associated with this control but it allows us to do some things in aqua which we weren't really able to do before basically under platinum a disabled control looks pretty much like a deactivated control but under aqua they look a little bit different and I don't know if you can read so maybe you can the labels under each of these button images so all I'll just read the math so we're clear the one on the far left is active meaning it's basically in the front most window and the user expects the interactive excuse excuse me it's in a window that the user expects to interact with but it's disabled the second one over from the left is active and enabled so it's not only in a window the user expects to interact with but that button actually responds to clicks third one over from the left is inactive meaning it's probably in a background window and it's disabled so it's sort of the most colorless and then the one on the right is inactive and enabled and that just means it's in some background window but if it were in a foreground window it would be clickable now we've added some contextual menu manager support to control and basically that support is intended to be provided by the control definition so the control definition is in the best position to know what contextual menu to provide so we let it provide one and basically the way that the application level client code works is you call handle control contextual menu click and it will query the control definition to find out whether it wants to provide a contextual menu if it doesn't want to provide a contextual menu it will excuse me the control manager will ultimately set the menu menu displays parameter to false and then you can test that after calling handle control contextual menu click and if it is false then it means if your application knows something about that control or the enclosing window or something on those lines and they can provide its own contextual menu we've added control excuse me we gotta drag and drop support to the control manager we've got a few slides on this because it's a pretty comprehensive support now the first point here where it says bike by default controls in that track drag basically what that means is there are some controls which support drag and drop inherently and that support does not change but you can tell an individual control whether regardless of whether it supports that I can drop you can tell it whether it should or not so it's really up to you some controls will call set control drag tracking enabled on themselves as they're created the only control that does this right now is the data browser control and I believe there's a way to specify that it not do that but in any case you can turn it off and of course there are api's to enable or disable the capability and I think they're pretty straightforward there's a setter and a getter and there's not really much confusion there so the way drag tracking works is or at least in one of the cases is you install your normal drag tracking handlers and while drive tracking is occurring your application needs to maintain state so it knows which of the drag tracking messages to pass to the control and of course as the mouse enters the control you send at the enter control message and as as the mouse is moving around within the control you send it the tracking and control message and I'm guessing you can figure out what the leave control messages for but anyway the port the important message here is that your app needs to maintain the state during drag tracking so that controls are given the right clues to draw the user feedback correctly and of course when you receive or when the user releases the mouth and the drag manager tells you that the user is intending to draw you basically pass the drag reference off to the control definition it looks at the drag reference figures out what data it cares about and what data it doesn't care about and then it incorporates that information into the control and in a way this is sort of like calling set control data except that you get to pass many different flavors perhaps many different items so it's sort of like it's almost like a container being shipped off to the control and the control incorporates whatever data it cares about now there's a much easier way to get support for drag and drop in your application and basically it involves telling the control manager for a given window just handle tracking you don't need to install tracking handlers you don't need to install drop handlers everything is taken care of for you automatically and you give up a certain amount of control over the process but we think the majority case people will just simply turn it on and forget about it and and from then on their controls will just work we're really proud of this API because it is definitely the longest function name in the entire mac OS api [Applause] we worked really hard to put that in there so idle control i don't want to sound alarming but idle controls is pretty much obsolete with respect to the standard controls the standard controls now install timers and that was again something we talked about in the carbon event session so they don't really need idle messages they're more or less self-sufficient with respect to idling the control manager still cares about the one Idol bit so if you have custom definitions that set that feature bit you're still okay you'll still get your idle messages we really want to encourage you to adopt timers because it's again it's a performance thing but if for some reason you really need to keep that Idol bit set will still honor it the distinction is that the standard controls simply don't set the bid anymore so because they have you know because they're self-sufficient with respect to idle time they don't need to tell a control manager to send them explicit messages periodically for Island if you've been to the aqua sessions you probably saw something resembling a demo on scroll to hear functionality we've added basically a quick summer is when the user clicks in the page up or page down area of a scroll bar or in the sort of non indicator area of eighth of a slider control the indicator jumps to wherever user clicks and of course there's various controversy associated with that user experience and there are definitely preferences associated with that user experience too so if you feel you need to stick with the old behavior that's possible but in any case we've added this functionality for users who want it and it's basically one of these carbon add rent a vent driven thing for the most part if you want if you need to add support for it in your control you need to add a carbon event handler and we'll tell you when to do the scroll to hear saying now of course like the rest of the carbon event support in control definitions we have a shim for the old messages but there are some conditions under which we can't do the shim a translation sort of thing the way to stay out of the situation where we can't support scroll to hear for your scroll bars or sliders simplest way any way is to instantiate the live controlling variants oh excuse me to live scrolling another live tracking variants another way to do it is if you for some reason need to have non live tracking variants specified no action proc for those scroll bars or sliders really what you need to stay away from is dry gray region upp and that's a weird historical sort of I don't want to call it an accident but basically it's once again it's one of those weird overloaded semantic cases where sometimes you specify an action proc with a certain prototype and sometimes you specify an action product with another prototype and it's really hard for the carbon event shim to figure out which situation you're in so basically it eliminates the possibility that it will try to call a function with the incorrect prototype by simply establishing conditions under which it won't even try to do a scroll here so if you stay away from those situations where it's a possibility that you would have to specify drag rage Greg gray region upp and basically you don't have to worry too much about scroll here it'll just work click activation is a whole new facility we've added basically click activation is a way to specify what are wait for a control to specify what kind of behavior it wants when it's been clicked on and the window is in is not active and again an active window is basically any window that the user expects to interact with and there are four cases that are control can specify erics should say for behaviors that control can specify for this situation I think the names are pretty straightforward control basically either wants to be once the window to be activated or not or and it wants the control to actually be hit or not and then you can specify all the combinations thereof and so basically your application when it detects a click in an inactive window it can call get control click activation and then find out what to do next as a result i believe the control which supports getting control click activation is the data browser control right now but in the future there may be more controls which actually care about this so if you're building framework type of code you probably want to use get control click activation in the general case and and not just avoid it just because you don't use data browser so here's a chunk of sample code that shows get control click activation in action the first if case is basically if the window is active do what you always did do what you do what you're doing now no change is necessary but if the windows not active then get control click activation comes into play and that basically after you find out what the control want you can figure out whether you need to select the window so if the control is saying activate the window then you just call select window and if the control is saying that it wants to handle the click then again you just call the same old code that you've always had to handle clicks and controlled and it should work just fine so I've given you a long laundry list of features we've been adding to the toolbox and I want to go back over some of them to emphasize what's what's in store for you in the next few weeks or a few months and hopefully few days basically drawing to the window manage report is no longer supported it kind of doable in DP for but don't get used to that idea because it's going to stop being possible very soon there's some changes to the custom window and custom window and control definition model there's not only changes to the way you need to instantiate them but also changes to the way they need to work internally and then of course there's the dialogue item list accessors that we've added in order to support dialogue opacity then there's a unicode support pervasive in the toolbox unicode is obviously an important future direction there's the carbon event support in the toolbox and once again I want to emphasize if you get a chance to see sessions 121 and 122 on quicktime streaming or video tape or however it is they end up distributing these things definitely take that chance and then we've added a bunch of new control manager features some to support the Aqua user experience and some just because they were cool you