Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open edX app theming capability improvements #173

Closed

Conversation

saeedbashir
Copy link
Contributor

@saeedbashir saeedbashir commented Nov 27, 2023

In this PR I've made the changes that will support app theming. Belowe are the changes that I made:

Multiple colors and images
I've broken down the xcassets folder of Core Framework into two: xcassets Assets and Configureable . From now on, Assets will contain all the images, icons, colors, etc that will not be configureable, like button icons, nav bar icons, bottom bar icons. Likewise, configureable assets will contain all the configureable assets.

Fonts

I've added an extra layer between the fonts and the theme class. The font names were hardcoded in the theme class, which made it a bit hard to change the fonts in a new theme. I've added a json file for key: name pair and a parser around it. Now the font change will only require the replacement of fonts JSON and font_file and there won't be any code changes.

@saeedbashir saeedbashir force-pushed the saeed/app_theme_configurable branch from f9ecbb7 to e7db1b6 Compare November 27, 2023 03:48
@saeedbashir
Copy link
Contributor Author

@rnr @volodymyr-chekyrta Please try to review this PR at your earliest convenience because it's breaking the CoreAssets into two, which most probably will result in conflicts too often.

@@ -114,7 +114,7 @@ public class CSSInjector {
<style>
a {
text-decoration: none;
color: \(CoreAssets.accentColor.color.cgColor.hexString ?? "");
color: \(Theme.Colors.accentColor.uiColor().cgColor.hexString ?? "");
}
@font-face {
font-family: "San Francisco";
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@saeedbashir font-family should be configurable too I think.
thank you

@@ -0,0 +1,89 @@
//
// Environment.swift
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@saeedbashir was this merged with latest develop? I believe this class was got rid in Config PR. Thank you

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not able to find this class in my branch. It might be showing off because of merge.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's strange because I see you merged 'develop' which has this file deleted. Did you do git merge or rebase? Thank you

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've rebased it. Sometimes I use the github web interface to resolve conflicts, and I guess that uses merge instead of rebase.

Copy link
Contributor

@rnr rnr Nov 30, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We are using 'merge' most of the time. A lot of articles say it's preferred way when big team is working. Perhaps it helps to avoid situations like this. And save more 'clear' history who/what/when did code

@volodymyr-chekyrta
Copy link
Contributor

Upon reviewing this, I have some concerns about the naming and implementation.

From your team's perspective, Configurable.xcassets may be configurable, but from this repository's standpoint, it appears as an assets catalog with a potentially misleading name.
I find the resources in Assets.xcassets to be configurable as well, adding to my confusion.
I believe this could also confuse newcomers.

It might be useful to break down the current Assets.xcassets into smaller catalogs, but I'm uncertain about this approach.

Additionally, SwiftGen generated files look a bit odd
CoreAssets.Assets.filename - Assets.Assets name duplication
CoreAssets.Configurable.filename - hard to understand which assets are located in the Configurable namespace.

Note for me: SwiftGen enum names can be fixed with a customized script that will put all resources just in CoreAssets as previously.
https://github.com/SwiftGen/SwiftGen/blob/1cf6d7eebd70c2157f69d5a991bc57c1ef182ed1/Sources/SwiftGenCLI/templates/xcassets/swift5.stencil#L132-L138

@saeedbashir @rnr wdyt?

@saeedbashir
Copy link
Contributor Author

From your team's perspective, Configurable.xcassets may be configurable, but from this repository's standpoint, it appears as an assets catalog with a potentially misleading name.

I was thinking about naming it ConfigurableAssets, but it was a long name.

I find the resources in Assets.xcassets to be configurable as well, adding to my confusion.

It would be nice if you could name them so we can also move them to the Configurable.xcassets

It might be useful to break down the current Assets.xcassets into smaller catalogs, but I'm uncertain about this approach.

This will help out in replacing the changeable / configurable assets, either manually or via script. Once someone makes a copy of their resources, it will be much easier to maintain and change the resources just before making a build with updated codebase.

Additionally, SwiftGen generated files look a bit odd
CoreAssets.Assets.filename - Assets.Assets name duplication
CoreAssets.Configurable.filename - hard to understand which assets are located in the Configurable namespace.

This is the default behavior of the SwiftGen. I'm new to SwiftGen so don't have in-depth knowledge of SwiftGen. If the enums can be removed (CoreAssets file created just like before in case of single file) this will make the codebase much cleaner. It would be nice if you could help here in writing / using the custom script to achieve above behavior.

@volodymyr-chekyrta
Copy link
Contributor

From your team's perspective, Configurable.xcassets may be configurable, but from this repository's standpoint, it appears as an assets catalog with a potentially misleading name.

I was thinking about naming it ConfigurableAssets, but it was a long name.

I find the resources in Assets.xcassets to be configurable as well, adding to my confusion.

It would be nice if you could name them so we can also move them to the Configurable.xcassets

It might be useful to break down the current Assets.xcassets into smaller catalogs, but I'm uncertain about this approach.

This will help out in replacing the changeable / configurable assets, either manually or via script. Once someone makes a copy of their resources, it will be much easier to maintain and change the resources just before making a build with updated codebase.

All resources are changeable/configurable.
Relocating it to a different catalog doesn't make sense in the context of the script.
This implementation will cause confusion for developers and increase the project onboarding time.
We cannot go for that. We have to come up with a better naming or implementation.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants