Hi All,
I recently added the "rectangle overlap removal" algorithm to inkscape and received so much useful feedback (advice, testing and so on) throughout the process that I'm now quite keen to start another project.
The connector stuff that was introduced in 0.43 is a really powerful concept and makes inkscape much more of a "diagramming" tool. Between the connector routing and the overlap removal stuff we have the basics of some nice automatic diagram layout. I'd like to continue this by incorporating some "graph layout" algorithms to adjust the positions of objects at the end of connectors to achieve things like minimal crossing of connectors and to better show coupling and cohesion in the network (graph) defined by the connectors.
I'd appreciate any feedback people have on this idea. Also, I'd really like to use the boost 'graph' libraries to get this happening quickly. Boost already has some basic layout algorithms which we can use right away, but I'll also need the underlying graph data-structures and algorithms in boost to implement new algorithms. What are the logistics of adding boost to the inkscape dependency tree?
I've noticed similar requests for boost in the inkscape-devel archives... it seems like I'm not the only one who would benefit.
Looking forward to your comments,
Cheers
Tim
My 2Eu on this connector thing.
The thing that I am really missing is a way to easy make some corners in the connector while connecting. And also the corners can all have a default radius.
Right now I have to modify the connection AFTER connection has been done.
Thanks for spending your effort.
Adib.
Tim Dwyer schrieb:
Hi All,
I recently added the "rectangle overlap removal" algorithm to inkscape and received so much useful feedback (advice, testing and so on) throughout the process that I'm now quite keen to start another project.
The connector stuff that was introduced in 0.43 is a really powerful concept and makes inkscape much more of a "diagramming" tool. Between the connector routing and the overlap removal stuff we have the basics of some nice automatic diagram layout. I'd like to continue this by incorporating some "graph layout" algorithms to adjust the positions of objects at the end of connectors to achieve things like minimal crossing of connectors and to better show coupling and cohesion in the network (graph) defined by the connectors.
I'd appreciate any feedback people have on this idea. Also, I'd really like to use the boost 'graph' libraries to get this happening quickly. Boost already has some basic layout algorithms which we can use right away, but I'll also need the underlying graph data-structures and algorithms in boost to implement new algorithms. What are the logistics of adding boost to the inkscape dependency tree?
I've noticed similar requests for boost in the inkscape-devel archives... it seems like I'm not the only one who would benefit.
Looking forward to your comments,
Cheers
Tim
On Wed, 1 Feb 2006, Adib Taraben wrote:
The thing that I am really missing is a way to easy make some corners in the connector while connecting.
Am I right in understanding that by "make some corners" you want to able to add extra control points to a connector that the route will travel through? That is, the connector is automatically routed between the start-point and control point, as well as between the control point and end-point, while still being a single connector. There would be controls for such a control point to allow it to be moved, deleted, etc.
And also the corners can all have a default radius.
A couple of people now have suggested (allowing) smoothing the corners of the current poly-line connectors, this is pretty trivial to do so I will add the ability to the connector tool shortly.
Cheers, Michael
Tim Dwyer wrote:
Hi All,
I recently added the "rectangle overlap removal" algorithm to inkscape and received so much useful feedback (advice, testing and so on) throughout the process that I'm now quite keen to start another project.
The connector stuff that was introduced in 0.43 is a really powerful concept and makes inkscape much more of a "diagramming" tool. Between the connector routing and the overlap removal stuff we have the basics of some nice automatic diagram layout. I'd like to continue this by incorporating some "graph layout" algorithms to adjust the positions of objects at the end of connectors to achieve things like minimal crossing of connectors and to better show coupling and cohesion in the network (graph) defined by the connectors.
I'd appreciate any feedback people have on this idea. Also, I'd really like to use the boost 'graph' libraries to get this happening quickly. Boost already has some basic layout algorithms which we can use right away, but I'll also need the underlying graph data-structures and algorithms in boost to implement new algorithms. What are the logistics of adding boost to the inkscape dependency tree?
I've noticed similar requests for boost in the inkscape-devel archives... it seems like I'm not the only one who would benefit.
If I'm correct we tried to avoid boost because it was just one more dependency. In the specific case I'm thinking of the need for boost was very minimal and in the end wasn't enough to merit adding it to the dependency list. That's all I know about the history of us and boost... I would bet others know much more.
So... you did remove overlaps and now you're looking at connectors. I don't believe this is quite what you're talking about, but I just filed an rfe that has to do with both removing overlaps and connectors (please check the file attached to the RFE to see an example): http://sourceforge.net/tracker/index.php?func=detail&aid=1421548&gro...
To summarize the rfe, it would be making connectors lay side-by-side as opposed to overlapping when routed through the same object(s). If you've ever seen bus or subway maps, it's the same theory. It may not interest you, but I figured I'd throw it your way since it ties into two areas you have/want to work with. Either way, I can't wait to see more graphing functions. And thanks again for remove overlaps. :-)
-Josh
On Wed, 1 Feb 2006, Joshua A. Andler wrote:
So... you did remove overlaps and now you're looking at connectors. I don't believe this is quite what you're talking about, but I just filed an rfe that has to do with both removing overlaps and connectors (please check the file attached to the RFE to see an example): http://sourceforge.net/tracker/index.php?func=detail&aid=1421548&gro...
To summarize the rfe, it would be making connectors lay side-by-side as opposed to overlapping when routed through the same object(s). If you've ever seen bus or subway maps, it's the same theory. It may not interest you, but I figured I'd throw it your way since it ties into two areas you have/want to work with. Either way, I can't wait to see more graphing functions. And thanks again for remove overlaps. :-)
That particular Feature Request is something I probably need to address in the connector routing code. This is something I definitely plan to look at, though it may not be for a couple of months.
FWIW, Tim and I are part of the same research group and will be working closely together in implementing some more useful diagramming features.
Cheers, Michael
On Wed, 1 Feb 2006, Tim Dwyer wrote:
I'd appreciate any feedback people have on this idea. Also, I'd really like to use the boost 'graph' libraries to get this happening quickly. Boost already has some basic layout algorithms which we can use right away, but I'll also need the underlying graph data-structures and algorithms in boost to implement new algorithms. What are the logistics of adding boost to the inkscape dependency tree?
While I haven't actually used boost before, I was just looking at the webpage for the Boost Graph Library (http://www.boost.org/libs/graph/doc/) which says "[it] is a header-only library and does not need to be built to be used."
From what I can see, the examples only require the graph library and don't
seem to depend on the main Boost library. So it may be that this library wouldn't have to be a "new dependency". If the licence is compatible we could just add it to the source tree.
Michael
On Wed, 1 Feb 2006, Tim Dwyer wrote:
I'd appreciate any feedback people have on this idea. Also, I'd really like to use the boost 'graph' libraries to get this happening quickly. Boost already has some basic layout algorithms which we can use right away, but I'll also need the underlying graph data-structures and algorithms in boost to implement new algorithms. What are the logistics of adding boost to the inkscape dependency tree?
While I haven't actually used boost before, I was just looking at the webpage for the Boost Graph Library (http://www.boost.org/libs/graph/doc/) which says "[it] is a header-only library and does not need to be built to be used."
From what I can see, the examples only require the graph library and don't
seem to depend on the main Boost library. So it may be that this library wouldn't have to be a "new dependency". If the licence is compatible we could just add it to the source tree.
Michael
On Feb 1, 2006, at 2:39 PM, Michael Wybrow wrote:
On Wed, 1 Feb 2006, Tim Dwyer wrote:
I'd appreciate any feedback people have on this idea. Also, I'd really like to use the boost 'graph' libraries to get this happening quickly. Boost already has some basic layout algorithms which we can use right away, but I'll also need the underlying graph data-structures and algorithms in boost to implement new algorithms. What are the logistics of adding boost to the inkscape dependency tree?
While I haven't actually used boost before, I was just looking at the webpage for the Boost Graph Library (http://www.boost.org/libs/ graph/doc/) which says "[it] is a header-only library and does not need to be built to be used."
Unfortunately, the majority of my experience with it has been negative.
That's not really due to the quality of the library itself or anything, but rather due to how it fit (or rather, didn't fit well) in projects, some with the individuals bringing it in, and some due to a more literal mismatch to code for the rest of the project.
Again, it was one of those things that seemed indispensable to those who implemented, but ended up being a net negative for the projects overall.
(Oh, and all of BOOST is, or at least was, header only)
From what I can see, the examples only require the graph library and don't seem to depend on the main Boost library. So it may be that this library wouldn't have to be a "new dependency". If the licence is compatible we could just add it to the source tree.
Well... check things carefully. I know that it is supposed to be crafted to be used in parts, we just would want to be sure those parts don't bring in too many others (like those magic, do-it-all-for- you-so-you-don't-have-to-think pointers).
Oh, and one general negative is having a duplicate of a live tree. That tends to get a bit problematic, and includes the need for periodic merging from the main source. Someone will have to commit to keeping a vendor import going.
At one point I think there were concerns in regards to platform coverage. Various people build Inkscape on a very wide range of platforms and compilers, so we end up with a bit more concern than some other projects.
Another factor might be the build process. I've not looked at things lately, but there used to be some issue with that.
Hmmm.... and then the "be sure to compile with optimization" has me a little concerned, since as among other things I always compile without it in order to facilitate debugging, etc.
Oh, and one general negative is having a duplicate of a live tree. That tends to get a bit problematic, and includes the need for periodic merging from the main source. Someone will have to commit to keeping a vendor import going.
If we duplicate the necessary parts of boost, the only time we need update is if we want to use new features or bugs are found that affect our usage. If I (and maybe Michael) are the only ones using it, this shouldn't be much of a problem. If many others start using it, then we're better off making boost an external dependancy - there're distributions for plenty of platforms, eg debian (stable), redhat, osx, windows, etc...
At one point I think there were concerns in regards to platform
coverage. Various people build Inkscape on a very wide range of platforms and compilers, so we end up with a bit more concern than some other projects.
Here's a pretty comprehensive list: http://engineering.meta-comm.com/boost-regression/1_33_0/user/graph.html
I understand the concerns about boost... let my try and allay them:
A quick browse of the boost graph headers shows there are some dependencies on other parts of boost, but I haven't found any reference to the dreaded smart_ptr stuff yet ;-). Hopefully, I could pare it down to a minimal set of headers (not including smart_ptr and so on) before adding anything to the inkscape code base.
Regarding the build process the graph examples compile with (assuming headers in the include path):
g++ example.cpp -o example
As for optimisation, the algorithms we're talking about are quite computationally intensive and boost is written in a heavily templated generic style. I think that's the only reason they recommend optimisation. Surely inkscape binary distributions are compiled with optimisation on anyway, right?
I was a bit worried about bloat and compilation speed but the examples which use the kind of stuff I need compile down to <100k (on x86 linux) in a few seconds. I'm guessing, but I think this would be comparable to an stl based implementation of the same thing.
Regarding "mismatch of code" with the rest of the project, I really would just be using the graph datastructures and algorithms. I don't have any intention of using any of the fancy stuff that fundamentally affects coding style (like the aforementioned smart_ptrs or the lambda stuff).
some useful functionality could perhaps be gleaned from http://freemind.sourceforge.net/wiki/index.php/Main_Page it has some neat workflows that might apply to the connectors.
On Thu, 2006-02-02 at 21:10 +1100, Tim Dwyer wrote:
I understand the concerns about boost... let my try and allay them:
A quick browse of the boost graph headers shows there are some dependencies on other parts of boost, but I haven't found any reference to the dreaded smart_ptr stuff yet ;-). Hopefully, I could pare it down to a minimal set of headers (not including smart_ptr and so on) before adding anything to the inkscape code base.
Regarding the build process the graph examples compile with (assuming headers in the include path):
g++ example.cpp -o example
As for optimisation, the algorithms we're talking about are quite computationally intensive and boost is written in a heavily templated generic style. I think that's the only reason they recommend optimisation. Surely inkscape binary distributions are compiled with optimisation on anyway, right?
I was a bit worried about bloat and compilation speed but the examples which use the kind of stuff I need compile down to <100k (on x86 linux) in a few seconds. I'm guessing, but I think this would be comparable to an stl based implementation of the same thing.
Regarding "mismatch of code" with the rest of the project, I really would just be using the graph datastructures and algorithms. I don't have any intention of using any of the fancy stuff that fundamentally affects coding style (like the aforementioned smart_ptrs or the lambda stuff).
On Wed, 2006-02-01 at 19:28 +1100, Tim Dwyer wrote:
I've noticed similar requests for boost in the inkscape-devel archives... it seems like I'm not the only one who would benefit.
In the past, a lot of the boost requests have been because people wanted to use the boost "smart pointer" class, which we really, really don't want people using because the temptation to misuse it is so strong (plus, we have a real garbage collector).
If we imported boost into the tree, I'd almost be tempted to see if we could excise that class...
-mental
All I'm really interested in is the boost graph library, which as Michael said, is header only and I don't think includes any of the smart pointer stuff. So, as far as I can tell, in the short term I can just add the headers I'm using to the inkscape repository.
Cheers
Tim
On 02/02/06, MenTaLguY <mental@...3...> wrote:
On Wed, 2006-02-01 at 19:28 +1100, Tim Dwyer wrote:
I've noticed similar requests for boost in the inkscape-devel archives... it seems like I'm not the only one who would benefit.
In the past, a lot of the boost requests have been because people wanted to use the boost "smart pointer" class, which we really, really don't want people using because the temptation to misuse it is so strong (plus, we have a real garbage collector).
If we imported boost into the tree, I'd almost be tempted to see if we could excise that class...
-mental
participants (8)
-
unknown＠example.com -
Adib Taraben -
Jared -
Jon A. Cruz -
Joshua A. Andler -
MenTaLguY -
Michael Wybrow -
Tim Dwyer