30 Apr 2012 3:02 PM #1
GXT 3.0 Theme Viewer
That would be extremely helpful when developing themes.
10 May 2012 10:01 AM #2
Thanks for the suggestion - we're working through some ideas on how to make building themes easier and we'll probably start with a page like that.
22 May 2012 2:02 AM #3
ThemeSelector in EXT-GWT 2.2.5
Hello, I'm also looking for a theme viewer, I noticed that a ThemeSelector class exits in EXT-GWT and we don't have the same in GXT 3.0
thank you in advance
7 Sep 2012 5:15 AM #4
a theme changer like the one in extjs is a must for an client API like GXT. I was very surprised this is not available yet as I'm migrating from EXT-GWT which is pretty old but still had that feature... I hope this is one of your priorities for th next release...
11 Sep 2012 10:39 PM #5
Right, theme viewer would be really for GXT...
12 Sep 2012 5:20 AM #6
Not being able to change the theme dynamically it's a major drawback for a client API....i really don't get how Sencha decided something like this...from what I've noticed things were "normal" in GXT 2...
Any chance to add this feature in the next release?
18 Sep 2012 2:52 PM #7
A runtime theme selector means that all css must be built to assume it will be removed later on - while this can make an application easily skinnable while it is running, we haven't found this to be a terribly common use case.
We didn't give up this feature for no good reason either - by leaving this out, our CSS selectors become simpler, and less CSS must be loaded into the page for it to work correctly. Both of these lead to better performance - each extra rule or complexity in each rule means that the page takes longer to update each time something changes. We've used GWT's ClientBundle and CssResource to ensure that our CSS class names never collide, which eliminates the need to namespace class names, and to ensure that CSS isn't loaded into the page before it is used, allowing the page to load more efficiently. Additionally, there is no need to load one full set of CSS and images, then to activate the theme and load yet another set.
That said, it is still certainly possible to devise a page that can switch between themes! The GXT Explorer has a module file that uses the default Blue theme, looking something like this (simplified slightly):
<module rename-to='explorer'> <inherits name='com.sencha.gxt.ui.GXT' /> <inherits name='com.google.gwt.activity.Activity' /> <inherits name='com.google.gwt.place.Place' /> <inherits name="com.google.gwt.inject.Inject" /> <inherits name='com.sencha.gxt.chart.Chart' /> <inherits name="com.sencha.gwt.uibinder.UiBinder" /> <!-- Specify the paths for translatable code --> <source path='client' /> <source path='shared' /> <!-- GZip the output files by default --> <inherits name='com.google.gwt.precompress.Precompress' /> <entry-point class='com.sencha.gxt.explorer.client.Explorer' /> </module>
<module rename-to='explorerGray'> <inherits name='com.sencha.gxt.explorer.Explorer'/> <inherits name='com.sencha.gxt.theme.gray.Gray'/> </module>
19 Sep 2012 2:26 AM #8
First of all thank you for sharing this solution.
If i got it right you are basically saying we should use multiple entry points for our gwt app and switch between them...? I guess this might work for a simple/small app, but I'm not sure how this will work for a more complex app, e.g. where users have to authenticate (on a login page) and only after would they reach the main app where one function would be to change the theme. If we would implement the way you're suggesting we would have to start fresh (new login) whenever a user changes a theme and also find a way to remember his theme choice before he logins (?).... so not really an option in our case.
We're now working on changing the Appearance pattern so it won't use CssResource. This way we will be able to change app style dynamically - see this thread: http://www.sencha.com/forum/showthre...me-dynamically
We are making progress but it's lot of work involved. So I still think that not having a way to change the theme dynamically was a bad call when all things considered. You were mentioning performance issues but we had this working just fine in GWT-EXT. I agree that using CssResource and ClientBundle is more efficient but then again, when I compare pros and cons from my point of view not having this feature, themeChanger, (or a way to easily implement) is still a miss.
Don't get me wrong. We do like GXT and I still think it was a good choice for us but in a perfect world having a way to change the theme it's a must from my point of view.
24 Sep 2012 11:15 AM #9
There is one more thing you need to consider when really changing the theme at runtime:
It will only work when you only change the colors. Once the new theme changes some paddings/borders, you need to force all components on the screen to recalculate their sizes.
24 Sep 2012 4:13 PM #10
If the ability to change the theme of an app while it is running outweighs the maintenance and performance benefits of ClientBundle, then I think you have made the right decision of building non-ClientBundle based appearances - it will be difficult, but on the plus side you'll be able to chance any styles without recompiling or reloading, assuming, as Sven pointed out, that your other themes don't do any resizing.
There is no need to make a new entrypoint - look at the explorerGray module. All it does is say "Load the Explorer module, and then apply Gray" - nowhere do we define new entrypoints or other classes. If your app makes use of any kind of a session (probably via cookies) then the app can cleanly be reloaded and keep the user logged in while a different .nocache.js file is selected.