Model-View-Presenter (or oter GUI architectures) f

I wasn't quite sure how to title this question or even ask it really, but I will do my best.

I am building a diagram/flowchart style designer which involves (from a very high level) a toolbox of controls, connections, connection points, overlays for editing,etc.

The controls are backed by business objects or components. (i.e. there might be an 'Accounts' components which is represented by a 'Accounts' UI/View component.

Below is a sample mockup of what I am mentioning above.

This is nothign out of control and hundres of applications have similar functionality.

I already have a working version of this (more-or-less), but it was done very poorly by myself (in my opinion) and in order for us to be able to make this extensible so that I can continue developing it our horizontally (additional toolbox support), I need to refactor and do this cleaner.

I have been referencing some articles on common GUI Architectures such as MVP, MVVM, MP, PV,PM,etc.

My concern is that everything I have read so far is very closely related to defining GUI Architectures for CRUD operations. None of these really discuss complex UI library design.

I have been able to find a few articles that give some 'Best Practices' on this topic, but its really not much for me to continue off of.

Thus far, MVP is the closest to what I would imagine would work for this, but I am just not convinced enough to go down that route.

It may not help much, but I figured I could give a brief list of some of the interactions/behaviors that need to be accounted for. Nothing out of the ordinary of what you would see in a diagram or flowchart application.

Controls (backed by business objects, most likely just a reference to the Type to be created at a later time) can be dragged from toolbox to the designer canvas.
- Controls can be dragged, removed, and have their state modified (business state).
- Connections can be initiated between a source and target component.
- Connections can be moved (at both ends) between a soruce and target component.
- Multiple designer windows can be open, so we will have to maintain the concept of 'active' designer.

I am still not sure in the case of designing this where I would want to maintain the UI state/logic as well as the business state/logic. Additionally, where would the concept of the 'active designer' be maintained,etc.

UPDATE Apparently, this is another target for SO trolls, so I will try to clarify my question/post.

I am somewhat knowledgeable on the different patterns that are applied for UI design, however It seems they are not versatile enough for library design of complex UI Components. I could be wrong in this. What I want to know is in the case of this particular scenario, from what was discussed above, am I wrong in assuming that going down the route of MVP might not be able to account for complex UI logic?

All patterns at this level (MVP, MVVM etc.) are suited for pretty much any complexity you'd need. What it can handle is only up to you, you must understand it's still just a pattern, not a framework with some pre-made functions you'd have to use.

Whatever you do however, pick WPF over Winforms, especially when you need complex control over UI.