[rkward-cvs] SF.net SVN: rkward:[4437] trunk/rkward/rkward/plugin/rkoptionset.cpp

[tfry at users.sourceforge.net]

Revision: 4437
          http://rkward.svn.sourceforge.net/rkward/?rev=4437&view=rev
Author:   tfry
Date:     2012-11-21 12:52:45 +0000 (Wed, 21 Nov 2012)
Log Message:
-----------
Push some notes, which are in the way of the following commit.

Modified Paths:
--------------
    trunk/rkward/rkward/plugin/rkoptionset.cpp

Modified: trunk/rkward/rkward/plugin/rkoptionset.cpp
===================================================================
--- trunk/rkward/rkward/plugin/rkoptionset.cpp	2012-11-20 12:19:29 UTC (rev 4436)
+++ trunk/rkward/rkward/plugin/rkoptionset.cpp	2012-11-21 12:52:45 UTC (rev 4437)
@@ -241,7 +241,7 @@
 // NOTE: *Not* fetching any other properties. Esp. not from the contents_container!
 }
 
-void RKOptionSet::setPropertyValues (QMap< QString, QString >* list, bool warn_internal) {
+void RKOptionSet::setPropertyValues (QMap <QString, QString>* list, bool warn_internal) {
 /* What happens when deserializing a plugin, with a driven optionset, and
  * the property connected to the keycolumn is restored *before* the optionset itself has been de-serialized?
  * 
@@ -255,6 +255,10 @@
  *       this assumption is valid, but it could change, of course.
  */
 	RK_TRACE (PLUGIN);
+#warning Grrr. It doesn't work like this!
+#warning Also it's wrong. Serialization needs to be done by rows (using the row's contents serialization!).
+// The good news is that this means that regular properties can be used, with not virtual fetch/setPropertyValues.
+// The above note still applies. Keys should be de-serialized last. This can simply be done by giving them a name that will be sorted last in the map (zzkeys, or something)
 
 #warning ------------------- TODO ----------------------
 	RKComponentBase::setPropertyValues (list, warn_internal);

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