I have two viewport windows: one 3D view only; the other split between 2D top and front views. I have to click to activate the 3D windows to navigate thru it. When I want to edit something on 2D I have to click-activate it first. PITA.

Also, if a dialog is active I have to click on the viewport window behind to Z navigate it. 

"I have two viewport windows: one 3D view only; the other split between 2D top and front views."

You do? How? And does it save between sessions somehow? 

Based on my tests Jackhammer could easily be supplied in an unzip and run configuration. The installation saves some uninstall information in the registry and offers to associate Jackhammer.exe with certain file extensions, it also attempts to set up various game configurations. None of that is really necessary.

Simply running Jackhammer.exe does not appear to create any program specific registry keys.

Windows itself will of course automatically make certain keys which refer to Jackhammer.exe, as far as I know this is unavoidable.

The Qt toolkit however, does create registry keys. So a true "portable" installation appears to be impossible in this case. 

Window / New window

You can have as many windows as you like for a single map. And no, it doesn't save between sessions, it's another request I did. The editor should save its state when it exits. 

Continuing to test Jackhammer, I noticed an unexpected executable, CrashSender.exe, in the Jackhammer folder.

This is apparently due to inclusion of something called CrashRpt (in the form of crashrpt.dll). According to the CrashRpt documentation, CrashSender.exe is capable of sending various data over the internet including desktop screen shots.

This is just my opinion, but it seems that use of CrashRpt and what it does should be disclosed during installation of the software and preferably be made optional. I couldn't actually make the software crash, so it's unknown to me if the user is prompted or not before any data is sent, what that data might be, or if data is even sent at all.

The current Jackhammer.exe will not run if the crashrpt.dll is missing. However, it will run without CrashSender.exe (though this will cause a message window to pop up when it starts). Rather than take any chances, I erased the CrashSender.exe, just because it's better to be safe than sorry these days. 

If you do not accept our privacy policy, please do not use Jackhammer (this link is displayed in a crash report window).
Crash report is sent if and only if you press the "Send" button in crash report window. This is not an option and never will be one in Windows versions, unless JH becomes very, very stable. If you doubt the way we use crash report, why don't you doubt the JH at all? Nothing can stop me to collect your passwords, nuclear missile activation codes and stuff from the JH's code itself. So, be sure you erase both CrashSender.exe and jackhammer.exe to ensure your privacy. ^_^ 

title. 

All I said was that use of CrashRpt should be disclosed at the time of installation and I suggested that it be made optional. Before posting, I looked all through the Jackhammer web site for a privacy policy, checking all links, and could not find one. If it's there, it is very hard to find.

I find your reply to my comments pretty bizarre and reactionary actually. 

IMO it is very hard to miss.
I personally respect privacy concerns in general and don't suppose them being ridiculous; I mean that CrashRpt library is quite clear and well designed, it asks for user permission before sending anything, contains a link to company's privacy policy, allows to examine the files about to be send, and so on.
I don't understand why the use of CrashRpt should be disclosured at any time except before sending the report, when it is *actully* used. If you don't press the "Send" button - nothing is sent, and what do you demand to disclose at the time of installation?
If there were any report sent without user's permission, I'd certainly make it clear and optional. But that's not the case.
And the last but not the least, CrashRpt is opensource and you can easily check it for any backdoors or whatever.

I'm sorry that you find my reply reactionary, but then I'd rather recommend not to use proprietary and closed source software, since you never can be sure of your privacy, unless you block program's network activity using a firewall. Just wait until JH becomes open source (it eventually will be).
The only thing I can do is to mention the use of CrashRpt in readme/installer as a part of "license agreement", without any options, however this is the first time during these 2 years when I get such a complaint... 

But I'm not sure of schedule. 

"Just wait until JH becomes open source (it eventually will be)."

=) 

I've slightly modified privacy policy text to be more clear. Now it explicitly mentions both the engine and VDK (which is actually Jackhammer). In the "Information we collect" section the statement "(etc)" is replaced with "Crash Minidump", so now it can't be voluntarily interpreted.
I've also put a link to the policy to the JH's website, at the bottom of each page. 

An option in the primitives to set what gridsize you want them to snap to. 

2 ptoing:
What do you mean? Snapping on dragging or on creation? 

I mean on creation. Everything is on grid, but it is the 1 unit grid. So if I want to make an arch or cylinder that is on say the 4 unit grid I have to do it by hand. 

Ok, but snapping cylinders and spheres to large grids may result in coplanar faces and overall bad looking geometry. There is even an option to turn grid snapping for created primitives off at all ("Don't snap primitive points to integer grid").
However you can create a cylinder one quarter of its original size (with snapping to integer grid turned on) and then scale it by four (using "Transform" dialog or manually resizing). After that its vertices will lie on 4 unit grid. 

Don't see how it would cause problems with cylinders. Spheres, yeah, those can be a mess already without being on a bigger grid.

Making a smaller piece and then scaling up is a decent workaround. 

Here is an example of problems with 256x256 cylinder when snapping to 4 unit grid: image. The larger is grid, the less subdivisions will cause problems. 

That makes sense, thanks for clarifying. 

I wanna stop asking things the UI wasn't meant to do.

So, I found a comfortable way to use Jackhammer: one maximized window, split in two views: one 3D and one toggled between top/front/side.

But since TAB toggles between 2D layouts, SHIFT+TAB could toggle backwards, don't you think? So far, SHIFT+TAB just gives focus to something else. Isn't it inconsistent? 

Added Shift+Tab to toggle backwards, thanks for suggestion.
Also added Tab and Shift+Tab shortcuts for 3D views, to change rendermodes. 

So I tried using the JH 'extract textures' feature, but where does JH deposit the created wads?

Oh, and for some reason JH won't recognize Zerstorer.wad. Any idea why this could be happening? 

Just not why zerstorer.wad won't work. 

I take it your wad is actually named zerst�rer.wad with the o-umlaut. If you rename that to o or something it will work. I reckon it is a unicode or otherwise text encoding issue. 

Thanks! MFX also pointed me in the right direction.