Content of the modern window

Mar 26, 2013 at 1:51 PM
Hi,
Just got a couple of questions:
1) Is there a way to put a direct content in a modern window? There was no way I could make the following xaml work:

<mui:ModernWindow x:Class="Framework.Shell"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:cal="http://www.codeplex.com/prism"
    xmlns:mui="http://firstfloorsoftware.com/ModernUI"         
    MinHeight="500" MinWidth="900" WindowStartupLocation="CenterScreen" 
    Title="Helllooooo!!!!">      

<Grid Background="Yellow">

</Grid>
</mui:ModernWindow>

Although it worked with MenuLinkGroups being filled with a LinkGroup. I wish to keep a different home page than tabbed! :)

2) Is there a way to hide back button? I am on my way to prepare a small demo with prism. Which I also need to present to the other stake holders. The navigation system that is already existing in the MUI is good but it tampers a lot with prism navigation system. Navigation will be done by any other layer but view. Obviously I need to write a back button of my own. :)

My apologies if I am overlooking something terribly simple!!
Coordinator
Mar 26, 2013 at 11:51 PM
Edited Mar 26, 2013 at 11:51 PM
1) ModernWindow.Content is not rendered by MUI, this is by design. If you require content to be rendered, you'll need to modify the ModernWindow template and include a ContentPresenter that will render the Content.

2) Hiding the back button requires the same technique; you'll need to modify the ModernWindow template and remove or hide the back button.

The default ModernWindow template is found at Themes\ModernWindows.xaml in the FirstFloor.ModernUI project.

There are others busy doing PRISM stuff with ModernUI, see also this discussion.
Mar 28, 2013 at 4:25 PM
babai28, maybe you can share your ideas on integrating mui with prism. i am currently working on the same stuff. I am happy with region based navigation by means of view discovery and view injection, but i am still experimenting with integrating mui and region navigation api. seems like your work points in the same direction. I'm happy to share my thoughts with you:

Since I don't see major conceptual discrepancies between the two navigation concepts, my idea is to implement an adaptation layer that marries mui and prism without affecting any of their implementation.
My current idea is to implement a Control (that will be used as kind of a hosting control) that implements Mui.IContent and delegates navigation to prism. I am still not sure if this apporach will need a custom prism.IRegionContentNavigationLoader. Still investigating. What are your thoughts, do you have a different approach?
Would be happy, if you could share your ideas...

Florian
Mar 29, 2013 at 6:41 AM
Florian,

I am on my way to write a framework that would encompass multiple modules just like any prism application. I am using MEF/PRISM. My first choice was Mahapps metro as it also gave me the tiles I needed for standard metro UI. However, pointed by a friend to this project I found this to be neater than Mahapps metro (this is what I think :) ).
I separated the Tile control from mahapps so that I can put it inside my framework which would be powered by MUI.
Having said this story, +1 for you support the idea that the implementation of MUI be remained untouched. But I dare not think it would be possible. You may try devising an idea that would do minimum changes to the MUI code but making changes (atleast) in the window template is inevitable.
The quick questions that come to mind:
1) Where are you going to define the main regions? Perhaps in a user control that would fill the ContentSource property of the window. Though I am not sure if that would work. We would need to check the loading time of the contentsource and the prism modules. If prism modules get loaded earlier, it would throw exception.
2) Regarding the Mui.IContent that you are pointing, how would you make any call being delegated to it without making change in the back button template that is defined in the main window template. The button automatically takes care of the navigation through LinkGroup.Links, you will have to make a minimal change to the project code so that it delegates call to your layer.
I am assuming that Mui.IContent would serve as the main region for the prism shell. Do let me know if I am not aligned with your thoughts.

Sid
Mar 30, 2013 at 6:32 AM
Sid,

thanks for sharing your thoughts. I am almost through with my solution. I did still not change any line of code in mui and prism. As for mui being the prism shell, my idea is the following:
  • The title links are (surprise!) the "TitleRegion" of the shell. If a module wants to have its content linked by a title link, it should register its view with this region.
  • The main menu group is the "MenuRegion" of the shell. Each module can then register linked content in there.
From the very beginning, the shell is empty, ie. does not contain any links in these regions.
So, to answer your first question: there is no "the main region" in mui as it is, since the links etc. define "sub-regions" out of the box. If you would want to support a "main region", I agree with you, we would then have to change the template. But I think, we could do that in such a general way, that we maybe end up with something like a "EmptyModernWindow" that could then be customized for whatever use-case. IMO if we need to change the template, we should do it in our app, but based on something from the mui framework. By following this strategy, the project as well as our applications can fully benefit from changes on either side.

