Discussion about making the XML viewer an independent tool

[julie777]

First the Survey

Is there is any interest in the idea of making the XML viewer a separate tool?
Are there a significant number of features that would be useful to the general OneMore user population?
Or, is this only useful for OneMore and OneNote developers, and if so are there enough of them to justify the work?
Does this fix a void in the OneNote developer tool ecosystem?

Problem to Solve

Currently view XML is a command that opens a new window showing the XML for the current page. However, that window is modal which requires closing the window, making changes and reopening the window to see the effects of the change.

New Feature/Solution

The more I use the XML viewer, which I should start calling the XML tool, the more obvious it becomes that it is actually a completely separate application/tool. It is shipped as part of OneMore and can be opened to the current page by OneMore, but its uses are far reaching and I don't even know how to use them all yet.

Benefits

Benefits of a separate tool

• using a separate non-model window for it would be a non-issue
• it could start supporting the attributes of an application that users expect of an application and many of these are things I want to propose anyway
  • menus such as File, Edit, Help
• it can be developed separately from the rest of OneMore if that is more efficient.

There might already be such a tool, and I will research and report here, however a tool that is part of the OneMore package can be more tailored to uses related to OneMore.

New Features

The XML tool is already extremely useful, but it could be 10x more powerful with additional features, most of which are not complicated to implement.

Save XML (File Menu)

The ability to save the page XML from the viewer to a file. This provides the ability to capture multiple versions of the page for comparison, adding to documentation, submitting with bug report, etc.

Settings (Help Menu)

Allow the user to configure it the way they want it to work, and minimize the use of check boxes and other visual clutter. One example is "save window position" which is obviously a user preference type of choice and one that is unlikely to be changed frequently.

Documentation (Help Menu)

The XML tool already has many non-obvious features and uses. It needs help that is available to the user from in the app. It is not like looking up how to use favorites once and then not needing the doc again.

Auto Refresh (Settings)

With auto refresh using the tool along side OneNote while making changes and seeing the effect on the XML caused by those changes is a massive efficiency improvement for that use case.

Switching to edit mode in the XML tool would of course turn off auto-refresh.

Syntax Highlighting

This really hit me as I posted my page XML into a bug report and specified XML as the language for the code block. I hadn't really thought about full syntax highlighting before that. However, I am constantly trying to find the actual OneNote page text in the XML and was thinking about was to make it more obvious, perhaps with a choice to just color "page text".

View Options

There are already some view options in the XML tool.

• hide author information
• show XML attribute on separate lines
• remove LF from CDATA (which at times I have just clicked on and off multiple times and never seen the actual change, but notice the the lines I was looking at moved up the page on each click for some number of clicks)
• wrap text
• select all is an "Edit Menu" function just like copy and paste and the shortcuts work for all three now, so I am not sure what the button is doing there

I have some other thoughts about ways to change what is shown in the XML Page view to reduce the clutter so the important information surfaces. (I'll add this if the discussion progresses.)

Function Orthogonality

It might not be a good heading name, but...

In addition to the Page tab which is always selected when I open the tool, there are tabs such as "Section", "Notebooks", etc. that I haven't used yet.

There is also the PageInfo selection that I have only used to get rid of the selection highlight, but haven't had time to look up what it is for in the documentation.

I know this isn't well organized or all that pretty, but it is primarily to see if there is any interest before putting too much work into it.

I am looking for comments please...

[stevencohn]

Background on each tab, PageInfo, etc.

• The Page tab invokes the GetPageContent method, which takes a PageInfo enum as a parameter.
  • I had originally added a comment to the top of the XML with the OneMore one.GetPage method call and parameters but found myself selecting all and copy the entire contents elsewhere and that comment interfered with what I wanted to do with the text and I got tired of constantly deleting it.
• The Section tab invokes one.GetSection which invokes GetHierarchy, passing in the current section ID.
• The next three tabs are variations of GetHierarchy but passing the appropriate object IDs and HierarchyScope.

[stevencohn]

Note on the yellow highlights.

This highlights all one:T runs that are marked as selected=all to make it easier to find the text cursor or selected content in a large page. Take care when changing the PageInfo option because some of them can actually remove the selected attributes which, if then saved, will update the page and eliminate any current selections.

[stevencohn]

Example of highlighted "page text"

This is implemented as a simple RichTextBox which is notoriously slow for syntax highlighting. This is why I've used highlighting sparingly but I think highlighting the "page text" or CDATA is a good idea.

[stevencohn]

Note on "settings"

Other than the "Save window location" checkbox, none of the other controls are what I would call settings. They provide a way to alter the current view in ways that help you understand the context. Some change the arguments passed to OneNote's IApplication Interop API, such as PageInfo. Some toggle visibility of "noisy" attributes that are hidden until you need them. And some simply change the view for readability. But the default view is the most efficient in terms of copy/pasting into other tools such as LINQPad which I use often; in fact, I'm going to add another control that formats the content into a C# string variable just for that purpose since LINQ is the most commonly used technique by OneMore for manipulating OneNote XML.