Gtkutil::registryconnector

[OrbWeaver]

In the latest revision I am getting an error about "gtkutil/RegistryConnector.h" not being found -- is this something that has been left out of a commit?

 

EDIT: Damn forum software, I will choose my own capitalisation dammit.

[greebo]

Sorry, forgot to add them to the repository. They are on SVN now.

[OrbWeaver]

That fixed the compile error, but now I get this on running:

 

WARNING: Failed to load module /home/mdm/workspace/DarkRadiant/install/modules/xmlregistry.so:
/home/mdm/workspace/DarkRadiant/install/modules/xmlregistry.so: undefined symbol: _ZTV8Registry

 

I get this if I fail to change the build options of a module to link in an additional library when adding code from that library. However I am not sure which symbol this is since "Registry" is defined in the include file, not a library.

[greebo]

Strange. I added some methods the registry recently, perhaps I forgot to commit this as well. My build is working ok, so I will send my current changes to SVN now. Stay tuned, commit is on the way!

 

edit: committed. Does it work?

[OrbWeaver]

Unfortunately I still get the same error. I found that there is a demangle option for nm which reveals that _ZTV8Registry is in fact "vtable for Registry". If I recall correctly, a missing vtable indicates that there is a virtual function in your subclass whose implementation is missing. There is some discussion of ths issue here.

 

Could you have added new virtual functions to the Registry base class but forgotten to provide implementations in XMLRegistry?

 

EDIT: Hold on, there are a couple of functions in Registry which are virtual but not pure virtual (= 0), this could be causing this issue. Recompiling now.

 

EDIT2: Yep, that fixed it.

[greebo]

Damn, I forgot to make them purely virtual. Why did it work on my machine then? Is that an OS-specific issue?

 

However, thanks for fixing this and sorry for the inconvenience!

[OrbWeaver]

Damn, I forgot to make them purely virtual. Why did it work on my machine then? Is that an OS-specific issue?

 

I actually have no idea, it never should have worked. Maybe the way in which Windows DLLs resolve external symbols is different.

 

However, thanks for fixing this and sorry for the inconvenience!

 

No problem, it's all useful experience.

[greebo]

As the thread already exists, I can explain what the RegistryConnector class is about anyways: I extended the preferencesystem with some methods that allow the adding of widgets to the preference pages and connecting their values to the XMLRegistry values (by passing the according key). This way I moved the camera and the brush preferences into the registry.

 

For example, one calls page.addEntry(, ); and the preference system does the rest. To actually connect the widgets I introduced the registryconnector which accepts the GtkObject* and the registryKey as argument. It internally maintains a list of all connected objects/widgets and loads/saves the values on demand. On calling "importValues()" the registry values are loaded into the widgets and converted where appropriate, on "exportValues()" they are saved back into the XMLRegistry.

 

The import and export methods are called by Radiant's Dialog class, where I added such an RegistryConnector object as member variable. So, each dialog has such a RegistryConnector built-in and also provides the according methods to add connected widgets to the dialog. Before the modal dialog is shown, the importValues() method is called, and in the PostModal() function the values are exported into the registry (if the user pressed OK, that is, but this is a virtual method if I recall correctly, so this behaviour is customisable).

 

I thought I post this here, as this could come in handy for general dialogs as well (one could add widgets that reflect preference settings in other dialogs than just the preference dialog window).

 

Currently, text fields, checkboxes, sliders and dropdown lists are recognized, but this can easily be extended if anything else is needed.

[OrbWeaver]

As the thread already exists, I can explain what the RegistryConnector class is about anyways: I extended the preferencesystem with some methods that allow the adding of widgets to the preference pages and connecting their values to the XMLRegistry values (by passing the according key). This way I moved the camera and the brush preferences into the registry.

 

That sounds like a needed feature, ideally the preference system should be based entirely off the XML registry and the old PreferenceDictionary (and its HashedCache) removed. This will enable the removal of the old libs/xml library in favour of the new xmlutil.

 

I actually made a start at this a while ago, but there were so many dependent changes that needed to be made that I got frustrated and reverted all the changes.