Am I correct in thinking that the other person reviewing the design can see everything just like the original designer (who has all the parameter files), but modifications to the drawing may require those files?

Only if the modifications needed are to add/replace or augment with (new) elements from the parm files.  Moving or Deleting existing elements, or Joining, or Adding flexible track elements, or Draw elements, etc - can all be done without needing the original parm files.  

Note that many parm files are shipped as part of the product - so it is only those that aren't which could be an issue. The format of parm files is text - so if needed they could be emailed, for example.

And if there are parm files with generally useful elements that we do not already ship inside the distro, we are always open to donations!! 

Adam

In short, yes. The .xtc file does not depend on parameter file contents, the elements are all copied/cloned into the layout.

Peter,
The N-Kato-Unitram file is shipped inside the product itself. Go to File->Parameter Files->Library and search for Kato.  The Unitram file should be listed. Hit "Add" and then "OK". 

The old parm file would still be loaded at startup in Mac case even after being deleted from Windows because they have different settings files so it needs to be removed from each using the Parameter Files Menu. (Unload). 

Adam

Peter Borcherds

BNSF Chicago Sub in N Scale
N Scale Commuter, Freight & Switching Layout

Website: https://www.chicagosubnscale.com/
YouTube: https://www.youtube.com/channel/UCZ-9Z-cHsMP5gw3ZXoOezLA
Facebook: https://www.facebook.com/chicagosubnscale
Instagram: https://www.instagram.com/chicagosubnscale/

This work has shown me that the color pallette works in inscrutable ways, making it very difficult to create and save a suitable gradation of colors.

This is a hangover from the days when XTrackCAD was born.  Those of long memory may recall that early graphics hw support had to use a limited "palette" of colors. You could have any color you wanted but only 16 or 256 different colors.  So it is that today, the colors users input are still "clustered" into a limited palette by seeing how far "off" a color is from ones already in use. 

One of the advantages of moving to a universal GTK3 would be to get away from this heritage and just use the "real" colors as input. 

In that area are also the potential of including transparency (alpha) with colors, gradient fills (and maybe pattern/hatch fills as well). 

Spray painting, however, is likely going to be beyond a vector-based (rather than raster-based) program. Things get complex with zooms and so forth. 

Adam

The deal is we have to pick between some imperfect solutions as we navigate between platforms and windowing systems. The situation of cursors and their behavior as they move between what are actually two separate widgets/windows (hotbar and drawing area) on Unix&Mac/Windows is not fully under our control.  We are building on some divergent underlying technology stacks. As a result, the implementation is a compromise between competing user interests/requests. On the one side is precision and clarity of effect. On the other is ubiquity of the system cursor in spite of the misleading impression.

In V5.2 we did not originally suppress the system cursor (cross-hairs) at all. This led to having two "cursors" (system cursor and the specialized prompt/anchor which could be in a different place due to magnetic snapping) and was complained about by users in some bug tickets and feature requests because (on Windows at least) different system cursor "effects" could be set in such a way that it inverted colors or otherwise got in the way of the XtrkCAD prompt/anchor and didn't show precisely where the action would take place.  The suggestion that users could disable that type of behaviour in the Windows preferences was not deemed adequate.  So then we added code that (imperfectly in a couple of cases, see below) suppressed the system cursor if the specialized cursor was drawn on the drawing surface.  You'll see that in most cases, this ensures only one cursor shown at a time, so the effect of what a user will do if they click is clear. 

There were some clear cases where the cursor was being suppressed too long (all ones we have found so far have been fixed and will be included the upcoming Beta V3.1 version). I also added some "belt and suspenders" code to always reset cursor state when a new command is run as well as after Esc.

However, there is still the issue that (on Windows and not UNIX) there seems to be a "buffer-zone" where the system does not  signal us that we have moved into the other window even though we have moved a long way into the hotbar and so doesn't allow us to turn the cursor on again. I imagine that may be related to not setting the focus to be on that hotbar window (doing so has negative effects the other way round when moving off it and back to the surface as you would have to click twice (once to gain focus, once to do the action). To cope with the system buffering, I have added some more code that keeps/restores the system cursor when within 20px of the drawing window edge (in-spite of the cries of pain from the overlay crowd, no doubt). 

The price of fixing the "but you left part of an XTrackCAD cursor stranded on the edge of the drawing area" complaint, would be that we suppress drawing that cursor when close to the edges as well (swap cursors). This would reduce the knowledge and precision of any specialized cursors/snapping in that buffer zone, however.  

I am not inclined to move back to V5.1, since that would remove a large amount of the usability gains of showing the user what will happen and where.

What we could do is to have an option that says (don't suppress system cursor). I suspect that those who requested the change to suppress the cursor are among those that now dislike the suppressed cursor...  But it would be relatively easy to give the option.  

This is not, of course, an excuse to not fix any remaining suppression circumstances as they occur.

Adam

Peter Borcherds

BNSF Chicago Sub in N Scale
N Scale Commuter, Freight & Switching Layout

Website: https://www.chicagosubnscale.com/
YouTube: https://www.youtube.com/channel/UCZ-9Z-cHsMP5gw3ZXoOezLA
Facebook: https://www.facebook.com/chicagosubnscale
Instagram: https://www.instagram.com/chicagosubnscale/