How to add <marker> objects to <def>
Hi,
I'm having a hack at the code for arrow heads, but I've got myself properly confused.
It seems that we have the SPItem class hierarchy (which contains SPMarker) and the repr tree, and that these are kept in sync with each other. So in which tree should I create my new marker object? AFAICS my alternatives are:
1. Do a sp_repr_new ("marker"), add it to the defs repr, set up the attributes using sp_repr_set_attr () etc. etc.
2. Create a SPMarker, and set up its struct with the required bits.
So which should it be? And how to I propagate my changes from one tree to the other?
I've just tried the first approach above and it works fine, except that the arrow heads only appear when you re-load the file. I think this is because a SPMarker is never created / initialised.
Any enlightenment would be greatly appreciated.
Carl
On Tue, 2004-04-06 at 11:28, Carl Hetherington wrote:
It seems that we have the SPItem class hierarchy (which contains SPMarker) and the repr tree, and that these are kept in sync with each other. So in which tree should I create my new marker object? AFAICS my alternatives are:
- Do a sp_repr_new ("marker"), add it to the defs repr, set up the
attributes using sp_repr_set_attr () etc. etc.
- Create a SPMarker, and set up its struct with the required bits.
So which should it be? And how to I propagate my changes from one tree to the other?
In general it's probably easier to create things in the SPRepr tree, since the SPObject layer will get updated automatically. That is normally the proper way, as well.
I've just tried the first approach above and it works fine, except that the arrow heads only appear when you re-load the file. I think this is because a SPMarker is never created / initialised.
The SPMarker will get created automatically.
Likely the SPShape upon which the markers are to be used is not getting updated when the markers are added, however. I'm not sure the marker code ever got updated to use the new URIReference facility.
See SPItem's usage of URIReference with clipping paths as an example (though, the CSS part of things there is slightly broken).
-mental
On Tue, 6 Apr 2004, Carl Hetherington wrote:
Hi,
I'm having a hack at the code for arrow heads, but I've got myself properly confused.
It seems that we have the SPItem class hierarchy (which contains SPMarker) and the repr tree, and that these are kept in sync with each other. So in which tree should I create my new marker object? AFAICS my alternatives are:
- Do a sp_repr_new ("marker"), add it to the defs repr, set up the
attributes using sp_repr_set_attr () etc. etc.
- Create a SPMarker, and set up its struct with the required bits.
So which should it be? And how to I propagate my changes from one tree to the other?
Number 1. In fact, if you can get that to work, that should help us a lot in moving forward with the marker implementation work in general.
I've just tried the first approach above and it works fine, except that the arrow heads only appear when you re-load the file. I think this is because a SPMarker is never created / initialised.
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.
Any enlightenment would be greatly appreciated.
Carl
This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
--- Bryce Harrington <bryce@...260...> wrote:
On Tue, 6 Apr 2004, Carl Hetherington wrote:
I've just tried the first approach above and it
works fine, except that
the arrow heads only appear when you re-load the
file. I think this is
because a SPMarker is never created / initialised.
you can find the new SPMarker with
mark = (SPMarker *) sp_document_lookup_id (doc, sp_repr_attr (repr, "id"));
where repr is the newly created repr.
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. 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).
cheers
John
__________________________________ Do you Yahoo!? Yahoo! Small Business $15K Web Design Giveaway http://promotions.yahoo.com/design_giveaway/
On Tue, 2004-04-06 at 14:50, John Cliff wrote:
you can find the new SPMarker with
mark = (SPMarker *) sp_document_lookup_id (doc, sp_repr_attr (repr, "id"));
where repr is the newly created repr.
Note that the URIReference class was introduced to automate this process somewhat, as well as provide notification when a marker with that name is added or removed.
-mental
[snip]
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?
Cheers
Carl
--- Carl Hetherington <lists@...169...> wrote: [snip]
Yes, it seems that way. With my hacks the arrow heads appear if you change some other aspect of the line's style.
interesting to know, any particular aspect? if we can work out whats being done differently there we can pin down what we need to change.
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.
likewise, dont let me stop you, its always good to see people getting into the code, and two people looking are more likely to spot issues in the code. (my code tends to start out with lots of issues :) )
What do you think is wrong with the UI?
Thats my appaling typing, what I meant was there was no point putting major effort into a full marker UI if they weren't rendered properly. (should have been a comma after that - although even then the english is appaling ;) )
cheers
John
__________________________________ Do you Yahoo!? Yahoo! Small Business $15K Web Design Giveaway http://promotions.yahoo.com/design_giveaway/
On Tue, 6 Apr 2004, John Cliff wrote:
--- Carl Hetherington <lists@...169...> wrote: [snip]
Yes, it seems that way. With my hacks the arrow heads appear if you change some other aspect of the line's style.
interesting to know, any particular aspect? if we can work out whats being done differently there we can pin down what we need to change.
Oddly, it seems to be working ok now. Mind you I was on Windows earlier and Linux now, so there might be a funny there.
I'll be able to clean the patch up a bit tomorrow, hopefully, then I'll put it in the tracker so people can have a play.
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.
likewise, dont let me stop you, its always good to see people getting into the code, and two people looking are more likely to spot issues in the code. (my code tends to start out with lots of issues :) )
I know the feeling ;-)
What do you think is wrong with the UI?
Thats my appaling typing, what I meant was there was no point putting major effort into a full marker UI if they weren't rendered properly. (should have been a comma after that - although even then the english is appaling ;) )
;-) The current UI is fine for my needs, and the ideas elsewhere on the list for generalising it sound fine to me. In particular, the "marker palette" thing sounds ideal.
Cheers
Carl
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
For the custom markers, I think we should adopt a palette type system where an svg path, or group, or a set of paths can be dropped onto the marker palette, or object palette and then it is rendered as a small thumbnail. This way, users can quickly draw shapes on the canvas and drag n drop them to this interface. Please see my illustrator screenshots page: http://protofunk.org/projects/group/inkscape/reference/adobeillustrator/10/a...
and look at the palette brushes (which is a similar concept)
A group of paths dragged onto this palette could be grouped together automatically and saved as a new marker (either for the doc. or into the users markers folder).
This approach would be good for a color palette as well where color swatches can be saved and drag n dropped onto lines and fills on the canvas.
I think we should seriously reconsider implementing double-interfaces like the text entry on the text-font and the gradient editor, as WYSIWYG on the canvas is what users expect and are used to IMHO...
Also, I'm writing a comment about the text/font dialog here shortly. Look at how precise and manageable the size of the palettes are in illustrator. I think our text/font palette needs to go further and be integrated inot the 2ndary interface in lieu of direct editing on the canvas...same for the gradients...
Jon
On Tue, 2004-04-06 at 15:51, Bryce Harrington wrote:
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
This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
--- Bryce Harrington <bryce@...260...> wrote:
[snip]
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.
The mini-inkscape option had occured to me, but was too big a task for the first iteration imo. My intended approach was a "convert selection to marker" button in the UI to take a selection and make a marker out of it (basically c/p it to the defs, and set some extra attributes) That coupled with a means of selecting from a drop down containing of all the markers in the current doc and the default markers shipped with inkscape (doc ones working, defualts still todo, was thinking of creating a markers.svg in share, and extracting from that, need to add previews to drop down tho.) the defaults bit shouldnt be too hard, its a cross between the gradient c/p and the icons.svg code.
Anyway, just my 2 cents
John
__________________________________ Do you Yahoo!? Yahoo! Small Business $15K Web Design Giveaway http://promotions.yahoo.com/design_giveaway/
On Tue, 6 Apr 2004, John Cliff wrote:
The mini-inkscape option had occured to me, but was too big a task for the first iteration imo.
Yeah, I was of the same mind, especially given how much underlying hookup work had to be done. I didn't want to put a lot of time into the UI until the basic functionality was working.
My intended approach was a "convert selection to marker" button in the UI to take a selection and make a marker out of it (basically c/p it to the defs, and set some extra attributes)
Ah, that's not a bad idea. I think rejon's idea of doing it with drag and drop may be the right way to go; I don't feel like we have a better idea than how Illustrator does it, so it'd probably be wise to do it that way.
That coupled with a means of selecting from a drop down containing of all the markers in the current doc and the default markers shipped with inkscape (doc ones working, defualts still todo, was thinking of creating a markers.svg in share, and extracting from that, need to add previews to drop down tho.) the defaults bit shouldnt be too hard, its a cross between the gradient c/p and the icons.svg code.
Originally when I started working on the markers I was going to implement the UI as a dropdown, but I ran into trouble in that I didn't find a standard dropdown widget that would allow graphics as the selection items. I thought the stroke-style dropdown would be a good model, but it turns out the graphics for it are hard coded into libart for some reason and difficult to override. We may have other options via GtkMM, etc. but even so I'm thinking that if we could do a widget like the one in rejon's screenshot, where all the markers are shown in little boxes, that might be best. I don't know - perhaps we need to research a bit more into what standard widgets are available to us?
Bryce
--- Bryce Harrington <bryce@...260...> wrote: [snip]
Originally when I started working on the markers I was going to implement the UI as a dropdown, but I ran into trouble in that I didn't find a standard dropdown widget that would allow graphics as the selection items.
the standard drop down allows you to, thats how the gradient selector is done. The menu items are containers, you can pack what you want in there. I just need to work out creating the thumbnails of the svg (which is where the icons code comes in).
__________________________________ Do you Yahoo!? Yahoo! Small Business $15K Web Design Giveaway http://promotions.yahoo.com/design_giveaway/
participants (5)
-
Bryce Harrington -
Carl Hetherington -
John Cliff -
Jonathan Phillips -
MenTaLguY