Visual Studio 2010

29 Sep, 2008 No Comment .Net, Diagramming

The first screenshot ever of VS2010 (codename ‘Rosario’) displays…a bubble diagram! Just emphasizing that diagrams are becoming more and more omnipresent in today’s development paradigms. I’m looking forward to it.

See the official annoucement as well more details on the .Net framework v4.0 on MSDN.

Fluctons and Spin(2|3)

8 Sep, 2008 No Comment Info

Dirac’s monopole was for a long time thought to be a Spin(2|3) representation of a hairless mini black-hole until an article of Josh Manin appeared wherein he describes a superstring fluctuation along a 5-brane in which an orbifold compactifdication captures the essence of a monopole as an holographic picture of this fluctuation. While this is remarkable on its own, he additionally shows that the string tension is related to the asymptotic confinement of smaller constituent which he calls ‘fluctons‘. Knowing that

Spin(2|3) ~SGO(3)/E_3 x SU(3)

one immediately recognizes that the monopole could be a reducible representation and fluctons a yet unknown kind of matter. Dark matter, maybe? While this is hard to test one can hope that the relationship sheds new light on the monopole mystery.

The bosonization of the BRST charges associated to the fluctons yields in Spin(2|3) a NS 4-point function which resembles much the N=8 supergravity assemblies. I would love to see how the Spin(2|5)~SU(4)xSpo(13) looks like and jobbled some things down already, but I’ll need some more weeks to figure out the details. Time is precious.

[Above, an artistic representation of Dawn Neal Mason of string compactification, Fermi Lab gallery]

WPF diagram designer

7 Sep, 2008 No Comment Diagramming, WPF

For those interested in a good tutorial and an excellent all-purpose diagramming library, have a look Sukram’s four-part series entitle ‘WPF diagram designer’. It boasts a lot of features which would have been much more difficult to achieve in a pre-WPF era. The library does not, however, have a MVC architecture and does not contain any hints on layout (neither in the traditional sense nor in the way WPF suggests it through the arrange/measure overridables).

For a long time I have been waiting to see if the series would go on and if ‘part V’ would eventually explain an MVC implementation. Alas, nothing yet and…I would be very surprised to see it considering how many hours I have spent coding it. I guess there is a treshold in moving into this direction. First, Microsoft makes the easy thing…easy, whether through the .Net programming model or through their API’s in a multitude of servers and services, it all gets well until you want to do something out of the ordinary. Second, while it might seem that MVC makes things easier when it comes to serialization, the contrary is true. Not so much because of the data you need to serialize but because events and all sorts of (data) bindings need to be handle with much care. The same can be said, in fact, about the intimately related subject of copy/cut/paste. Third, it takes more patience and commitment rather than ingenuity and WPF knowledge to get all things straight when developing diagramming and layout algorithms in a MVC context. The devil is in the details and the hours you need to spend grow exponentially as you move from a library as examplified by Sukram to a something like GraphSquare.

The CodeProject series is in any case a very fine set of articles and for most applications out there, I reckon, the library is more than enough. Few people would understand the need for MVC until they are stuck with some problem which begs a decoupling of presentation and data storage.

I wouldn’t be surprised someone has taken the Sukram lib and ventured into more jazz and that it will eventually pop up on CodePlex. But even then, it seems quite a lot of good ideas appear on CodePlex but not all are carried to a success, especially if it’s not part of one’s day-time job. Even important Microsoft initiatives seem to wave down, like V2 of the application architecture guide which in V1 was a bible for generations of .Net companies.

.NetMap

23 Aug, 2008 No Comment Diagramming

Microsoft released already a while ago the GLEE library as a closed source library for graph layout which you can use for non-commercial purposes for free. Now, more recently, the MS research group also released on CodePlex .NetMap which

…is a pair of applications for viewing network graphs, along with a set of .NET Framework 2.0 class libraries that can be used to add network graphs to custom applications…

The code is partially based on the GLEE library and is well-documented to allow one to extend it with, for example, additional layout algorithms. So, this library could be a good start for a stand-alone component or library for diagramming in general. The only minor point at this moment is the fact that it’s .Net 2.0 code and, hence, GDI+ based. No WPF in sight. Not yet, but who knows…

Large diagrams and layout algorithms in WPF

29 Jul, 2008 6 Comments Diagramming, GraphSquare

In a previous article I already showed how large diagrams can benefit from layout algorithms. Netron was at the basis of the pretty pictures in this article and it was fairly easy to port the code to WPF, though WPF has some threading intricacies:

Although the BackgroundWorker helper class is supposed to help in using non-UI threads in your application, it did not perform as expected on various occasions. Here I was unable to trace the source of the problme…threading issues are in general horrendous to pinpoint.
The Dispatcher object is your friend when it comes to marshalling modifications from a thread to the UI-thread. The mechanism is easy to use but it can be at times difficult to access the Dispatcher when your architecture is based on a MVC (read: whatever pattern acronym you have chosen to build your WPF application) pattern.
There seems to be at times a difference between using the Dispatcher you get from the UI elements and the one you access through the Application.Dispatcher property.
In general, you should minimize the stuff you perform in a BeginInvoke call to keep the Dispatcher queue lightweight.
Is it possible to access a property rather than a method through the Dispatcher? Can one change the location of a UI-element through the Dispatcher? I haven’t been able to to that, which seems to be a rather crual constratint sometimes.
The VS2008 just stops sometimes because some debugging optimization was ‘optimized away’! This occurs when you try to peek into properties of some objects in the non-UI thread.

There is no noticeable difference between using layout algorithms in WPF and in GDI, the positioning and handling of coordinates is similar. On the other hand, there is a big difference between the responsiveness of WPF. In the examples below I was able to lay out 1500 nodes in less than five seconds but altering the diagram or scrolling produces grinding sounds. Obviously the cause is in the usage of the Control as a base class and the heavy weight of carrying animation, databinding and other stuff which for large diagrams is usually less an advantage. Using the System.Windows.Shapes namespace of .Net would be a better choice for big diagrams and layout.

When it comes to diagramming there is always a choice between sacrificing features or sacrificing scalability. There is also the balance between making a general purpose control and implementing stuff for a particular target group. For example, if you are interested in HMI diagrams you are not interested in large diagrams and vice versa. As well as the choices in what to deliver as shape libraries. Because it’s really hard to enable users to create shapes without understand the API (or opening the source code) one has to deliver a common set of shape libraries, but of course everyone has particular needs. If you use Visio you can easily add new shape to libraries but I wonder whether the serialized shapes are just groupings of predefined elements or really standalone blocks. In that respect one can consider grouping of basic shapes a good solution for a wide audience. I think, however, that for custom diagramming solutions and integrations one inevitably flows into custom code and custom diagramming controls. Diagramming software cannot be separated from consultancy unless you constraint yourself to the average (common) needs.

But anyway, in April 2006 I produced large diagrams in Netron and here they are again but based on pure WPF code. The first screenshot represents randomly generated nodes on the diagramming surface.