The key to marrying mui and prism the way I am trying, is the IContentLoader interface. By using this interface, I don't come into a race-condition at application startup.

For your second question:
My approach is not to override the existing functionality, but to harmonize it, so it goes well with each other. You are right, the back button could need to be changed. I will see, I am not that far yet.
To make mui delegate the navigation to my layer is a matter of implementing IContentLoader as well as IContent. As I had a first look at the IContent interface, I realized that it does indeed look so much like prism's INavigationAware interface.

As soon as i have sth. I am confident with, I'll post it here.

I did not yet implement a tile control, it would be great, if you could share yours.
btw, I have used mahapps before as well, but I had to tweak a lot and found some strange behaviors. I was really happy to see, that modern ui was released.

Please let me know, what you think about these ideas.

Florian
Coordinator
Mar 31, 2013 at 12:36 PM
If you need any help from the mui side of things, I'm happy to assist.
Mar 31, 2013 at 3:01 PM
Florian,

What I gather from your reply above is, you are making the home screen of the application to follow the metro-tabbed based look. What if someone wants a different look for home screen (e.g.: tile based). The problem statement is : "I want to use the wonderful theme provided by MUI but want to follow a flow and look of my choice."
While I appreciate your idea of leaving MUI/PRISM code untouched, I feel, MUI is a little forcing on the consumers to follow the infrastructure provided by it (the decoupling factor is missing).
I will be happy to share the Tile Control. But I can't see any attachment link here in the editor. You might, would like to share your email address over a personal message.

Kozw,

You had mentioned that MUI is MVVM agnostic, but IMHO it should provide more flexibility if the consumer wishes to apply some navigation logic of his own.
While the built in functionality of MUI is sufficient for smaller applications, an enterprise application would use an IoC and modular framework. How will I unit test, for example, the navigation logic. Again the pages will always have to have their view models being tagged to them (either in xaml or code behind). Having said this, I believe a slight redisigning of the MUI project might make it the strongest opensource UI framework. I am ready to provide my whole hearted contribution if you decide in favour of this idea. The idea is not to remove the existing navigation functionality (its great, trust me, for building small apps) but to give the consumers a choice if they want to make use of the MUI navigation system. If someone opts out he should still be able to make use of the wonderful theme provided by MUI. Let us give someone a chance to override. :). Let me know what you think?

regards,
Sid
Coordinator
Mar 31, 2013 at 7:25 PM
Looking forward to your suggestions. What parts need to be overridable?
Apr 1, 2013 at 8:47 AM
For the navigation, most of mui navigation code is in ModernFrame class, maybe we could extract an interface (or several, we'll see what fits) from the navigation concepts, refactor ModernFrame to make use of the interface and encapsulate the existing navigation in a separate implementation of the new interface. We would then be able to plug any navigation concept we like. The command binding of the navigation commands should be adapted as well to make use of the concrete implementation. We could then even reuse the "back button" and do not have to replace it.

For the mui templates, I think it's a little controversial. IMO adding other (general) templates like a tile-based window or an EmptyWindow would help other people as well. But for custom applications that want to make use of the mui look & feel but need a custom shell, the template should imo be part of the custom application, not of mui.
I did not look very extensively on the wpf parts and templates of mui until now, but maybe it is also an idea to separate the ModernWindow in different independent layers.
For the existing ModernWindow it may be an idea, if mui would provide an empty window template that encapsulates all the styling and a different control/template that encapsulates the Metro-tabbed template that is in place now. In this way, mui style and host(=window) could evolve within the mui open source project and contributors could add new window layouts/templates/whatever to a mui.contributions project.

I may have some ideas regarding content loading/unloading/activation/deactivation, but have to think about it again. Will post it here then.

If I find the time today, I will also wrap up my current progress of prism integration (which already works for the metro-tabbed default ui) and post the sources.
Apr 1, 2013 at 3:06 PM
With respect to setting the window title.. I agree that it should be easier to set:

http://mui.codeplex.com/workitem/19548
Apr 1, 2013 at 3:31 PM
Hi Koen,

I am aligned with Florian about the navigation logic be decoupled from the MUI application. While you can put the existing logic as default, still giving the user an option to override it.
At present, I can identify few things that need to be overridable:
  1. Window Content. Can we have an option that would let me put a content control in the window. I am not sure as of now how to keep that configurable (so as to switch between the two functionalities). If the idea is hazy, for sake of simplicity, you might create two window templates namely: ModernUIWindow and ModernUIEmptyWindow (or whatever!).
  2. The back button, IMO should not be a mandatory thing to have in your window (we can handle its visibility with an added dependency property in the window). If the user chooses it to be there, it should expose some sort of command for binding purpose. I hope you would agree WPF looses its beauty without binding. :)
  3. The settings link on the top right corner should also expose a command and should have its visibility configurable.
