G'Day! Peter and I have been working on a new grids and guides idea which extends the control handle idea of Dia and Visio 'correctly' (We can justify this claim quite strongly). There is a test bed version of it at:
http://bowman.csse.monash.edu.au/~pmoulder/guides-LATEST.tar.gz
To run it you will need python-gtk2 and python-numeric (also called numpy).
Please run it and tell us if the behaviour feels right - it is easier to try variations whilst the code is python, rather than C++ (although it is easier to know whether the behaviour feels right once we implement it in inkscape proper)
Feel free to ask questions about our intentions, and suggest extensions that would be helpful. Clearly the prototype is but a taste of what can be done with this new approach (We have several whiteboards worth of ideas to implement :), but it is important to work out the basic interface now.
In particular, what do people think about the two tools behaviour? Should this be folded into a modifier key on the selection tool? Can it be done well with only one tool? Is the breaking of constraint behaviour (which control point disconnects when you move something) reasonable, or can you suggest a better heuristic? (Currently the rule that is broken is chosen arbitrarily, perhaps it would be better to break the oldest created relationship, or perhaps the least recently moved?)
What do people think of the indicators for how control points are connected to guide lines and guide points? Suggestions?
In case you're wondering, our intent is to provide Dia level diagraming support, as well as strong CAD type design elements. Some things which we know how to do, but haven't added include: adjustable spacers, enforced alignment and distribution, clipart with programable control handles (like visio), and many other goodies :)
Thanks, njh
On Wednesday 10 December 2003 13:10, Nathan Hurst wrote:
G'Day! Peter and I have been working on a new grids and guides idea which extends the control handle idea of Dia and Visio 'correctly' (We can justify this claim quite strongly). There is a test bed version of it at:
http://bowman.csse.monash.edu.au/~pmoulder/guides-LATEST.tar.gz
To run it you will need python-gtk2 and python-numeric (also called numpy).
Please run it and tell us if the behaviour feels right - it is easier to try variations whilst the code is python, rather than C++ (although it is easier to know whether the behaviour feels right once we implement it in inkscape proper)
Feel free to ask questions about our intentions, and suggest extensions that would be helpful. Clearly the prototype is but a taste of what can be done with this new approach (We have several whiteboards worth of ideas to implement :), but it is important to work out the basic interface now.
Guides/grid/snapping are killer features... thanks for investigating in this field !
In particular, what do people think about the two tools behaviour?
Little lost at first try but getting back and 3 minutes of more "methodic" test later it seems to be good...
Should this be folded into a modifier key on the selection tool? Can it be done well with only one tool? Is the breaking of constraint behaviour (which control point disconnects when you move something) reasonable, or can you suggest a better heuristic? (Currently the rule that is broken is chosen arbitrarily, perhaps it would be better to break the oldest created relationship, or perhaps the least recently moved?)
Seems like this is going to be the hot point ! For sure, it's what lost me at first try, but feel like for dumbies like me, arbitrarity (english ? :-P) is not so good as, from definition, it's not predictable and makes anticipating the way you're going to draw quite impossible.
What do people think of the indicators for how control points are connected to guide lines and guide points? Suggestions?
AFAIC... excellent !
In case you're wondering, our intent is to provide Dia level diagraming support, as well as strong CAD type design elements. Some things which From architectural CAD point of view, it would be very nice to be able to get
rid of orthogonality. I mean: - set the angle between "vertical" and "horizontal" grid lines (instead of 90°) - set the angle of angle of "vertical" and "horizontal" guides
we know how to do, but haven't added include: adjustable spacers, enforced alignment and distribution, clipart with programable control handles (like visio), and many other goodies :)
Still have to check Visio to understand more clearly what's in your brilliant minds
BTW, subscribed to this list as soon as I discovered yall had forked from Sodipodi and didn't got time to wish Inkscape my bests... so that's done now ! ;-) Hope I'll find time to build Inkscape this week and report my feelings.
Best regards
Tarax
PS: Just leading my first fights with programming and Python, let me thank you, Peter and Nathan, for providing such an "example" graphics Python/GTK app :-))) Spéciales dédicaces !
Tarax wrote
Guides/grid/snapping are killer features... thanks for investigating in this field !
In particular, what do people think about the two tools behaviour?
Little lost at first try but getting back and 3 minutes of more "methodic" test later it seems to be good...
Why were you lost? We've been talking about the two tools, and it appears that we can get all the behaviour we want from one tool (tentatively :) so the two tools issue may disappear.
Should this be folded into a modifier key on the selection tool? Can it be done well with only one tool? Is the breaking of constraint behaviour (which control point disconnects when you move something) reasonable, or can you suggest a better heuristic? (Currently the rule that is broken is chosen arbitrarily, perhaps it would be better to break the oldest created relationship, or perhaps the least recently moved?)
Seems like this is going to be the hot point ! For sure, it's what lost me at first try, but feel like for dumbies like me, arbitrarity (english ? :-P) is not so good as, from definition, it's not predictable and makes anticipating the way you're going to draw quite impossible.
This is something we would like feed back on. If I added a menu to allow different rules, would you be able to give us feedback on which rules felt the most consistant?
What do people think of the indicators for how control points are connected to guide lines and guide points? Suggestions?
AFAIC... excellent !
Groovy!
In case you're wondering, our intent is to provide Dia level diagraming support, as well as strong CAD type design elements. Some things which
From architectural CAD point of view, it would be very nice to be able to get rid of orthogonality. I mean:
- set the angle between "vertical" and "horizontal" grid lines (instead of
90°)
- set the angle of angle of "vertical" and "horizontal" guides
One thing we've looked at is providing a different affine space in a group, but this has been mostly talk. It poses several complex UI issues. More interesting is allowing guidelines have their own angles. At the most primative level a guide line could be created with a specific angle, or passing through a specific pair of lines, but things get tricky if the designer is allowed to change the line angle once things have been attached to it. We're working on this now, but it may be too hard.
BTW, subscribed to this list as soon as I discovered yall had forked from Sodipodi and didn't got time to wish Inkscape my bests... so that's done now ! ;-) Hope I'll find time to build Inkscape this week and report my feelings.
well 0.36 is about to come out, so you can install that and test it!
PS: Just leading my first fights with programming and Python, let me thank you, Peter and Nathan, for providing such an "example" graphics Python/GTK app :-)))
Cool!
Spéciales dédicaces !
njh
On Thursday 11 December 2003 04:44, Nathan Hurst wrote:
Tarax wrote
Guides/grid/snapping are killer features... thanks for investigating in this field !
In particular, what do people think about the two tools behaviour?
Little lost at first try but getting back and 3 minutes of more "methodic" test later it seems to be good...
Why were you lost? We've been talking about the two tools, and it appears that we can get all the behaviour we want from one tool (tentatively :) so the two tools issue may disappear.
Indeed I think all could be available under one tool
Should this be folded into a modifier key on the selection tool? Can it be done well with only one tool? Is the breaking of constraint behaviour (which control point disconnects when you move something) reasonable, or can you suggest a better heuristic? (Currently the rule that is broken is chosen arbitrarily, perhaps it would be better to break the oldest created relationship, or perhaps the least recently moved?)
Seems like this is going to be the hot point ! For sure, it's what lost me at first try, but feel like for dumbies like me, arbitrarity (english ? :-P) is not so good as, from definition, it's not predictable and makes anticipating the way you're going to draw quite impossible.
This is something we would like feed back on. If I added a menu to allow different rules, would you be able to give us feedback on which rules felt the most consistant?
For sure ! BTW having a menu for the diff behaviours seems interesting...
What do people think of the indicators for how control points are connected to guide lines and guide points? Suggestions?
AFAIC... excellent !
Groovy!
In case you're wondering, our intent is to provide Dia level diagraming support, as well as strong CAD type design elements. Some things which
From architectural CAD point of view, it would be very nice to be able to get
rid of orthogonality. I mean:
- set the angle between "vertical" and "horizontal" grid lines (instead of
90°)
- set the angle of angle of "vertical" and "horizontal" guides
One thing we've looked at is providing a different affine space in a group, but this has been mostly talk. It poses several complex UI issues. More interesting is allowing guidelines have their own angles. At the most primative level a guide line could be created with a specific angle, or passing through a specific pair of lines, but things get tricky if the designer is allowed to change the line angle once things have been attached to it. We're working on this now, but it may be too hard.
Was just a wish ;-)
BTW, subscribed to this list as soon as I discovered yall had forked from Sodipodi and didn't got time to wish Inkscape my bests... so that's done now ! ;-) Hope I'll find time to build Inkscape this week and report my feelings.
well 0.36 is about to come out, so you can install that and test it!
ASAP dude... ASAP !
Tarax
participants (2)
-
Nathan Hurst -
Tarax