2007/12/4, Lars Clausen <[EMAIL PROTECTED]>: > > > On Tue, 2007-12-04 at 12:28 +0100, Marcel Toele wrote: > > Lars/any dev with svn acces/anyone else, > > > > Can you please comment on the updated information about the > > non-uniform scaling patch > > (I've added extra information via Replies to that thread) > > Sorry it took a bit, I've again been busier than I hoped for. I got the > patch to work as intended, and can now start to look at problems with > it.
Cool. A major but fixable problem is that the bounding box does not get > updated correctly when a sub-shape is large enough to be outside its > super-shape, leading to dirt on the diagram. However, some of your > previous comments seem to indicate that you expect sub-shapes to always > be within the super-shape. If that is the case, the super-shape should > limit its resize if it would put the sub-shape outside it. That's a good idea, I'll look into it and fix it. The sub-shape in the example that's anchored at the lower right doesn't > appear, but that's a bug in the SVG path for it. Once I copied the > first star's paths, it turned out fine, and the bottom/left anchors work > fine. Actually, it's not a bug in the SVG path code. The bottom-left sub-shape does not have an outline, it consists of fill-only. But, as I have stated previously, the default value for "filling dia objects" has been changed from true to false. This means that from now on, no shape will be filled by default. As I also said before: this may be a big problem, because many (if not all) custom shapes depend on this attribute to default to true (if they are to appear according to their icon). Anyway, if you simply turn on "draw background" (actually, "fill" comes closer to its meaning) on the example shape the lower-left sub-shape will appear. To be honest, there should be a fix for this "draw background" default attribute. It only appears in defaults.dia, cannot be changed in the GUI (at least, I couldn't find the setting, so surprise me!), and as I said, breaks most, if not all, custom shapes in the /shapes/ directory. I'm not convinced that the default_scale attribute is the right way to > go about handling the scaling issues. It means that whereas the > super-shape ignores the absolute scale and just uses the coordinates as > relative coordinates in a 2x2 cm space, the sub-shape actually uses the > units of the SVG, modified by the default_scale. This is confusing: The > coordinates of the super-shape and the sub-shape are now interpreted in > different ways, one of which is controlled by a "default_scale" > attribute whose meaning is not clear from context. If the default_scale > was on the main shape, it would be less confusing and at the same time > close a long-standing bug. Another problem with the default_scale is that it's defined relative to > something that's not in the shape definition, namely the unit system. > mm might be default in many locals (I frankly don't know, and would > rather not have to remember), but how would the shape be rendered in the > US, where inches or suchlike are the default? As I see it, the > coordinates for the super-shape and the sub-shape should have the same > meaning, or else editing the shape becomes a trap. Rather than the > default_scale attribute we should, IMNSHO, have either a unit definition > or a bounding-box definition with units. I'll look into it and will come back to you on the default_scale issue, which as you states, perhaps should be fixed outside the scope of sub-shapes, or in combination with a default shape size of other shapes. Can you point me to the bugreport you are referring to. Am I right to think that there is no such thing as a sub-sub-shape? > When I try, the sub-sub-shape appears, but not different from when it's > a sub-shape. Theoretically it should be possible to have sub-sub-shapes and recurse to infinity, however, I have intentionally opted not to do this, as this will be very confusing to end-users. It will also create a big user-interaction problem: "How to resize the sub-sub-shapes or the sub-[sub]*-shapes?" I'm not included to apply the patch until we have agreement on the > default_scale matter. > > -Lars > > _______________________________________________ > Dia-list mailing list > [email protected] > http://mail.gnome.org/mailman/listinfo/dia-list > FAQ at http://live.gnome.org/Dia/Faq > Main page at http://live.gnome.org/Dia > >
_______________________________________________ Dia-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/dia-list FAQ at http://live.gnome.org/Dia/Faq Main page at http://live.gnome.org/Dia
