WWDC2004 Session 422
Transcript
Kind: captions Language: en [Applause] are you ready welcome to session for 22 which actually would like to call by the H I toolbox day of hig day other things has been evolving inside mac OS tanner and this week you probably learn a lot of this evolution first like you probably heard quick-draw is being deprecated we talked about being ready for like a resolution independence so what does that mean for you as a carbon and C C++ developer what does it means for you as an itch I toolbox users well that means a couple of things and first that means that your code is going to have to evolve as well to play great in the next operating system of Mac OS 10 the next version of Mac OS 10 the good news is that we have a lot of technology that we're going to be announcing this week here in a chai tool book and a lot of things with HIV which we've been doing but should really help you and we have really pack station that you really like in your help you move forward we're going to start today with ghee who is all representative from franza who's going to be actually talking about switching to a modern edge right tool box and going to teach you you really warka take your pitch have you and how you as a developer can take advantage of you how you going to get there and all the features that you're going to be able to take advantage of so I think it's a great first step for you to understand the foundations of where we're going here after that please don't miss the station but we're going to have at three-thirty with a curved with you Curt we're actually we know that a lot of you guard our steel base have dialogues and windows resources and so we're going to take a full hour to kind of like give you a basis and help you switch your resources based user interfaces to need five and then we'll teach you as well how to kind of like link them together using carbon event very very cool session I think you'll like it now getting ready for resolution independent we're going to teach you tomorrow we're gonna have a session but can explain to you how to switch your custom drawing content and how to switch you know like in OC or using c def for instance to use custom HIV this is a very very very important session if you have crystal control i really encourage you to attend that session so you're probably thinking well but Mindy I'm gonna have like still to like you know like Rev some old code that I have it has been working yes you're correct you're gonna have to revise the Makino move some code if you're using quick draw you can have to switch you know to call graphic but what's very very important to understand it but this is very very good for a core user because you user interface a new application is going to gain in performance and in features and this is really where we're moving toward the other thing will be very pleased with the war between been doing and let's start with Miss Judy who is going to be taking you for the next hour with like the new things we'll be doing with a chive you mr. G thank you very okay so good afternoon I hope everybody had a great lunch get ready for a very packed session maybe my fast speech will help me for one's here okay so what I'm going to cover in essence is the meaning of a chive you and how that can help your application and then I'm going to show you a step-by-step example of how you can take advantage of a pH I've you in your application then I'm gonna have a section on resolution independence it got mentioned that the graphic sessions already but i'm going to show you the carbon story for resolution independence and how you can start thinking about that for your application and finally i'm going to go through a potpourri of various new features and a chai toolbox for tiger so we use this word a chive you a lot davia probably said it 15 times as he was taught in there and a lot of people wonder what a chive you is i mean i'm sure you've seen the typedef and then we say adopt HIV I mean I just need to grab one view well know what a chive you means when we say adopt a chive you because it means get on board with everything we've been doing for the last three or four years in the toolbox a chive you is this conglomeration of cool new features we've been adding since since Jaguar essentially so technically HIV you is our object oriented view system it's based off the control manager if you've seen the control manager and you're familiar with it and I know most of you are a chive you is also going to feel very very familiar it's so familiar and so similar in fact that it's the same type rent typedef a control rough is an HIV ref it's the exact same type they are literally typedef to one another the header means you can use HIV reps in control manager api's and you can use control reps in HIV you ap is now our object model is based of course on H I object we've talked about that in the past the very cool subclassing mechanism for carbon clients and we use carbon events as a messaging model now H I've you also includes all the new widgets we've added over the last few years I like the search field and the toolbar and things like that HIV also represents a much more advanced drawing model where you can take advantage of all the cool courts features and there's some other side perks in there H I've you gives you much better drawing support in the sense that the api's now makes sense when you use them and I don't do things you're not exactly expecting and they don't force you to take work around now the reason you want to adopt a chive you is because what your customers are asking for can really only be granted by HIV HIV you can give you all those buzzwords like the library sizing quartz transparency various forms of animation going to HIV you is also the only way to adopt certain new toolbox features we've added over the past couple years the toolbar is one our text view and scroll view which is our full featured text editing view and carbon is another we've got an image view we have HIV layout mechanisms which are like Springs and rods on steroids and all that only works under a chive you now another reason you should use a chai view is it just going to make your apps faster right we did a lot of things much more efficiently we learn from our mistakes in the control manager and just made it better and the best thing about a chive you is it actually makes your jobs a lot easier the code you end up writing to do something custom in your app is a lot simpler when you use HIV to implement it than if you have to hand roll it yourself the old way so some of you may be looking at your applications these days and feeling like look it looks a little bit like this house you know I've kind of got a crummy lon the paint's chipping here and there the windows are kind of ugly the roofs maybe got a couple weeks well one reason you might want to adopt a chive you is because it can allow your house to look like this put a little work into it you know give it some new paint clean up the lawn you know clean up the yard and suddenly it looks a lot better but then there's another side perk that house is exactly the same as it wasn't the other picture we've added some things right there's a new fence there there's new windows in fact one of the windows was expanded a little bit so H I view is going to not just let you polish up your applique but it's going to let you expand it and grow it so there's five basic steps to adopting HIV or adopting all the technologies in HIV so let's jump right into the first one that's using the standard windows and controls this is something we say every year and we need to repeat it because it bears repeating right there's a lot of good reasons to do it and we know some of you still need a little bit of a push to keep adopting the standard windows and controls so we've added a lot of new views over the last few years they can do basic things that your apps used to have to do for themselves if you want to list view that interacts a lot like finders lists you go ahead and use the data browser fact finder uses a data browser to do with lyss you like I mentioned before we have a text view and a scroll view of it together can be a full-featured text editing engine for carbon applications but you don't have to use the scroll view just with the text view you can use it to scroll image views or any other custom view you might want to make so take a look at the controls we offer and take a look your application and find out what you were doing custom and see if now there's there's some parity between what we offer and what you do and see if you can replace your custom implementations with our new features also be sure to take advantage of you embedding or control embedding this is something that we've had a long time Mac OS 80 but we know a lot of people like to use controls in a very flat hierarchy right they have a window and they have a bunch of controls in it and then they try to manage the overlapping controls themselves and try to manage the containment themselves well a chive you can do all of that for you so you might as well use the built-in infrastructure that's also going to give you a lot of Bennett's benefits with respect to accessibility an app that's been revs to use a chai view is going to be mostly accessible in addition going to a chive you insulates you from future interface changes that we might make the best example of this is probably the tab on Jaguar that have looked a lot different than they started to on Panther and continue to look on tiger but there were a lot of applications that rolled their own tab ensure they use the appearance primitives to try to get the standard look but because of how the appearance needed to change in Panther those same primitives could not draw the new look so people that did their custom tabs on Jaguar and got a good Jaguar look unfortunately carry that Jaguar look into the future into Panther and tiger another great reason to use our standard tabs if you use the standard tabs it's going to get the new looks as we as we rep the user interface that's really the first step it's pretty straightforward right but it's going to give you a lot of good wins and most of you already know how to do that and are already at least partway through doing that in your application so that one should be pretty easy the next step which is probably the most time-consuming step let's say is taking your custom user interface in your application and wrapping that inside individual HIV objects the first step as part of that process is to look your interface and factor your custom areas into individual subcomponents right its standard engineering design methodology you want to make a view around the simplest smallest thing possible in most cases if you do that it's going to be a lot easier to write a chive use around those individual small widgets and you'll be able to reuse them in various places as well which is cool then using our H objects subclassing mechanism you create a subclass of a chive you to represent your custom object then when your custom object is put in the view hierarchy it will receive carbon events to handle things like mouse clicks keyboard events all sorts of other users interact interaction accessibility activation of the activations all that stuff so you just handle those carbon events do the right thing we have lots of header doc and carbon events th for all of the control and view related events you can look in there it tells you what you need to do what events you want to handle for certain situations and it's really straightforward then if your view needs to communicate state changes to other parts of your application like what's they have one a button is clicked right you need you need to carry out some action someplace else in your app you can use H I commands to do that we have convenient api's to send out a chai command in fact the view system already has built-in support for a chai commands you can associate a command with a given view it'll automatically get sent out when the view is clicked but if you have more complex communication needs you can use custom carbon event carbon events to communicate between different pieces of your app one good example of this is our scroll view the scroll view is based on our scrollview carbon event protocol which is just a set of simple carbon events that it can use to communicate with scrollable canvas if you have similar needs in your application there's no reason you can't use carbon events to implement them they're really flexible really full featured you can put all sorts of attributes in them you can cue them you can direct dispatch them and it's really powerful then it bears repeating keep using view embedding you know you might get partway through this step and say okay while I wrap my custom content in some views but I'm still going to use a flat hierarchy well I really recommend not doing that I really recommend using a full embedding hierarchy because it's going to make subsequent steps a lot easier finally we have a bit of sample code called a chai framework it's on the developer website we have a bunch of sample applications based on HRM work and this is the c++ class library that manages the kind of boring details of a chai objects subclassing in the HIV mechanism you can just derive a subclass from our RT view class and it'll automatically set up the HOF sub sub class the event dispatcher and all that then you just override whatever virtual method you need to and do whatever work you need to in those now we're going to be covering some of these steps in more detail because I just don't have time to talk about them today so we're going to cover them in two other sessions as examined session for 21 immediately follows this and it talks about taking an old style dialog or some old window code and replacing it with a nib file and it's part of that adopting a chive you in the process where you can and then tomorrow we have a session entirely on writing an HIV from the ground up to represent some custom area in your application so I strongly urge you to attend these sessions to get more details on this step so that's two of the five steps the next is adopting the standard window handler this is probably the most fun step mainly because it gives you kind of this cool bang for the buck it gives you this cool win now the standard window handler has been around for several releases and essentially what this is is it's a carbon event handler that can automatically be put on your windows to do all the normal event dispatching that you use to have to do manually when you called wait next event so you no longer have to call wait next event see if it's a mouse event call fine window see if it's in your window that you're interested in if so call find control rather to the control if it's not a control yeah you know that whole rigmarole you don't have to do any of if you turn on the standard window handler so the standard window handler is designed to work directly with a chive you and what I mean by that is the standard window handler only knows how to deal with views it can route mouse advanced keyboard events all that stuff's of use but if you have completely custom stuff in your window and it's not represented by an HIV you have to jump through hoops to make that work you have to install a bunch of carbon event handlers on your window and deal with all that rigmarole so the right thing really to do here is if you're going to use the standard window handler use HIV they work together really really well the standard window handler is also the most important key to using the toolbar the toolbar essentially put a system driven piece of code or a system different piece of interface in your window and the only way that can receive events is if you jump through some hoops to find the right events to send to it or if you just use a standard window handler might as well use the standard window handler so to get the standard window handler for your window you need to do a few things in interface builder which is our preferred way of creating your windows there's a checkbox in the window and spectryx palette so standard handler just check it standard handler will automatically be turned on for your windows but if you need to programmatically instantiate your windows there's an attribute the case window standard handler attribute that you can specify at creation time once you've turned that on for a window the standard handler will automatically be in effect since your application runs it will start servicing events which means you can go back into your weight next event loop and rip out all the code that had to deal with routing events to that one window you can just get rid of it it's generally not necessary but the standard handler can't do some sort of functional things on the window that you're going to need to respond to for example when they closed box is clicked a window gets sent the cave k event window closed carbon event and by default the window will tear down but if you need to save changes to do something else you want to hook into that carbon event to handle handle it completely there's a bunch of other carbon events like this you can think of them as hooks they're not strictly necessary but they're good ways for you to hook into the systems processing and provide custom behavior where you need to carbon events that H again has lots of documentation in that better so I urge you to take a look at it see what sorts of other hook events are in there and take advantage of whatever makes sense for your application let's step three step four is probably the coolest because it's the flashiest that's switching on compositing mode and starting to draw with quartz now this is cool because it gives you radically better performance and it just makes your life a heck of a lot easier one of the ways we sped up the HIV subsystem through compositing mode is that we no longer draw a pixel twice unless we absolutely have to and what I mean by that is when a view draws we know whether or not it's apple cake and we know what part of it needs to be redrawn and so we make sure to just redraw the parts of the views that intersect that dirty area in addition now that we are not redrawing right when you call various api's like that site control value well step back for a second so in the old control manager every time you called an API likes that control value the control redrew so if you did a typical setup of a scroll bar where you call second roll value minimum maximum the maybe V sighs that's for redraws of the scroll bar right there that's a big waste of performance h I've you eliminates that now instead of redrawing in those AP is we mark the appropriate areas of the scroll bar is dirty and needing redraw later so some time later right before you get back into the event loop that view will automatically be redrawn the other cool thing compositing mode does it eliminates the need to erase if you've ever written a custom see def you knew is your responsibility to call setup control background and a race before your control actually drew which meant that you if you had a complex view hierarchy of controls there was a lot of erasing and redundant drawing of the window background going on that's just crummy so we eliminate that in HIV which speeds up the drawing pipeline now of course compositing mode means you can use quartz really really easily which gives you access to all the cool quartz features and additionally the compositing draw model is far easier to write than the old draw model in the old draw model every time your control received certain messages it was your responsibility to execute your own draw code sometimes clip differently or who knows how well in the compositing mode you only draw at a very well defined time and the K event controls our event so suddenly your code is way simpler you just handle the draw event and in your other events you just handle your mouth tracking or whatever else you need to and you don't need to worry about weird cross-pollination of functionality so let me give you a quick demo of some of the cool things compositing mode can be for you okay so if you hammer home a point a lot of people made requests over time for the ability to draw controls on top of an arbitrary picture and this is how it would look if you tried to do that in non compositing mode the controls try to erase behind themselves so they blow away whatever picture was there ensure there were workarounds right you could hook into the quick-draw bottlenecks on your port and try to patch things up but those even broke as our views in the toolbox started switching over to court so this is what you ended up with which is pretty crummy instead with compositing mode you get something like this obviously a lot nicer now you can see the controls were animating and some of them the disable button up at the top left if you can just barely tell that you can see the picture through it because that button itself is partially transparent in addition the cloud and the Sun is somewhat transparent and as I resize you might actually be able to see the background moving underneath them and stuff so one thing that David did when he wrote this app is he just put a little bit of animation in there right so clearly not smoking mirrors this stuff is clearly all live it's very fast it's very easy to use it works really intuitively one other thing I want to show off with this application if you make this really small all those views are overlapping but they're all still properly Z ordered and they all still draw in the property order so you can see in the various things going over top of stop button and you know I can still click on things when this is going on in tracking still works you know I can track on hit tennis I'm getting blocked by other views the orders on top of this one from hit effing there we go so now I'm actually tracking in the other button and that all just it works it's very cool so not many other view systems on this platform or otherwise can do anything like this so here's here's a fun little app this is not something I'd necessarily recommend you do but it might give you some idea of the power of HIV you and compositing mode so like I said before have you every view draws in a very well-defined place the K event controlled draw Handler and that handler is passed a core graphics context reference to do its drawing with and the view must do its drawing with that context this means that anybody can come along to your view intercept handling of the K event control draw handler and manipulate the context a little bit if it wants to for cool reasons so what Eric did is he / she / rode the draw handlers on a couple of these controls and transformed the context to scale up and down the various widgets here now granted there's some artwork problems this is why I don't exactly recommend that you do this technique but you can see from the scroll bar and the checkbox that you actually get kind of reasonable results so this is kind of cool things you can do with compositing though don't you leave that open and fire up transparent windows okay so ignore care wants to show you just how cool it is transparent windows on carbon this is something we get requests for a lot how do i do a splash screen with transparency or something like that this is an example of how you might achieve that this is an overlay window that inside of it has a couple views embedded it has a view that's drawing that image of the character from aqua teen hunger force and there's also a push button in that window and also this slider and they're all together in the same window I can move it around it's got a shadow and everything and I did this just by creating a custom HIV class to render that image and then put a couple other controls in that window as well but that doesn't exactly meet the goal people want to transparent window so what I did is I wired up this alpha slider to talk to the other view and change its alpha value so I can do stuff like this and it's all live it all keeps working it's really easy to write and it's really fast and it's all still a window in this button I put the standard minimize command so when I click it window goes away just like you'd normally expect so the stuff is really powerful and really really easy to use it only took me about an hour to write okay so i can go back to slides please okay so to turn this on there's a few things you need to do and I want to cover this from two different perspectives one is from an app's perspective as in there going to be a client of the HIV you ap is the other is as a views perspective and I'll cover the views perspective later so from an apps perspective what you need to do is go into interface builder with your window and turn on the compositing mode checkbox for that window if you create it programmatically of course we have the K window compositing attribute that you can set once you've done that all drawing in that window must be done with a chive use we will no longer send update events to you you will not get update events for that window out out of weight next event so any drawing that you're expecting to do to wait next event isn't going to happen got to put everything inside a chive use the other major change you need to worry about is the notion of frame coordinates so if you think back to the control manager when you want to position a button at the bottom right hand corner of your window and the control manager you figured out the coordinate the top-left coordinate for that button as it were port relative if you find out the quick trial court for the window you find out the appropriate offset from the top left at that court and use that as a button top left it changes a little bit in HIV mode and compositing mode now you specify the buttons top left relative to its parent view so it's just a little change something we had to worry about when we rev navigation services and panther to start using compositing mode but it's also something pretty easy to to get through your head you just do it a couple times suddenly it becomes intuitive another change you need to make is pretty much elimination of code in compositing mode don't call api's that draw right away don't call draw one control to draw control in current port they just don't make sense compositing mode is all about invalidation deferring drawing until later anytime you call draw one control you're defeating the purpose of a chive you and you're slowing your application down auto-embed control is another API you want to avoid but that's mainly because it doesn't make sense really in compositing mode it uses a different notion of coordinates and it tries to figure out heuristic alee what the right what the proper parent he would be it was really there for dialogue manager compatibility so just avoid it instead using API like HIV you add sub you and figure out the parent you'll usually know what the parent is anyway just associate the child with the parent so there's also a few steps from a views perspective and I want to cover them individually so the first thing you can do is test to see whether compositing mode is on for that window you don't have to do this right some people write H I've use just to work in compositing mode in fact that's what I did in that last demo app I knew I was only going to use in compositing mode so it was really easy to write I didn't bother testing but if you're going to rev to compositing mode over time in one window and then another and another over a couple of your applications releases you may find it useful to package your custom content up in views that can work in either compositing mode or non compositing mode so if you want you can take a look at the view zoning window see whether the compositing mode attribute is on and if so you can behave one way in compositing mode in another way in non compositing mode the next step is to make sure you invalidate appropriately right don't draw all those state changes like I was talking about we send out a handful of carbon events when appropriate state changes occur in various views right we tell you when of you activate your deactivates when the highlight part changes when it enables or disables or when its value changes and we also send out carbon events anytime a views bounds change so that you can make intelligent decisions about invalidating exactly the portions that need to update this is really useful for a list like data browser when data browser resizes it knows all the stuff in the upper left-hand corner of itself doesn't need to get redrawn a little just invalidate sort of the l-shaped a region that gets revealed and maybe a few other bits here and there and just those areas get repainted so when you get one of these notification api's you just inform the HIV subsystem what parts of your view or dirty if the whole thing is dirty you can just call HIV you set needs display pass the view past troop marks the whole thing is needing repainting and the whole thing will get repainted later but if you know just some sub part needs to get redrawn you can use an API like HIV so that needs to play in rectangle and there's a couple other variants of that API so you've got more fine-grained control the next step is to switch your view over to draw with quartz pretty much have to draw with quartz and compositing mode no it's not literally true but that's really the recommended solution and it's the only way you're going to be able to get the free resolution well I can't say free the low-cost resolution independent support which I'll talk about later but the key here is that you only draw in a cave control jaw handler like I mentioned before and that event comes with the core graphics context rep that you're supposed to draw with don't try to manufacture one for the windows port it won't be clipped right it won't necessarily be transformed right just use the one in the event it's there for a reason draw with it once you've done that you can start leveraging whatever courts features you want you know start taking advantage of setting the transparency on the context use bezzie as he's whatever you want but the key to remember is never a race only draw you can count on the fact that the HIV you subsystem has painted the views behind you already that's already taken care of and if you want to make a view that is aqua compliance and aqua savvy we have a bunch of H I seem drawing primitives which are designed to be used with core graphics or with the core graphics context you can take a look in a chai toolbox / h ith for a bunch of different ways to draw the standard button looks with standard tabs those tabs lips and things like that so that's step for the next step maybe the most gratifying step because it lets you toss out all kinds of code from your application that's switching to run application event loop so over the course of time you put the standard window handler on your various windows you switch them over to compositing mode and you finally just finish the last window so now you look at your weight next event loop and you say well this isn't doing a whole heck of a lot I'm tracking the menus here and I'm calling it you process applet and that's about it well one application of that Luke can do that for you and allow for more future growth as well so take your weight next event loop toss it away put run application event loop in its place now one thing the weight next event also did that a lot of you rely on is give you periodic idle time the problem with doing that through wait next event is you had to sort of centralize your notion of idle time and your objects had to communicate with wait next to meant you had to find the smallest time slice that was needed by any given object they wanted to animate it was just big mess so instead we recommend using carbon event timers carbon event timers are an easy way to get either periodic processing or like one shot deferred processing off in the future and it allows you to encapsulate all of your codes with an animating view right there in that view that view doesn't need to know its operating under weight next to man to run application event loop or whatever similarly wait next event also allows you to detect mouse movement based on a region well again have the same kinds of problems your views that wanted to communicate with wait next event had to no wait next event was there you had to figure out the minimal region and it was just a big mess so instead a couple releases ago maybe last release we gave you tracking areas mouth tracking areas and these tracking areas are designed to manage a window relative Mouse region and you get informed of enters and exits into that region so it's a very handy way of doing something like roll over or cursor changes so once you switched over to run application event loop the thing you need to realize is that run application event loop will not return until it's quick and the way you quit it is with quit application event loop so you put that in appropriate place in your application probably like your quit apple event handler or something and if you have various places in your app where you call modal dialog or you call wait next event in the fashion where you're trying to simulate modality the way you would do that now is with run app moda loop for window you can pass that api a window it will make the window automatically modal and it quits similarly to run an application event levitas call quit eps modal loop for window that's all five steps once you take advantage of that you should be able to transfer your application so it looks something like this really make it modern really make it great start taking advantage of other new toolbox features and be prepared for the future future might be something like resolution independence hey speak of that so resolution independent is kind of a big big subject so let me see if I can explain better with a demo it's very visual so I should do the trick so maybe I should give a little bit of background about resolution independent first so that we don't really have high DPI hardware yet we know that the industry is moving that way over the next couple years and we'd much rather have applications that are going to be ready for that hardware when it becomes available so we don't want you waiting to start thinking about resolution independence until after the hardware shows up we all know the hardware is eventually going to show up so let's start thinking about these topics now start considering how you can adopt a resolution independence in your application all right so I've got the back called resolution modes right now it looks pretty normal right these are three windows the the windows are basically identical except for one slight change i made to each of them in interface builder that's how they look now but if you launch quartz the bug and you go up to the Tools menu there's a new item called show user interface resolution give you a little slider with a multiplier on it if you change the value on this slider it multiplies the resolution that apps will run in so if I move it up to 1.25 relaunch my resolution resolution modes application you can see that the windows got a little bit bigger but you don't have to stop at 1.25 I'm actually going to go really high here so you can see it a little bit better ok so this window which is titled magnified see if I can get these other windows out of the way this magnified window has not been modified at all in fact this applications event basic core event processing processing has not been modified at all and this is the result sure you get a bigger window but it looks a little grainy right I don't know if you can see it on the big screen but the magnified text is a little blurry it certainly looks like it's been blown up well that's because it has been blown up magnified mode is what you will get by default for any non savvy window in your application how we do this is we tell the windows server look this is the window that doesn't know it's in resolution independence or that it's under a scale factor so please blow it up for me right your windows backing store is still very small so when we blow it up bigger it kind of grainy now there are two resolution independent savvy modes you can set on a window first one I want to talk about is framework scaled mode now obviously this window looks a lot better you can see the text in the text area is a lot crisper the picture still looks kind of crummy let the where are we can I not switch oh we have bad things happening oh we have really bad things happening alright um oh cool all right I gotta reboot the machine from back here and I can't get to the front all right well strictly speaking the demos are not necessary so I'll just I'll just cover more detail here I guess so magnified mode 925 mode is the fall back case this isn't really what you want to have your application look like but it'll work in a pinch it'll allow users to get something reasonable with your application even if your application has not read for resolution independence like I showed it looks kind of crummy particularly compared to the other mode but it doesn't take any effort on your part now unfortunately I didn't actually get to show this but David's going to try to troubleshoot it so maybe I can the next mode is application scaled mode this mode is not the second one do I show it is that little small one that came up application scale mode is a mode where you do all the work now well you do most of the work the benefit of application scale mode is that you can actually use quick draw in that mode unlike the third mode so when you specify you want your window to work an application scale mode you're responsible for making all parts of that window bigger except subcomponents of things driven by the toolbox so if we can get this back up i can show you what i mean the application scaled mode window was still at the same size as it was when the scale factor was 10 but the title bar was a little bit bigger well the title bar was bigger because it's handled by the system and we know to apply the appropriate multiplier to it and another thing you could have seen there is that the text was a little bit bigger right we know the system font when somebody requests the system font isn't just 13 pixels tall anymore there times some multiplier tall so we made it bigger but the problem was all the views inside that window that the application foot there were still the same size and that's because that app had modified yet an application that uses application scale mode on its windows is responsible for sizing the window content area bigger as well and then you resize all the views inside of it this is the price you have to pay for using quick draw now we really would prefer you to not use quick draw if you can just switch over to a chive you switch over to drawing with courts you can take advantage of framework scale mode the cool thing about frameworks killed mode is you get a really good appearance and its really really easy to do this is the second window that showed up there that I was comparing the magnified window to that was an application scale mode the only change i made to that window relative to the magnified mode as i went into interface builder and change the value in a pop-up menu to say please framework scale this and you get all the rest for free events still get routed right so speaking of event routing this is something I need to show off their that was one application had three windows and each of those windows was in a different mode now we don't necessarily know how that applications getting event might be in a weight next event loop might be in run application event loop who knows maybe savvy it may not so what we have to do is since by default we magnify windows we need to make sure that all global coordinates that come through api's that get passed into api's and come out of structures like an event record all map to the coordinate space that a magnified window uses so essentially what we do is we magnify all the coordinates that come out of those sorts of AP is now this is still a little bit of work in progress here and I've got another slide that talks about this but what we're going to try to do is make it so that ap is that talk specifically about a window that we know is either an application scaled mode or framework scale mode can be used with coordinates that are not magnified so we're going to do as best we can there so really my point here is that these coordinates may be coming back in a way that at first films feels a little counterintuitive to you but it'll make sense eventually and we have a bunch of api's that can help you convert points from the sort of magnified sense of global to the true pixel sense of global okay so to turn on resolution independence for your application start with a window go in interface builder there's now a little pop-up menu there that says a scale mode I think it's got three choices magnified app scales and framework scale if you can't use the Saab pop-up menu and you need to create your windows programmatically we've got creation attributes for those of course once you do that your application may or may not want to take advantage of that knowledge inside inside your code obviously if you're an application scale mode you have to take advantage of that knowledge because you're required to do a bunch of work so you can determine a windows scale mode at run time by calling a chai window get scale mode passes back whether or not the windows running a nap scale mode or frameworks failed mode or magnified mode and additionally it hands back the scale factor in case you need to do multiplication to figure out of appropriate size for a view but if you want the user scale factor without a window we also have a convenience API for that and like I mentioned before we have a whole bunch of coordinate conversion api's and hid geometry H which were originally intended for use with resolution independence but they actually end up being really cool because they allow you to do things like translate between a view and window coordinates or a view of use coordinates in one window with abuse coordinates in another window which you know in rare circumstances might prove useful but I found a couple cool things to do with those oh the other cool thing about these conversion api's is up until now the toolbox didn't have a great way like a one-stop shopping way to take a global coordinate and convert it to a window coordinate most of the time I think we recommended people convert that point to the windows port coordinates and then you can call QT global local to global and stuff like that it's a little bit nasty so now we just the set of api's can also achieve that for you so I did is it is a good bad bad okay all right so first thing to realize and the demo would have shown this as well is resolution independence for Tiger is a work in progress it's intended as a developer only feature you should not ship your applications with this stuff turned on things could even change right we're not done developing an engineering internally so we could have 50 new paradigms here in there we just don't know yet the least ready mode is application skilled mode right I did magnified mode first and that was really easy to do and then we did a framework scale mode and that was pretty easy to do application scale mode is taking a lot more change throughout the toolbox so we'll get there but it's not quite ready for prime time on the tiger seat but still I encourage you to try it out you'll see very obvious visual artifacts just blame the toolbox keep moving forward see if you can kiss and continue exercising the api's and developing on it but probably the coolest thing here is unlike previous WWE seas where we've given you this little window of time saying please give us your feedback like in the next two days so we can implement it this because it's not going to be a user feature for tiger we actually have a little bit window a little bit bigger window of opportunity to hear your feedback and this is really important because there's a huge variety of applications out there particularly the ones that are going to need to use application scale mode and I need to hear from you what sort of things we could do with convenience api's what extra support you could need you know maybe you need a few new api's to help with you know blowing up you're blowing up a window after you instantiate it from a nib or something like that so please try this stuff out start making a little brainstorm list of things we might be able to do for you right bugs contact us on the mailing list I want to hear your feedback we also have a document referenced by rhi toolbox release notes on your developer seed which is carbon resolution independence notes it takes advantage of some knowledge that's also in a sort of overarching resolution independence document that's also in the release notes so i encourage you to read both of those it's going to go into more detail in fact it'll cover some of the stuff I would have been able to cover in the demo so please check that out all right so the rest of our time we've been doing things that you've asked us for we pay attention to mailing list obviously we have Eric the Android on carbon development list responding to messages as soon as we can and we hear what you asked for and and we've done a few of those things for tiger the first thing which i think is the coolest is we actually now have text notifications that you can get one stop shopping knowledge whenever a text in it and one of our unicode fields changes so the matter if it was pasted in doesn't matter if it was typed in doesn't matter if there's in line input who cares you just get this notification similarly there's the textured change in range event that's sent out so you can have one stop filtering you can filter the text you can change it and block it whatever you want doesn't matter how the text was put in there you can do it and we send this to all of our Unicode based edit fields right doesn't work with the old text edit or edit text control that everything more modern than that the search field the combo box the H I text view the Unicode edit field works with all of those but there's a catch that's not really a big catch it's probably a little too scary to say on the feed it doesn't quite work right for a few edge cases so while I encourage you to try this out please you know start switching their applications over to it take a look at the release notes see those couple edge cases where we know there's a problem and you know it'll save you time for having to write the bug and will say oh no we already fix this we already know about it so just take a look and see what those edge cases are but doesn't that I encourage you to adopt this as soon as possible now we also expanded the set of HIV you ap is our first set wasn't really complete I mean it was functionally complete because you could always rely on the control manager equivalents but what we did is we put together a whole nother set of HIV API to sort of fill in all those missing holes well all but one percent of those holes but still we've got api's like HIV setvalue HIV count subviews so your code is a lot more readable and in addition we took the chance to modernize a few of the API so that you know there were some clunky mechanisms in the control manager side we smooth those over and the HIV equivalents the coolest part about this though is that we had a big request to give back latent state information about our views I'm sure some of you have switched on compositing mode and you have an invisible window and you have a view that you've just called HIV setvisible true you know what's visible it's definitely logically visible but if you called a chai view is visible you get back false well that's because the compositing subsystem tells you of use physical visibility not as logical visibility so now we return the late States we have a new API to deal with the late invisibility we had to do a new API for that one because we already had HIV was visible which obviously just returns the physical visibility but we added two new HIV was active nhi view is enabled api's which tell you the physical enabled and active state as well as the layton states so it should make dealing with some of your education is a lot better we also had a request for more fine-grained control over exactly which windows in your application were supported by expose so we have the H I window get and set availability api's that allow you to control whether or not a window gets are handled by actually now I know I mentioned tracking areas already and I'm sure some of you were thinking yeah right tracking here is there a big pay and I try to use them with my H I've use but H I've use apparent relative and when they move i don't really know it and then i got to try to figure it out which means i have to install an event handlers anyway we know we know we've had to do with ourselves it really sucks so what we did is we made HIV based tracking areas exact same concept very similar usage model except the tracking areas are bound to a view now we know when a view moves in a window relative space so we can automatically adjust the tracking area for you automatically automatically do it automatically anyway so we send carbon events directly to the view whenever the mouse moves in or out of that view so they're really easy to use suggest you adopt these wherever you can they're a great way of doing rollover or mouse tracking other people that started adopting compositing said compositing is great until I try to scroll view greater than quick draw coordinate space that doesn't make any sense it's supposed to be court space yeah yeah I know the internals of the control manager used to be based on quick-draw coordinates even though we supported this cool compositing mode and unfortunately you know that was that was prevalent throughout various events we sent events to view saying tell me your structure region well that's a quick draw region which are regions are inherently limited to 16 bit integer coordinates wasn't so good so what we did is we came up with a chai shape a chai shape now has full integration into the HIV subsystem you can now communicate region type concepts in a way that breaks the 16-bit withdraw limit coordinates H I shape also allows us to improve performance throughout the HIV subsystem we don't need to do as many translations back and forth from quick-draw coordinates anymore so it's a boom there we also added a few new accessibility API s for those of you who got a chance to see the accessibility sessions and the boys over sessions these should help out a lot we have a very easy way to add extra attributes to an existing elements like let's say a push button you want to give it a description you can use the set auxiliary accessibility attribute API to do that really easily in addition those of you who are implementing accessibility for your own objects but you need to use the standard roles and you want the standard role descriptions we have a way that you can query the standard role description of the system uses we also have a way that you can easily override the accessibility hierarchy provided by an object this is kind of an educator that most of you won't need to use it but if you do run into one of those situations we have an API that can help out and finally one thing we realized when we were working with finder to provide accessibility information for their list view is that you know data browser is really great but and data browsers accessibility implementation is really good too but we need to interject some extra info in there right what is just a row in one application might need to be called something else in my application so I want to be able to customize what data browser provides so we have a set of API is that allow you to modify the information sent out or pass into data browser for any given element pretty cool take a look at control definition CH for that and in fact let's see that was this morning right so if you want more details on this see if you can travel back in time a few hours and check out session for 24 we covered a lot of accessibility information there one thing we did to the toolbar to kind of expand the possibilities for what you can do is allow for per window enabling and disabling of toolbar items as well as selection of toolbar items so what I mean is you can have two windows that use the same toolbar object you know they both binder the same toolbar but you want let's say you want the delete button in the toolbar to be enabled in one window but not in the other well up to now there wasn't really a way to do that what you ended up having to do is create two different toolbar instances for each one for each window and that was kind of a pain so we built in per window selection enabling and disabling support now the cool thing is that the toolbar can manage the selection for you automatically all you need to do is have your toolbar delegate respond with carbon event that says hey tell me the selected selectable items if you respond to that the toolbar can manage it for you automatically it'll just track the selection change the selection send out a carbon event when that selection changes happen but you can listen to if you need to there's lots of other stuff that I just don't have time to cover today though with my my demos crashed I could probably talk about stuff let's see see what I can do here H I object archiving I don't think this is actually turned on is that true yeah unfortunately there is a runtime problem we couldn't actually turn this on but essentially what H I object archiving is the way to take nehi object which means a window or our control and say hey flatten yourself out to a stream i want to write you someplace and it grabs all the information from those views and you can hook into this this is achieved through new carbon events they get sent to views and windows or nehi object really and you can hook in and provide your own data into this flattened stream so you can store it out wherever you need to we also expanded the hotkey api's let's see some cool stuff for the combo box ah yeah the combo box we asked we were asked by you guys for better control over when the list is shown in hidden unit want to programmatically invoke it and not just have a user click on it so we gave you that there's an easy way to make the list show up the search field we were seeing places in the interface where people wanted a search field with an icon on both sides of the search field but they didn't want that left icon to actually bring down a menu they just wanted it to act like a button so you can do that now in a search field we added a bunch of new menu glist to the menu manager so you can support those if you want to Eric did a ton of work in carbon to kind of give us a lot better integration between carbon and Coco windows if you've ever tried to integrate them yourself or use system services that did the integration for you like a like the color panel or something like that you notice that some time there were some activation problems and it wasn't clear which text field focus well we did a bunch of work in that realm to clean it up and we did it by using proper window levels so there are some things we changed with respect to window levels we I think we always used to use window level 0 and now we actually use the proper window level so we can interact with the coco windows better we cover this in the H I toolbox release notes in detail urging take a look at it just in case there's any compatibility concerns there but see if there's any of this new functionality you can take advantage of with the new API as we offered we also sent out a couple new carbon events as sheets open and close i believe severide sheets open and close I'm looking for Eric Idle Sam okay oh don't worry so like I said a chai toolbox release notes are the key it goes into more detail about everything I've talked about already already as well as the stuff on this slides and even more but there's three other things I want to talk about these are sort of compatibility concern these are changes we made a tiger that may affect your ways and through our application in ways that you don't exactly anticipate right now the first change was to support resolution independent I don't know he can remember but the machine before it crashed had a bigger menu bar when I increase the scale factor well that was achieved by switching the menu manager over to using a compositing window for the menu bar now since it's a regular old compositing window this window is going to show up in the window list so if you're calling a P eyes like get window lists or get front window of class the all classes constant you're going to get the menu bar window so you've got to be prepared to expect that but better yet don't use either of those API so you don't prefer those anyway what you really want to use is active non floating window that generally gives you the frontmost document window which is what you want nine times out of ten anyway another change we made is we brought the user pain control sort of up into the HIV space so at least it can be used as a grouping view but that required a few changes one of the changes we have to make is we no longer store it's private as I say private private that stuff internal to Apple instance data in the controls data handle we found a few applications out there that access that data or at least query it and we had to do some weird workaround to make those applications continue to work so don't ever access the private data some control in fact don't ever access the private data of any control you're not in charge of writing it's a bad idea and don't even direct it now the third change which is something we haven't made yet but it's something we're going to do by the time Tiger ships there are some api's like event avail still down and wait math wait mouse up that currently flush window buffers meaning you could do some drawing in a window and then you could call event avail and that drawing will be flushed to the screen right away that's kind of convenient but it killed performance in many ways a lot of people use event avail are still down it's part of a very tight track mouth tracking loop and so any painting that happens is either a visual inconvenience because they didn't want it to happen or it just slowed down that tracking live which is kind of crummy so by the time Tiger ships we're going to make changes to those three AP is such that they no longer automatically flush window buffers with the big parentheses which is only for applications linked on tiger and later right so if you built your application on Panther and you run it on tiger those three api's are still going to flush the way they always have only if you link on tiger and then run on tiger will those api's change behavior so if you find some situations where suddenly wait my window is not drawing i'm expecting it's your all what's going on it's probably because of this change was to see if you rebuilt for tiger and you know surely that's going to be what's going on so if you really depend on this behavior what i suggest doing it's fine those tracking links where you depend on the behavior and make manual calls to QT flush port buffer something like that and that will get the flushing behavior back but maybe a better solution is to stop doing your own tracking loops in those places where it is a tracking loop and instead switch to an api like traffic track mouse location location excuse me which does flush because it's documented to flush so what I want you guys to go do now let me get up right now because i need to do tend the next session install the feed take a look at the toolbox release notes start looking at the new things we've added start playing with HIV you if you haven't already try switching on compositing mode and the standard handlers for some of your windows you may actually find out that it's a lot easier to adopt this stuff than you may have thought then take a look at the resolution independence release notes there's a lot of cool info in there they're really fun to play with I mean even if you don't start developing for it right away turn it on when application see what looks good see what doesn't look good and start making with some things you might need from us from the toolbox and then you know maybe start fiddling with it in your app and you know see if you can't make it work it might actually end up being easier than you thought particularly if you've adopted a chive you also start looking at supporting accessibility you know if you're if you're supporting a chive you it's just a tiny additional little step to support accessibility if you're in there and you're modifying your nibs hey you know by all by all means when we get support and I be for adding extra attributes to widgets sorry extra accessibility attributes to widgets start selling that information in there it's only going to do good and then take a look at all the other Tiger features that we've added and see what you can do to make your application look great so we've got a bunch of information out there on the web and in the release notes the top item here this upgrading to the macro shi toolbox is one of the featured articles on the developer apple com website it's really really good it's a great article covers all kinds of aspects of H I do HIV UNH I tool box a little bit of older documentation is introducing HIV takes you through some of the basics if you need a little refresher course go check that out we have the reference material for a chai shape it's going to be critical to start using a chai shape once you become a chive you because it's going to break various quick trial limitations and finally the release notes that I say release enough enough so now I'd like to bring Xavi a backup and the rest of the toolbox crew we can go through some shooting you