[rkward-cvs] SF.net SVN: rkward: [1894] trunk/rkward

[tfry at users.sourceforge.net]

Revision: 1894
          http://svn.sourceforge.net/rkward/?rev=1894&view=rev
Author:   tfry
Date:     2007-05-09 14:19:06 -0700 (Wed, 09 May 2007)

Log Message:
-----------
Small additions

Modified Paths:
--------------
    trunk/rkward/TODO
    trunk/rkward/doc/en/writing_plugins_introduction.docbook

Modified: trunk/rkward/TODO
===================================================================
--- trunk/rkward/TODO	2007-05-09 16:51:01 UTC (rev 1893)
+++ trunk/rkward/TODO	2007-05-09 21:19:06 UTC (rev 1894)
@@ -121,6 +121,12 @@
 	- provide a menu action / shortcut to switch to the directory of the current script file.
 	- Quitting:
 		- instead of closing windows one by one, and asking to save changes if necessary, first list all windows that might need to be saved, let the user chose to save them, then close all windows without further questions.
+	- RObjectViewer
+		- also show the summary for objects
+		- do some formatting to make it look nicer
+		- make it an MDI window
+		- add update buttons and such
+			- on updating: if object has changed, display a note to that effect in the window
 
 Internal stuff:
 	- Handling fonts:
@@ -215,12 +221,6 @@
 		- provide the set of enclosed options for each of the selected variables
 		- will provide dynamic properties based on which variables are selected in the source
 		- how to determine default values?
-	- RObjectViewer
-		- also show the summary for objects
-		- do some formatting to make it look nicer
-		- make it an MDI window
-		- add update buttons and such
-			- on updating: if object has changed, display a note to that effect in the window
 
 Documentation:
 	- add an example to show rkward-specific commands (rk.print, rk.graph)

Modified: trunk/rkward/doc/en/writing_plugins_introduction.docbook
===================================================================
--- trunk/rkward/doc/en/writing_plugins_introduction.docbook	2007-05-09 16:51:01 UTC (rev 1893)
+++ trunk/rkward/doc/en/writing_plugins_introduction.docbook	2007-05-09 21:19:06 UTC (rev 1894)
@@ -41,7 +41,7 @@
      and in the FDL itself on how to use it. -->
 <legalnotice>&FDLNotice;</legalnotice>
 
-<date>2007-04-25</date>
+<date>2007-05-09</date>
 <releaseinfo>0.4.8.00</releaseinfo>
 
 <abstract>
@@ -1167,7 +1167,7 @@
 That is, a plugin embedding another plugin will typically not need to know much about the internal details of the embedded plugin. A prime example is the plot_options plugin. Plugins wishing to embed this do not necessarily need to know about all the options provided, or how they are provided. This is a good thing, as otherwise a change in the plot_options plugin might make it necessary to adjust all plugins embedding this (a lot). In contrast, include and insert really exposes all the internal details, and plugins using this will - for example - need to know the exact ids and perhaps even the type of the elements used.
 	</para>
 	<para>
-Hence the rule of thumb is this: include and insert are great if the relevant options are only needed for a clearly limited group of plugins. Embedded plugins are better, if the group of plugins it may be useful to is not clearly defined, and if the functionality can easily be modularized. Another rule of thumb: If you can put the common portions into a single "chunk", then do so, and use embedding. If you need lots of small snippets to define the common portions - well, use <snippets>.
+Hence the rule of thumb is this: include and insert are great if the relevant options are only needed for a clearly limited group of plugins. Embedded plugins are better, if the group of plugins it may be useful to is not clearly defined, and if the functionality can easily be modularized. Another rule of thumb: If you can put the common portions into a single "chunk", then do so, and use embedding. If you need lots of small snippets to define the common portions - well, use <snippets>. A final way to look at it: If all plugins provide <emphasis>highly</emphasis> similar functionality, includes and inserts are probably a good idea. If they merely share one or two common "modules", embedding is likely better.
 	</para>
 	</section>
 </chapter>


This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.