True black theme about dawn

[ThePreviousOne]

also its using DayNight theme so it can change with system theme but its locked to day theme right now I'll set that up in the menu

[ThePreviousOne]

I'm willing to give this a shot, but this is going to be A Lot of work.

I saw the issue and thought "new theme... Ha give me 10 minutes" but then I forked the code. I wrote a new theme and applied it but this app makes such heavy use of color nothing changed. I found 270 unique @color references in the xml and then there is all the hardcoded R.color references, I hate to say this (espesially to someone how is clearly a better programmer than me) but this code is a mess.

Anyway I'm posting this to ask first because if you don't like the way I plan to do this then I'd just be wasting my time.

Most colors need to be defined as attributes, so the colors can be set per theme. Then to use those in place of R.color calls there needs to be a function to look them up via R.attr so they can change too.
I plan to rename all the colors to actual color names rather than where they appear, and change some attribute name so there arent any duplicates linking to the same color. (ie. @color/windowBackground)
Lastly I want to use white borders to break up entries from one another and around windows, like above and below threads/comments and around the login window. I'm not sure I know how to do that part, at least not for a single theme.

[Tunous]

Sounds like a nice idea which could be done in incremental steps.

I didn't look into the colors too closely myself so I'm not 100% aware of how many unique colors there are (I'm not the original developer) but it would be a very good idea to (as a first step) try and reduce their amount . The less we have of them the easier it will be to add more themes.

After that we can look into introducing attributes and changing the usage to them, introducing light version and doing the other stuff you mentioned.

[ThePreviousOne]

Butterknife doesn't support BindAttr so I was going to use
if (themeid == R.style.theme) { color = R.color.color } else if (themeId == R.style.otherTheme) { color = R.color.otherColor }
And get the themeId like this
Class<?> wrapper = Context.class; Method method = wrapper.getMethod("getThemeResId"); method.setAccessible(true); themeId = (Integer) method.invoke(c);
elsewhere
but I can't call getResource() in Adapter Classes (also I can call it in Constructor Classes but I have my doubts as to whether it will run)

any Ideas

all I can come up with is set the colors at startup and make them global. Its just a few integers so it should by fine but I don't as a general rule use globals unless absolutely necessary.

[Tunous]

What are you trying to achieve here? To get a color from attribute you can use the obtainStyledAttributes method of Context.

@ColorInt
fun resolveColor(context: Context, @AttrRes styledAttributeId: Int): Int {
    val typedArray = context.obtainStyledAttributes(intArrayOf(styledAttributeId))
    val color = typedArray.getColor(0, 0)
    typedArray.recycle()
    return color
}

[ThePreviousOne]

but there isnt always a context available
anyway broke a bunch of stuff, starting over maybe 4th times the charm

[ThePreviousOne]

Edit:
Nevermind

[ThePreviousOne]

I rebased onto Tunous/master which apparently closed the PR. So I'll update you here until its done, because I'm going to use git rebase -i to remove the .gitignore commit when I'm finished.

WIP branch here

Oh and I want to do a Popup Menu thing for Theme Switching like the one for Typeface, Not really sure how yet though.

[ThePreviousOne]

WIP branch

I have been working on setting up preferences for the past few days and am stuck can you take a look at this please

[Tunous]

What is the thing that you are stuck on?

[ThePreviousOne]

I have 2 preferences set_theme and night_mode I want to set them in ThemePreferencePopup.handleAction()
I added @Provider's to UserPreferenceModule and ThemePreferencePopup to RootComponent but error: Dagger does not support injection into private fields on build whether or not they are actually private.

Also need to check them in Activity.onResume() but I'll deal with that after if its a problem

[ThePreviousOne]

Oh and I was wondering in my ThemePreferencePopup I used an interface for Option is there any reason not to use this approach over @AutoValue on an abstract class like in MultiOptionPreferencePopup

while im at it here is links to the other classes I mentioned
RootComponent
UserPreferenceModule

[Tunous]

I've looked at your code and here are some suggestions:

https://github.com/ThePreviousOne/Dawn/blob/TrueDark/app/src/main/java/me/saket/dank/di/UserPreferencesModule.java#L131

Avoid using R.style.xxx constants here. They can change between app compilations. Instead you should introduce an enum with all the possible values and use that as the type of preference.

https://github.com/ThePreviousOne/Dawn/blob/0dfad2de789758a76c4defe21fad03fe8816e92e/app/src/main/java/me/saket/dank/ui/preferences/adapter/LookAndFeelPreferencesConstructor.kt#L148

You don't need to introduce another class for the preferences popup. Once you add an enum for the themes using MultiOptionPreferencePopup becomes simple. For example:

val builder = MultiOptionPreferencePopup.builder(themePreference)
builder.addOption(Theme.Dark, "Dark", R.drawable.some_icon)
builder.addOption(Theme.Light, "Light", R.drawable.some_icon)
clickHandler.show(builder, event.itemViewHolder())

To get access to the themePreference you can add it to constructor similar to other preferences added here: https://github.com/ThePreviousOne/Dawn/blob/TrueDark/app/src/main/java/me/saket/dank/ui/preferences/adapter/LookAndFeelPreferencesConstructor.kt#L23

The only thing left would be to listen to the changes of this preference. Quick idea that came to me would be to add the preference to RootComponent and use it in DankApplication to subscribe to the changes and update what is necessary. (AppCompatDelegate.setDefaultNightMode I guess?) No idea whether that would work correctly but might be worth trying.

Also https://github.com/ThePreviousOne/Dawn/blob/TrueDark/app/src/main/java/me/saket/dank/utils/lifecycle/LifecycleOwnerActivity.java#L21 shouldn't be necessary. You can do it just once application starts and whenever user changes the preference (in observer mentioned above probably).

I used an interface for Option is there any reason not to use this approach over @autovalue on an abstract class

That's how this project implemented immutable models in Java. Now the best option would be probably to simply use data class from Kotlin.

[ThePreviousOne]

It works now, almost done, but it crashes with a Duplicate ID error when an option is pressed
Stackoverflow hasn't been very helpful on this one.

Im still using ThemePreferencePopup because I want Themes to be Automatically added to the List

[ThePreviousOne]

0001-WIP-Theme-Switcher.patch.txt

This is what I have done so far, I give up. I'll do the Black Theme when this is ready but for now I'm done.
The menu loads and the preference is properly set, but the app crashes with duplicate ID error no matter what I try.

[Tunous]

Good work so far no need to give up yet :) I’m here to help.

