Solution to Dark mode and limited design ability for settings app and new keyboard (honeyboard)

Ok so there have been a few things that are driving me absolutely insane and both are something that should be easily implemented. I say that because you are Samsung and you have some talented people around!

The first issue is dark mode and dark themes. So for those that may not know why these two simply don’t play well together, this is a matter of how theme editor builds the overlay apks. Inside them all are several folders. For example drawable-xxhdpi-v4, drawable-night-xxhdpi-v4 / values-xxhdpi-v4, values-night-xxhdpi-v4.
When we create our theme our images and hex choices are created and with the exception of .9.png’s they’ll be compressed into qmg which Samsung’s been using for about 10 years. They compress bitmap images really well but the issue is that these images are only being added the the standard (or non-night if you will) folders. The night folders are still being generated, but they contain the stock images and stock xmls. This is what the actual issue is and is why our themes look like garbage when someone uses them and turns on night mode.

All they need to do to correct this is do one of two things. Either reverse this for dark themes so that our themed elements are created as the “night-xxhdpi-v4” folders and have the stock images in the non night folders, or have our elements touch all folders. This make no sense why this has not happened yet.

Here are some of the main issues with the current setup:

First it is cheating customers from getting a full theme experience that they’ve paid for. I’m sorry but to expect users to have to turn off night mode and sacrifice so many other things ie: google apps is not acceptable.
Secondly it causes confusion to customers who are using night mode already and then apply a theme only to find out the theme does not match any of the screenshots we have advertised. This creates a lack of trust among users as they do feel it’s a type of false advertising which it is. As designers we are not in control over these things and it causes users to not only rate themes poorly but dissuades them from purchasing from us in the future or from anyone for that matter.

Another factor is that by placing the stock images and xmls in the night folders (the current setup) it doubles the size of the themes causing a lot of wasted space. Most overlay apks have anywhere between 140-160 images be it .9.png or .qmg files and this is completely unnecessary. Since the current theme system is based on the runtime resource overlay system which was commited in android lollipop stock images and xmls are not even needed in any theme. Android will by default show the stock images if no themed elements are present so this just makes no sense why they’re even included. It just adds bloat!

So please change the configurations and have our themed elements for dark themes present in the night folders!

The second thing that drives me crazy is the limitations of some apps like settings for example. Currently we are limited to changing 4 hex colors of the icons. I am requesting the ability to change the actual icons themselves (21 in total). The can be changed in a couple of different ways. But really allowing png would be ideal as the colors.xml can be overwritten by a simple png. For example the first icon is “Connections”. This is located in the drawable folder as a vector xml "sec_ic_settings_connections.xml. This is then further tinted via redirect to the colors.xml with the color title: “@color/sec_dashboard_connections_color”. Due to it being coded this way (and every single icon is) this allows for a replacement of the drawable xml with a simple png or if we wanted we could write a vector and do it that way and note the color attribute within the xml instead of redirecting to colors.xml. it is proven to work 100% by doing it this method so why not give designers the choice to either tint each icon individually which would utilize the colors.xml or to replace it with a png image which would overwrite the colors.xml. The amount of creativity that is currently being stifled is crazy!

Next let’s move onto the new keyboard aka the honeyboard!

Currently we can only change the colors of this and no longer can we add png or .9.pngs for it. I understand why which is because now it is using a layer-list.xml for the main key background (key_bg.xml in drawable folder).
This layer-list points to two seperate ids in each item of the layer-list. Which means you cannot replace the xml with a .9.png or the overlay would crash. So what can be done is to allow us to have drawable xml support and subsequently we can keep the exisiting two items of the layer-list intact but below it we can essentially cover it up using our own additional “items”.

For example: <?xml version="1.0" encoding="utf-8"?> <layer-list xmlns:android="http://schemas.android.com/apk/res/android"> <item android:id="@id/key_background_stroke" android:left="500.0dip" android:top="500.0dip" android:right="500.0dip" android:bottom="500.0dip"> <shape android:shape="rectangle"> <corners android:radius="40.0dip" /> <solid android:color="#4285f4" /> </shape> </item> <item android:id="@id/key_background" android:left="500.0dip" android:top="500.0dip" android:right="500.0dip" android:bottom="500.0dip"> <shape android:shape="rectangle" android:tint="@null"> <corners android:radius="30.0dip" /> <gradient android:startColor="#000" android:centerColor="#1a1a1a" android:endColor="#404040" android:angle="90.0" android:tileMode="repeat"/> </shape> </item> <item android:left=".0dip" android:top=".0dip" android:right=".0dip" android:bottom="0.0dip"> <shape android:shape="rectangle" android:tint="@null"> <corners android:radius="10.0dip" /> <gradient android:startColor="#006fff" android:centerColor="#4285f4" android:endColor="#00ffff" android:angle="90.0" android:tileMode="repeat"/> </shape> </item> <item android:left="2.0dip" android:top="2.0dip" android:right="2.0dip" android:bottom="2.0dip"> <shape android:shape="rectangle" android:tint="@null"> <corners android:radius="10.0dip" /> <gradient android:startColor="#000" android:centerColor="#1a1a1a" android:endColor="#404040" android:angle="90.0" android:tileMode="repeat"/> </shape> </item> </layer-list> would create this right here:

So it would be great if drawable support could be looked into. Now I don’t expect Samsung to teach people how to write these as we don’t expect them to teach us (designers) how to make images and icons. That’s something they need to learn on their own but it would be nice to have the support for it for those who want to make more advanced themes.

Thanks for taking the time to read this! I’d love to further discuss this with anyone who will listen!

1 Like

I agree with you that the possibilities for design have been severely limited recently, from which themes differ only in three pictures from each other. I would venture to point out the approach to design at Hu…i, where in the editor there are two options for designing a thematic design, the maximum (almost all elements of the theme) and the minimum.

Fully agree, but the problem is the Theme Framework based on Android 5.0 ^^.

No that’s not why. It’s exactly what I said it is. Go ahead and decompile any overlay app and see for yourself. The night folders in our themes contain the stock images and stock xmls. All Samsung needs to do is have our themed elements be amended to the night folders and our themes will work on night mode. It is as simple as that.

Although you are correct about the 5.0 rro which is still present in aosp alongside the newer oms (overlay management system) . Sony actually committed the rro code and LG also uses it given it works perfectly, there’s not really a need to change from it.

I know. The night mode default files are stored in dark_theme folder in installation folder of the tool.

Yes, it can be really simple that our themes work in Dark Mode too, but there Theme Policy forbidden it. Don’t know why??? These choice was bad. It will be better when a Dark Theme from us works in Dark Mode and Light Theme in Day Mode.

Well we need to make some noise about this. It’s completely unacceptable. This needs to be fixed

YES… I agreed with you that the new Honeyboard is VERY limited in design comparing with Gboard. For example, Honeyboard should let us to choose the Fonts we like also.