greebo

Can't reproduce this on Windows, what do you mean by "double free"? Do I destroy a widget that's already destroyed (that would be catched by GTK+, wouldn't it?)? Can you see any schemes in the editor list?

The Colour Scheme Editor is now on SVN, along with some changes to the XMLRegistry class. The colours aren't used yet (still to come), but the colours can be edited and saved correctly. Could Orbweaver or New Horizon test if I got everything right and DR compiles without glitches?

Ok, there seems to be an superfluous qualifier in the member function declaration. Strange, the compiler didn't mind until now and it definitely worked before I committed this version. Hang on, I will commit a larger change of the XMLRegistry later this evening anyway.

Have you tried to reinstall python or scons? Has the Python version changed with the upgrade from 6.06 to 6.10?

Ok, I'll add this version check when I'm done with the ColourSchemeEditor. It's nearly finished, I just have to clean up and document the code after doing some testing.

I see what you mean, but this would still not solve the problem with deleted colour schemes being re-imported on startup. With changed registry values this solution would work out fine, but as soon as keys get deleted, the XMLRegistry has a hard time distinguishing between items that are deleted on purpose and therefore missing and items that should be newly imported because they were never there. Additionally, IMO one of the strengths of using an XML tree is that I don't have to do tedious recursions when looking up or saving values. I would prefer a solution that does not require to walk the whole tree and touch every single XML node. I agree with you that the time-stamp method would introduce more problems. If we want to use time-stamps, we'd have to store them directly into the registry files, which can also be problematic or at least unconvenient to implement. I also thought of adding a "dirty" attribute to changed registry values, but I'm not sure if this would be practical or not. I think we should avoid altering the install/user.xml file, as all the default values are stored there. If we need to change this base file, we wouldn't need a local copy of the user.xml in the first place, would we? (Sorry, if I sound repulsive in this post, I don't mean to .) I'm somehow inclined to the option where we leave the base install/user.xml untouched after the initial import. We would need to add some version stamp to the base XML file (e.g. 0.6.0), so that the local user.xml is recognized as being outdated and the user can be warned that his/her changes are going to be overridden. Little changes could also be imported via a upgrade.xml file that could be added to the local user.xml. Would this produce any problems?

Ok, we definitely need a plan regarding the XML file conflicts. Right now I'm running into this problem: I can delete an existing colour scheme using the scheme editor and it gets correctly deleted from the registry. The correct structure is saved into the user's user.xml as well. The problem is: as soon as I restart DarkRadiant, the ColourSchemeManager searches the XMLRegistry for colour schemes and now the schemes stored in the install/user.xml are found as well, and the formerly deleted scheme gets re-imported, which is annoying. Possible solutions that I can think of: - Don't import colour schemes from the install/user.xml, unless the user.xml file is empty. This would be some kind of "hardcoded" feature, and we might run into the same problem with other registry structures. - Don't import anything from the install/user.xml if there is a copy in the user settings folder. The user.xml is copied into the user settings folder only once after installation and after that this is the only copy DarkRadiant is working with. Here, we have to address the problem of how to import settings that are added in later DR releases. The advantage of the latter version would be that conflicts are impossible, perhaps we could import new registry values with some kind of upgrade.xml that gets deleted after importing the new values into both copies?

Yes, I agree. Two things that came into my mind: 1. We add an export button the colour scheme editor, so that users can export their theme and import it after upgrading (this is not too much work). 2. We find a way to merge the two user.xml files, but there will be conflicts that have to be avoided. We somehow have to tell DR which nodes are new and have to be replaced/copied and which are not (like a patch file or something similar). Everything is generated from the XML file, even the descriptions. The addition of new colours is no problem at all, but one has to definitely touch the code if the newly defined colours are to be used in the right places as well.

This is the current draft: The button functionality is not fully implemented yet, but I hope that I can finish this tomorrow.

Just a quick update of my status: So far I've got the colourscheme routines implemented and the schemes can be loaded and saved correctly from and into user.xml. A rough version of the Colourscheme Editordialog is up and running, but at the moment it's dead ugly: I had a hard time figuring out the importance of the gtk_main() call, and I learned quite a bit about the GTK+ widgets, that's why it took me so long to get this "far". Additionally, I had to add some functionality to the XMLRegistry functions (add named nodes, delete xml subtrees and so on), but these may come in handy in the future. Still to come: - Tweak the dialog window (I want to arrange the colour buttons in two or three columns and of course add a description) and make it nicer overall - Add the "Copy" and "Delete Colourscheme" functionality. - Make the colours actually being used in the right places, so that the hardcoded colours disappear. I will do this after the whole functionality of the editor is done.

Oh, I've always had these needles (face normals, I assume) since I first compiled DR in July and I thought they were there on purpose, so I didn't mind. They are missing in the DR 0.6.0 Release Package, so I assumed there must be some kind of switch to turn these on or off. Orbweaver can tell us more about this, I hope.

There is this tutorial in the Documentation Forum. It's on DarkWiki as well (Creating multiple skins for a model), but as long as the Wiki database isn't replaced, you can find it here: http://forums.thedarkmod.com/index.php?showtopic=3098

You can highlight the face of the brush you want to copy the texture from. Select "Copy Brush Face" from the menu and then you can apply the copied texture by Ctrl-Shift-MMB to any brush face you point your mouse to. I assigned a shortcut to the "Copy Brush Face" command as I find selecting it from the menu as cumbersome. I'm working on that, you should be able to customise and save your own colourset in the future. Two of the four D3ED features have already been cross-ported from GTKRadiant: "Select inside" and "Select touching". This will be available in the next release.

I get your point. I'm positive that we would be able to choose a color set that doesn't hurt our sense of taste. However, if it is easy to do, I'd vote for keeping the door open for this.

Sounds ok to me. As long as there is some possibility to recognize/distinguish keys in that list, I can see that the flat list is faster to use. What I would add: I could imagine that colouring the property key/values according to their category (blue for model, green for light, red for readable keys or something like that) would help distinguishing if there are a lot of spawnArgs displayed. Is there anything we should keep in mind for future expansions like displaying keys that are inherited? Or should we perhaps display the inherited values in a grey colour to reflect their origin?

It's in the slums of Athkatla, where all the mercenaries wait for you to hire them (like Nalia). In the German version it's called the Kupferkrone. I personally found the sword quite annoying after a short time, but it has some cool features I have to admit.

Wouldn't this be a step back from the current system? You can choose many colours directly with a colour picker in the misc menu - I would find it inconvenient to have the user type in vector3-floats into the XML.

Ok, what are our requirements for the new colour scheme code? I can think of this: - Everything's stored in the registry (that was clear anyway). - A new dialog is opened where a list of saved colour schemes are displayed. Each scheme can be edited freely and saved as a new one (Save as...). The class hierarchy would be like this: - Colour (with "item" name and its colour value), basically a struct - Scheme (consisting of name and a map of colours) Methods located in the scheme class would be load(), save(), setItemColour(item, colourvalue), getItemColour(item) and of course the constructor that loads all the existing schemes from the registry. I can figure that a good deal of the work will be the scheme editor dialog with all its callbacks, but I already have a rough picture in mind of what would be necessary. Any comments?

Actually, there should be two such sections in the radiant log, as the toolbars are parsed everytime a ToolbarCreator class is instantiated (which happens twice: once in mainframe.cpp and once in texwindow.cpp). Thinking of this, I should probably change this in the same manner as it's done with the XMLRegistry, as local static instance.

Committed. All the other three window layouts work as well now. It was just two characters that had to be changed.

Shouldn't be too difficult - I will try to do this tomorrow. No toolbars at all? Is there some error message in radiant.log from ToolbarCreator?

Ok, will test it at 800x600 (although I believe anyone using this resolution for editing is kind of masochistic) and then commit the changes.

This is how it looks like at the moment: Any suggestions? It's a matter of seconds to edit the user.xml file to change the position of the icons.

Maybe there is some problem with the permissions for accessing this partition?

I found the problem: the findXPath method of the registry() object didn't append the /darkradiant automatically. The changes to XMLRegistry are committed, it's working now: xml::NodeList filters = GlobalRadiant().registry().findXPath("game/filtersystem//filter");