The content of the dialog can be entirely controlled by the developer, so the same restrictions apply.
On Sun, Feb 15, 2009 at 6:19 PM, Nick <[email protected]> wrote: > > Thanks for the quick responses. I have just one more related > question. Do the same restrictions (dark background with light text) > apply to the Dialog theme since the dialog is merely a frame around > whatever content the user decides to display? > > Here it seems ok to let the frame change to be light background with > dark text since it doesn't affect a developer's content. > > Thanks, > Nick > > On Feb 14, 5:35 pm, Dianne Hackborn <[email protected]> wrote: >> Runtime skinning is a whole other issue, which we would certainly like to do >> but requires some work in the resource system (a fair amount of >> infrastructure is in place, but there are some missing pieces) and for a >> production quality solution requires figuring out how this interacts with >> zygote, which pre-loads key system resources at boot time to optimize app >> process initialization. >> >> And even so, if an application uses the theme with a dark background, you >> can't skin that to a light background and expect reasonable compatibility >> with existing apps. >> >> The widgets already work with either light or dark backgrounds, since they >> retrieve all of their display information from whatever Theme they are >> instantiated with. >> >> The apps as I said will probably need some customization to work with a >> different type of background. Even ignoring that, many of them have their >> own custom images that you will probably need to modify anyway to really >> have something that consistently matches with your new UI design. >> >> >> >> On Sat, Feb 14, 2009 at 3:26 PM, Nick <[email protected]> wrote: >> >> > No, I don't want to make 3rd party apps consistent (that's not the >> > goal). If they don't care and used the default, then it seemed >> > reasonable to let it change. >> >> > The heart of the idea was to simplify the system applications and >> > widgets since I want to re-skin all of Android to this new Theme. I >> > was trying to take the approach of having different system themes that >> > the user can select much like changing the theme on your desktop. I >> > know this is a major task so that's why I wanted to know the >> > ramifications before proceeding further. >> >> > On Feb 14, 3:05 pm, Dianne Hackborn <[email protected]> wrote: >> > > Yes this will break things. This is why they are defined the way they >> > are >> > > -- when you use Theme you are promised to be sitting on top of some dark >> > > background, and Theme.Light to be on top of some light background. You >> > just >> > > can't change this basic assumption without breaking applications. >> >> > > If you want to change the look of the standard apps to this extent, you >> > will >> > > need to go and modify them. Note this could very well require doing more >> > > than changing the theme they use, because there are likely some custom >> > > graphics and colors that will no longer work in the new environment. >> >> > > And trying to make third party apps consistent? That's a losing battle, >> > > don't even try. Third party apps get to do what they want. >> >> > > On Sat, Feb 14, 2009 at 8:39 AM, Nick <[email protected]> wrote: >> >> > > > The only assumption with the default theme in the SDK is that light >> > > > text on a dark background. However, will an OEM jeopardize being >> > > > Android compatible if they change the default theme to be dark text on >> > > > a light background? >> >> > > > The reason for this is that I don't want all the built-in applications >> > > > to have to specify some custom theme since it's easier to just change >> > > > the default theme. Also, I would like those 3rd party applications >> > > > that use the default theme to change as well so there is consistency >> > > > throughout the device. >> >> > > -- >> > > Dianne Hackborn >> > > Android framework engineer >> > > [email protected] >> >> > > Note: please don't send private questions to me, as I don't have time to >> > > provide private support. All such questions should be posted on public >> > > forums, where I and others can see and answer them. >> >> -- >> Dianne Hackborn >> Android framework engineer >> [email protected] >> >> Note: please don't send private questions to me, as I don't have time to >> provide private support. All such questions should be posted on public >> forums, where I and others can see and answer them. > > > -- Romain Guy Android framework engineer [email protected] Note: please don't send private questions to me, as I don't have time to provide private support. All such questions should be posted on public forums, where I and others can see and answer them --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "android-framework" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-framework?hl=en -~----------~----~----~----~------~----~------~--~---
