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

Bringing windows platform more in line with more complete win32 impl #3744

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

acoates-ms
Copy link
Contributor

This change introduces our first .officewin file. The idea of the .officewin extension is to allow us to continue to use our theme fragments that are picked up by the bundler, but allow two themes for the windows platform. By default the windows platform should provide a windows fluent theme. But for office we want the default theme to have various officeisms. We will do that by having custom resolution logic when building against the windows platform within office. (Office will resolve *.officewin, *.windows, *.native for FURN packages when building against the windows platform.

Currently the only difference between the Windows theme and Office's theme for the .windows platform is that we override the default button size to be small within Office. But I expect that to expand as we dig into the details of the theming differences between Office and Windows.

Mostly this change unifies some theming of Button/Checkbox by sharing definitions of various parts of the theme between win32 and windows (by moving the win32 implementation to windows). The win32 definitions are more complete and more tested than the current windows ones. Over time as we work out that parts of those themes are more Office specific, we could move those parts of the definitions to .officewin files.

@acoates-ms acoates-ms requested a review from a team as a code owner September 10, 2024 22:50
@Dewsk
Copy link
Collaborator

Dewsk commented Sep 24, 2024

@rurikoaraki and @PPatBoyd - any concerns here? Will review as well but this one should have a couple sets of eyes.

@rurikoaraki
Copy link
Collaborator

@rurikoaraki and @PPatBoyd - any concerns here? Will review as well but this one should have a couple sets of eyes.

Will make time to review today

@@ -33,7 +33,6 @@ export const defaultToggleButtonColorTokens: TokenSettings<ToggleButtonTokens, T
const highContrastColors = {
checked: {
backgroundColor: PlatformColor('SystemColorHighlightColor'),
borderColor: PlatformColor('SystemColorHighlightColor'),
Copy link
Collaborator

@rurikoaraki rurikoaraki Sep 24, 2024

Choose a reason for hiding this comment

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

Was this change to the border intended? #Resolved

Copy link
Collaborator

Choose a reason for hiding this comment

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

I see, it's to align with win32

@@ -76,7 +76,8 @@ export const useButton = (props: ButtonProps): ButtonInfo => {
const hasTogglePattern = props.accessibilityActions && !!props.accessibilityActions.find((action) => action.name === 'Toggle');

const theme = useFluentTheme();
const shouldUseTwoToneFocusBorder = Platform.OS === ('win32' as any) && props.appearance === 'primary' && !isHighContrast(theme);
const shouldUseTwoToneFocusBorder =
Copy link
Collaborator

Choose a reason for hiding this comment

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

const shouldUseTwoToneFocusBorder =

At the moment, this is an Officeism. Potentially this will come later to windows but I don't think the windows platform does this today.

Copy link
Collaborator

@rurikoaraki rurikoaraki Sep 24, 2024

Choose a reason for hiding this comment

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

This also applies to the focusInnerBorder component on Button, ToggleButton


export const defaultCompoundButtonTokens: TokenSettings<CompoundButtonTokens, Theme> = (theme: Theme): CompoundButtonTokens => ({
medium: {
padding: globalTokens.size120 - globalTokens.stroke.width10,
Copy link
Collaborator

Choose a reason for hiding this comment

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

globalTokens.size120 - globalTokens.stroke.width10,

I wonder if this will be needed on windows... we end up having to subtract the width of the border of the button to figure out the padding on win32 because when Views are bound by minHeight/Width instead of just height/width, the border adds to the height of the button so it ends up being bigger than intended (and sometimes causing size changes on focus). This (seemingly?) doesn't happen on web, so I wonder if windows has this problem or not

Copy link
Collaborator

Choose a reason for hiding this comment

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

(and we need minHeight for handling text scaling, and minWidth for just who knows how long strings are)

Copy link
Collaborator

@rurikoaraki rurikoaraki left a comment

Choose a reason for hiding this comment

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

:shipit:

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