greebo

Yeah, I just went quickly over this changelog and it's mostly SPoG who worked on this piece it seems. Many years ago (I was 15 I think) I considered it to be kind of uncool to write comments, as I thought: real programmers always know their code, but we all get wiser, don't we? My largest Pascal/Assembler pieces were about 10k lines of code (uncommented of course), which was not a problem as long as I constantly worked on it, but imagine what happened to my brain as I re-opened some of the files two years later.

I totally agree, altough I personally prefer paper and pencil to plan out my code, but of course this is a matter of taste . I also use the time that it takes to compile my changes to comment the code. This worked quite well up to now, but it gets harder now as the compile times have reduced recently

Ok, will do what I can. Aren't there several people on GTKRadiant itself? I first suspected that they may be faster than us because of more manpower. Or are they heading to different directions (like Wolfenstein-specific things)? Is id software still involved in GTKRadiant development?

This one-man-show stuff reminds me a bit of the Ion Storm Guy who coded this uber-leet flesh engine all by himself. On the one side it's pretty impressive for me, as he must have been skilled at coding, but on the other hand it was foolish to believe (from both Ion Storm and that guy himself) that one man alone can code an engine in such a short time without turning it into one huge hack. But back to the selection stuff: I re-read some of the code in selection.cpp and it's getting somewhat more transparent by the time (but there is still some way to go for me). It's hard to disentangle and overview all those classes if everything is written into one cpp-file that's weighing several thousand lines. Briefly I thought about separating some of these classes in files and putting them in subdirectories, but I'm afraid that cross-porting features from GTKRadiant would get really hard for us afterwards.

Ok, I'll let you know, if this is too much for me. At least I should be able to drop some comments between the lines - it's amazing to find 1 commented line for 3000 uncommented ones. How many people were writing on the base GTKRadiant application?

My first impression on this topic: this seems to be a hard nut for me. I spent the last 4 hours reading code and I'm still uncertain where to start... I think I understood how the clicks are monitored and passed on to the according observers, but I have no idea where the actual connections are being established (I lost the trace somewhere in this jungle and I'm too tired for today). What I found out is, that the current entities (including lights) don't seem to support for the eComponent selection modes, so this needs to be implemented. I wonder if this kind of overlaps with the future task of projected lights, as their vertices have to be draggable as well. There are also some fragments of code that were introduced with projected lights in mind, but they are commented out and not finished as it seems. I'll look further into this, but this maybe too much for me, but I'll try of course.

I just wanted to post this here, when I realised you already edited this into your post I will just add a version tag to the current user.xml, this should make upgrading even easier in the future.

Before I will take a look at the code for the draggable light center, I will implement the versioning check of the user.xml file. I think I will need about two or three days (maximum) to do this. Is this fast enough for the release of DarkRadiant 0.7.0, Orbweaver?

No, the colour of the dashed brush/patch selection lines is already customisable, I referred to the camera view (render view), where all objects are being half-transparently overdrawn with a red colour when selected. BTW, you can change the dashed line to a solid line via the preferences, so the selection highlighting is fully adjustable at the moment.

Try this: scons BUILD="release"

Well, the debug exe is huge IMO (takes 60-70 MB), the release build takes only 4.2 MB of disk space, so there is a LOT of code or information missing in the release build. But as I use globalOutputStream() for debugging anyway, the missing debug info doesn't affect me. I really hope that this effect lasts, as I'm working at least 60% of my time on Windows.

I'm still looking for the red overlay of selected brushes in the camera window, but instead I found the colours for patch and brush vertices. These are on SVN now. I also had to increase the row count in the scheme editor, since it was getting really big. BTW: I recently built DR in release mode for angua, and now scons defaults to release mode when hitting Ctrl-B in Eclipse (this is kept till I clean the targets or force scons to build in debug mode). When compiling in release mode my build times have decreased dramatically (5 sec. for the exe link), as you have experienced it before, so maybe the build mode is the reason for the ultra fast linking.

