Thanks for your feedback! I agree entering codes manually should be an option and will be an option in the next beta release.

PR #1538 adds a manual color string editor. Will be included in the next beta release 0.3.14-beta10

that would be great actually

Yup something I forgot to add. Will be an option in beta10.

PR #1538 adds the ability to customize the color of the glide trail (aka gesture trail). Will be included in the next beta release 0.3.14-beta10

Yup I somehow didn't think of that. In the next beta release you will be able to enter codes manually as well.

PR #1538 adds a manual color string editor. Will be included in the next beta release 0.3.14-beta10

I have now reworked them default themes quite a bit in terms of variables usage and came to the following results:

• --on-primary and --on-secondary have been removed, but would still be translated if manually re-added by a user (if someone wants to implement these Material Design colors in their own theme)
• Added --on-surface-variant. Color usages slightly differentiate from your theme, but in general I halved the remaining fixed colors and improved/corrected color variable usage.
• Added --shape and --shape-variant. The former is for keys, key popups and Smartbar keys, the latter for all rounded stuff in clipboard history. The Smartbar clip candidate has its own directly defined shape, this will not change in the default theme.
• Added generic circle() shape, which replaces all `rounded-corner(50%,...) shapes.

Other changes thus far based on your feedback:

• The level selection icon has been replaced by a tune symbol, when pressing this a dialog shows up with all fine tune settings regarding editing related stuff. In here the level is choosable, as well as an option to modify color string appearance (hex vs rgba, where hex is the default now).
• Var names are now translated in basic and advanced in the secondary line within a rule set.

If you want you can try out the debug artifact (will not alter your current installation) of #1538 and give a short feedback of the changes thus far.

I'm also starting to think it could be very interesting to be able to use a slightly lightened / darkened version of variables for coloring items (thus alleviating the need for color variants), but I think I'm getting really off-scope there smile

Yes this would be quite off-scope xD. For now I am concentrating on getting the existing fixed up and also add some other theme-related properties (border, elevation, ...). But someday in the future I may be coming back on this idea.

Will try that !

(edit: not sure how, though ?)

https://github.com/florisboard/florisboard/pull/1538/checks Then Artifacts > app-debug.apk

You need to be signed in on the browser you are viewing the link else it won't work though (GitHub restriction)

LMAO

I've been searching on this page for 5 minutes and didn't see the button 😆

Custom fonts would be awesome.

Yes I also thought of something similar and I'd add another thing: some explanation of the variables. It could be a short sentence or, even better, a photo of the object the user is modifying.

A key code reference sheet is linked when pressing on add code.

@patrickgold
But in my opinion atleast basic and maybe also the advanced modes should map the keycode to the according keys. So most users actually will be able to see which key they are editing.

As additional proposal it would be neat if it would be possible to add key codes by actually pressing on the keys on the keyboard when you are in the add code menu:)

Great to hear you like the theme editor!

Edit 1: Cannot theme the following "Enable Clipboard History" button

That's true, it is currently not styleable at all

Edit 2: Also include an easy way to export a theme, right now you have to go to advance settings, export data to zip archive, select the .flux theme from the archive and then import it.

You can just click on the theme name either in the theme manage or theme select screen and then use the export button.

Tapping on the theme name does nothing, but tapping on "My Themes" or "local.themes..." brings the view up

Green brings theme export menu, red doesnt

Edit: I think it must be related to the above but the radio buttons on the "Manage installed themes" view currently serve no purpose

Well.... @patrickgold ... I think that we need to move Create theme extension and Import options to the main Theme sections instead of keeping inside Manage Installed themes, which is kinda ironic..... It took me some time to figure out how to create a new theme as the Create new theme Extension option was inside Manage Installed Themes section

Overall, I feel the new theme editor is much better... Kudos on that...

Tapping on the theme name does nothing, but tapping on "My Themes" or "local.themes..." brings the view up

My bad, I meant to tap on the extension name

I think that we need to move Create theme extension and Import options to the main Theme sections instead of keeping inside Manage Installed themes

If I do that the manage themes screen becomes totally useless, meaning I need to rethink the theme selection/import/create design. But I agree, it is confusing, so I will see with what new layout I will come up for this.

@patrickgold, maybe just rephrase "manage installed themes" to "manage and customize themes" ?

Also I agree the export button is particularly hard to find, because the extension name doesn't look like something clickable. The option should be at the top of the "edit extension" screen.

That's an interesting proposal, never heard or thought of this idea yet. From a technical side I see a problem that the UI elements pull its visual properties from a compiled stylesheet. Compiled means it is fully immutable and if I want to change the color (due to randomness) I either have to add a wonky variables system for all color property usages (which I am not a fan of) or I re-compile the stylesheet on window open (which is performance wise not ideal).

Generally this idea is cool though, so in the future I am open to try to find a solution using seeds and salts, this way I can minimize object re-allocation for color re-computation I think. This is currently low-priority for me though as there are some other more fundamental things in themes to fix atm.

You seem to have added a variable which contained invalid characters, which in turn caused this validation crash during the stylesheet json build process. I've now restricted the input and added an appropriate error message, which will be included in the hotfix release 0.3.14-beta11 today.

Yes this is my plan, because I cannot simply remove the emoji view in 0.3.14

Thanks for your feedback, really appreciate it!

PR #1569 is my current working branch and contains a lot of fixes and small improvements.

Two changes are already based on your feedback:

1. URLs without the http:// or https:// prefix now work perfectly fine, so this should not be an issue anymore.
2. Within the editor the keyboard now only auto-opens after closing dialogs when it was open before opening it. This is configurable however by clicking on the "Fine tune" symbol top-right within the editor. Available options are Remember last state (default), Always show and Never show, so every user can configure this to their likings.

Multi-value fields like tags & maintainers: to me it wasn't clear that the separator for multiple values is just a new line. I first tried space and comma sweat_smile Maybe it's just me, but it might be helpful to add a note how values are separated.

What would be the minimum sufficient note that new line is required in your opinion? I am trying to minimize the text displayed and thought maybe adding a new line symbol besides the label could work, but not sure if everyone thinks of that.

In the default theme you can tap on the maintainer's name which shows an email address. I wasn't able to do this for a custom theme. While I'm not sure if this is really needed as there are options to add a homepage and issue tracker I just noticed this difference between default and custom themes and wanted to share it.

You are able to do this for custom themes as well, the doc string of extension maintainer explains the format:

I wondered why there are radio buttons for the different themes in the "manage installed themes" view. Will this be used for a feature in a future release?

Yes and no. It was actually in use in a debug version, but all public versions of that screen don't utilize the radio buttons atm. It is not yet decided if this screen even stays, because some users suggested merging the selection and managing screens into one, and I also have some ideas on how to rework the selection process for themes. Should the screen live like it does in the future I will either remove the radio buttons or give them a proper use.

One more thing I want to add: if a color for a property is set to be fully transparent, it is previewed as solid white instead.

Yes I know, this is because drawing the checkerboard is quite annoying (code and technical wise) and thus it is currently only drawn within the color picker itself. I agree that this should be added though and will address this before 0.3.14 stable.

Thanks for already considering three of the topics in beta 12. I tested all of them successfully.

multi-value fields

What would be the minimum sufficient note that new line is required in your opinion? I am trying to minimize the text displayed and thought maybe adding a new line symbol besides the label could work, but not sure if everyone thinks of that.

I agree, reducing the amount of text is a good idea. I'm not sure if a symbol behind the label would help. The shortest note in the label I could come up with would be "label (separate by new line)" or "label (separator: new line)". But honestly I don't really like the idea of adding the note to the label.

What about using a helper text for those input fields? Like this one:

Then the note would only be displayed when the field is active and one could use a proper sentence, e.g. "Use new lines to enter multiple values." / "Enter additional values on new lines.".

maintainer's email

You are able to do this for custom themes as well, the doc string of extension maintainer explains the format

Thanks for the tip. When using the correct format it did work.

can someone please tell me from where I can change the color of specific button like spacebar?

One idea: Maybe there could be a custom URL scheme (e.g. fbtheme://) that the app could then intercept and display in a kind of preview activity with an import button. Or, to take this even further, a website instead of a scheme that, when opened in the browser (at which point we can assume that FlorisBoard isn't installed), displays a preview and download buttons for both FlorisBoard and the theme itself. (I could work on the web part if desired.)

That's the ultimate goal for the community repo, having the theme store as a web site and then make the installation process as easy as possible. As FlorisBoard probably won't have Internet permission this means I need to let the browser do the downloading part, then when the user clicks on open the file is opened within FlorisBoard and ready for install. Lots of ideas but absolutely nothing sure yet, there are still a lot of other things (including word suggestions to fix first.

can someone please tell me from where I can change the color of specific button like spacebar?

Add a background attribute to a key rule with the code 32. If you copied from the default themes, then this rule will already exist.

Yes this is a LineageOS only. Hard to integrate such a niche case into the theme system, but maybe with dynamic Material You added in the future there is the necessary API to include this ROM-dependent functionality as well.

Thanks for your detailed feedback! WIll now try to respond to some of the most important points you talk about.

Have more preinstalled themes. Borderless, different shapes, etc. So that users choose the template they like the most and just change the colors to their liking.

This is true and in 0.3.13 there where more themes. See #1702, I will soon re-add additional core themes for selection, with this also borderless themes.

I also believe it would be very useful for "basic" users to have the name of the keys that are being edited be displayed instead of codes. So have Space bar, Enter button, A-Z, Numbers, etc.

0.3.15-beta02 fixed this issue, the preview of the key and the key name+type is shown above the code now. Additionally you can record a key press within the code dialog so you don't need to manually write the code anymore. Is part of 0.3.15-beta02 and will soon be in 0.3.15 stable.

To me the steps to create a new theme was very confusing. Things like "Create Theme Extension" seemed very unfriendly to me.

To an extend I agree but I haven't really found a better UI for this yet, especially because creating a theme without an extension is impossible, so the first step is the extension container (one extension can then house multiple themes however).

Just saw your reply in Discussion 1635, guess I will have to wait until it is included in the next stable.

You can export in the current stable, either by using the backup tool or by clicking on the extension name. I just need to make it more discoverable but it is already implemented in 0.3.14.

I would like to be able to edit the height of the space bar and the enter button. I was unable to do it in the advanced mode (can this be done?).

Nope individual key height adjustment is not available atm, maybe I can add it, not sure yet when and how though.

Latest stable release 0.3.15 has borderless themes included again :)

Okay thanks!

See #1781