[PLUG] About to start developing a new Graphing (as in mathematical graphs) program

M. Edward (Ed) Borasky znmeb at cesmail.net
Sat Jun 9 19:32:27 UTC 2007


Robert Jeffrey Miesen wrote:
> Hi all.
> 
> 
>    I'm currently in the planning phase of designing a new graphing
> application (as in the discrete math kind, not the calculus kind). My
> primary intent in writing this application is to create a GUI front-end
> for a graph library that extends the boost C++ library to suit more
> specific kinds of graphs (like, say UML or E-RD.) This isn't meant to be
> a clone of Visio, but is rather meant to focus on providing a front-end
> for users to do graphical analysis on their graphs (such as finding the
> number of cycles in their graphs, getting the number of outgoing and
> ingoing connections between nodes (where a node can be either just a
> plain old node or a specialized node like a UML class or a database
> table), auto-balancing graphs based on the number of ingoing and
> outgoing connections, finding the shortest paths and so on and so forth.
> As I envision it, these functions can have special meaning inside
> certain modes (such as Plain Old graph mode, UML mode, or ERD mode or
> whatever other modes there may be).
> 
> 
>    Architecture wise, I currently plan to write this application in C++
> using QT4 and possibly the KDE widget set (whatever it's called). I wish
> to use this architecture because C++ is a stable, proven language that
> is supported DFSG-wise (Debian Free Software Guidelines) across every
> major platform (including Windows---an important consideration in this
> case.) I wish to use QT4 and, if it's multi-platform compatible, the KDE
> libs and widgets (I honestly don't know, namely because I've never tried
> to compile KDE under Windows) because they are:
> 
> 
>   1. Well designed: They implement the standard composite design
>      pattern both correctly and in a manner that can be both easily and
>      effectively exploited in the originally-supported language (for
>      those who don't know, GUI widget sets tend to be designed using a
>      Composite pattern, which enables widgets to be built in a
>      hierarchy of widgets, which consist of Leafs and Components. A
>      Leaf cannot have any Leafs or Components, but a Component (like a
>      frame widget) can hold either more Components or Leafs. For a more
>      detailed discussion of the Composite design pattern, look it up by
>      name in "Design Patterns: Elements of Reusable Object-Oriented
>      Software" or check it out at
>      http://en.wikipedia.org/wiki/Composite_pattern.)
> 
>   2. Operating system-independently free: As long as the program being
>      written is licensed under the GPL licensing scheme (which it will
>      be), your program can be distributed freely, under both Linux
>      /and/ Windows (see
>      http://trolltech.com/developer/downloads/qt/windows.)
> 
>   3. Stable and reliable: Both C++ and QT4 have been around for a long
>      time and both appear to be quite stable and reliable: both from a
>      design perspective and a QA perspective.
> 
> 
>    I also plan to draw certain design ideas from a few existing
> graphing-like applications. Namely:
> 
>    * Kivio: The front-end they use for their graphing library. It is
>      nicely done and a lot can (and should) be drawn from it.
> 
>    * Umbrello: It automates certain things about building UML diagrams.
>      Namely, they automate the implementation of abstract methods and
>      (should) auto-inherit public and protected methods. These would be
>      useful generalize and allow the user to decide if and when they
>      want these automated features active (like, for example, I
>      shouldn't be forced to have aggregations going to diagram-defined
>      classes when I've specified them as attributes of a class, even if
>      it's "correct").
> 
>    * Visio: It implements custom nodes of some sort and should probably
>      be looked at.
> 
>    * PIGALE: It seems to do a lot of the stuff I'm talking about, and a
>      few concepts not really seen in most graphing programs, such as
>      multi-dimensional graphs. This should be looked into by all means.
> 
> 
>    I'm posting a notification of this here because this is my first
> major project---open source or otherwise---and I could use some advice
> from a veteran open source software developer on the logistical and
> pragmatic ends of open source development. I'm also looking for anyone
> interested in joining me in developing this graphing program. I've
> already submitted this project for consideration for hosting at
> sourceforge.net and, if all goes well, it will be approved soon. I'd
> also like feedback in general on my ideas in general. Is what I'm
> planning something others would be interested in or am I just
> reinventing the wheel?
> 
>    Thanks in advance for all your support!
> _______________________________________________
> PLUG mailing list
> PLUG at lists.pdxlinux.org
> http://lists.pdxlinux.org/mailman/listinfo/plug
> 

1. A couple of other wheels that you might want to look at:

a. Dia/dia2code/tedia2sql
b. Graphviz
c. XFig

You've looked at Visio, Kivio and Pigale, which I haven't seen.

2. QT4 is an excellent toolkit and is available in open source for for
Windows, unlike its predecessors. Unless you're hell-bent on sticking
with C++, I'd recommend using a "scripting language" like Perl, Python
or Ruby, though. All of them have excellent bindings to QT4 and IIRC to
"boost" as well. And you don't have to recompile stuff to be
cross-platform -- the scripting language interpreters and run-times are
cross-platform by design.

3. KDE sorta kinda can be made to work on Windows. I have no idea about
Macs, though. By "sorta kinda can be made to work", I mean:

a. First you have to load CygWin
b. Then you have to go to the CygWin "ports" project and find a recent
version of KDE and all the libraries.
c. Then you have to start up KDE, and it's slower than the proverbial
January molasses.

In short, my recommendation is that you design at the QT4/scripting
language level and let the scripting language libraries take care of
integration with the platforms/desktops (Windows, Mac, Linux/Gnome,
Linux/KDE and Solaris)





More information about the PLUG mailing list