Ok, I've replaced some more hardcoded colours, including the colours of... ...the small x,y,z axis indicator ...the workzone lines ...the camera icon ...the brush size info ...and the light volumes. At the moment the "selected brush" feature requires a DarkRadiant restart for the changes to take effect, I couldn't find out where this colour is set, perhaps I stumble on it in the future. I had to implemented an override of the light volume colour (which is originally defined in misc.def), so that one is able to choose the colour via the scheme editor. Additionally, the function colourschemes() is now available in GlobalRadiant(), although it's unused at the moment.

Actually, there was just the according update call missing - the colours were reloaded correctly, but the scene was not updated after reloading. This is fixed now as well as a bug with reflecting the read-only status when only one scheme (the default scheme) is left to edit. I also changed the copy behaviour, the newly copied schemes is now automatically highlighted.

Hm, it really should be reverted, as I reload all the colour info from the XMLRegistry on cancel. The colourbutton callbacks just alter the in-memory colour schemes, not the registry itself. Only upon pressing OK the changes are written into the registry. I will try to reproduce this. edit: yep, is reproducible.

The original themes are now on SVN. There is not much difference between the default scheme and the QE3Radiant one (that only makes the minor grid invisible). All themes except the default one have the readonly flag unset, i.e. they can be deleted by the user.

I found quite a lot of hardcoded bindings in camwindow.cpp. I suspect that these can be customised with reasonable effort.

Ok, I'm done with the colours. Should I include the three other schemes ("Maya Emulation", "Q3Radiant Original", "Black and green") in the install/user.xml or aren't they used by anyone anyway? I will do an SVN update and fresh compile and then it should be ready to commit. edit: committed.

I have one colour left to implement before it's finished, so the feature should definitely make it till the weekend. I already removed the unused stuff and will try to add some more options to the scheme editor as I stumble on them.

Thanks, I will try to change the class so that it is as simple as possible without having to change the entire ColourSchemeEditor methods - I will particularly focus on removing the internal GdkColor storage. On a different note: has someone managed to change the colour of a selected brush (both XY and camera view)? Looking at the code, I suspect that these options were never working. I also noticed that "Grid Minor Small" and "Grid Major Small" aren't used anywhere in the code, so I'll kick them both.

Ok, I'm running into the first problem: I have this operator in my ColourItem class: ColourItem::operator GdkColor* () { return &_gdkColor; } which returns a pointer to the internal GdkColor member variable. I use this for, say, the gtk_color_button_new_with_color() method, which expects a pointer to a GdkColor variable. How would I do this with no internally stored GdkColor variable? If I did it this way: ColourItem::operator GdkColor* () { GdkColor returnValue; // ... pump the rgb values into the returnValue return &returnValue; } I would return a pointer to a variable that would get destroyed immediately after return. How should I do this in a clean way? For GTK+ the GdkColor object has to be stored somewhere for the ColourButtons to function correctly, hasn't it? I think this was my main reason for making the _gdkColor representation an actual member variable of the ColourItem class, so that I can easily provide a pointer to an object that stays "alive".

Ok, will change this. In my first version I stored the ColourItems in a vector and I recently replaced this by a std::map, therefore the redundancy. I will fix this. I must admit that I implemented the ColourItem class because I wanted to get some practice with classes. But as I don't want to clutter the codebase with redundant functions, I will of course remove it. One thing that I somehow like about the ColourItem class is the constructor that takes an xml::node to retrieve the colour information, but I guess this can also be done another way. I will stick to the Colour3 inheritance you suggested. I guess my code can be classified under "bad design", so I'm sorry for that. Four weeks of C++ are not that much I reckon, but I will work on that.

Thanks for the FAQ, I have a couple of purple, visited links on that site . I know the difference between stack and heap, but obviously I just didn't think about this. edit: The changes are now on SVN, I hope I got it right this time. Thanks for your support, Orbweaver!

Ah, I see. Another lesson learned...

Thanks, I will try to fix this! (Strange, why doesn't it crash on Windows?) Concerning the gtk_main() loop: I only implemented this, because I got some really weird crashes when I don't call the loop. For example, the signal "changed" got called only once and crashed DR immediately when it got called the second time. Perhaps I did something wrong (most probably I did ), but the problem magically disappeared after using gtk_main(), so I thought this call was vital for GTK dialogs to function correctly.