[PLUG] About to start developing a new Graphing (as in mathematical graphs) program
Robert Jeffrey Miesen
bobby_miesen at yahoo.com
Sat Jun 9 05:55:08 UTC 2007
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!
More information about the PLUG
mailing list