On Sun, 2007-05-06 at 08:23 -0700, Bryce Harrington wrote:

On Sun, May 06, 2007 at 07:33:29AM -0700, Ted Gould wrote:

...

...

This means that there would be an "up" key which makes the next layer active and visible and all others invisible, and a "down" key which makes the previous layer active and visible and all others invisible.

This might be possible from the technical perspective, but I don't think that "up" and "down" are good keys for it.

"left" "right" maybe?

I was thinking that "up" and "down" are pretty overloaded already -- infact all the arrow keys are. So something like "o" and "p" might work better, or something with a modifier. I think we're going to have to start requiring second keyboards ;)

...

Unfortunately it is pretty much a full replacement today. Plus with serializing everything into files, it really isn't high performance. I'm not saying it's impossible with enough hardware, but I don't think using a script will work for you today.

This approach might be interesting for a proof of concept, but this really sounds like something more geared for the DOM-based embedded scripting approach.

Yes, but C++ works too. :) Implementing an effect in C++ is also pretty easy (if you know C++) as the interface is already well defined. I hope that we can get loadable C++ extensions working someday also.

--Ted

Ted, Bryce, thanks for your detailed response and your suggestions. Since you offered help further down the road, I'd now like to ask for your advice again.

I was thinking that "up" and "down" are pretty overloaded already -- infact all the arrow keys are. So something like "o" and "p" might work better, or something with a modifier. I think we're going to have to start requiring second keyboards ;)

Sorry for the misleading labeling, I really wasn't thinking of the arrow keys. The Flash IDE uses "," and ".", but of course any two keys next to each other would do the job.

...

...

Unfortunately it is pretty much a full replacement today. Plus with serializing everything into files, it really isn't high performance. I'm not saying it's impossible with enough hardware, but I don't think using a script will work for you today.

This approach might be interesting for a proof of concept, but this really sounds like something more geared for the DOM-based embedded scripting approach.

Yes, but C++ works too. :) Implementing an effect in C++ is also pretty easy (if you know C++) as the interface is already well defined. I hope that we can get loadable C++ extensions working someday also.

I am almost as inexperienced and uncomfortable with C++ as I am with Python, so I wouldn't mind using C++. :-)

You just need to subclass the Inkscape::Extension::Implementation::Implementation object and implement the functions you're interested in (probably effect). You should look at blur and grid for examples.

Alright, the effect method is passed an Inkscape::UI::View::View as a "document" parameter. How do I get the current active layer from here? In the docs, I found these two layer functions:

((SPDesktop*)document)->selection->activeContext() ((SPDesktop*)document)->currentLayer()

"currentLayer" looks better to me, but the Doxygen comment says it's actually the top layer???

And once I got the layer, how do I set it to visible/invisible? At first glance, the method SPItem::setExplicitlyHidden(bool const) looks like it'd do the job. Can I safely cast the SPObject pointers to SPItem? What is the actual class of the layer nodes?

Finally, how do I register the extension class and bind it to keystrokes? Is there an example?

Thanks a lot for your advice! Gerrit

_________________________________________________________________ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

Heya Mental,

Gerrit is working on a layer-flipping based animation feature - Ted and I gave a little advice, but perhaps you could addressg some of his questions relating to the layers code?

Thanks, Bryce

On Tue, May 08, 2007 at 01:30:58PM +0000, Gerrit . wrote:

...

You just need to subclass the Inkscape::Extension::Implementation::Implementation object and implement the functions you're interested in (probably effect). You should look at blur and grid for examples.

Alright, the effect method is passed an Inkscape::UI::View::View as a "document" parameter. How do I get the current active layer from here? In the docs, I found these two layer functions:

((SPDesktop*)document)->selection->activeContext() ((SPDesktop*)document)->currentLayer()

"currentLayer" looks better to me, but the Doxygen comment says it's actually the top layer???

And once I got the layer, how do I set it to visible/invisible? At first glance, the method SPItem::setExplicitlyHidden(bool const) looks like it'd do the job. Can I safely cast the SPObject pointers to SPItem? What is the actual class of the layer nodes?

Thanks a lot for your advice! Gerrit

This weekend, I finally found the time to play a little with Inkscape and try out your suggestions. I got the layer flipping working, not yet as an extension however.

Here's what I did:

1. Added 2 actions to the key mappings in keys/default.xml

<bind key="l" action="LayerFlipToNext" display="true" />

<bind key="L" action="LayerFlipToNext" display="true" />

<bind key="k" action="LayerFlipToPrev" display="true" />

<bind key="K" action="LayerFlipToPrev" display="true" />