I think with these changes incorporated, creating a PRISM demo should not be that difficult. The consumer may keep the interface tabbed based, tile based, link based or anything of his choice. I would appreciate if @codedevote expresses his thoughts too!!
Let me know what you think!

regards,
Sid
Coordinator
Apr 1, 2013 at 4:47 PM
Great feedback guys!

@codevote
Decoupling navigation from ModernFrame; I'm curious as to what you need. Currently ModernFrame does the following:
  1. async load content (already abstracted with IContentLoader)
  2. keeping content in memory
  3. maintaining navigation history
  4. navigation by specifying a source, go back and refresh
  5. raising appropiate navigation events
@babai28
  1. Window Content presenter; no problem to add to the default ModernWindow theme. When no content is specified, the presenter is still there but doesn't render anything. BTW, the same is true for a window title presenter, it just doesn't exist yet and my main problem is that I don't know where a title fits in a ModernWindow.
  2. Back button visibility; adding a dependency property to ModernWindow sounds good to me. As far as commanding goes, the BackButton command is currently set to NavigationCommands.BrowseBack with a CommandTarget set to the main ModernFrame instance named 'ContentFrame'. Not sure yet how to expose all back command features (Command, CommandTarget, CommandParameter).
  3. The settings links at the top is not part of the ModernWindow theme. It's a link added to the ModernWindow.TitleLinks collection.
Apr 2, 2013 at 8:00 AM
@kozw:
The points you are mentioning do pretty well define the abstractions to introduce. I will comment on each.
  • Content loading via interface is already abstracted and for the moment, I am fine with that.
  • Prism for example has its own notion of KeepAlive. Instead of coexistence and synching two (redundant) mechanisms, we should be able to override it.
  • Prism as well has a navigation journal. Again, we have two mechanisms doing the same thing instead of being able to plug the desired one.
  • Navigating to a source, going back and forth, etc. - again, prism provides these mechanisms as well. But it does this at the view model layer. And, on top of it, it introduces some additional concepts. E.g. a view model can veto navigation (this is kind of similar to canceling mui navigation in the OnNavigatingFrom event). It also supports navigation to content that does not yet exist. Imagine a tab control with different tabs for editing different customers. With fragment navigation (a uriquery in prism) I am able to request a navigation to editing of a customer that has not yet an its own opened tab. Prisms content loader is then used to wire up the new view/view model and inject it into the right place in the UI. I could mimic this with mui's navigation, but I have to work at the view layer with the IContent interface (at least thats what i understood). My current approach is a MUIContentHost control, that is a ContentControl hosting the actual content, implementing Mui.IContent and delegating the calls to the datacontext, if it implements the prism navigation interface.
  • prism does raise the events, too. It does this at the view model layer (which I prefer).
Maybe its clearer now. If I misunderstand some of the mui concepts, please tell me. If we could abstract away these concepts and provide current mui implementation as default, we would still be able to completely or in parts override it and tweak it to whatever need. I would be glad to contribute time and code.

@babai28:
  • Content presenter is a good idea. I like kozw suggestion with the optional presenter.
  • Optional Back button or back button cusomization will be very nice. Maybe a MUI Link that is backed by an ICommand would help in exposing all features of the back button.
Apr 2, 2013 at 4:37 PM
Would you be so kind and review my current attempts to marry mui and prism. You can find a demo app here.

Viewing this demo I am sure, you will gather more insight on what I am trying to accomplish. Would appreciate your feedback.
Coordinator
Apr 2, 2013 at 9:34 PM
I'll review your demo app asap and post my findings in this discussion asap.
Coordinator
Apr 3, 2013 at 9:34 PM
Wow, your ModernUI.Prism project is impressive. There's a number of Prism concepts I still need to grasp to fully appreciate it.

