Difference between revisions of "Talk:Scripting"

From Freeplane - free mind mapping and knowledge management software
m (Text replacement - "</groovy>" to "</syntaxhighlight>")
m (Text replacement - "<syntaxhighlight lang="Groovy" line>" to "<syntaxhighlight lang="Groovy">")
 
(3 intermediate revisions by the same user not shown)
Line 33: Line 33:
 
I appreciate all of your work! Thank you. --[[User:Nz0ptk|Nz0ptk]] 12:50, 29 May 2010 (UTC)  
 
I appreciate all of your work! Thank you. --[[User:Nz0ptk|Nz0ptk]] 12:50, 29 May 2010 (UTC)  
  
Scripting would only allow for a reformat on demand. I don't think that this would be very useful but <tt>Node.getNodeLevel(true)</tt> is the method you need for checking the level and <tt>Style.setStyle()</tt> is the method for changing the style: <syntaxhighlight lang="Groovy" line>
+
Scripting would only allow for a reformat on demand. I don't think that this would be very useful but <tt>Node.getNodeLevel(true)</tt> is the method you need for checking the level and <tt>Style.setStyle()</tt> is the method for changing the style: <syntaxhighlight lang="Groovy">
 
if (node.getNodeLevel(true) == 4)
 
if (node.getNodeLevel(true) == 4)
 
   node.style.style = new org.freeplane.features.common.styles.StyleString('Subtopic')
 
   node.style.style = new org.freeplane.features.common.styles.StyleString('Subtopic')

Latest revision as of 18:30, 18 November 2018

Scripting Questions and Answers

In this section Volker Börchers, our scripting specialist, has kindly agreed to answer questions. For anyone reading this Wiki section on Scripting, please feel free to add your own questions here!

Only one attribute can be added per one script?

By the current scheme: If the beginning of the script matches the pattern ^[a-zA-Z0-9_]+=, then the script would add one attribute with the name matched. As it only matters at the beginning of a script, thus only 1 attribute per script can be added.

I found that one can take advantage of the convention to calculate attribute values by the following pattern:

attributeName=<initialValue>

//procedures to compute the attribute's value.

// have the final value as the last expression in the script.

The current design seems an interesting one. But I'd wish that there was more comprehensive scheme to allow for multiple attributes to be added or updated by one script. --Yubrshen 11:22, 24 April 2011 (UTC)

The attribute assignment via scripts is a legacy feature that only can be used in the old formatting "Patterns"/"Physical Styles" until Freeplane 1.1. - So you can't use it for normal scripts. The best way to manipulate attributes is via the scripting API for attributes. This API will be greatly extended with the next stable release. --Boercher 17:07, 1 May 2011 (UTC)

Vertical Spacing in Map View

Ctrl+Drag works great, but can this be scripted? Some of my children nodes/branches really run together, and automatically vertically spacing them would be great. Thanks! --Nz0ptk 12:50, 29 May 2010 (UTC)

Currently this property is not scriptable. Please add a feature request for it in Mantis. --Boercher 18:59, 15 January 2011 (UTC)

Automatic Layout Styles

Is it possible to take the automatic layout styles that I have created, and extend them to affect more levels than the default 4-5 via scripting? If so, the first thing would be to find out where they're stored?

I appreciate all of your work! Thank you. --Nz0ptk 12:50, 29 May 2010 (UTC)

Scripting would only allow for a reformat on demand. I don't think that this would be very useful but Node.getNodeLevel(true) is the method you need for checking the level and Style.setStyle() is the method for changing the style:

if (node.getNodeLevel(true) == 4)
   node.style.style = new org.freeplane.features.common.styles.StyleString('Subtopic')

In the next preview version 1.2.2_05 I will change that to node.style.name = 'Subtopic' for simpler use.

But the best option for you is to use the new Conditional Styles feature introduced in version 1.2. Under Style > Manage Conditional Styles you can define Styles dependent on the node level. --Boercher 07:52, 11 January 2011 (UTC)

Execution Modes

On the main Scripting page, under the heading Execution Modes, I'm confused by the phrase Execute on one selected node. From following along with the tutorial, it seems to me that a better name for this would be Execute the script once, accessing all selected nodes. Is my interpretation essentially correct? Otherwise, please set me straight!

Thanks, --Jayseye 23:18, 11 March 2010 (UTC)

Hard question, but I think a "no" is appropriate. It took a while until I had the impression I had found a proper name for this mode. It's irrelevant here that the script may access more or less nodes since every script has access to every node by using the appropriate controller methods (like currentNode, rootNode). The execution modes are only dealing with the implicit "node" variable. Selecting Execute on one selected node should mean:

  • Only execute this script once - no matter how many nodes are selected.
  • The script is not interested in the "node" variable (although node is set to some node). - Select whatever node you want before calling the script - the script doesn't care.

I considered Execute once as an alternative but I thought that Execute on one selected node would support that "node is set but it doesn't matter" aspect. (That might be wrong.)

The other modes in contrast are meant for scripts that actually refer to the "node" variable. They are executed once for every selected node (in one of these modes recursively).

I expected this to be complicated since it took me two takes to get the concepts right. I'm sure, you will find the right words to make it comprehensible.

BTW: I really enjoyed looking over the changes you've made so far. --Boercher 00:33, 12 March 2010 (UTC)


Working through the tutorial again really convinces me that we need a more descriptive menu command in place of Execute on one selected node; perhaps Execute once would be clearest. The reply above from last March describes the internals "under the hood" re the node variable; however, the user's point of view is most relevant here.

Specifically, when running sumNodes.groovy it definitely is relevant which nodes are selected in the map. In this case it misses the point to say "Select whatever node you want before calling the script - the script doesn't care." Does this example clarify the issue? Jayseye 09:22, 9 January 2011 (UTC)