On Tue, 6 Apr 2004, Carl Hetherington wrote:
I ran into this same issue when I was working on it. Obviously, somewhere there needs to be a command to force a redraw of the document; I don't know where that function would need to be placed, though. I suspect that tracing through one of the other defs features like gradients might help.
Not sure this will help, as I think its an issue with the CSS not updating, as the issue is the curve not showing the marker when its style data is changed, not the marker itself being changed.
Yes, it seems that way. With my hacks the arrow heads appear if you change some other aspect of the line's style.
Having just looked at gradients, markers were next on my list to play with, this issue was top of my list of things to look at (without fixing that UI aint no good to us).
Don't let me stop you ;-) The code is making my head hurt, TBH.
What do you think is wrong with the UI?
I think he means that having the UI bits there for applying markers isn't useful if the markers don't show up properly when added to the lines. (This is why the marker UI is currently commented out.)
But I do have some comments on what needs to be done to the UI once all these parts work.
The current UI is just a set of buttons to stick arrowheads on, which is ok for proof of concept, but for real use we need something a bit more sophisticated. I think what would be ideal would be an SVG editing widget sort of like the gradient editor, but that allows creating a regular SVG object. Sort of a mini-inkscape-inside-inkscape.
Another approach is to allow in-document editing of markers, in some fashion. Maybe something analogous to in-group editing or layers editing.
A third approach would be to have some sort of separate document window with all the marker defs there for editing.
I suspect that once it gets beyond basic proof of concept it grows into a larger issue of general handling for <use> style objects such as gradients, stroke dashes, etc. that may need to be solved at a higher level than just markers. It feels like a common editing policy/approach could be figured out, rather than having each of these features have their own unique editing systems; more concise code and more consistency for users. I've not much clue how to do this though, or what form it might take.
Bryce