Thank you for clarifying. We were going to create custom button images for all of the buttons but it seems like you're recommending that we don't do that? We just want to make sure that an application won't be penalized for using the standard button widgets with the orange background?
Thank you, AN On Feb 21, 12:01 pm, hackbod <[EMAIL PROTECTED]> wrote: > On Feb 21, 8:57 am, aetmos <[EMAIL PROTECTED]> wrote: > > > Yeah, that's what I was trying to say above. It would be nice if there > > were a global way to set highlight colors, though. Like, if the > > default buttons had a number of different colors to choose from. At > > the very least, the documentation should really make it more clear how > > to swap out the images. It took me forever to figure out. > > The main mechanism we have for an application to select standard > appearances is themes, basically letting you pick between a dark > background and a light background. (Though note that the current > light backgroundthemeis not yet ready for use.) > > There is an interesting balancing act we need to play with the > standard appearance, because we expect that manufacturers of > individual devices will want tomodifythe look of the UI to some > degree to match their hardware (either just the appearance, or things > like you saw with M5 where the size of widgets is modified to account > for whether or not there is a touch screen), and we also in the future > want to support user-installed skins. > > Our general approach is: > > - Applications can decide whether they want a dark or light background > (thetheme), and we guarantee that whatever appearance is in effect > will match that basic design so you can pick colors and graphics that > will work on that background. > - The device decides the exact appearance of the standard UI elements, > both how they look and their overall size, to match the design of the > hardware and how the user interacts with it. This is done by > modifying the standard system resources. During the design of these > resources, careful restrictions will need to be applied to ensure that > existing applications work well with them. > - (Eventually) third party skins can be installed tomodifythe > standard resources to provide different appearances on a device. > Skins have a lot more freedom to do wild things with the appearance, > because they are user-installed and if they cause poor interactions > with applications they can be removed. > > We realize that this kind of variation in the UI causes a lot of > complication for applications. In general, it is best to be > conservative with your application design: rely on the standard > resources for the widgets and other UI elements, so you will match the > device. As the platform evolves and devices appear, we will be > putting effort into ensuring that applications that use the standard > UI elements continue to look and run well. > > I would certainly think twice before replacing a button's graphics > with my own custom one. If the thing you are doing is not really a > button nor intended to look anything like a button, then this is > fine. If it is still supposed to be a button, however, then do keep > in mind that the way buttons look is going to change (don't expect > what we have right now to be the look that ships in a device), and > vary across devices, so it is very unlikely your own graphics are > going to match other buttons the user sees. > > Also, if you are doing your own widget graphics, then you are > eventually going to need to deal with multiple device configurations. > At this point I would suggest focusing on the current M5 configuration > -- a device with a touch screen -- and thus design the graphics > accordingly to be large and touchable like the M5 design. At some > point in the future, however, you will probably need to make > additional graphics for other configurations like the old "QVGA non- > touchable" UI we had in M3. > > Again, we will be helping application developers as the platform moves > to different hardware configurations. I realize that right now > without any hardware it is difficult to visualize what you are > actually designing for. It is a safe assumption, however, that the M5 > UI is designed to work on the kind of hardware that will initially be > shipping, so you would be best off to take it has a guide (and don't > worry about the particular look), rather than working against what is > there and doing your own thing. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] Announcing the new M5 SDK! http://android-developers.blogspot.com/2008/02/android-sdk-m5-rc14-now-available.html For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~----------~----~----~----~------~----~------~--~---
