Search the Community

Showing results for tags 'graphx'.

More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


    • Announcements
  • GraphX for .NET (open-source)
    • Updates & Releases
    • Discussions
    • Documents & Tutorials
    • Bug reports
    • Redirect to GraphX repository on GitHub
  • General Discussions
    • General software discussions
    • Monogame/XNA
  • International Discussions
    • Обсуждения на русском
  • News & Announcements
  • Discussions

Found 28 results

  1. Now also on Twitter: Latest source code with specified changes is available on GitHub Version 2.3.7 WIP DETAILED CHANGELOG: - Added edge drag functionality to be able to reattach edge to another vertex (thanks to LaborJos) - Fixed SimpleTreeLayout vertex sizes supplement (thanks to edgardozoppi) - Fixed and improved parallel edge handling (thanks to perturbare) - Fixed RemoveEdge() method were not removing edges from data graph (thanks to perturbare)
  2. RELEASE 2.3.6 DETAILED CHANGELOG: + Added edge endpoint calculation for rotated vertex that use ellipse, circle and rectangle math shape + Added VertexControl::LabelAttached and LabelDetached events which fires when new label is attached to VertexControl or detached from it + Added new parameter to GraphArea::UpdateParallelEdgesData(Dictionary<TEdge, EdgeControl> edgeList) to be able to specify edges list to parse for parallelization instead of full edge list parse + Added support for object visbility and attachable labels to GraphX serialization data + Added ZoomControl::ResetKeyBindings() method to clear all (incl default) set key bindings + Fixed ZoomControl dynamic content switch to corectly refresh viewfinder + Improved ZoomControl handling with disabled animation + Renamed ZoomControl::IsAnimationDisabled to IsAnimationEnabled and changed the logic according the modification + Renamed ZoomControl::MaximumZoomStep to ZoomStep and updated description + Implemented easy ZoomControl key bindings with BindKey() method and exposed base commands for zoom and pan actions to be able to bind keys for them + Some class refactoring Go to the archive & sources download page NuGet version is also available
  3. RELEASE 2.3.5 FEATURES HIGHLIGHT: - Added new awesome vertex snapping feature on vertex drag. Many thanks to perturbare for this wonderful contibution! The feature is implemented around DragBehaviour class and is represented in several new settings allowing the drag to be perform around some sort of virtual snap grid. Please read the comment for the DragBehaviour class for detailed info. - Added new feature & example preview in showcase app: graph data filtering. This feature allows you to filter the graph prior to layout generation or relayout based on the pipeline of LogicCore::Filters that are processed sequentially. These filters can modify graph using custom logic. The output graph will be available for interaction along with the copy of the original graph. User then may choose if he wish to revert graph to the original state or apply filtering results permanently. Please read the details at: DETAILED CHANGELOG: - Added Universal Windows Application support and example project - Added StateStorage::ImportState() method to allow state import/export logic between several graphs - Added GraphArea::IsDisposed property that indicated that GraphArea object has been disposed and shouldn't be used anymore - Added GraphArea::CreateNewStateStorage() protected method to be able to implement custom state storage logic for GraphArea - Added ParameterizedLayoutAlgorithmBase::EnsureUniqueRandomInitialPositions property that enables unique random positions generation for layout algorithms. False by default, True for LinLog algorithm. - Added VertexControl::VCPRoot property whcih represents the VCP root container for easier runtime VCP management. To be able to use it you have to define PART_vcproot template element as Panel descendant. - Added new awesome vertex snapping feature on vertex drag (thanks to perturbare) - Added GraphArea::EnableVisualsRenewOnFiltering property which is True by default. Specifies if visual graph should be updated up on relayout method call. - Added methods LogicCore::PushFilters(), LogicCore::ApplyFilters() and LogicCore::PopFilters along with LogicCore::Filters property which implements graph data filtering feature - Added LogicCore::IsFiltered property to identify graph filtering state. If graph is filtered the filter results can be applied or popped back. - Added new porperty EdgeControlBase::HideEdgePointerOnVertexOverlap which can hide edge pointer on zero length edge - Added new property EdgeControlBase::HideEdgePointerByEdgeLength to be able to hide edge pointers if edge length is less than or equal to the specified value. Off by default (0 value). - Fixed LogicCore::GetVertexSizeRectangles() method input params and description - Fixed incorrect edge pointer position on zero length edge - Fixed Avalon Dock interaction which caused strange exception by skipping ZooomControl viewfinder unnecessary refresh pass in some cases - Fixed edge label positioning, now it is more accurate for pathed edges - Fixed LinLog negative energy issue (thanks to Katya) - Fixed one vertex ISOM algorithm exception (thanks to jorgensigvardsson) - Fixed external alg vertex sizes grab logic (thanks to ValentinMarinov) - Made StateStorage class extensible by adding virtual modifiers to methods - Improved algorithm factory logic to avoid graph type cast exceptions in some class declaration cases - Improved calc performance for large graphs that use both OR and ER algorithms - Moved code extensions to GraphX.PCL.Common library thus eliminating the need for GraphX.PCL.Logic for *.Controls libraries - Removed GraphArea::EnableWinFormsHostingMode property as it is not needed any more. The WF checks has been automated. Go to the archive & sources download page NuGet version is also available
  4. Greetings everyone! Today we proudly announce the release of the GraphX for .NET PRO 1.0.0 version which is planned as our mainstream product! We have a great plans for it so you may expect more features and content to be added soon followed by special highlights. Feel free to read through this announce and ask us questions if you'll have some. So, what's inside? GraphX PRO utilizes open-source GraphX logic core making possible for you to use all the algorithms from this version and all the possible custom algorithms you already have. This also allows us to create new PRO algorithms compatible with open-source GraphX which is still a great visualization tool for templated interactive graphs. Using the PRO version you gain access to a set of new high performance controls designed to handle large data graphs in WPF and UWA environments by utilizing the low-level rendering techniques. These controls allows you to build your graph visualization from scratch skipping the heavy XAML templates and optimize overall performance by using fast and efficient graph object techniques. We also have an performance-tweaked zoom control and additional layout algorithms to play with. For example this highly customizable Radial Layout Algorithm can do the magic with the tree data graphs. Here are some GraphX PRO highlights we have to offer you: New controls for maximum rendering performance you can achieve in WPF. New low-level rendering techniques and plenty of performance optimizations allowed us to create controls better suitable for large data graph rendering and visualization. Also we have more performant ZoomControl to offer. New layout algorithms for better tree graph visualization with different configurable options, including Radial Tree Layout. Expect more algorithms to come soon. Extended support for both FREE and PRO GraphX products including the access to VIP customers area on the forums and guaranteed quick responses on all the questions related to GraphX and derived projects. Priority version updates and feature requests. Access to requested hotfixes in any desirable form and ability to request minor new features with top priority mark. More tools to work with will be added in the future including new algorithms, controls and much more. Special discounts and offers for other services including GraphX-based paid project development and feature implementation! On-demand source code access that includes full GraphX PRO source code sharing and support The Requirements? We want to supply our customers with the best software possible so we have to use modern tools to achieve the best performance and usability . GraphX for .NET PRO software requirements as follows: Visual Studio 2015 Community Edition or higher (for sample projects) .NET Framework 4.5* or higher * Compatibility with other framework versions is a subject for a discussion, feel free to contact us What about the license? GraphX for .NET PRO utilize subscription based licensing model which means you can get new product versions while your license is active and continue to use them even when your license is expired. You won't be able to use new product releases after your license is expired and you have to renew it to be able to do so. Each license is valid for one developer only but if you want to purchase GraphX PRO for many developers you can always contact with the Sales Department. Check the subscription details on our new web-sites: Have Something Special? Sure! We want to thank all our contributors and give them life-time -15% discount for indie and professional bundles if you'd contributed to GraphX before the PRO version release. We appreciate your work and hope to see you working with us on the free open-source GraphX version. Remember, buying our products also helps to push forward our open-source projects! For all the questions regarding the GraphX PRO please contact or use the order form below ** The text given above is not a public offer
  5. There has been some new data filtering features introduced In GraphX version 2.3.5. Let's see the quick review. In order to provide more flexible data filtering for GraphX the LogicCore::Filters property has been introduced representing the Queue<IGraphFilter<TVertex, TEdge, TGraph>> of custom filters. The queue means that the filters that are added into it are processed in a FIFO (First In First Out) order consequently modifying the graph. Filters are automaticaly applied on GraphArea::GenerateGraph() and GraphArea::RelayoutGraph() method calls before any visuals are calculated and ensures that all calculations will be done on filtered graph. In case of relayout, each relayout method call will initiate filtering process starting from "original graph". Original graph is the copy of the LogicCore::Graph property that is saved before first filter is applied on an unfiltered graph to have an untouched graph copy. Also we'd implemented dynamic visuals add/remove routine specially for the filters in the relayout process so during the each relayout method call GraphX will now check if there are vertices or edges that needs VertexControl/EdgeControl objects to be created/removed to reflect changes made by filters. This behavior can be turned off by setting GraphArea::EnableVisualsRenewOnFiltering property to False. You can check if graph is currently filtered by checking the LogicCore::IsFiltered property. Furthermore you have several methods to work with data filtering: LogicCore::PushFilters() - this method is called automaticaly as described above and applies LogicCore::Filters to LogicCore::Graph. You can also call it manually to push the filtering for your custom purpose. LogicCore::ApplyFilters() - this method will remove graph filtering, clear all filters, clear original graph and save filtered graph as unfiltered making the changes permanent. You want to make changes from filtering permanent? That is the method! LogicCore::PopFIlters() - this method will remove graph filtering, clear all filters, clear original graph and revert LogicCore::Graph property to original graph saved earlier. Want to revert all the filtering changes and restore the graph? You can do it! PS: Remember that while you operate with filtered graph you hold the original graph copy in the memory which can cause performance issues depending on the graph size. The graph data filter itself is very simple: public class BlueVertexFilter: IGraphFilter<DataVertex, DataEdge, BidirectionalGraph<DataVertex, DataEdge>> { public BidirectionalGraph<DataVertex, DataEdge> ProcessFilter(BidirectionalGraph<DataVertex, DataEdge> inputGraph) { inputGraph.RemoveVertexIf(a => !a.IsBlue); return inputGraph; } } It has only one method named ProcessFilter() that do all the stuff. This method receive some graph as the input parameter and shoud return the graph when it is done with the filtering. So, basically you will want to do the following: Create custom filters derived from IGraphFilter interface Add them to LogicCore::FIlters in desired order Run GraphArea::GenerateGraph() or GraphArea::RelayoutGraph() methods That's it! If you need this feature functionality expanded please let me know, thanks!
  6. SERVICE RELEASE 2.3.3 DETAILED CHANGELOG: - Exposed internal PrintHelper class with new CalculateEstimatedDPI() method which can calculate DPI required for image export based on specified criteria - Fixed arrows display issue when printing SERVICE RELEASE 2.3.2 DETAILED CHANGELOG: - Added GraphArea::ExportAsImageDialog() method which act as old ExportAsImage and the ExportAsImage() method now accepts file name to work without the dialog BREAKING CHANGES: - GraphArea::ExportAsImage() now takes file name as the first parameter and don't have save file dialog (use GraphArea::ExportAsImageDialog() instead) RELEASE 2.3.1 DETAILED CHANGELOG: - Added default templates for attached vertex and edge labels - Added HighlightBehavior::HighlightedEdgeType attached property that indicates In or Out edge is currently highlighted. Default value is None. - Added GraphArea::GetRelatedVertexControls() and GraphArea::GetRelatedEdgeControls() methods to fetch corresponding objects faster and easily - Added new printing logic. Now you can use GraphArea::PrintDialog() and GraphArea::PrintVisibleAreaDialog() methods with extended optional parameters - Added new image export logic. Now GraphArea::ExportToImage() method allows graph image export in original size via optional parameter - Added GraphArea::SetPrintMode() method which is used internally by print and image export methods but can be useful to override due to complex GraphArea print preparation logic. - Fixed excessive rendering issue when ZoomControl viewfinder is hidden. Should significantly increase performance of the viewfinder in this case. - Fixed showcase app edge example graph - Fixed ZoomControl viewbox logic to correctly react on zoom control background change - Improved attachable labels logic. Simplified base classes, added checks for mandatory base classes - Improved attachable labels customization possibilities by making several methods virtual BREAKING CHANGES: - Made DefaultLabelFactory class abstract and it is now accepts only one generic param (output object type) - GraphAreaBase now has new abstract members needed to be overriden in derived controls: GetRelatedVertexControls(), GetRelatedEdgeControls(), SetPrintMode() KNOWN ISSUES: - Graph image export may throw OutOfMemoryError for large graphs Go to the archive & sources download page NuGet version is also available
  7. Explanation As of pre GraphX version 2.3.0 there was only one possibility to add labels to vertices and edges: using VertexLabelControl and EdgeLabelControl objects definition in VertexControl and EdgeControl XAML templates. This logic was quite straightforward and solid due to label management was tightly integrated into the Vertex(Edge)Control class and there was some issues like: Label content were cut when fixed object size were used Labels can be obscured by edges or other vertices Edge endpoints behave strangely on certain type of edge label operations Now i want to introduce a new type of labels called attachable labels. As you might get it from the name these labels are presented as standalone objects that can be attached to specific Vertex(Edge)Control thus providing many new customization features and design possibilities. The most notable features of the attachable labels are: Independence from the host object size Enhanced control on the labels rendering order allowing to define how and where the new vertices will be inserted into Factory pattern implementation for labels generation logic provides unqiue customization possibilities for individual labels Simplified design and label handling logic that corresponds to true modular app design and helps to customize core GraphX logic more easily To start working with new labels you have to do following: (Optional) Add your own customized XAML template for AttachableVertexLabelControl and/or AttachableEdgeLabelControl. Default templates are built into GraphX controls library. Set GraphArea::VertexLabelFactory and/or GraphArea::EdgeLabelFactory properties specifying corresponding factories that will generate labels. There are default factories present such as DefaultVertexlabelFactory and DefaultEdgelabelFactory. Set Vertex(Edge)Control::ShowLabel property to true or use GraphArea::ShowAllEdgesLabels() and/or GraphArea::ShowAllEdgesLabels() methods to enable labels display. Then you'll have several usecases depending on how you work with GraphX: If you don't use automatic graph generation method and prefer to fill visual grah manualy then you should specify optional parameter generateLabel for GraphArea::AddVertex() and/or GraphArea::AddEdge() methods and such. You can also add them completely manualy but this kind of action isn't adviced. If you use automatic graph generation methods such as GraphArea::GenerateGraph() then you shouldn't do anything else at all. NOTES: You should remove any references of VertexLabelControl and EdgeLabelControl classes from XAML templates if you plan to use attachable labels. Attachable labels are created using factories so if label factory is set then labels will be generated though might not be visible due to ShowLabel property set to false by default. Implementing custom attachable labels You should note the following: Attachable label class should be derived from UIElement base class or some of its descendants Attachable label class should implement either IVertexLabelControl or IEdgeLabelControl interfaces depending on which label type you want to generate Attachable label class should implement IAttachableControl<T> interface where T is the host object class (for ex. VertexControl or EdgeControl) Tutorial I don't think i have to post detailed code tutorial here as you can always examine the GraphX source code. Just let me point where to look: Vertex label, Edge label attachable controls Default label factory
  8. RELEASE 2.3.0 WIP Highlights: Added new layout algorithm GroupingLayoutAlgorithm which allows to layout graph vertices by different groups each using its own sublayout algorithm. You can see it in action using new feature highlight in showcase app. Currently there are two modes supported: Layout groups to predefined bounds, when you can specify rectangular bounds in which vertices are layed out (Bounds must be supported by algorithm used to layout vertices group) Generate bounds from groups, when each group is layouted using its algorithm and bounds are automatically calculated to fit all vertices in the group and then group bounds overlaps can be removed. Added two new label controls AttachedEdgeLabelControl and AttachedVertexLabelControl which acts like separate entities in GraphArea visual tree and have weak references to graphx controls. Default EdgeLableControl and VertexLabelControl are designed to act as the part of their parent classes and this approach impacts their customization possibilities when these parent classes are limited in size. So with the new labels you can mitigate following restrictions: No more label cuts when vertex is strictly limited in width or height No more jerky edge endpoints when edge label is too large No more labels behind edges or vertices. You can control how to inject them. To use new labels you have to add AttachedVertexLabel and/or AttachedEdgeLabel XAML templates and also set GraphArea::VertexLabelFactory / EdgeLabelFactory. Detailed changelog: Added GroupId property to IGraphXVertex interface Added parameters class RandomLayoutAlgorithmParams for corresponding algorithm. It contains Bounds property which can restrict vertex coordinates to respect provided bounds. Added two methods to EdgeControl: GetEdgePointerForSource() and GetEdgePointerForTarget() which allows to get to edge pointer objects manually Added VertexShape.Ellipse math shape Added support for reversing the geometry. This is required for animating shapes along a path where the direction needs to be reversed without using the Storyboard.AutoReverse property (thanks to bleibold) Added two new attached label classes for Edge and Vertex controls. Added EdgeControl::LabelMouseDown event Added separate ID counter for edges while autoresolving missing id Added EdgeControl::UpdateLabel() method to be able to update attached edge label manually (tech means to overcome some template puzzles) Added GraphArea::GetChildControls() method to easily fetch any child objects (incl. custom) by condition or just get all of them Fixed id autoresolve issue when calling GraphArea::GenerateAllEdges() after manual edge data compilation (thanks to Hannes Hasenauer) Fixed some METRO code that hasn't been ported correctly Fixed an exception in ZoomControl caused by Ctrl + Alt + DblClick combination (thanks to persalmi) Fixed NaN result for FR algorithms calc (thanks to bleibold) Fixed edge bundling in the case when empty Control points are present that would sometimes cause exceptions.(thanks to bleibold) Fixed numerous event issues with GraphX controls where events wasn't passed down the hierarchy tree Fixed edge label size on some template manipulations by adding additional update on label size change event. You can turn it off using EdgeLabelControl::UpdateLabelOnSizeChange property. Fixed bindings to DefaultEdgePointer::Visibility property Improved styles flexibility by working with dependency values instead of straight assignment in some places Improved random layout algorithm randomness by seeding new Guid hash which fixes some odd behavior in rare cases Improved overall graph cleaning in different areas allowing to easily clean graph data and fix potential memory leaks Implemented edge cut logic for EdgePointer placed at edge 'source' to gain better visual quality like its 'target' counterpart Implemented many changed in algorithm base classes, mainly in AlgorithmLayoutBase: made VisitedGraph and VertexPositions props assignable externally Implemented RandomLayoutAlgorithms to derive from LayoutAlgorithmBase class Merged GraphArea code for WPF & METRO into a shared files Merged EdgeControl and VertexControl code for WPF & METRO into the shared files Breaking changes: IExternalLayoutAlgorithm interface now demands TEdge generic specification and have one new method ResetGraph(). All built-in algorithms now use IMutableVertexAndEdgeSet<TVertex, TEdge> for TGraph generic specification to be able to modify Graph data on demand. Made Vertex and Edge ID Int64 be default. Was Int32. Added mandatory IOverlapRemovalAlgorithm::Initialize() method for all OR algorithms to be able to initialize initial data not only when you instantiate class but at any time Go to the archive & sources download page NuGet version is also available
  9. Hello. I have downloaded sample. In WPF Showcase App in EditorGraph page I have found interesting issue. When I press control and pick vertex new edge appears. And if I place edge pointer on editor (without picking another vertex) new edge is created. But, for some reason, in many cases edge pointer ponts on top left corner of vertex (first picture). I decided to check the issue and modified code of the EditorGraph.CreateVertexControl method. In my case this method creates two connected vertexes at once. private VertexControl CreateVertexControl(Point position) { // Commented code from the sample //var data = new DataVertex("Vertex " + (graphArea.VertexList.Count + 1)) { ImageId = ShowcaseHelper.Rand.Next(0, ThemedDataStorage.EditorImages.Count) }; //graphArea.LogicCore.Graph.AddVertex(data); //var vc = new VertexControl(data); //graphArea.AddVertex(data, vc); //GraphAreaBase.SetX(vc, position.X, true); //GraphAreaBase.SetY(vc, position.Y, true); var data = new DataVertex("Line Start " + (graphArea.VertexList.Count + 1)) { }; graphArea.LogicCore.Graph.AddVertex(data); var vc = new VertexControl(data); graphArea.AddVertex(data, vc); GraphAreaBase.SetX(vc, position.X, true); GraphAreaBase.SetY(vc, position.Y, true); var enddata = new DataVertex("Line End" + (graphArea.VertexList.Count + 1)) { }; graphArea.LogicCore.Graph.AddVertex(enddata); var endvc = new VertexControl(enddata); graphArea.AddVertex(enddata, endvc); GraphAreaBase.SetX(endvc, position.X + 200, true); GraphAreaBase.SetY(endvc, position.Y, true); VertexControl oldFrom = null; if (_ecFrom != null) { oldFrom = _ecFrom; } _ecFrom = vc; CreateEdgeControl(endvc); _ecFrom = oldFrom; return vc; } And I get two connected vertixes, but edge is placed like on the second picture. How can I resolve this issue?
  10. Hellow fellow members of GraphX community! I want to thank you for your dedication and contributions for all these yars. Let me introduce this donation topic for those of you who are willing to support GraphX development even more. In the past we'd completed several significant tasks related to GraphX by requests and received generous donations as the reward for these tasks. We assure you that we're always opened for requests on both free and commercial basis as each of the requests brings something new to open-source GraphX releases. Currently, if you want to be the part of GraphX community you can: Contribute your code Donate any amount of money which will be spent on open-source GraphX improvement Request for a GraphX based project development service at If you have any questions, please contact us at And, here it goes: Let me once again thank all of you who participated in GraphX developement in any way for several years. Especialy: Tom Verheijen perturbare jorgensigvardsson stefanpe Paul Mandalka bleibold thinkJD birbilis
  11. RELEASE 2.2.0 RELEASE NOTES: New features can still have some bugs as there are many scenarios that might involve them and it's hard to check all of them on my own. If you feel uncomfortable with anything in this release please let me know. I appreciate any feedback as this is almost the only reason i'm still working on GraphX. Thanks! NEW TERMS: VAESPS - vertex and edge skip processing support VCP - vertex connection point HIGHLIGHTS: VCPs has been added into GraphX making edge endpoint fixation(binding) possible. By default GraphX automaticaly calculates edge endpoint position relative to vertex dimensions and approximate math shape, but with this feature on you'll be able to bind edge endpoint to a separate customizable object. This will allow you to create static edge fixation endpoints on the vertex and give you full control over edge endpoints positioning. Now GraphX for WPF requires only .NET Framework 4.0 to build & run. Deprecated all code that required .NET 4.0.3 Now you can easily customize edge pointers with the help of DefaultEdgePointer class which can host any content including Image/Path and supports rotation. Changes include more precious edge endpoint calculations so the edge will overlap with the edge pointer no more. Because of these changes the old logic that utilizes direct Path object in EdgeControl template will be removed completely in favor of notable performance improvements. Serialization has been decoupled from GraphX completely to allow bring much more freedom to custom serializers. All what GraphX do now is provide serialization data and accept serialization data for deserialization. Serialization classes are not limited by interfaces now. See FileServiceProviderWpf class for an example. Now you can use "" XAML namespace in GraphX for WPF for all its visual content. Additionaly, assemblies (and output filenames) for WPF/METRO dlls are both changed to GraphX.Controls.dll so Post-Build process copies output files to GraphX/Bin folder with distinct filenames reflecting the platform as before. Performance improvements are always welcome. In this release the whole layout calculation logic has been revisited in terms of both performance and code quality gains. We've also eliminated some redundant layout updates, moved all math & algorithms handling from GraphArea directly to LogicCore under better async implementation, cleaned up ZoomControl logic, revisited edges & edge labels code to remove redundant calculation passes. DETAILED CHANGES: Added support for custom VCP [WPF, METRO] * New control class added: StaticVertexConnectionPoint. It represents ContentControl which can host virtualy any valid object. * VCP supports the same math shapes as VertexShape property or can use VertexShape::None value to disable precise edge endpoint calculations Added vertex and edge skip processing support to METRO version (VAESPS) [METRO] Added VAESPS for following algorithms: Circular [ALL] Added VertexShape::None enum option, currently affecting only VCP logic [ALL] Added different layout options to EfficientSugiyama algorithm using new Direction param [ALL] Added true orthogonal edge routing for EfficientSugiyama algorithm using EdgeRouting param [ALL] Added new property GraphArea::ControlsDrawOrder which defines vertex or edges should be drawn topmost [WPF, METRO] Added GraphArea::PreloadGraph() method for manual graph rendering which generate vertices and edges from GraphArea::LogicCore.Graph property w/o any algorithms and also sets vertices positions if needed [WPF, METRO] Added new EdgeControl template PART (PART_SelfLoopedEdge) for custom self looped edge indicator visualization. It represents FrameworkElement and if specified in the template will be positioned in the top left vertex corner. Also made indicator settings more flexible by implementing some dependency props [WPF, METRO] Added StateStorage::SaveOrUpdateState() method for easier use [WPF,METRO] Added new read only property EdgeControl::IsParallel that identifies edge as currently parallel to other edge. Made GraphArea::UpdateParallelEdgesData() method public to be able to refresh IsParallel property on manual graph operations [METRO, WPF] Added EdgeLabelControl::FlipOnRotation dependency property which controls if label should be flipped when axis is changed while rotating [WPF, METRO] Fixed parallel edges labels handling. Now edge labels are more readable when there are two of them [WPF, METRO] Fixed edge routing when graph state has been loaded. Graph state now stores AlgorithmStorage too [ALL] Fixed ZoomControl zoom-out to the value equal to zoom-in resulting in similar smooth zoom [WPF, METRO] Fixed ZoomControl::Zoom property change not firing [WPF, METRO] Fixed manual graph composition routines in case of ER algorithm is set [ALL] Fixed layout algorithm calculations to always receive actual vertex positions as input parameter. This will fix VAESPS for default algorithms. [WPF, METRO] Fixed outdated edge rendering in some cases when vertex coordinates are changed manually [WPF, METRO] Fixed edge overlapping edge pointers [WPF, METRO] Fixed use of ControlFactory for edge deserialization [WPF, METRO] thanks to perturbare Fixed some algorithm calculation problems, especial FR [ALL] Fixed EdgeControl.ShowArrows to implement DependencyProperty [WPF, METRO] thanks to perturbare Fixed minor performance problems in ZoomControl [METRO] Fixed and enhanced automatic data object Id resolve logic [WPF,METRO] thanks to perturbare Fixed ZoomControl zoom sometimes not firing from code call after control is loaded [WPF] Fixed VB sample project dependencies and refactored code a bit Reorganized Example apps namespaces and code for greater good Made EdgeControlBase::UpdateEdge() method public. It can be used now to fully update edge visual on custom edge-related modifications [WPF, METRO] Improved main layout calculation logic to gain performance improvements [WPF, METRO] Merged EdgePointerImage and EdgePointerPath into one universal DefaultEdgePointer class [WPF, METRO] Improved edge and its template parts rendering/calc performance [WPF, METRO] Enhanced edge labels logic so now it don't require additional template bindings and modifications (Angle or RenderTransform) [WPF] GraphArea::PreloadVertexes() now accepts graph param as optional (null by default) and uses LogicCore.Graph in that case [WPF, METRO] Decoupled serialization logic from GraphX completely [ALL] thanks to perturbare Adjusted FR and BoundedFR default values for random initial positions [All] Now GraphX for WPF requires only .NET Framework 4.0 to build & run [WPF] Refactored almost all of the GraphX code for improvements and code quality. Changed many namespaces for better name reflection [ALL] BREAKING CHANGES: !!!WARNING!!! This GraphX version has fallen under the heavy hand of code refactoring and along with the numerous code improvements almost ALL of the namespaces has been changed to better reflect logical code grouping and ease additional platform support through code reusability. Also i've get rid of the several different XAML xmlns usings in favor of single one. I'm very sorry that this changes will force you to update your GraphX projects but i realy felt that i must do it once and for all. You will have to change most of the usings in code and XAML templates: i strongly recommend you to use Resharper or any other code quality tool which will help you to do this in minutes (or even seconds). Core changes: - All controls, behaviours and their interfaces are moved to GraphX.Controls namespace - All algorithms are spreaded across GraphX.PCL.Logic.Algorithms namespace with additional OverlapRemoval, LayoutAlgorithms, EdgeRouting endings - All base models and interfaces are now in GraphX.PCL.Common.Models namespace - All GraphX primitives (Point, Rect, etc.) are left in GraphX.Measure for better code readability in cases when they are intersected with System.Windows namespace twins IGXLogicCore now include ExternalLayoutAlgorithm, ExternalOverlapRemovalAlgorithm, ExternalEdgeRoutingAlgorithm properties for simplier external algo assignment Now GraphX for WPF requires only .NET Framework 4.0 to build & run Serialization decoupling process changes some method names: GraphArea::SerializeToFile() -> GraphArea::ExtractSerializationData() and GraphArea:: DeserializeFromFile() -> GraphArea::RebuildFromSerializationData() EdgeLabelControl no longer needs default Angle binding and RenderTransformOrigin setup. They are processed internally [WPF] GraphArea::GenerateGraph() method now has generateAllEdges param True by default. Renamed following peoperties, moved them to EdgeControlBase and implemented them as DependencyProperty: - LogicCore::EdgeSelfLoopCircleOffset -> SelfLoopIndicatorOffset - LogicCore::EdgeSelfLoopCircleRadius -> SelfLoopIndicatorRadius - LogicCore::EdgeShowSelfLooped -> ShowSelfLoopIndicator Renamed following ZoomControl properties: - ZoomDeltaMultiplier -> ZoomSensitivity - MaxZoomDelta -> MaximumZoomStep Completely deprecated EdgeControl::PART_edgeArrowPath template PART in favor of the new DefaultEdgePointer (PART_EdgePointerForSource & PART_EdgePointerForTarget). Please renew your custom templates. You can find an example in Generic.XAML template. Self looped edges display logic has been slightly changed with the introduction of custom template PART (PART_SelfLoopedEdge). Now LogicCore::EdgeSelfLoopElementOffset is (0,0) by default and indicator is shown in the top left vertex corner minus indicator size. You can change this behavior by overriding EdgeControl::PrepareEdgePath() method. GetVertexSizeRectangles() method moved from GraphArea to LogicCore. Edge labels placement logic has been slightly changed when they are applied to parallel edges. Labels offset now translates them into different directions, for ex. one up, one down, one up.. etc. This behavior helps to better place labels for double parallels. Also parallel edge labels now are not flipped when axis changes during label rotation. If you're uncomfortable with these changes, please let me know!
  12. We're actively looking for people interested in GraphX imporvement! New features and improvements are always wanted for such complex project as GraphX. What do we want to see in you? - Be interested in GraphX idea and have basic knowledge of graph theory - Be interested to contribute to open-source GraphX GitHub repository - Be able to communicate in english or russian language For example, here are some interesting improvements GraphX project might have: - New platform support: Silverlight, Windows phone, ASP.NET, Xamarin, etc. - New algorithms of all kinds, for example new layout algorithms like baloon trees - New edge routing algorithms like orthogonal edge routing - Edge and vertex labels overlap removal - New zoom control features and improvements - New fancy templates for GraphX controls REMEMBER, we will be glad to see your Pulls in GitHub repo no matter what We're also ready to review any proposals regarding GraphX you might have with your own terms. If you have any questions or proposals you can contact us at Thank you for reading this! Hope to see you soon
  13. Following features must be implemented manualy in your algorithm in order to work properly: 1. VAESPS - vertex and edge skip processing support Freeze mode.
  14. Vertex and edge skip processing support (VAESPS) is a feature that allows you to mark separate vertices or edges to be treated by algorithms in a desired manner. As of version 2.1.9 only vertices are supported and only several layout algorithms are supported for Freeze option as well. Exclude option works for any algorithm. List of supported layouting algorithms: Random Circular Any custom external algorithm if implemented Each vertex or edge have SkipProcessing property available which can hold following values: Default - treat object as usual. Object will take part in all calculations. Freeze - treat object as frozen, so its position will not be affected by following layout calculations. Exclude - don't treat object as anything at all so it will be completely skipped by layout calculations. Actual vertex positions will be supplied to layouting algorithm before every invocation therefore you should be aware of the following situations: 1. If you'll mark vertices with Freeze before initial graph generation then these vertices will have NaN position value and will not be displayed. You should manualy set initial coordinates for each marked vertex in this case using VertexControl::SetPosition() method. Tutorial There is not much to say on the topic for now. You have to mark object using SkipProcessing property any time you want and then generate/relayout the graph. Excluded vertices are not included in any consequent calculations so you can effectively use this option to work with a subset of nodes in a complete graph. Frozen vertices are meant to add some "stable" vertices to graph which are not affected by relayouting themselves but affects other vertices in a layout calculation.
  15. For the tutorial please follow THIS LINK. Thanks to Kindrashunt!
  16. Here you can find GraphX extensibility features documented for the version number pointed in topic title. VertexControl and EdgeControl customization It is possible to customize VertexControl and EdgeControl objects through control factory. You have to implement custom control factory using IGraphControlFactory interface and then implement CreateVertexControl() and CreateEdgeControl() methods to create custom edge and vertex controls based or configured on your own logic. You can find an example code under the cut: You can also override main methods for EdgeControl such as UpdateEdge to control edge points generation in derived class. Vertex and edge custom animations There are several types of animation present in GraphX based on the action. Each custom animation can be assigned to corresponding GraphArea properties. IBidirectionalControlAnimation is responsible for MouseOver animation. It can perform two-way animation for both vertex and edge. EXAMPLE IOneWayControlAnimation is responsible for control delete animation. It can perform one-way vertex or edge animation. EXAMPLE MoveAnimationBase class is responsible for control movement animation. It can perform vertex and edge animations. EXAMPLE Each animation should implement Completed event to correctly track animation completion for different other features. IOneWayControlAnimation should also handle if underlying data object should be removed from the graph when animation is finished. This can be done by specifying correct value in Completed event call. File serialization GraphArea provides two methods for data serialization and deserialization. Using these you're able to save and load graph operations. File serialization is not implemented by default in GraphX library release though you can see examples in ShowcaseApp.WPF. GraphArea methods description: void RebuildFromSerializationData(IEnumerable<GraphSerializationData> data); Serializes supplied data to list of data objects in GraphSerializationData format where you specify object data and position. List<GraphSerializationData> ExtractSerializationData(); Deserializes data from data objects list. Edge pointers IEdgePointer interface provide capability to create custom edge pointer class that can be specified in EdgeControl template. Derived class will be responsible for edge pointer rendering for the graph edges. Two different objects can be added to the template with two different names: PART_EdgePointerForSource and PART_EdgePointerForTarget. The first one is for edge source connection point and the second one for edge target connection point. Both of them are completely optional. You can see example here. Resulting objects are affected by EdgeControl::ShowArrows property. Interface members description: bool NeedUpdate property specifies if object angle should be calculated and sent into Update() method Update(Point? position, Vector direction, double angle = 0d) method is executed each time edge is updated. Its parameters supply your object with position, direction and angle data to correctly place an edge pointer. Hide() & Show() methods are responsible for object visibility. Edge labels IEdgeLabelControl interface provide capability to create custom edge label that can be specified in EdgeControl template. Derived class will be responsible for edge label rendering for the graph edges. Old labels system demands that edge label should be declared in host control XAML template and have PART_edgeLabel name to be correctly processed by the EdgeControl. You can see an example here. New attachable labels demand that resulting class should be derived from IAttachableLabel<T> interface and label factory pattern should be used. You can read the detailed explanation here. Resulting objects are affected by the following EdgeControl properties: LabelAngle, UpdateLabelPosition, ShowLabel, AlignLabelsToEdges Interface members description: Angle property receives rotation angle for object in degrees relative to how approximate edge center is positioned - each time edge is updated. UpdatePosition() method is called every time an edge is changed. UpdateLayout() method is called when edge label data is needed and it is not yet created by WPF. Here you should implement smth like UIElement::LayoutUpdate() logic if you're not deriving from UIElement class or one of its descendants. Rect GetSize() and SetSize(Rect size) methods are needed to query and set edge label size in rectangular format. Hide() & Show() methods are responsible for object visibility. You can also override UpdatePosition method to control label placement in a derived class. Vertex labels IVertexLabelControl interface provide capability to create custom vertex label that can be specified in VertexControl template. Derived class will be responsible for vertex label rendering for the graph vertices. Old labels system demands that vertex label should be declared in host control XAML template and have PART_vertexLabel name to be correctly processed by the VertexControl. You can see an example here. New attachable labels demand that resulting class should be derived from IAttachableLabel<T> interface and label factory pattern should be used. You can read the detailed explanation here. Resulting objects are affected by the following VertexControl properties: LabelAngle, ShowLabel Interface members description: Angle property receives rotation angle for object in degrees each time vertex is updated. UpdatePosition() method is called every time a vertex is changed. Hide() & Show() methods are responsible for object visibility. You can also override UpdatePosition method to control label placement in a derived class.
  17. METRO support has been introduced with the latest source upload into PCL branch. This is still beta so don't expect stable release anytime soon. Feel free to test it and leave some feedback. Basicaly, two new projects has been added: GraphX.METRO.Controls - core library Examples/METRO.SimpleGraph - example project There are some functionality limitations compared to WPF GraphX version that hopefuly will be reimplemented in future releases. Currently there are some issues that has not yet be resolved (including edge labels handling).
  18. Please feel free to show us your opinion on the subject. Remember, that your vote can affect the future of GraphX development. If you have other suggestions for porting you can freely share them in this thread. Thanks! PS: Stage 2 incoming
  19. Most notable addition to GraphX in this release are vertex lables implementation and Nuget dependencies support. All other changes mostly consist of bug fixes and misc improvements. Change log: + Added vertex control labels with following functionality: + 2 available positioning modes: by sides or by coordinates + Always attached to vertex and moves with it + Rotation angle support + Same template logic as in EdgeLabelControl + Added key modifiers to vertex event args + Added XAML templates usage example in WF project + Added new layout type Custom. When set layout algorithm calculation is skipped completely and manually added data is used for OR and ER algorithms (if any). + Added (reintroduced) GraphArea::SideExpansionSize property which gets or sets additional space for GraphArea borders. Useful for zoom adjustments when custom text or controls which are not used in size calculations must fit into the zooming. + Added IGraphControlFactory-Interface and Implementation for Edge and Vertex controls creation (thanks to Paul Mandalka) + Added simple Nuget-Package specification for GraphX (use createPackage.bat to create the nuget package for GraphX) (thanks to Paul Mandalka) + Added new ZoomControl::ZoomAnimationCompleted event (thanks to Paul Mandalka) + Fixed hidden edges update on vertex drag + Fixed PrintHelper::ExportToImage method to use DPI-Settings for Image Rendering (thanks to Paul Mandalka) + Fixed labels rendering for parallel edges. Now they are displayed separately for each edge. + Fixed async calculations being broken due to LogicCore property became dependency + Fixed ViewFinder not deriving ZoomControl content background + Fixed edge label update on alignment change + Fixed self-looped edges handling in GraphArea::GenerateEdgesForVertex() method + Fixed bugs with edge routing calculation in some cases + Fixed: Graph-Area LogicCore Property was registered using GraphAreaBase which could cause a problem (thanks to Paul Mandalka) + Fixed visual properties recovery terminating template values + Fixed Sugiyama and EfficientSugiyama algorithms calculation with only one vertex + Implemented some properties as dependencies + Implemented EdgeControl::IsSelfLooped property as read-only dependency property. + Reworked EdgeLabelControl inner logic. Should now be more flexible and performance efficient. + Reworked main objects hierarchy to use more interfaces for loosened conditions + Some code refactoring. Minor performance improvements. VISIT DOWNLOADS PAGE
  20. It appears there is no active usage of QuickGraph.Serialization.dll. Is this because YAXLib is being used for serialization? Is it safe to remove this dependency? Thanks!
  21. I'm just curious exactly what code was used from NodeXL and if that code offers me anything in particular. Or is it just buried down deep in GraphX for internals only? I'm asking because NodeXL looks interesting...
  22. It seems that i've accidently created two different GraphX repositories on GitHub while studying GitHub windows client Currently, i've deleted GraphXv2 repository and now only true GraphX repo left. Sorry for any inconvinience it possibly caused.
  23. Finally GraphX v2 has made it to the public. Though it don't have much new features it definetly bring new capabilities and architectural improvements. Starting from this product version it is now possible to move forward the porting solutions with ease. Currently there are no officialy released ports but there is work in progress for Silverlight and Windows 8 solutions. Most notable features for this version are: Portable architecture support. Still testing, but all of the core features except file handling and serialization has been made PCL compliant. Separated algorithms in standalone GXLogicCore class. Now you can easily use all GraphX algorithms separately from visual stuff. ZoomControl enchanced. Merged most viable features of ZoomControl and Zoombox into one control and made smooth graph representation while dragging vertices. Parallel edges support and rotated edge labels. Further enchanced edge visualization by implementing parallel edges vis between same vertices and labels aligned to the edge by angle. There are some key moments that you must be aware of that can break old v1 projects. They are: GraphArea now uses coordinates system that place objects by TOP-LEFT corner. Old system operated by object CENTER coordinates. So you need to check your logic to be sure that you operate with coorect coordinates. GraphArea canvas object real size now always (10, 10) so if used separately from ZoomControl it must be centered in container. No matter what its children are placed relatively so the whole picture looks the same. Zoombox has been removed. Use enchanced ZoomControl instead. If you lack any features, please let me know. Also currently it is not possible to use ZoomControl for hosting objects other than GraphArea out of the box. If you need it for other purposes ypou have to modify its interaction logic with GraphArea. All logic has been moved from GraphArea to GXLogicCore. You need to modify calls to methods and properties in your code, please look at the examples provided in source code. Source code and documentation updates will follow soon. Changelog: + Spearated GraphX into the 3 projects: GraphX.Common, GraphX.Logic and GraphX.Controls. Each project serves its own purpose. GraphX.Logic contains all the logic and algorithms GraphX.Common contains common objects between logic and visual controls GraphX.Controls contains visual controls and all associated classes + Added GraphArea.LogicCore property that must be set in order to be able to work with GraphArea + Added parallel edges logic call in GraphArea.UpdateAllEdges() method + Added some code improvements and corrections, made some classes internal, abstract or sealed + Added EdgeControl::AlignLabelsToEdges and EdgeControl::LabelVerticalOffset properties that implements edge labels alignment to edges at different angles. Labels now can be placed at the same angle as edge is drawn and optionaly offseted up or down to not overlap the edge itself. + Added some recently implemented features to Showcase app + Added optional param to GraphArea::GenerateAllEdges() that enables GraphArea layout update before edges calculation. True by default. + Added minimap from Zoombox to ZoomControl and changed some of its features. + Added new method ZoomControl::ZoomToContent() that should be used instead of ZoomTo() method + Added ZoomControl display in VS design view with minimap preview + Slightly improved rendering performance for large graphs + Fixed long living issue with zoom content resize and vertex drag which involves following global changes: + Correct GraphArea size rectangle can now be only determined by GraphArea::ContentSize property whcih contains rectangle that includes all viusuals added. GraphArea visual size remains ALWAYS intact at (10,10). + Now all vertices and edges positioned in GraphArea using TOP-LEFT corner as the position coordinates (previously coordinates was pointing at the object center). + ZoomControl now closely tied with GraphX, though it can be made universal + Fixed edge labels rendering issue + Fixed some showcase app exceptions + Fixed edge labeling showcase example + Fixed GraphArea in design diplay mode + Fixed ParameterizedLayoutAlgorithm exception (thanks to thinkJD) + Fixed parallel edges calculations in case of opposite-directed edges (thanks to thinkJD) + Fixed invalid parallel edges detection in some cases (thanks to bleibold) - Image export currently supports only ZoomControl visible area export - Moved ImageType enum into GraphX namespace - Moved all properties associated with logic from GraphArea to GXLogicCore class - Removed Zoombox from project completely (now only ZoomControl is supported and being actively enchanced) VISIT DOWNLOADS PAGE
  24. If you're reading this then let me wish you a hapy new year! No matter why you've come here, for fun or for business i whish you a lot of hapiness and prosperity. Let your wishes come true and don't forget to work hard towards that direction as our future and our dreams are all in our own hands... mostly! Anyway, i wish the new year to bring us all something new and exciting! Cheers, PDW team
  25. InfoQ has posted an interview recently about graphs and GraphX in particular. You can read an article here: That is another little reason to be proud of the work that has been done