I’ll try to check the patch you sent tomorrow and return to you with info about what’s wrong and how to fix it. Should I base it on top of the previous branch or did you create a new one?

By the way, GitHub has an option to create pull requests with draft status. You don’t have to worry about the state about your changes, creating a pull request will just make it easier for us to give back feedback.

[ThePreviousOne]

It will apply cleanly yes but the WIP branch from before is where its staged currently though It doesn't have the latest commit from the PR, not that its related

[Tunous]

The problem with duplicate ID was caused by the code which was setting adapter ids for items in the preferences screen. Both sections and buttons only used the displayed text to calculate them which resulted in a duplicate, because both the new section and the new button had the same text "Theme". The fix was to also take under account the type of the item. You can see the code in the patch below.

I've also went ahead and made few additional changes on top of that:

Replaced ThemePreferencePopup with MultiOptionPreferencePopup using for loop over all the values of the theme preference. This gives the effect you desired without creating duplicate code.

Updated com.google.android.material:material library to version 1.1.0 which enables automatic theme update when calling setDefaultNightMode. With that no additional manual action is necessary.

Replaced ThemePreferences with enum and adapter for mapping. The additional code with moshi parsing is not necessary. All of that is handled by RxPreferencesEnumTypeAdapter. Note that you'll have to clear app data to be able to launch app as the preference values changed because of that change. Otherwise the app won't start

Added the theme option subscription to referenceHolders in DankApplication just to be safe that its lifecycle won't break.

Here is the patch with your and all the mentioned changes: Theme_switcher.patch.txt

Note that MODE_NIGHT_AUTO is deprecated so you should change to not use it.

[ThePreviousOne]

Whats this thing called?