Will someone please give an example of setting the color of a button to a specific color such as yellow?
Thanks, AN On Feb 21, 2:41 pm, "Romain Guy" <[EMAIL PROTECTED]> wrote: > Hi, > > All the widgets graphics are loaded as Drawable. As it turns out, a Drawable > expose a method called setColorFilter(). This method can be used to colorize > drawables with the color you want. For instance, take a look at > LightingColorFilter and ColorMatrixFilter. > > > > On Thu, Feb 21, 2008 at 11:35 AM, aetmos <[EMAIL PROTECTED]> wrote: > > > Hackbod, > > > Thank you for this detailed answer. I think it's *very* important to > > realize that application developers will want to be able to make a > > custom UI, even if it means creating a number of new button graphics. > > Especially since you've chosen such a brightly colored highlight for > > the default UI. For instance, the application I'm designing is mostly > > blue and gray with red highlights, to match our web site. The > > background of our app is blue, and the default bright orange button > > highlights look absolutely terrible. Especially the spinner graphics. > > To get around this, I've made my own button and spinner graphics that > > are the exact same size as the ones provided in android.jar, but match > > the color scheme of our UI. > > > It took me quite some time to figure out how to substitute these > > images, since it's not really documented very well, but now that I > > know how, I don't see any reason why developers shouldn't be able to > > swap out the graphics with graphics of the same size and shape that > > match their UI design. > > > Thanks, > > Tom > > > 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 background theme is 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 to modify the 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 > > > (the theme), 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 to modify the > > > 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. > > -- > Romain Guywww.curious-creature.org --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
