Itches, Glitches & Anything Else...

[greebo]

OrbWeaver, do you know how I can disable the Alt-Shift-LMB being caught by the window manager? It seems that my Ubuntu has assigned this to "Move Window" by default.

[OrbWeaver]

I'm fairly sure you can't disable it within DR, but there must be some way of configuring it in Gnome, even if you have to use the gconf-editor application to edit the "registry" manually.

[greebo]

I already looked under Compiz>General>allScreens>Options, but there was nothing. However, I will probably assign something else in my input.xml, before I spend half a day searching for that key.

[Fidcal]

I don't think this should work anyway but trying to parent a brush directly with a model door entity gives the error: "The instruction at nnn referenced memory at nnn. The memory could not be read. Click on OK to terminate the program." Shall I add to bugtracker?

[OrbWeaver]

It shouldn't work, but it certainly shouldn't crash either.

[greebo]

What is the purpose of the spritemodel module? I had a brief look at the comments and it seems to be a bit outdated, referring to Q3 and Half-Life. It's the only module still referencing the libs/mathlib folder, btw, that's why I ask.

[OrbWeaver]

I don't think spritemodel is used, in fact I am surprised I didn't remove it already (unless I tried and it was in fact used for something, I can't remember).

[greebo]

Off it goes then, along with the mathlib. I checked and it wasn't included in the sconscript, so it's certainly not used.

[greebo]

Back in Windows, I got this nice scons error (after being able of compile a few times, it now instantly exits with this):

scons: Reading SConscript files ...
TypeError: Tried to lookup Dir 'build\release' as a File.:
 File "G:\Dark Mod\darkradiant\SConstruct", line 331:
SConscript(g_build + '/SConscript')

WTF? I didn't change anything there, it just stopped working from one compilation to the other. Googling is not terribly helpful here, searching for the error hardly gives results. Any ideas?

 

I have already tried upgrading to scons 0.97 (brand new), but this gives me the same result.

[OrbWeaver]

Not sure, can you print out the value of g_build before you get to that line? It looks like it should be "build/release", which raises the question why it is looking in there for the SConscript file which is in fact in the root of the tree.

 

EDIT: Seems there is a note in the manually about that last part:

 

			  Note that specifying a BuildDir works most naturally with a sub‐
		  sidiary SConscript file in the source directory.   However,  you
		  would then call the subsidiary SConscript file not in the source
		  directory, but in the build_dir , as if scons had made a virtual
		  copy  of  the  source tree regardless of the value of duplicate.
		  This is how you tell scons which variant of  a  source  tree  to
		  build.  For example:

		  BuildDir(’build-variant1’, ’src’)
		  SConscript(’build-variant1/SConscript’)
		  BuildDir(’build-variant2’, ’src’)
		  SConscript(’build-variant2/SConscript’)

[greebo]

I wondered that myself. I already tried to specify the SConscript directly:

SConscript('./SConscript')
SConscript('G:/Dark Mod/darkradiant/SConscript')
SConscript('C:/temp/darkradiant/SConscript')

all to no avail. The funny thing is, if I specify an invalid sconscript location, it says "ignoring non-existant sconscript" or something like that. If I point its nose to the very file, it raises this error. I'm currently downloading a new Python version, maybe this helps. So many problems these last few days...

[greebo]

New Python didn't help, but doesn't hurt either.

 

Angua is getting that same error now, so perhaps it's the SConscript itself. I'll go back the SVN history (yet again).

 

edit: Yep, revision 1829 is working, there is something weird in the SConscript.

[OrbWeaver]

I made some formatting changes to the SConscript recently, but I don't see why it would cause some filesystem error when actually loading the SConscript.

[greebo]

The radiant_src expression has been reorganised in revision 1830. I've virtually no experience in python, hence I have no idea what is going wrong here. OrbWeaver, can you give me a hand here?

 

edit: It seems to affect the Windows scons version somehow. If I copy over the version from 1829, everything is fine again. Strange.

[OrbWeaver]

I think I may have introduced a bug actually, the part that adds the icon is written as:

 

if radiant_env['PLATFORM'] == 'win32':
radiant_src += ' darkradiant.o'

 

but radiant_src is a list, so it should be

 

if radiant_env['PLATFORM'] == 'win32':
radiant_src += ['radiant/darkradiant.o']

[greebo]

Yes, this was the error, thanks a lot!

 

I don't get quite the hang of the various python types and the valid operations, it all seems to be a bit fuzzy. The lack of proper block brackets { } is giving me the creeps, but I guess Python's success is justified after all.

[OrbWeaver]

I don't get quite the hang of the various python types and the valid operations, it all seems to be a bit fuzzy. The lack of proper block brackets { } is giving me the creeps, but I guess Python's success is justified after all.

 

Python certainly has some really cool dynamic features, but I tend to agree the formatting is not good. It's all very well saying that using indentation for blocking "forces programmers to indent correctly", but just try copying and pasting some code between Python files and scratch your head wondering why it refuses to run (generally caused by different use of spaces and tabs which looks identical but isn't).

[greebo]

Another thing: I have turned IRadiant into an abstract base class - so far so good. I added the method getLocalPixbuf() to the interface, which is also fine, but there are some other gtkutil routines (like gtkutil::IconTextMenuToggle()) relying on the gtkutil::getLocalPixbuf() method.

 

As calls to GlobalRadiant() are forbidden here, how can I tackle this problem without having a static (global) bitmapsPath variable within the library?

[OrbWeaver]

I guess the IconTextMenuToggle will need to accept a GdkPixbuf* (which you get from GlobalRadiant().getLocalPixbuf) rather than a local string path.

[greebo]

Hmh, yes, I'll look into that if I can convert the other occurrences this way as well. Thanks!

[jdude]

I think it would be handy to have the ability to see what textures your map uses in alphabetical order. Maybe there could be options on how the texture window arranges the textures.

[greebo]

I don't know if there is any sorting in the current implementation, I'll add this suggestion to the tracker.

[sparhawk]

Python certainly has some really cool dynamic features, but I tend to agree the formatting is not good. It's all very well saying that using indentation for blocking "forces programmers to indent correctly", but just try copying and pasting some code between Python files and scratch your head wondering why it refuses to run (generally caused by different use of spaces and tabs which looks identical but isn't).

 

I have mentioned this several times on some pyhton forums, but you are always shot down.

"You are a newbie and have to get used to it."

"You must be doing something wrong it always works for me."

"But it's so great because it forces programmers to write nice looking code."

 

etc.

 

I also don't really like this indentation as a syntax but that's how it is.

[greebo]

It must be pretty tiresome to write the script parser for that, I mean which other language is using whitespace as syntax?

[Crispy]

Psh. Python's syntax is awesome. Braces are so 1980s.