On 6/21/07, Maximilian Albert <Anhalter42@...173...> wrote:

I'd appreciate comments, although I admit that there is not much to comment on yet. ;)

It's a great start, thanks a lot!

Now, apart from all the other things you need to do, one more thing to take care of: styles. Now the tool paints all sides of the box the same last-used style. This is less than useful. In a scene, I usually want all sides that are parallel to be one color but different from the color of all other sides.

This means the tool must store not one style, but SIX possibly different styles, one for each side, and apply them to the newly created boxes. This means you cannot simply reuse the existing style-remembering machinery that all other object-creating tools use; it must be extended.

Here's how (I think) this should be done. As you probably know, each tool may be in one of two modes: using its own fixed style or using the last-set style for new objects. The 3DBox style should be no different in that. The fixed style is stored in prefs. So, you just need to add the six default colors (make them meaningfully different) to prefs, for example instead of the current

<eventcontext id="3dbox" style="..." />

use six child elements under eventcontext:

<eventcontext id="3dbox" style="..."> <side id="XYtop" style="..."/> <side id="XYbottom" style="..."/> <side id="XZtop" style="..."/> <side id="XZbottom" style="..."/> <side id="YZtop" style="..."/> <side id="YZbottom" style="..."/> </eventcontext>

This way, you can have a separate style for the entire box group in <evencontext> and styles for each of the sides. If a side has not specified some style property, it will be automatically inherited from the parent eventcontext's style.

Then in the box3d-context, add code to use these substyles on the six sides of a box you create.

However, more useful is the mode where the tool uses the last-set style on the newly created boxes. This mode needs to be similarly extended to store six different styles (plus one style of the entire box), but this needs to be done not in the 3dbox tool but deeper - because you can Ctrl+click to select a side and paint it in almost any tool. Here's what you need to do.

Currently, the last-set style is stored in prefs as the style of the desktop group:

<group id="desktop" style="..." />

No matter how you set style on an object, that style= value is written in one single place: in the beginning of sp_desktop_set_style function (see comment 1a). This is where you need to add the following, in pseudocode:

iterate over desktop->selection: for each selected object, if it's a XYtop side of a 3Dbox: write the style to <group id="sideXYtop"/> inside desktop group if it's a XYbottom side of a 3Dbox: write the style to <group id="sideXYbottom"/> inside desktop group .... etc for all 6 sides

Then, this style-remembering will work in any tool or context, and in the 3D tool you will be able to use these remembered last-assigned styles for newly created boxes. Note that for this to work, you will also need to add some sodipodi:type attribs to the sides, not only to the box group as you do now. Also note that this code will work in addition to the existing code that writes to <group id="desktop" style="..." />, not replacing it, so the regular last-used style will still be set for other tools to use.

Does this make sense? Please write me with any questions you may have.

Thu, 21 Jun 2007 15:04:50 +0200 Maximilian Albert <Anhalter42@...173...> kirjoitti:

following Gail's example, I would like to post a short note on my progress, too, and at the same time announce version 0.1 of the 3D box tool. :) Well, that's probably too much of a promise. It is _extremely_ limited, the only thing it may be useful for is giving an impression of the envisaged behaviour (also see http://www.rzuser.uni-heidelberg.de/~malbert/core_functionality.shtml ). I'd appreciate comments, although I admit that there is not much to comment on yet. ;)

It seems that this won't compile on 64 bit platforms.

In sp_3dbox_toggle_vp_changed (toolbox.cpp:2109) a pointer (64 bits) is casted to an integer of a smaller size (32 bits), which is a big no-no. (even though in this case there's a good reason)

For a quick solution, the offending line could be changed to intptr_t dir = (intptr_t)data; but as intptr_t is a C99 feature, this may prove to be a problem, too. (I don't know if it is or not)