The New Control Panel 

This document gives a brief description of how the new Control Panel is implemented.

Note: I’ll use the terms simple view and category view interchangeably to denote the new simplified inductive UI version of the control panel. I’ll use classic view or icon view to denote the traditional defview based control panel.

The relevant files
Here’s a brief description of all the relevant files, located under the shell\ext\webvw\ dir. (The dhtml files and template are in the rc subdirectory.)

cpframe.htt : This file is used to generate the templates cpsimple.htt and cpicon.htt using a perl script in the build process (see webvw\dll\makefile.inc).
	cpsimple.htt  	: template for simple view
	cpicon.htt	: template for icon view
	Both of these files only contain an <iframe> tag. cpsimple.htt loads up cpmain_s.htt by default while cpicon.htt loads cpmain_i.htt by default in that iframe.  

When you navigate to the control panel, CControlPanelViewCallback::OnGetViewInfo() is called to determine which template is used. We hand out the right template based on the policy restrictions in effect. This saves us from doing the policy check in the script code in the template itself (BIG PERF WIN).

We need this outer template file (cpsimple.htt or cpicon.htt), which only contains an iframe tag, so that we can simulate the navigation to the category pages while remaining within the control panel namespace. So while you are navigating to the category pages in the control panel, as far as the Shell is concerned you are still in the Control Panel folder. This saves us from modifying the control panel namespace, so we can maintain the classic view as it is (for advanced users and legacy reasons), and at the same time provide a two level hierarchy in the simple view.

cpmain_i.htt :  This is the template which shows you the icon view (hence the _i  ). It contains a FileList object like all other folder webview templates. Navigation to icon view is pretty fast as the only script code we need to run is to verify if we are in RTL (mirrored) mode, and adjust accordingly. We also test explorer policy to see if we need to disable the link to “switch to the simple view”.

cpmain_s.htt : This is the new simple view (hence the _s ). The UI is hardcoded html in the page itself. The only script code we run on navigation is the same as that mentioned above. We do not have the FileList object on this page, as we do not need one. When we switch to classic view, we simply navigate to cpmain_i.htt within the parent iframe mentioned earlier. What that means is that switching views is now a navigation, if you do a back, you’ll come back to the simple view. Incidentally, this behavior was not only better for perf, but Joelgross wanted it this way too ( I was against treating the switching between the views as a navigation, but was happy to oblige when it helped me improve the perf). 

cpmain.js : Contains script code common to cpmain_s.htt and cpmain_i.htt. 

cpcatgry.htt : This template file is used to generate all the category pages, such as cppgat.htt (at = Appearance and Themes), cppgpoh.htt (poh = Printers and Other Hardware), etc. (see webvw\dll\makefile.inc for details). This template contains three CCPTask objects. One each for the Tasks, See Also and Troubleshoot lists on the page. We also generate a table of all the control panel applets which belong to this category page.

cpcommon.js :  Script code common to cpmain_s.htt and cpcatgry.htt. Basically this code determines which applets are there in a category.

cpcatgry.js : Script code specific to the category pages.

cpwebvw.css : The style sheet for all the control panel pages. This is the common stylesheet that is used by control panel, user accounts and webview. We still need to be able to obtain the right template from the ThemeManager object, but some work needs to be done to package the files correctly with .theme/.mstheme files. Please see my notes in http://liveraid/?id=103675

cptask.cpp : This implements an activex object which is placed on all the category pages. Each instance of this object displays a list of links, after checking policies, OS version etc to see if the link should be displayed. The list displayed by each object instance is based on the category and also the class (Task, See Also or Troubleshooter).

How does it work
When you navigate to the control panel, either cpSimple.htt or cpIcon.htt are loaded as the template for the folder. As explained earlier these files are identical except for which template they load up as the default file in the <iframe>. This way we do not have to do a script based check and switch of the view based on policy etc. All subsequent navigations to the category pages or switching of views are simply loading up a new file in that <iframe> so we let Trident’s travellog maintain the correct navigation stack for us. 

If you go to a category page and navigate to some place outside control panel and then do a back, you land up in the correct category page. This was enabled by adding the support  to save trident’s persist history also when persisting history in defview (see CDefViewPersistHistory::SaveHistory() in shell32\defvphst.cpp).

So what needs fixin’ in there ?

Nothing. Wish it were so. The two main bugs that I wished I had resolved before I left are http://liveraid/?id=103675 and http://liveraid/?id=108621, namely enabling the theming support and fixing the up button navigation from category pages. The theming support got delayed because there was no clear story on how the themed styled sheets should be packaged, there still seems to be some confusion.

I have added comments in both the bugs regarding what needs to be done. It’s just that I have run out of the time to do it 

How would you go about if you had the time to rewrite the whole thing?

I would probably do something like the webview rewrite rajeshg has done, remove all code from htt files, just use activex objects to spew out all the html. However, I must point out that there is not too much to be gained there. For one, the navigation perf to the control panel cannot be improved significantly by this method, as the main control panel templates (cpmain_s.htt and cpmain_i.htt) just use raw html with very little script code. Aslo, we would still need to use an outer template file with an <iframe> tag to get the correct navigation behavior, and we will need the same number of indivdual category pages files and outer pages files so that each navigation can be recorded uniquely in the travellog. 

Once we enable themed style sheets, we will have extra script code to link to the right css file. This may cause a slight additional delay, but I still think that the perf disadvantage will be too slight to merit a rewrite. 

If you just want to improve navigation perf, you might get better results by looking though the code in ctrlfldr.cpp and control1.cpp and figuring out why do we load so many dlls when navigating to the control panel? Some of that stuff maybe redundant now.

That’s all I can think of right now. If you come up with any issues you need explained, feel free to contact me at mailto:arish@acm.org I really want to see this thing ship in good shape and will be willing to help out as much as necessary. GOOD LUCK!

- Arish Ali 	

1st Nov 2000