2. Added 2 verbs for these actions to Verb::_base_verbs[] in verbs.cpp, defined in verbs.h.

new LayerVerb(SP_VERB_LAYER_FLIP_TO_NEXT, "LayerFlipToNext", N_("_Flip to Next Layer"),

N_("Flip to the next layer."), "flip_next"),

new LayerVerb(SP_VERB_LAYER_FLIP_TO_PREV, "LayerFlipToPrev", N_("_Flip to Previous Layer"),

N_("Flip to the previous layer."), "flip_prev"),

3. Wrote 2 case blocks for the verbs.

case SP_VERB_LAYER_FLIP_TO_NEXT: {

SPItem* currentLayer = SP_ITEM(dt->currentLayer());

if( currentLayer && dt->isLayer( currentLayer ) ) {

SPItem* nextLayer = SP_ITEM( SP_OBJECT_NEXT(currentLayer) );

if( nextLayer && dt->isLayer( nextLayer ) ) {

currentLayer->setExplicitlyHidden(true);

nextLayer->setExplicitlyHidden(false);

dt->setCurrentLayer( nextLayer );

}

}

break;

}

case SP_VERB_LAYER_FLIP_TO_PREV: {

SPItem* currentLayer = SP_ITEM(dt->currentLayer());

if( currentLayer && dt->isLayer( currentLayer ) ) {

SPItem* prevLayer = SP_ITEM( SP_OBJECT_PREV(currentLayer) );

if( prevLayer && dt->isLayer( prevLayer ) ) {

currentLayer->setExplicitlyHidden(true);

prevLayer->setExplicitlyHidden(false);

dt->setCurrentLayer( prevLayer );

}

}

break;

}

This works, and so far it's all I need, but I'd still like to know how I would implement this as an extension. I didn't, because I couldn't figure out:

1. How to register extensions with keys. The verbs all seem to be mapped to internal functions.

2. How to call the extension's effect method. It's nonstatic, so I'd think need an object pointer somehow. Where can I fetch it?

For some reason, I couldn't find the corresponding code blocks for Grid or BlurEdge...

Also, I am still looking for some keys on the keyboard that are still available. "k" and "l" are maybe already used somewhere else. When I tried "," and "." (comma and period), it seemed they were already used by some stroke scaling effect, even though it was not specified in keys/default.xml. Does anyone know where these effects are specified or where I can find a full list of all keys?

Thanks for your help! Gerrit

_________________________________________________________________ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

On Mon, 2007-05-14 at 22:20 +0000, Gerrit . wrote:

This weekend, I finally found the time to play a little with Inkscape and try out your suggestions. I got the layer flipping working, not yet as an extension however.

Cool, it's not crucial that it is an extension, though it's always nice.

Here's what I did:

1. Added 2 actions to the key mappings in keys/default.xml

Looks good.

2. Added 2 verbs for these actions to Verb::_base_verbs[] in verbs.cpp,

defined in verbs.h.

Looks good. I'm hoping you added entries to verbs.h also, but if it works, you probably did.

3. Wrote 2 case blocks for the verbs.

Yup. Looks good.

This works, and so far it's all I need, but I'd still like to know how I would implement this as an extension. I didn't, because I couldn't figure out:

Okay, I'd like that too.

1. How to register extensions with keys. The verbs all seem to be mapped to

internal functions.

Basically there are two types of verbs. The ones that you're looking at are all static verbs, they're created with fixed IDs mostly at compile time. There are also dynamic verbs that are created at run time, the extensions all fall into this category. There are actually a few other verbs that do this, but by and far, the majority are static. If you look at the two Verb constructors, you can see that one knows the code, and the other creates it -- those are the two categories.

2. How to call the extension's effect method. It's nonstatic, so I'd think

need an object pointer somehow. Where can I fetch it?

The effect method gets called by the verb. Basically the verb that gets created is a subclass of the global Verb, called an EffectVerb. The effect verb calls the effect function. That's all taken care of, you just need to subclass Implementation.

For some reason, I couldn't find the corresponding code blocks for Grid or BlurEdge...

/src/extension/internal/grid.[cpp,h] /src/extension/internal/bluredge.[cpp,h]

You'll also need to modify:

/src/extension/internal/init.cpp

To add a line for initializing your extension. You can just search for "Internal::Grid::init()" and put it in that list. I'm working on cleaning this little messy-ness up, but haven't done so yet. (feel free if you'd like :) )

I think the biggest trick here is in that init function, basically this is where you're creating the extension. Don't forget the N_() on some of the strings, as that is how they get marked for translation.

--Ted