I'll be without phone or internet access for the next few days (hopefully not longer), so I probably won't be getting much Inkscape work done in that time. CVS isn't really very friendly for disconnected operation.
In my absence, there are a few important things I wanted to make sure were nailed down before the 0.39 release:
A. Clipping Paths
Clipping paths are an extremely important feature for me personally, so I want to make sure they're in order before the release.
1. I think the clipping-paths-not-activating-on-load bug is related to a cut+paste mistake in sp_item_set -- if you compare the SP_ATTR_CLIP_PATH and SP_ATTR_MASK branches, one ->clip_ref has not been changed to ->mask_ref in the SP_ATTR_MASK branch. (hopefully that's right; this is from memory) Could someone please check, fix and commit that?
2. 'clip-path' specifications are currently only supported as XML attributes, not style= properties. Changing that now will require non-trival architectural work (I think), so just be aware of that when testing.
3. In case Bulia or anyone is interested, clipping paths currently require recursive updates. Not fatal, but if it bothers you you might want to have a look.
B. Layers
I kind of snuck in some layers stuff over the weekend. You can pick "enter group" from the context menu to start using a group as the current layer (i.e. the drawing tools will draw within it). "leave group" will "back out a level" (until you hit the root <svg> element again).
I'd been hoping to get it a little more polished, but I probably won't have a chance before the release at this point...
1. The implementation is pretty crude and doesn't add any UI feedback; we should probably disable those menu entries for the final release
2. If you do decide to add feedback, I'd recommend adding a SigC++ signal to Inkscape::ObjectHierarchy that fires whenever the top or bottom object in the hierarchy changes. Also add a signal to SPDesktop that indicates when the current layer changes. The SPDesktop layer change should be driven by the signal belonging to SPDesktop::_layer_hierarchy (an Inkscape::ObjectHierarchy).
SPDesktop would also end up needing to keep a SigC::Connection around to track its connection to the hierarchy signal -- so please remember to:
a. explicitly call the constructor and destructors for any SPDesktop members of types in the SigC:: namespace
b. disconnect the SigC::Connection before destroying it
3. The tools currently set the newly created item's transform by directly assigning to SPItem::transform. That's incredibly bad, and I had not intended to leave it in. It'd be nice if someone could make a public SPItem::setTransform() method (which would more or less just call the private sp_item_(mumble?)_set_transform() .. sorry, this is from memory) and use that instead. SPItem::transform should really be treated as read-only by outsiders.
4. "enter group" and "leave group" should really both go next to each other in the menu and in interface.cpp
5. There are also some issues of "transparency" (in the sense of event delivery) for layers currently, which is another reason I think we're probably best off shipping with the feature disabled.
C. 0.40 release planning
Also some entries I want to make sure we have on the 0.40 roadmap in the wiki:
1. add a dependency on libgc (the Boehm conservative collector), which will be required for the AST code
2. add a dependency on libcroco (which will be needed for the CSS portion of AST)
3. switch to sigc++ 2.0/newer gtkmm early in 0.40, before we start doing gtkmm-intensive stuff like the layers dialog etc.
See y'all in a few days I hope...
-mental
- I think the clipping-paths-not-activating-on-load bug is related to a cut+paste mistake in sp_item_set -- if you compare the SP_ATTR_CLIP_PATH and SP_ATTR_MASK branches, one ->clip_ref has not been changed to ->mask_ref in the SP_ATTR_MASK branch. (hopefully that's right; this is from memory) Could someone please check, fix and commit that?
I would but I don't have a file to test it on. If you could provide one that would help.
- The tools currently set the newly created item's transform by directly assigning to SPItem::transform. That's incredibly bad, and I had not intended to leave it in. It'd be nice if someone could make a public SPItem::setTransform() method (which would more or less just call the private sp_item_(mumble?)_set_transform() .. sorry, this is from memory) and use that instead. SPItem::transform should really be treated as read-only by outsiders.
I just wanted to ping you about that. We have this function already, it's sp_item_write_transform that does all the compensations (stroke width etc.), calls/not calls object's own transform writer (depending on optimize/preserve) and emits signal. Why don't you use it?
On Wed, 30 Jun 2004, bulia byak wrote:
- I think the clipping-paths-not-activating-on-load bug is related to a cut+paste mistake in sp_item_set -- if you compare the SP_ATTR_CLIP_PATH and SP_ATTR_MASK branches, one ->clip_ref has not been changed to ->mask_ref in the SP_ATTR_MASK branch. (hopefully that's right; this is from memory) Could someone please check, fix and commit that?
I would but I don't have a file to test it on. If you could provide one that would help.
<svg width="100px" height="100px" viewBox="0 0 100 100"> <circle clip-path="url(#blah)" cx="50" cy="50" r="46" style="fill:blue;stroke:black;stroke-width:2px;"/> <clipPath id="blah"> <rect x="0" y="0" width="50" height="50"/> </clipPath> </svg>
... from memory. I think that should work. Hopefully we support <circle>.
- The tools currently set the newly created item's transform by directly assigning to SPItem::transform. That's incredibly bad, and I had not intended to leave it in. It'd be nice if someone could make a public SPItem::setTransform() method (which would more or less just call the private sp_item_(mumble?)_set_transform() .. sorry, this is from memory) and use that instead. SPItem::transform should really be treated as read-only by outsiders.
I just wanted to ping you about that. We have this function already, it's sp_item_write_transform that does all the compensations (stroke width etc.), calls/not calls object's own transform writer (depending on optimize/preserve) and emits signal. Why don't you use it?
write_transform does a little _too_ much; in this particular case optimization is NOT appropriate, and we do not want to combine the transform with the existing one, but replace it entirely (though the old transform will be identity in this specific case anyway).
Ideally what I have in mind would be:
SPItem::setTransform(NR::Matrix const &xform)
- sets the object's transform directly, with no optimization or special handling
SPItem::applyTransform(NR::Matrix const &xform, bool optimize)
- formerly sp_item_write_transform; applies the given transform on top of the existing transform, optionally optimizing it (according to the second parameter -- preference lookup would become the callers' responsibility; I want to decouple the SPObject classes from the preferences API altogether)
-mental
I just wanted to ping you about that. We have this function already, it's sp_item_write_transform that does all the compensations (stroke width etc.), calls/not calls object's own transform writer (depending on optimize/preserve) and emits signal. Why don't you use it?
write_transform does a little _too_ much; in this particular case optimization is NOT appropriate
Why? Remember, optimization is guaranteed to always give the same results (modulo stroke scaling, as we discussed on the list recently).
and we do not want to combine the transform with the existing one, but replace it entirely (though the old transform will be identity in this specific case anyway).
Yes, so with the old one being identity, most of the stuff in that function would not harm you at all. So I don't see a need for a new function.
optimizing it (according to the second parameter -- preference lookup would become the callers' responsibility; I want to decouple the SPObject classes from the preferences API altogether)
Oh. OK. But, it looks up _several_ pref values, one for each of compensations it does. If you want to move them all to arguments you can, but then please add applyTransformUsingPrefs so that we don't have to look up all these numerous prefs (with more likely to be added) in all the places (more than a dozen) where write_transform is now called. (Also, don't forget about the adv argument too.) And once you add it, I don't see much sense in having ApplyTransform without UsingPrefs - who's gonna use it anyway? :)
On Thu, 1 Jul 2004, bulia byak wrote:
Why? Remember, optimization is guaranteed to always give the same results (modulo stroke scaling, as we discussed on the list recently).
Stroke scaling is an interesting issue. Do we want the created shape to get the stroke width the user selected, or should we compensate for the scaling factor of the parent? What about the transform gradients/patterns?
I don't know the answer yet.
Maybe we should just use sp_item_write_transform for now, although I suspect the set of compensations that is usable for manually transforming the shape is going to be different from those that are best when drawing new shapes.
I think in general the compensations we want to use when creating the shape within a transformed group should aim for giving exactly the same appearance as if the user were drawing at the top level, even if that means using different line weights/dashes etc.
-mental
Stroke scaling is an interesting issue. Do we want the created shape to get the stroke width the user selected, or should we compensate for the scaling factor of the parent?
Of course we do.
What about the transform gradients/patterns?
Same.
I don't know the answer yet.
I think we must always follow this simple principle: Do it so that it _looks_ right. If the user selects 3pt stroke, it must _look_ 3pt regardless of any parent transforms. If the user has a horizontally aligned pattern fill in his current style, any new objects must have fill that is horizontally aligned, no matter what is the parent transform of the layer they're added too. Et cetera.
In fact I've been steadily implementing this principle in any part of the code that I touch. Hence the various compensations and other stuff I introduced. We don't yet fully follow this principle everywhere but we're getting closer.
I think in general the compensations we want to use when creating the shape within a transformed group should aim for giving exactly the same appearance as if the user were drawing at the top level, even if that means using different line weights/dashes etc.
Totally agree.
Except that, as a side note, I don't think layers will have any transforms at all, for most users. The Illustrator paradigm does not have a place for that (a layer is just a grouping that is not supposed to be transformed as a whole), and most users will follow this paradigm as the most familiar and convenient. So while it's important to get this issue right, it's not what will affect most users every day.
Stroke scaling is an interesting issue. Do we want the created shape to get the stroke width the user selected, or should we compensate for the scaling factor of the parent?
Of course we do.
Err, I guess that should have been "of course we should", as I was answering the second part of your sentence.
On Wed, 30 Jun 2004, MenTaLguY wrote:
C. 0.40 release planning
Also some entries I want to make sure we have on the 0.40 roadmap in the wiki:
add a dependency on libgc (the Boehm conservative collector), which will be required for the AST code
add a dependency on libcroco (which will be needed for the CSS portion of AST)
switch to sigc++ 2.0/newer gtkmm early in 0.40, before we start doing gtkmm-intensive stuff like the layers dialog etc.
I've added these to the 0.40 roadmap. I also trimmed down some of the pango tasks that are no longer relevant.
Mental, could you look through the Roadmap and mark off items that were completed or are no longer relevant, and move forward items that can be postponed til 0.40 or later? I'll also plan to go through the 0.40 list within the next week or so to make sure we have a doable set of tasks.
Bryce
participants (3)
-
Bryce Harrington -
bulia byak -
MenTaLguY