Ziriax
Topic Author
Posts: 60
Joined: 10 Dec 2015, 17:59
Location: Belgium
Contact:

1.3 BETA4: SetTheme and ResourceDictionary

07 Feb 2017, 16:22

Hi,

I have two questions related to BETA4:

- SetTheme can only be called once. Is this by design?

- ResourceDictionary cannot be created from C# code anymore. Again, is this intentionally?

Thanks,
Peter Verswyvelen
Peter Verswyvelen,
Strongly Typed Solutions
 
User avatar
sfernandez
Site Admin
Posts: 2983
Joined: 22 Dec 2011, 19:20

Re: 1.3 BETA4: SetTheme and ResourceDictionary

08 Feb 2017, 01:05

- SetTheme can only be called once. Is this by design?
It was a design decision, as we initially thought a theme should only be set at application start and not allowed to change. But this vision is not compatible with the hot reloading of resources, so we are going to change that limitation and allow calling SetTheme anytime.
- ResourceDictionary cannot be created from C# code anymore. Again, is this intentionally?
This seems like an unintentional bug. I will fix it for the next release.
 
Ziriax
Topic Author
Posts: 60
Joined: 10 Dec 2015, 17:59
Location: Belgium
Contact:

Re: 1.3 BETA4: SetTheme and ResourceDictionary

10 Feb 2017, 12:11

Nice!

But I'm not sure that calling SetTheme again will actually work as expected, since all StaticResources in all loaded XAMLs will need to be resolved again, effectively making them DynamicResources in a sense.

In that sense the old API was more rigid, where you had to pass in the main XAML and theme in one call.

So the question is, what does one expect when calling SetTheme again?

Now if ResourceDictionary can be created again, than there is no need to call SetTheme twice for my hot-reloading, I just create a proxies.
Peter Verswyvelen,
Strongly Typed Solutions
 
User avatar
sfernandez
Site Admin
Posts: 2983
Joined: 22 Dec 2011, 19:20

Re: 1.3 BETA4: SetTheme and ResourceDictionary

15 Feb 2017, 19:39

The idea was that calling SetTheme will provide a new theme for the xamls loaded from that point.
Previous xamls will be still using old resources.
 
Ziriax
Topic Author
Posts: 60
Joined: 10 Dec 2015, 17:59
Location: Belgium
Contact:

Re: 1.3 BETA4: SetTheme and ResourceDictionary

15 Feb 2017, 19:44

Sounds reasonable.

Can one use StaticResource to access resources from this global theme?

And when replacing the theme, this will replace existing resources with the same keys?

That sounds very useful for reloading, right now I have to use DynamicResource everywhere

One thing I find anyoing (also in WPF), is that one cannot use StaticResource inside a ResourceDictionary to refer to resources in another ResourceDictionary (at least not last time I tried), one has to use the heavyweight DynamicResource.
Peter Verswyvelen,
Strongly Typed Solutions
 
User avatar
sfernandez
Site Admin
Posts: 2983
Joined: 22 Dec 2011, 19:20

Re: 1.3 BETA4: SetTheme and ResourceDictionary

15 Feb 2017, 20:45

StaticResource is solved during xaml loading providing the resource itself that is then stored in the property. So after xaml gets loaded there is no reference in the UI tree to any use of StaticResources.

DynamicResources are different as they provide an expression that is listening for changes in the resource dictionaries of the tree.
 
User avatar
jsantos
Site Admin
Posts: 3905
Joined: 20 Jan 2012, 17:18
Contact:

Re: 1.3 BETA4: SetTheme and ResourceDictionary

15 Feb 2017, 23:45

In that sense the old API was more rigid, where you had to pass in the main XAML and theme in one call.
Problem with the old approach was that you were passing the XAML + Theme when creating the view but the XAML was loaded before that point. So, the XAML was being loaded without knowing the theme in advance. In this scenario, StaticResources were not optimal and the code for solving this properly was complex. So we decided to follow the one Theme set at init time approach that is more consistent with the way WPF does this.

Do you really need to hot-reload the theme? You cannot do that in WPF right (I mean overriding the global operating system theme)? I am asking this because in the v1.3 we are even evaluating setting the theme in a structure that is passed to Noesis::GUI::Init().
 
Ziriax
Topic Author
Posts: 60
Joined: 10 Dec 2015, 17:59
Location: Belgium
Contact:

