[ALOY-378] Widget themes
GitHub Issue | n/a |
---|---|
Type | New Feature |
Priority | Medium |
Status | Closed |
Resolution | Fixed |
Resolution Date | 2014-05-02T00:06:06.000+0000 |
Affected Version/s | n/a |
Fix Version/s | Alloy 1.4.0 |
Components | Runtime, Widgets, XML |
Labels | notable, qe-testadded |
Reporter | Tony Lukasavage |
Assignee | Tim Poulsen |
Created | 2012-11-13T15:44:44.000+0000 |
Updated | 2014-05-29T05:02:20.000+0000 |
I want this ;) It could be as easy as:
It would be slightly more complex, as themes will not just overwrite styles, but will instead merge with them. This will prevent a developer from having to rewrite a whole style file in order to theme it. You can just change as many or as few characteristics of the style as you like.
@Tony I get that, but I assume you have the logic for merging TSS already in place so I just meant 'easy' as in 'same story, other paths'. And concerning theming a widget's view; that you can't merge obviously and should just overwrite, like assets.
Mmmm, maybe I know how to make it more difficult :) I'm using Alloy widgets for small UI components like pull-to-refresh. I use these on multiple places within the same app. Now, if I want to theme e.g. the pullToRefresh widget in different ways for different places it's being used in, the solution I proposed isn't sufficient. Maybe we can add an optional subfolder structure, named after the controller the widget is used in:
Does this make any sense?
+1 on this request. I've got a widget (custom tab group) and need to easily change the design based on themes.
A workaround can be found at: https://github.com/FokkeZB/Alloy-Theming-Widgets
Out of curiousity, how dynamic is dynamic? Is there any possibility that this restyling feature is something that can be done at compile time (if not now, but in the future)?
Blain, that's essentially how it will take place initially. Later once dynamic styling is incorporated we'll build in a means to make this change at runtime.
This is something that would really help me automate a few things that always need manual changes or poorly used syntax/location of resolution. Hoping this becomes a priority.
PR: https://github.com/appcelerator/alloy/pull/365 Functional test 1. Run the ALOY 378 test app included in the PR. It uses a theme, which is applied to the tableview and starrating widget. 2. Confirm that the theme was applied correctly: * On all platforms: ** Labels in the tableview will be red, rows will be 50dp high (set via the theme using existing theming functionality) ** In the widget, the star on, off, and half images used by the widget will be replaced with a plus, minus, and empty-circle set of images ** star images are distorted by having a height and width applied from the theme * On iOS: ** the half-star image used by the widget will be replaced by an Appcelerator logo ** star images will have a yellow background color applied
PR merged
From the QE: "non-platform-specific assets from a theme should not overwrite those from a widget's platform-specific folders." Reopening to update asset priorities.
New PR: https://github.com/appcelerator/alloy/pull/381 I've updated the https://github.com/appcelerator/alloy/tree/master/test/apps/testing/ALOY-378 test app to include the platform-specific asset within the widget. Functional test: build the app, the star.png asset (a star) from the widget's platform (ios) folder should overwrite the star.png (a plus-sign) from the theme.
Verified fixed and working as expected with the PR https://github.com/appcelerator/alloy/pull/381 TiSDK 3.3.0.v20140430151716 Alloy 1.4.0-dev Appcelerator Studio 3.3.0.201404301307 CLI 3.3.0-dev Closing.