I was thinking about modifying ModernFrame, and started to wonder whether you want to use ModernFrame at all? Why not use the default TransitioningContentControl and implement the content navigation and history navigation (which I learned is part of Prism's view model layer) in your viewmodels. The content transition animations are all in the TransitioningContentControl and there's little use of the other ModernFrame features in Prism.
Apr 4, 2013 at 7:00 AM
I agree with Koen. The Integration is impressive. What I gathered is you made use of the existing navigation system of the MUI and galvanized that with Prism's metal.
Nice work Florian!

Koen,
Why not use the default TransitioningContentControl and implement the content navigation and history navigation (which I learned is part of Prism's view model layer) in your viewmodels. The content transition animations are all in the TransitioningContentControl and there's little use of the other ModernFrame features in Prism.
Exactly! That is why I was asking to make the navigation of MUI an optional thing. So that for PRISM users, they don't get duplicated.

regards,
Sid
Apr 4, 2013 at 8:11 AM
Thanks for having a look at it guys. Yet, there's some more work to do, before I am really happy with it.

Koen, just using the TransitioningContentControl sounds like a good idea. I'll have a look at it. This would definitely streamline the integration.
I also have some other ideas of improving this stuff. Must get my head around those...
...and galvanized that with Prism's metal
Sid, YMMD.
May 10, 2013 at 11:03 PM
Hey codedevote,

How much further did you get with this??

It's looking so good from this slightly older demo. I know this sounds awfully lazy but I'm doing exactly the same thing, and I'm keen to not reinvent the wheel if someone else has solved the problems, especially if we can pool the common knowledge and work.

Thanks.
May 13, 2013 at 9:47 AM
Hey a_pawsey,

I would be happy to share it. If you have ideas to improve it, I will be happy to hear about them.
I threw away most of the things of the first demo app, and now I have only a few PRISM glue classes. I also implemented a own Empty Window template and my own ModernMenu (that allows modules to register themselves in there). I do need to extract this stuff and put it back into the ModernUI.Prism library. I don't know, when I can manage to post it, lots of work at the moment. Maybe the next weekend,
May 29, 2013 at 2:53 AM
Hi kozw, any plan for Modern UI and Prism integration? I really want to see this wonderful UI library work nice with Prism. I would like to contribute if you have a plan for the integration.
Coordinator
May 29, 2013 at 10:06 PM
There are no plans to add Prism specific elements to mui (or any other framework for that matter). mui should be flexible enough to work with any design pattern or framework, and leave it up to the developer to choose his/her framework. Having said that, I can imagine a mui contrib project that enables smooth integration with frameworks such as Prism.
May 30, 2013 at 1:04 AM
Sounds reasonable. Again thank you for sharing your wonderful library.
Jun 5, 2013 at 8:08 PM
Apr 20, 2014 at 4:45 AM
codedevote wrote:
Hey a_pawsey,

I would be happy to share it. If you have ideas to improve it, I will be happy to hear about them.
I threw away most of the things of the first demo app, and now I have only a few PRISM glue classes. I also implemented a own Empty Window template and my own ModernMenu (that allows modules to register themselves in there). I do need to extract this stuff and put it back into the ModernUI.Prism library. I don't know, when I can manage to post it, lots of work at the moment. Maybe the next weekend,
Since no one asked, I'd love to see your latest code. The project template would be great as well for us lazy programmers. Thank you for your effort!
May 5, 2014 at 11:01 AM
codedevote wrote:
Hey a_pawsey,

I would be happy to share it. If you have ideas to improve it, I will be happy to hear about them.
I threw away most of the things of the first demo app, and now I have only a few PRISM glue classes. I also implemented a own Empty Window template and my own ModernMenu (that allows modules to register themselves in there). I do need to extract this stuff and put it back into the ModernUI.Prism library. I don't know, when I can manage to post it, lots of work at the moment. Maybe the next weekend,
Hi codedevote,

I am also very interested in what your project became in the end. I have followed the whole conversation including the demo you shared (https://docs.google.com/file/d/0Bx5f-K4qfA-rT09HTHVXTnJPUTA/edit?usp=sharing). It would be very helpful if you would share what it became after the rest of the discussion in this thread.

And if you don't I would still like to thank you for the contributions!
May 5, 2014 at 11:15 AM
Sorry, I posted the updated sample a few months ago in a different thread.
Find the sample linked in one of my comments in this thread:
http://mui.codeplex.com/discussions/456422

Have fun with it :-)
Mar 8, 2015 at 1:10 PM
is there a .net 4.0 for that sample.I really need it but cant get the mordern shell to display correctly under .net 4.0