Re: 1.3 BETA4: SetTheme and ResourceDictionary

16 Feb 2017, 00:50

Currently when auto-reloading I create an empty ResourceDictionary and set that as a theme.

I also create a dummy control as the main view.

Then I load the theme resources, and add these to the merged dictionaries.

Then I load the main XAML as content of the dummy control.

When either resources or XAML change, I clear the ResourceDictionary and dummy content, and reload.

This works fine but I must use DynamicResource everywhere, and that is strange if the "theme" is loaded first. I consider the "theme" more as globally available resources (like the one in WPF's App.xaml), and not like a real WPF theme that can be switched at runtime. Or is that called a Skin, I always mix up these two ;-)

Btw I also have Roslyn based reloading of C# now, I will update my github repo as soon as it is stable. I will make my view-models serializable, and restore after them reloading the assemblies. I also generate PDBs so debugging also works. Like that I should get real "hot" reloading, I.e. keeping most of the state. Visual Studio 's edit and continue (both c# as XAML) is often annoying since you can only do certain changes. Using the WPF designer works but you need to create "design time" view-model instances, awkward and the WPF designer often works incorrectly. So I hope to make a nice little life coding environment, since restarting an application is so 2010-ish ;-)
Peter Verswyvelen,
Strongly Typed Solutions
 
User avatar
jsantos
Site Admin
Posts: 3905
Joined: 20 Jan 2012, 17:18
Contact:

Re: 1.3 BETA4: SetTheme and ResourceDictionary

16 Feb 2017, 01:28

Currently when auto-reloading I create an empty ResourceDictionary and set that as a theme.

I also create a dummy control as the main view.

Then I load the theme resources, and add these to the merged dictionaries.

Then I load the main XAML as content of the dummy control.

When either resources or XAML change, I clear the ResourceDictionary and dummy content, and reload.
Cool! This seems to be a simple and elegant solution. I like it, yes, you need to use DynamicResources but I don't think that's a big problem. So, for you, having the global dictionary set once at initialization time would be fine right?

In the final 1.3 we are also exposing in C# callbacks for custom resource loading (xamls, textures and fonts). We plan to pass all this information once at initialization time. We think that passing the theme at this point is better than calling SetTheme() later because at initialization time we need to load our default theme. Wasteful if the user later sets a different one.
 
User avatar
ai_enabled
Posts: 231
Joined: 18 Jul 2013, 05:28
Contact:

Re: 1.3 BETA4: SetTheme and ResourceDictionary

16 Feb 2017, 07:30

Btw I also have Roslyn based reloading of C# now, I will update my github repo as soon as it is stable. I will make my view-models serializable, and restore after them reloading the assemblies. I also generate PDBs so debugging also works. Like that I should get real "hot" reloading, I.e. keeping most of the state.
I remember how much pain it was to properly convert WPF-code to be compatible with NoesisGUI - we need to properly rewrite namespaces with Roslyn to make it working. Here is the snippet of the Roslyn preprocessor code which works very well for us https://gist.github.com/aienabled/d20c5 ... be8b76bd09 it will do namespaces rewriting (not only in the "using" block but everywhere in the code) we're using it for more than one year now and have no issues. However, there are still some API difference with WPF at NoesisGUI (which I've already reported at bugtracker). As a workaround we're using a custom branch of C# SDK code.

Regarding the 100% hot reloading with view-models serialization - that's a nice approach thought it have serious limitations - some data simply could not be serialized (even if technically it could be done, I mean some data objects should not be serialized-deserialized as it will lead to cloning them instead of using original objects). Also proper objects graph serialization is not a trivial task (thought if you still want this, I recommend to have a look on https://github.com/AqlaSolutions/AqlaSerializer as it works quite good for us). So it might be viable if your view-models are "pure" (without dependencies on data objects, events and callback delegates, etc), but that's a big limitation...

We abandoned that approach and reload UI completely by restarting NoesisGUI (so we needed to modify C# SDK code even more to support that approach and still have some issues like memory access violation, @jsantos promised us a proper NoesisGUI reload API in 1.3.x). Of course it leads to the UI state loss but in our case the game restores the state quickly (but not completely, so some opened menus will be closed).

Regards!
AtomicTorch Studio Pte. Ltd. http://atomictorch.com

Who is online

Users browsing this forum: Google [Bot], jayk.techabbot and 43 guests