XDraw 2.0 Software Design Documentation

Software modules


Loose idea collection


  • Drawings should be stored in xaml file only
  • Add additional informations directly into xaml by comments (like it is done for Text objects already)
  • Also allow to edit Brush resources
  • Allow to use other resources by reference (Static- DynamicResource)
  • Allow using resources from different XAML-Files and even different precompiled assemblies.

Standalone application

  • AvalonDock would be good

Open questions


  • Which license should be choosen for XDRAW 2?

Visual Studio plugin

  • How should XDraw be integrated?
  • Because a XAML file can contain everything: Window, Page, UserControl, ResourceDictionary, ... and a ResourceDictionary can also contain more than drawings: How should the editor be integrated? I think somehow like the XRES Editor.

Standalone application

  • How to manage referenced resources? Parse VS Project files? Add comments with reference list to XAML file?

Last edited Aug 11, 2010 at 9:31 AM by osre, version 8


kainhart Aug 13, 2010 at 4:57 AM 
Also regarding integrating with Visual Studio there is a great topic on MSDN about creating custom designers and editors.


Also the following StackOverflow post discusses creating a designer for Visual Studio and has some relevant resources.


kainhart Aug 13, 2010 at 4:52 AM 
Visual Studio Plugin - I would envision that integrating the XDraw plugin to the at the XAML editor level would be the most desirable. There are many tools out there that integrate nicely within the text editor such as ReSharper. Visual Studio 2010 XAML Editor IntelliSense Presenter Extension, XAML Power Toys. If we could integrate XDraw into the context menu in a way that takes into account the position of the cursor and whether it is within an element than can be edited using XDraw that would be quite awesome.

kainhart Aug 13, 2010 at 4:34 AM 
I like the idea to use AvalonDock. Also in terms of whether we are interested in opening solutions and project files, the IDE framework available for SharpDevelop may also be attractive although I believe this would require the outer UI for this app to be written in Windows Forms.

kainhart Aug 13, 2010 at 4:31 AM 
Another project that we may wan to keep an eye on is XamlTune for it's aspirations of being able to refine XAML drawings. My assumption is that this would consolidate redundancies say where a common shape is used in several places but transposed. If that shape is instead redundantly declared it could be factored into a single shape resource that then is used in several places with different transpose transformations applied to it. The same would be probably even more relevant to shared colors, gradients, or other brushes.

kainhart Aug 13, 2010 at 4:27 AM 
The most difficult item in the list that I can see is the idea to "Allow using resources from different XAML-Files and even different precompiled assemblies." If you look at tools like Blend you can see that Microsoft ended up forcing users to use it almost as an alternative editor for Visual Studio projects/solutions instead of for individual UI elements and resource dictionaries in order to simplify the resolution of references.

A few ways to approach resource references:
1. Do not support referenced resources.
2. Support only resource references which can be resolved locally within the same resource dictionary.
3. Require the user to locate an assembly that holds all resources and require that the other external resources be compiled into that assembly before XDraw can see them. A possible path (relative or absolute) to the assembly could be stored within a comment within the original resource dictionary to aid in automatic resource lookups when this file is opened in the future. If the path and resource cannot be resolved the user is prompted again to locate the assembly open opening that .xaml file or the specific drawing within that contains the external reference.
4. Allow for project files and/or solutions to be opened up as first class items in XDraw like Blend does to allow XDraw to have access to all resources that may be referenced within the app. Since some of these resources could be provided dynamically at runtime it could be a bit tricky doing design time rendering is it would likely require temporary or partial builds of the projects in order to allow the output to be rendered. Think about how finicky the Visual Studio XAML designer is and especially as it was in VS 2008 when referencing things like templates or user controls and trying to work with these things in the designer.

Personally I think lean more towards option 2 with 3 being a suitable way to at least handle cases where external resources are unavoidable.

Note that external references also complicate things such as the destructive filters and such that I mentioned before. In these cases any resource that is externally referenced (ex. a DrawingGroup or Brush resource) would likely not be able to be modified by the effect since we cannot guarantee that we could resolve the location in which the code for that resource would be in order to modify it and in some cases these resources may be dynamically generated or provided through imperative coding. The best case for handling these situations would be to make a copy of the external resource locally and modify that instead very similar to how Blend allows copying a template in order to customize it. Perhaps when a drawing has such an effect/filter applied to it that contains external references the user could be prompted to whether they would prefer the externally referenced resource to be left unmodified or a copy made that then also shows the affect of the filter.