OpenTemplot2024

[NoIdea]

This topic is about the internal programming of Templot. If you are interested only in using Templot, this topic can be ignored.

---

But when I made Templot (as it then was) open-source in 2018, I did hope that by 5 years later there would be a group of users with as much knowledge of the code as me. Sharing and developing ideas together. Sadly that hasn't happened. There has been occasional short-lived interest from programmers, but no-one who was an actual user of Templot or with much, or any, knowledge of railway track or track-building. Usually the interest has been in computers to get the existing code running on a different platform, rather than extending and developing it further for track planning and building.

Is it still open source, Martin? I've looked over the Templot Club links looking for a source repo link but couldn't find one...

 

[Martin Wynne]

Is it still open source, Martin? I've looked over the Templot Club links looking for a source repo link but couldn't find one...

@NoIdea

Hi Martin,

Yes, but bear in mind the original code was from 2018 -- it didn't include a lot of later developments and plug track.

It's time I released some later versions of the files, but it's a massive task to prepare them all. Templot2 includes some licensed components which can't be open-sourced, and need to be cleanly by-passed or worked around.

edit: now updated:

https://sourceforge.net/projects/opentemplot/

Link:

cheers,

Martin.

 

[NoIdea]

Templot2 includes some licensed components which can't be open-sourced, and need to be cleanly by-passed or worked around.

Hi Martin,

I assume these are 32-bit DLLs? Are they COM components?

Could you identify them and their purpose?

Martin

 

[Martin Wynne]

Hi Martin,

I assume these are 32-bit DLLs? Are they COM components?

Could you identify them and their purpose?

Martin

@NoIdea

Hi Martin,

The non-open-source components are these in red:

They are not DLLs. Sorry, I do not know what a COM component is, although I have heard the term and no doubt I could find out.

For all these I purchased licences (a long time ago now, when Templot was a paid-for product):

DtpDocuments is a desk-top-publishing component. The core engine drives the sketchboard function in Templot. I purchased the Delphi source code and significantly modified it for the sketchboard user interface. Sadly the developer Nils Haeck suffered a brain injury in an accident and was unable to continue supporting his software:

https://torry.net/components/edits-memos/packs/dtpdocuments

TRichView is an enhanced text editor. It drives the formatted text blocks on the sketchboard. I purchased the Delphi source code:

https://www.trichview.com/features/trichview.html

wPDF is a PDF generator which drives Templot's native PDF exports. I purchased it in the form of Delphi DCUs (object files), although there is also a DLL option:

https://www.wpcubed.com/pdf/products/wpdf/

cheers,

Martin.

 

[NFWEM57]

@Phil G @James Walters

Hi Phil,

It's a good question.

At the back of my mind for years now I've been hoping to find a long-term user of Templot with as much Templot knowledge as me so that we could bounce ideas off each other -- and I could be the one asking questions and learning, instead of always the one answering the questions. Often the same ones I've answered many times before.

I realise that's not a realistic expectation now. But when I made Templot (as it then was) open-source in 2018, I did hope that by 5 years later there would be a group of users with as much knowledge of the code as me. Sharing and developing ideas together. Sadly that hasn't happened. There has been occasional short-lived interest from programmers, but no-one who was an actual user of Templot or with much, or any, knowledge of railway track or track-building. Usually the interest has been in computers to get the existing code running on a different platform, rather than extending and developing it further for track planning and building.

So it's just me. Templot is my hobby and I enjoy the coding and tinkering with new ideas. But to be honest it's being spoilt for me by the constant need to keep explaining everything. Over and over again. Since the present version of Templot Club started there have been 762 topics and well over 9,000 messages on here -- and here I am typing yet another one. And there are 3,000 topics in the archive from the previous version of Templot Club. And hundreds of messages on other forums. It's difficult to believe there could be much left to say after all that, and I'm getting weary of it all.

So what am I looking for in the Zoom meetings? Someone to come on with a brilliant new idea for Templot with details of how it would integrate into the existing code. Someone telling me things instead of asking me questions. I live in hope.

cheers,

Martin.

Martin,

What language is TEMPLOT written in?

Is it in manageable modules (i.e. Object Oriented Modules) or is it one piece of code that has continuously expanded over the years?

Is the code annotated? (Critical to anybody else understanding it..!)

Do you think it should, and if so, could be updated to reflect standard interface menus/protocols to make it more intuitive?

On constantly having top explain things, its called the RTFM problem - and people rarely do, especially if there is a very accommodating responder..!

Thank you for all your hard work.

Regards,

Patrick

 

[Martin Wynne]

Martin,

What language is TEMPLOT written in?

Is it in manageable modules (i.e. Object Oriented Modules) or is it one piece of code that has continuously expanded over the years?

Is the code annotated? (Critical to anybody else understanding it..!)

Do you think it should, and if so, could be updated to reflect standard interface menus/protocols to make it more intuitive?

On constantly having top explain things, its called the RTFM problem - and people rarely do, especially if there is a very accommodating responder..!

Thank you for all your hard work.

Regards,

Patrick

@NFWEM57

Hi Patrick,

Thanks. Welcome to Templot Club.

It was good to see you at the Zoom meeting last night.

Templot is written in Delphi5/Pascal. The open-source version will compile and run in Lazarus:
https://sourceforge.net/projects/opentemplot/

Sorry, I don't know what you mean by modules. There are about 80 .pas source files and a similar number of .dfm form files.

Yes, it has been continuously expanded over the years -- originally started 45 years ago in 1979. Yes, the code is commented, but in a strange martin-language which few understand.

Do you think it should, and if so, could be updated to reflect standard interface menus/protocols to make it more intuitive?

I think that is what Alistair and Graeme are trying to do, but we haven't heard from them for many months. I'm not sure what you mean by "more intuitive". I have tried many times over the years to follow similar suggestions, but always it has required that some functionality be lost, which I am not willing to do. Essentially Templot is my hobby, and developed for my own use as its primary purpose.

Here is the current full list of source files. Some are very long (thousands of lines), some are quite short. I added one more this morning:

  control_room in 'control_room.pas' {control_room_form},
  keep_select in 'keep_select.pas' {keep_form},
  switch_select in 'switch_select.pas' {switch_select_form},
  alert_unit in 'alert_unit.pas' {alert_box},
  help_sheet in 'help_sheet.pas' {help_form},
  math_unit in 'math_unit.pas' {math_form},
  xing_select in 'xing_select.pas' {xing_select_form},
  chat_unit in 'chat_unit.pas' {chat_form},
  pad_unit in 'pad_unit.pas' {pad_form},
  entry_sheet in 'entry_sheet.pas' {data_entry_form},
  info_unit in 'info_unit.pas' {info_form},
  print_unit in 'print_unit.pas' {print_form},
  gauge_unit in 'gauge_unit.pas' {gauge_form},
  metric_unit in 'metric_unit.pas' {metric_form},
  preview_unit in 'preview_unit.pas' {preview_form},
  colour_unit in 'colour_unit.pas' {colour_form},
  calibration_unit in 'calibration_unit.pas' {calibration_form},
  plain_track_unit in 'plain_track_unit.pas' {plain_track_form},
  startup_unit in 'startup_unit.pas' {old_startup_form},
  dxf_unit in 'dxf_unit.pas' {dxf_form},
  bgnd_unit in 'bgnd_unit.pas' {bgnd_form},
  bgkeeps_unit in 'bgkeeps_unit.pas' {bgkeeps_form},
  panning_unit in 'panning_unit.pas' {panning_form},
  grid_unit in 'grid_unit.pas' {grid_form},
  shove_timber in 'shove_timber.pas' {shove_timber_form},
  stay_visible_unit in 'stay_visible_unit.pas' {stay_visible_form},
  action_unit in 'action_unit.pas' {action_form},
  edit_memo_unit in 'edit_memo_unit.pas' {edit_memo_form},
  mint_unit in 'mint_unit.pas' {mint_form},
  wait_message in 'wait_message.pas' {wait_form},
  enter_timber in 'enter_timber.pas' {enter_timber_form},
  jotter_unit in 'jotter_unit.pas' {jotter_form},
  rail_options_unit in 'rail_options_unit.pas' {rail_options_form},
  print_settings_unit in 'print_settings_unit.pas' {print_settings_form},
  pdf_unit in 'pdf_unit.pas' {pdf_form},
  dtp_unit in 'dtp_unit.pas' {dtp_form},
  dtp_settings_unit in 'dtp_settings_unit.pas' {dtp_settings_form},
  sketchboard_unit in 'sketchboard_unit.pas' {sketchboard_form},
  prefs_unit in 'prefs_unit.pas' {prefs_form},
  print_now_box in 'print_now_box.pas' {print_now_form},
  export_unit in 'export_unit.pas' {export_form},
  platform_unit in 'platform_unit.pas' {platform_form},
  data_memo_unit in 'data_memo_unit.pas' {data_child_form},
  math2_unit in 'math2_unit.pas',
  check_diffs_unit in 'check_diffs_unit.pas' {check_diffs_form},
  image_viewer_unit in 'image_viewer_unit.pas' {image_viewer_form},
  dtpGR32 in 'DtpDocuments\Source\Third\Graphics32x\dtpGR32.pas',
  mouse_colour_unit in 'mouse_colour_unit.pas' {mouse_colour_form},
  file_viewer in 'file_viewer.pas' {file_viewer_form},
  sb_rvf_outer_unit in 'sb_rvf_outer_unit.pas' {sb_rvf_outer_form},
  sb_rvf_unit in 'sb_rvf_unit.pas' {sb_rich_form},
  arc_shape_unit in 'arc_shape_unit.pas',
  edit_outline_unit in 'edit_outline_unit.pas' {edit_outline_form},
  web_browser_unit in 'web_browser_unit.pas' {web_browser_form},
  map_loader_unit in 'map_loader_unit.pas' {map_loader_form},
  web_map_help_unit in 'web_map_help_unit.pas' {web_map_help_form},
  trackbed_unit in 'trackbed_unit.pas' {trackbed_form},
  make_slip_unit in 'make_slip_unit.pas' {make_slip_form},
  create_tandem in 'create_tandem.pas' {tandem_form},
  chairs_unit in 'chairs_unit.pas' {chairs_form},
  bitmap_viewer_unit in 'bitmap_viewer_unit.pas' {bitmap_viewer_form},
  shoved_colour_unit in 'shoved_colour_unit.pas' {shoved_colour_form},
  track_spacing_unit in 'track_spacing_unit.pas' {track_spacing_form},
  detail_mode_unit in 'detail_mode_unit.pas' {detail_mode_form},
  gaps_unit in 'gaps_unit.pas' {gaps_form},
  lib_unit in 'lib_unit.pas' {lib_form},
  intersect_unit in 'intersect_unit.pas' {intersect_form},
  getfile_unit in 'getfile_unit.pas' {getfile_form},
  httpsend in 'httpsend.pas',
  create_y_turnout in 'create_y_turnout.pas' {create_y_form},
  resample in 'resample.pas',
  map_clarity_unit in 'map_clarity_unit.pas' {map_clarity_form},
  jigs_unit in 'jigs_unit.pas' {jigs_form},
  dxf_warning_unit in 'dxf_warning_unit.pas' {dxf_experimental_form},
  heave_chairs in 'heave_chairs.pas' {heave_chairs_form},
  search_unit in 'search_unit.pas' {search_form},
  mw_unit in 'mw_unit.pas' {mw_form},
  brick_unit in 'brick_unit.pas' {brick_form},
  chair_frame_unit in 'chair_frame_unit.pas' {chair_frame: TFrame},
  export_preview_unit in 'export_preview_unit.pas' {export_preview_form},
  clips_unit in 'clips_unit.pas' {clips_form},
  heave_customize_unit in 'heave_customize_unit.pas' {heave_customize_form};

cheers,

Martin.

 

[NoIdea]

NFWEM57 - Patrick, I've downloaded the 2018 open source version and studying the code with an extension to VS Code. I'm not a Pascal developer so I'm going into a learning curve here. Hopefully my c#, typescript, c++ background will flatten the curve a bit.

I also need to learn more about Templot - I'm very much a beginner - and I think, like others, that the UX/UI that Martin has developed over the years, is, um, unusual, which is why IMHO there are repeated questions.

At the moment, I'm trying to figure out how best I can help Martin's endeavours. I respect that this is Martin's code, not an open-source project. I'd much rather Martin was implementing K crossings and flat-bottom rail support in Plug Track instead of implementing new menu structures (Only kidding, Martin) .

Martin

 

[Martin Wynne]

@graeme @Alistair Ward @NoIdea @NFWEM57

It's now nearly a year since there has been any activity in the open-source version of Templot.

Which makes me wonder where we go from here?

When I've got 244a released with the chair heaving done, I'm minded to start again and release the whole* of Templot2 as open-source in its present state, before going any further.

*apart from the licensed components which I mentioned in my previous post.

There is still a lot of chair designs to be done (not to mention GWR chairs and other prototypes), and having all the present code available might encourage others to have a go at them (and take a bit of pressure off me ).

When I say "release as open-source" I mean simply to publish the current Delphi5 files as-is. I'm not getting involved in Git repositories and such like -- I've tried and failed several times to understand that mystery, and wasted many many hours in the process. If others want the files committed/pushed/pulled/merged/forked or whatever it will be up to them to do it.

Just releasing the 160+ Delphi5 files is a big task, each one requiring the copyright and open-source licensing details added, a lot of tidying up, and the licensed components removed. Which is likely to take a month or two to get them all done, with a further delay to my getting back to the chairs. So it's a trade-off as to whether it is worth doing now, or at all.

On the other hand, if not now, when? I'm getting uneasy that folks will soon be relying on Templot plug track for their real-world projects, rather than just experimental tinkering, and hence relying on me alone. It's a lonely place to be.

Martin.

 

[Steve_Cornford]

Hi Martin,
I can understand your concerns.
In a past life I ran a small software company, and we looked after and developed a Stockbroker package pre Big Bang (that was when the Stock Exchange moved from fortnightly settlement periods to Rolling Settlement. To protect the clients (all 5 of them!) we entered into a Software Escrow Agreement that ensured in the event of our demise they would gain access to the source code.

Would it reduce your concerns if something like that was in place?
Steve

 

[Martin Wynne]

Hi Martin,
I can understand your concerns.
In a past life I ran a small software company, and we looked after and developed a Stockbroker package pre Big Bang (that was when the Stock Exchange moved from fortnightly settlement periods to Rolling Settlement. To protect the clients (all 5 of them!) we entered into a Software Escrow Agreement that ensured in the event of our demise they would gain access to the source code.

Would it reduce your concerns if something like that was in place?
Steve

@Steve_Cornford @James Walters

Hi Steve,

I'm not a company, and I don't have paying clients, so the situation is not the same. Open-source files are available to the entire world regardless, so no such agreement is needed.

At present the Templot files to which that applies relate to Templot as it was in 2018. You can download them as a zip file here:

https://sourceforge.net/projects/opentemplot/

But Templot has moved on a lot since then, not least for the 3D chairing, so it's time I released a fresh set of updated files. In practice that is easier said than done, because there are 160+ of them, and each one needs tidying up, with licence details added, and some copyright components removed without breaking the code.

Even when it is done it doesn't get anyone much further forward without some means of compiling the code. As it stands that requires a copy of the Delphi5 compiler from 1998. I can't publish that because it is copyright of Embarcadero, and I don't know where a copy might be obtained.

The solution is to compile the files in the open-source Lazarus compiler instead, set to Delphi mode. That requires some modifications in the code. I did that for the 2018 files, but it took a lot of time and testing, and would need doing again.

If we could get to that stage it would permit others to join in and help with writing code.

Which would be a big help because the truth is that my recent injury has made me realise that I'm getting old and tired, and it is all getting too much for me. I still enjoy writing new code to develop the Templot program forward, but all the rest -- explaining, explaining, explaining, making videos, doing Zoom meetings, running Templot Club and updating the Templot web site is now too much commitment. James is being a big help, but he has a day job and his own model projects.

And here I am writing yet another explanation, this time about the open-source files. Time now to get some lunch and no Templot work done yet today. I need to go out later, so it's not likely much will get done today.

Answers on a postcard.

cheers,

Martin.

 

[Stephen Freeman]

Well I do have a copy of Turbo Pascal but it is sitting on the original 3.5inch diskettes and I don't have a drive attached to any of the Windows 10 computers. I suppose I could copy them onto a CD/DVD via my special retro PC (don't ask why I have one) or alternatively I might just have a copy of Delphi5 as they were very fond on putting them on PC magazine cover CDs at one time. I shall have to see.Found the diskettes bu no CDs as far as I know. I don't really have the time at the moment to explore the possibilities as am too busy building signals and 3d track (not necessarily printed).

 

[Martin Wynne]

I might just have a copy of Delphi5 as they were very fond on putting them on PC magazine cover CDs at one time.

Just to clarify that my copy of Delphi5 is a purchased Professional Edition licensed for commercial use.

Martin.

 

[Steve_Cornford]

Hi Martin,
One does not need to be a company to enter into an escrow agreement.
Rather than the "open-source" files I was thinking of the Delphi 5 files.

I'm getting uneasy that folks will soon be relying on Templot plug track for their real-world projects, rather than just experimental tinkering, and hence relying on me alone. It's a lonely place to be.

Perhaps an arrangement could be made between yourself and one or more of the societies that promote track building.

But if there is any way any of us can help to reduce the burden, just ask.

Steve

 

[nickom]

Hi Martin,

Having just restarted using templot, I have been taking a look at the code you have made open-source a few years ago. Browsing around and tracing via the debugger to try and get a handle on the program flow reveals a very impressive codebase. I cannot say I understand any of it at the moment, but I'm intrigued how you used the available tools over the years to produce a blazingly fast piece of software.

My understanding so far is:

• The UI is drawn by building a bitmap. I don't know this for sure, but my thinking is that if the.Box file is logically held in binary format, it makes sense to draw that directly rather than using Canvas or similar. Is this correct?
• I have yet to find the unit that carries out this bit manipulation , so I'm probably wrong.

From a software architecture point of view, what techniques did you use to squeeze out every last ounce of processing cycles on very constrained hardware.

Apologies if this seems impertinent; I would very much like to understand the inner workings of your code and who knows, if I learn enough, I may be able to contribute in the longer term.

Thanks
Nick

 

[Martin Wynne]

Hi Martin,

Having just restarted using templot, I have been taking a look at the code you have made open-source a few years ago. Browsing around and tracing via the debugger to try and get a handle on the program flow reveals a very impressive codebase. I cannot say I understand any of it at the moment, but I'm intrigued how you used the available tools over the years to produce a blazingly fast piece of software.

My understanding so far is:

• The UI is drawn by building a bitmap. I don't know this for sure, but my thinking is that if the.Box file is logically held in binary format, it makes sense to draw that directly rather than using Canvas or similar. Is this correct?
• I have yet to find the unit that carries out this bit manipulation , so I'm probably wrong.

From a software architecture point of view, what techniques did you use to squeeze out every last ounce of processing cycles on very constrained hardware.

Apologies if this seems impertinent; I would very much like to understand the inner workings of your code and who knows, if I learn enough, I may be able to contribute in the longer term.

Thanks
Nick

@nickom

Hi Nick,

Welcome to Templot Club.

Many thanks for your kind words. And not impertinent at all -- Templot coding is my hobby and I'm happy to share it with anyone interested.

But I'm a retired oily-fingered toolmaker (no relation to Keir Starmer ). I'm not a software professional and have never had any formal training in the subject, so I often find it difficult to understand questions from professionals. Usually such professionals ask me why Templot doesn't follow some accepted software standard or other. But since I don't know what those standards are, and definitely didn't know anything about such things 25+ years ago when most of the core code in Templot was written, it's not surprising that the code doesn't follow any expected norms.

In all that time you are the first I can recall writing in such positive terms about my code -- it is news to me that I have produced a "blazingly fast piece of software", or that I have "squeezed out every last ounce of processing cycles on very constrained hardware". So thank you for that, but I'm not too sure how I did it.

I'm still using the Delphi5 compiler from 1998, which probably means that the executable doesn't contain much of the later Windows bells and whistles, but one constant mystery to me has been why the Templot executable file is so much smaller (8MB) than any comparable software. But my guiding principle is always "if it ain't broke don't fix it", so I'm happy to leave it at that.

Yes the BOX file is in binary format, but I'm not sure that is relevant to the user interface. The contents are copied into memory and used to draw a background bitmap, containing the grid and the background templates . This is copied to the screen bitmap and then the control template is drawn over it. To update the screen bitmap as the control template is modified, the background bitmap is re-copied to the screen bitmap without needing to be re-created, and the new control template is drawn over it.

Yes, drawing on the bitmaps is mostly done using the Delphi TCanvas control, although I'm not sure that's what you mean by Canvas?

As to where all this is done, have a look in grid_unit.pas :

  procedure draw_background_templates(canv:TCanvas; group_code:integer; highlight_index:integer; highlight_on:boolean; highlight_colour:TColor);  //  all the background templates.

  procedure do_background(mode:integer);                  //  draw the complete background.
  procedure copy_draw_to_pad;                             //  copy the draw-bitmap to the pad.
  procedure wipe_draw_bmp(add_sketchboard_items:boolean); //  wipe the draw-bitmap.
  procedure wipe_pad;                                     //  wipe the actual pad form.

  procedure draw_bg_shapes(canv:TCanvas;index,colour:integer);        // draw any background shapes.
  procedure draw_notch(canv:TCanvas);                                 // draw the pegging notch. (might get redrawn by the control template).
  procedure draw_rings(canv:TCanvas; copies,dummy_vehicle:boolean);   //206b  draw the spacing-ring or copies.

  procedure draw_dummy_vehicle_copies(on_canvas:TCanvas);    // 0.98.a



  procedure copy_drop_to_canvas(canv:TCanvas);forward;  // copy the drop-bitmap to the specified canvas.
  procedure wipe_fill_drop;forward;                     // draw as much as will remain fixed on the backdrop.
  procedure draw_all_on_canvas(canv:TCanvas);forward;   // normal draw, use the specified canvas for everything.
  procedure finish_on_canvas(canv:TCanvas);forward;     // draw any items not on the backdrop on the specified canvas.

Much of the actual drawing work for the control template is done in math_unit.pas, see for example:

function show_a_line(on_canvas:TCanvas; aq, pen_width:integer; erasing:boolean):boolean;     //  draw a rail-line on the screen.

Many of the .pas files have grown over the years to become unwieldy, and would ideally be broken down into more manageable chunks with more meaningful names. But that's a lot of work which doesn't advance the functionality one inch, which means it looks to me more like work than hobby, and gets left as it is.

The above applies to the original files as uploaded by me in 2018/2019. I think Graeme and Alistair may have re-arranged some of it, but making sense of the Github stuff is beyond me.

Ask me again if you need more. All the code you can see is now over 5 years old. Templot today has moved on a long way, not least with the 3D exports for 3D printing. I'm intending to upload the current version of everything soon, but preparing all the files for open-source is a lot of work.

p.s. see also this recent topic:

https://85a.uk/templot/club/index.php?threads/open-source-again.839/

cheers,

Martin.

 

[NoIdea]

I thought I'd report in on progress after a few months of effort, bearing in mind my first (and so far, only) requirement is to ensure Martin is not disturbed.

In order to study (and attempt to build) Templot I have installed Lazarus v3.2, Delphi 11 Community Edition and Pascal and Omni Pascal extensions to Visual Studio Code.

So far, my biggest issues is the lack of time I've been able to devote to this, along with my complete ignorance of Pascal, the application itself and additional 'stuff' needed to compile the application.

First, Lazarus. The build instructions for v2.0.10 don't translate to v3.2 - HTMLViewer is missing, for example.

Delphi 11's IDE is much easier to use, albeit throwing errors with //{$MODE Delphi} directives, amongst other things.

VS Code extensions help reveal other issues as it validates syntax without the need to compile the code.

Here are two examples:

shove_timber.pas line 188 contains a string const that is truncated, missing the terminating semi-colon
I cannot find a definition for LCLType. I assume it's defined in one of the other packages.

Martin, sorry to bother you, but I'd appreciate your thoughts on my continuing to work on what is a six-year old codebase, and discuss options, whether through this forum and/or on a zoom call.

 

[Martin Wynne]

@NoIdea @nickom

Hi Martin,

Thanks for continuing to look at this. Don't worry too much about disturbing me, I'm not always bad-tempered.

LCLType appears to be a Lazarus unit, which isn't any part of Templot or Delphi. I don't have any memory of adding it to the interface uses sections, but I obviously did so to get it running in Lazarus. But I have found this comment:

{Important: Be sure to list LclType after SysUtils and Classes in order to use LclType's THandle declaration (32 or 64 bits)
rather than THandle in SysUtils and Classes (=System.THandle, which apparently is always 32 bits).}

I've looked at shove_timber.pas in the original upload (attached below).

At line 182, the terminating semi-colon is on line 323:

const
    shovetimb_help_str:string='green_panel_begintree.gif These help notes are longer than most -- you may prefer to print them out. Click the `0PRINT`1 button above.green_panel_end'

  +'|      `0Shoving  Timbers  and  Sleepers`9'

  +'||Templot0 normally draws templates with the timbers of the correct sizes and in positions based on full-size railway practice, or in accordance with your size and spacing settings.'
  +'||The SHOVE functions permit you to change the position, alignment and size of individual timbers and sleepers within the control template, or to omit them from the template.'

  +'||"Timbers" are normally used for pointwork (switches, crossings and turnouts). The standard timber size for British standard-gauge railways is 12 inches wide by 6 inches thick. In Templot0 their numbers are prefixed S, T or X.'
  +'||"Sleepers" are normally used for plain track. The standard sleeper size for British standard-gauge railways is 10 inches wide by 5 inches thick. In Templot0 their numbers are prefixed A, B, E, J, N or R.'
  +'||The length of timbers varies as required to support the rails. Sleepers are normally of a standard fixed length,'
  +' typically 9ft in the pre-grouping era and 8ft 6ins later. Sleepers can be shortened, but it is not usual for them to be longer than this; a timber would be used instead.'
  +' For more information, see the help notes for the REAL > TIMBERING > TIMBERING DATA... menu item.'

  +'||You can shove or omit as many sleepers and timbers as you wish, or add additional "bonus timbers" to a template.'
  +'||Some of the reasons you might want to do this are these:'
  +'||Timbers may be shoved along the track to increase the space for point-rodding runs, etc.'
  +'||Timbers may be shoved along and/or twisted slightly to avoid conflicts where tracks come together in crossovers, junctions, etc.'
  +'||A minimum timber spacing of 2ft (centre-to-centre) is needed for rail joints and fishplates.'
  +'||Lengthened timbers can be used to support hand point-lever boxes, ground signals and detection devices, etc.'
  +'||Wider than standard timbers are sometimes used when this is necessary to accommodate chairs or baseplates which are offset or set at an angle.'
  +'||In the pre-grouping era, some railways used 12 inch wide timbers in place of standard sleepers adjacent to the rail joints in plain track.'


... lines removed to fit forum post size limit ...


  +'||Using the mouse actions for shoving will also enable the FULL MOUSE DRAW screen refresh option so that you can see the timbers being shoved.'
  +' You may want to revert to the skeleton draw option when you have finished shoving timbers. To do this select the ACTION > MOUSE ACTION OPTIONS > SKELETON MOUSE DRAW menu item or SHIFT+CTRL-F12, or just press the ; (semi-colon) key.'

  +'||Bonus timbers are not affected by any blanking of turnout templates and unlike ordinary timbers they can be shoved into the blanked area.'
  +'||Bonus timbers and plain track sleepers can be shoved out beyond the CTRL-0 template datum end position if necessary.'
  +'||To shove an ordinary turnout timber out beyond the CTRL-0 datum end of a turnout template, it is first necessary to apply sufficient negative blanking to accommodate the shove.'
  +' This can be done by moving the fixing peg out as far as needed (CTRL-F8 mouse action), and then clicking the DO > BLANK UP TO PEG menu item.';

Martin, sorry to bother you, but I'd appreciate your thoughts on my continuing to work on what is a six-year old codebase, and discuss options, whether through this forum and/or on a zoom call.

I'm happy to discuss this here, you are not bothering me. But I'm wondering if it might be better to wait until I have released the current code as open-source, which I intend to do shortly. Rather than looking at the old code which includes modifications for Lazarus as it then was, and may no longer apply.

I know the HTMLViewer package is a thorny issue, I remember battling with it back then. The problem is that I originally obtained it from David Baldwin before he made it open-source, and before it was integrated natively into both Delphi and Lazarus. Which means the Templot integration still works fine, but doesn't necessarily translate into current Lazarus or Delphi11.

If you are trying to get Templot to run in Delphi11, a significant problem is that its default strings are 16-bit unicode. Templot has strings of 8-bit ASCII, which in places are treated as byte arrays. Lazarus defaults to compatible 8-bit unicode, so that works ok.

cheers,

Martin.

 

[NoIdea]

But I'm wondering if it might be better to wait until I have released the current code as open-source, which I intend to do shortly.

Aha! That makes sense. Will the open-source version still require external closed-source dependencies due to licensing issues?

 

[Martin Wynne]

Aha! That makes sense. Will the open-source version still require external closed-source dependencies due to licensing issues?

@NoIdea

Hi Martin,

I'm not too clear what "external closed-source dependencies" are, but before releasing the files I shall simply remove the 3rd party stuff which I'm not free to publish, and replace it with comments. I'm in two minds about releasing the sketchboard stuff. I will try to get in touch with Nils and see what his current situation is.

This time I'm not intending to release a working version which will compile and run in Lazarus, it is too much work. I shall simply post the existing Delphi5 files as-is. Just doing that is a lot of work -- 160 files requiring tidying up and updated copyright notices.

cheers,

Martin.

 

[NoIdea]

Hi Martin,

The 'third-party stuff' is what I meant by external dependencies.

This time I'm not intending to release a working version which will compile and run in Lazarus

I understand. I look forward to the release...

 

[nickom]

Thanks Martin,

I'm not certain that the version I'm working on is the original you 1st posted, I would prefer to work on your master version considering that all future versions you may release will roll back all the changes made by Graham and Alistair anyway.

Its going to take me a long time to get my head around this, but its very interesting.

I've downloaded the Delphi community edition, do you think this would be compatible with future versions you may release to the opensource community. It has a 1 year timer bearing down on me which is a bit annoying but if it works it could be a better option as it would save you the hassle of converting from Delphi to Lazarus each time you released a version.

Regards
Nick

 

[Martin Wynne]

Thanks Martin,

I'm not certain that the version I'm working on is the original you 1st posted, I would prefer to work on your master version considering that all future versions you may release will roll back all the changes made by Graham and Alistair anyway.

Its going to take me a long time to get my head around this, but its very interesting.

I've downloaded the Delphi community edition, do you think this would be compatible with future versions you may release to the opensource community. It has a 1 year timer bearing down on me which is a bit annoying but if it works it could be a better option as it would save you the hassle of converting from Delphi to Lazarus each time you released a version.

Regards
Nick

@nickom

Hi Nick,

If you are trying to get Templot to run in the Delphi Community Edition, a significant problem is that modern Delphi defaults strings to 16-bit unicode. At least, I think it still does that. Templot has strings of 8-bit ASCII, which in places are treated as byte arrays, which will fail. Lazarus defaults to compatible 8-bit unicode, so that works ok.

There might be compiler directives to treat the default string type as 8-bit, but I'm not sure.

If using the Delphi Community Edition bear in mind that Embarcadero can be quite aggressive in protecting the licence terms -- I had a stroppy email all but accusing me of using it commercially, even though I had done no more with it than download it and have a look at it. So I deleted it and haven't looked at it since. If you make any code that you wish to keep, bear in mind that there is no guarantee that they will renew the licence after 12 months.

I'm going to merge this topic shortly with the other one which has come alive today:

https://85a.uk/templot/club/index.php?threads/open-source-again.839/

as both you and Martin are covering mostly the same ground.

Attached below is the old code as I last released it. At that time I ensured that it could be compiled and run in Lazarus, following the instructions in the old links. But Lazarus has been upgraded since then, so I'm not sure of the present situation. Going forward I shall be releasing the Delphi5 code exactly as-is -- I'm too old and tired now to repeat all the work of creating two versions, and I need to spend my time on the unfinished 3D chairing stuff.

cheers,

Martin.

 

[nickom]

Hi Martin, @NoIdea All

What is the view on taking this forward? What do we want to achieve out of this?
My tuppence worth is:

1. Find ways to ease the support burden Martin is constantly under.
2. Out of respect to Martin, both technical and frankly just respect for the huge effort put into this over decades
   1. We need to preserve the original technical and UI workings of Templot, I assume a fairly large group of users rely on it?
   2. This will aid in merging future features into the open-source version.
3. In the longer term, find a way to retain the above but make it accessible to people who are more used to Windows UI's, although I think this is a shrinking group of people since the emergence of icon-based apps on tablets and phones.
   1. Do we need to even consider this? Should we stick with what works and has worked perfectly well for decades?
4. Slowly introduce modern coding techniques where they are deemed necessary to aid in the wider developer-volunteer community
5. To keep this free, we need to consider the toolchain.
   1. Lazarus with free Pascal is an obvious IDE, but it is an obstacle to introducing new features from the primary codebase.
   2. Delphi would is a good option (assuming the 8-bit ASCII to 16-bit unicode hurdle can be handled, plus other incompatibilities)
      1. it is prohibitively expensive; this will only hinder the wider involvement of volunteers
   3. Very slowly, port over to another language.
      1. I am not sure if this is possible, and I will still have difficulties converting from Delphi 5 to whatever; I guess, eventually, we will be merging new features and upgrades, so the effort could reduce.

I have no idea how we do this at this stage, but I'm willing to have a go.

Martin, As the Chief Architect and, of course, owner of Templot, what / how would you like to see it progress?

 

[Martin Wynne]

Hi Martin, @NoIdea All

What is the view on taking this forward? What do we want to achieve out of this?
My tuppence worth is:

1. Find ways to ease the support burden Martin is constantly under.
2. Out of respect to Martin, both technical and frankly just respect for the huge effort put into this over decades
   1. We need to preserve the original technical and UI workings of Templot, I assume a fairly large group of users rely on it?
   2. This will aid in merging future features into the open-source version.
3. In the longer term, find a way to retain the above but make it accessible to people who are more used to Windows UI's, although I think this is a shrinking group of people since the emergence of icon-based apps on tablets and phones.
   1. Do we need to even consider this? Should we stick with what works and has worked perfectly well for decades?
4. Slowly introduce modern coding techniques where they are deemed necessary to aid in the wider developer-volunteer community
5. To keep this free, we need to consider the toolchain.
   1. Lazarus with free Pascal is an obvious IDE, but it is an obstacle to introducing new features from the primary codebase.
   2. Delphi would is a good option (assuming the 8-bit ASCII to 16-bit unicode hurdle can be handled, plus other incompatibilities)
      1. it is prohibitively expensive; this will only hinder the wider involvement of volunteers
   3. Very slowly, port over to another language.
      1. I am not sure if this is possible, and I will still have difficulties converting from Delphi 5 to whatever; I guess, eventually, we will be merging new features and upgrades, so the effort could reduce.

I have no idea how we do this at this stage, but I'm willing to have a go.

Martin, As the Chief Architect and, of course, owner of Templot, what / how would you like to see it progress?

@nickom @NoIdea @James Walters

Hi Nick,

Thanks for that. I like the idea of being called Chief Architect. But it suggests there is some grand design here, which is definitely not the case. Chief Cobbler-together would be nearer the mark!

My main concerns are:

1. Many folks are relying on Templot, sometimes for lifetime projects. I would like to know that it will continue to be available (and preferably developed further) if anything happens to me. I don't just mean the dreaded bus -- recently I fell and smashed my shoulder badly, I could easily have hit my head at the same time. The grey cells are dying off fast enough, without having chunks knocked out of them.

2. There is still a long way to go with Templot2. The 3D plug track looks like becoming a popular feature but there is still much to do, and folks are waiting for the next steps. Some help with it would be very welcome, and has been kindly offered. But an STL file for a chair isn't much help without some lines of code showing how I would integrate it into Templot, and modify it when required to match changing crossing angles and flangeway gaps, etc. It needs chair creation code written similarly to the existing chairs, and it's going to be a long time coming if I have to do it all myself.

For a long time I assumed that eventually a young software engineer would turn up -- preferably an experienced Templot user with a good knowledge of railway track -- and create a complete replacement for Templot starting with a blank sheet of paper and doing everything properly from the start. I could then put my feet up after 45 years of Templot. But I've been told several times that it just isn't going to happen.

Meanwhile we plod on, using a program tied together with string, still using some code and methodology which started life on a programmable calculator in 1979.

3. I still enjoy writing code, even though I'm much slower now than I used to be. But the task of endlessly explaining it does become exhausting and ever more time-consuming. More than once recently I have left out function options which might occasionally be useful, because I just can't face the task of explaining them.

---

How all that feeds in to your thoughts for the open source version is far from clear. At first sight an obvious move would be to switch the entire thing, including Templot2, from Delphi5 to Lazarus.

But there are problems:

Several of the 3rd party components were written for Delphi and are unlikely to work in Lazarus. I know Graeme was trying to find open-source replacements, but I don't think he got very far.

The Windows EMF metafile format is integral to much of Templot, especially the sketchboard, and Lazarus doesn't include the relevant Delphi-style wrappers for the Windows API. I managed to get it working in Lazarus by calling the API functions directly, but whether that still works in the latest versions I'm not sure. I know there is nothing comparable on the Apple platform, so it's likely to fall by the wayside on most other platforms in favour of the SVG format.

The BOX file format is a binary format, and most floats in Templot use the Win-32 Extended 10-byte floating-point format. This isn't supported in Lazarus (or Win-64), which means hundreds of users' legacy BOX files would become unusable. Graeme was working on a conversion utility, and for a while Templot2 included an XML-based alternative file-saving format. But maintaining it was too much work, users found it confusing, and I just couldn't face continually explaining it.

For now I think we should update the name to say OpenTemplot2024 to make a fresh start after all the previous ins and outs. I will make a start on posting the current Delphi5 files in the next few days.

Thanks again,

Martin.

 

[NoIdea]

@nickom - My observations on your tuppence worth

"My first (and so far, only) requirement is to ensure Martin is not disturbed." This (hopefully) allows Martin to concentrate on the coding.

"Find ways to ease the support burden Martin is constantly under." - This is the next requirement, in my view. This doesn't need coding skills and Martin doesn't need to reply to every question. Can we find volunteers with a greater knowledge of Tempot help with answering questions, documentation, videos etc. This is moving toward a true open source project.

As an aside, I've relinquished code I wrote decades ago as open source and I was uncomfortable about relinquishing control. I expect Martin would experience the same uneasiness.

And then there's the source code...

I'm reluctant to spend any time with the Delpi Community Edition. There's a nag screen every time you compile, a warning about how long your licence has left, and a ridiculous price for a developer edition.

"Very slowly, port over to another language" - Yes. "I am not sure if this is possible" - Yes.

A very long term goal, obviously, but would handle the problem of a very, very small number of Pascal developers who are railway modellers and are using or interested in Templot.

So, what about this:

This is what I've been working on for the last few months.

From an 'architecture' point of view I see three very big 'bits': The UI including the track pad, the domain itself, and Input / Output such as saving / loading box files and printing.

@Martin - Just do 2. and the first bit of 3. Again, can others help with the rest of 3.?

Regards,

Martin

 

[Martin Wynne]

@NoIdea

Hi Martin,

Thanks for that. But can you explain what I'm looking at in your screenshot? What language is that? What is the .ts file format? Where are the javascript files coming from?

Sorry if I'm being dim, but it means little to me.

Are you suggesting re-writing the whole of Templot in that format? I've just run the compiler and it says:

Total lines: 430,980

I don't know exactly what it counts as a line, but I do know that getting on for half a million is a lot!

cheers,

Martin.

 

[NoIdea]

Are you suggesting re-writing the whole of Templot in that format?

Yes. But not by hand. The screenshot is the output of my Templot converter which converts Pascal (pas) into Type Script (ts). The number of lines doesn't matter. The converter spits out the ts files in seconds. This satisfies my 'do not disturb Martin' requirement .

The screen shot is Visual Studio Code editor with control_room.ts - a Type Script version of control_room.pas.

The import statements refer to Type Script versions of other classes not found in Templot - those I do have to write by hand.

In the (distant) future the plan was to host these files in an Electron app, which I've used to build apps in the past.

I hope that helps. I'm happy to go into more detail if you guys are interested.

 

[Martin Wynne]

Yes. But not by hand. The screenshot is the output of my Templot converter which converts Pascal (pas) into Type Script (ts). The number of lines doesn't matter. The converter spits out the ts files in seconds. This satisfies my 'do not disturb Martin' requirement .

The screen shot is Visual Studio Code editor with control_room.ts - a Type Script version of control_room.pas.

The import statements refer to Type Script versions of other classes not found in Templot - those I do have to write by hand.

In the (distant) future the plan was to host these files in an Electron app, which I've used to build apps in the past.

I hope that helps. I'm happy to go into more detail if you guys are interested.

@NoIdea

Hi Martin,

Wow. That sounds great. Presumably it runs in a browser? So it would work fine on Apple mac computers?

Would it be able to read existing binary BOX files? How does your converter deal with the Delphi DFM files?

Are you able to post a link to one of your apps and post a bit of the code? This is all new to me. I can see there is a lot to learn, but we could be glimpsing the future of Templot. I do like the words "automatic converter"!

cheers,

Martin.

 

[NoIdea]

Here's the home page:

More details to follow...

 

[Martin Wynne]

For now I think we should update the name to say OpenTemplot2024 to make a fresh start after all the previous ins and outs. I will make a start on posting the current Delphi5 files in the next few days.

@nickom @NoIdea

The first of these files are now at:

https://85a.uk/templot/club/index.php?threads/opentemplot2024-files-ex-delphi5.926/

I have set the version number for the first version of OpenTemplot2024 at 555a .This leaves plenty of future space for Templot2, which is currently on 244d.

Martin.

 

[Steve_Cornford]

This looks promising.
Learnt a new word today.....
"Transpile"
courtesy of Wikipedia.

But can it handle 8 sided objects?


Steve

 

[Martin Wynne]

This looks promising.
Learnt a new word today.....
"Transpile"
courtesy of Wikipedia.

But can it handle 8 sided objects?


Steve

@Steve_Cornford

New to me too, but Google is our friend:

https://crystallize.com/answers/tech-dev/compiling-vs-transpiling



Martin.

 

[NoIdea]

The converter consists of three bits: A single lexer that tokenises each pascal file, a single parser that converts the stream of tokens into an in-memory representation of the file, and an emitter to output a file in the required syntax - in this case type script. Other emitters could be produced to produce Rust, C++, Go, Dart or C# versions, for example.

Each emitter has to deal with the broad and specific differences between pascal and the language in question. pascal uses 'uses'; C# uses 'using', C++ uses '#include' and for type script it's 'import'. There are so many other considerations, too many to list here and I'm not sure I've found them all yet.

And that's only part of the story. On the other side of each emitter additional code is required to implement the missing classes such as TObject, TForm or TListBox, for example, as well as metadata to describe attributes such as properties and methods for the emitter to render the correct syntax.

There's also the app that I need to build. I need to refresh my memory with Electron as it has gone through a few updates since I last used it. I'm many, many months away from this yet.

Presumably it runs in a browser?

Yes. It will do.

So it would work fine on Apple mac computers?

In Electron, yes - or any linux distribution. A C# version could be used to output a MAUI multi-platform app, or a Uno multi-platform app. A Dart version could be used to build a Flutter app. On a desktop, Android and iOS tablet and mobile is all possible...

How does your converter deal with the Delphi DFM files?

They, like LFM files, are text files so I just need to write a parser for them.

Would it be able to read existing binary BOX files?

Yes. And write as well. This is easier in some languages such as C#. I *think* this is going to be quite a challenge in type script / java script. If there was one thing I would wish for it would be a text representation in BOX files, whether that's XML or JSON or some other simple format.

That's all for now. Fire away if you have any further questions...

Martin

 

[nickom]

Hi All,

I just asked chatgpt a question about templot. it produced the following:

Yes, I know about Templot. Templot is a specialized software application used primarily for designing model railway track plans. Developed by Martin Wynne, it is particularly popular among enthusiasts of model railways for its precision and flexibility in creating custom track layouts. Templot allows users to create highly detailed and accurate templates for trackwork, including turnouts (points), crossings, and curved track sections. These templates can be printed out and used as guides for constructing the physical track.
Key features of Templot include:

1. Precision Design Tools: Templot provides tools to design tracks with precise geometry, accommodating various scales and gauges used in model railroading.
2. Custom Track Templates: Users can create and modify templates for different types of track elements, ensuring that the track plan fits the specific requirements of their layout.
3. 3D Visualization: While primarily a 2D design tool, Templot also includes some 3D visualization capabilities to help users understand how their track plan will look in the real world.
4. Support for Various Standards: It supports a wide range of track standards and scales, making it versatile for different model railway communities.

Templot is well-regarded in the model railway community for its detailed approach to track design, which is critical for creating realistic and operationally reliable model railways. It has a steep learning curve, but its powerful features make it a valuable tool for serious model railway hobbyists and professionals.



how is the box file structured

In Templot, the "box file" (with the .box file extension) is the primary file format used to save track plans and templates. The structure of a box file is quite specific and contains all the necessary information to recreate the track layout designed in Templot. While the full technical details of the box file format are typically not publicly documented in great detail, an overview of its structure can be described as follows:

Basic Structure of a Box File​

1. Header Information: The file begins with header information that includes metadata about the file, such as the version of Templot used to create the file and general settings applicable to the entire track plan.
2. Template Data: Each track component or template in the track plan is stored in a structured format. This includes detailed geometric data about each piece of track, such as:
   • Track type (e.g., straight, curve, turnout)
   • Geometric parameters (e.g., lengths, radii, angles)
   • Position and orientation in the layout
   • Rail and sleeper (tie) specifications
   • Custom user settings and adjustments
3. Layer Information: Templot allows users to organize their templates into layers. Information about which templates belong to which layers, and the visibility settings for these layers, is included.
4. Background Shapes and Images: If the user has added any background shapes (like roads, buildings) or imported images to help with the layout design, details of these are stored in the box file.
5. Settings and Preferences: The box file can also store user-specific settings and preferences, such as display options, grid settings, and measurement units.
6. Additional Elements: Other elements such as notes, dimensions, and markers added by the user for reference or construction purposes may also be included in the file.

Example Overview​

While an actual .box file is in a binary format and not human-readable, conceptually, it can be broken down into sections like this (simplified for illustration):

Header:
- File version: 2.23.b
- Creator: Templot user
- Date created: 2024-05-25

Template 1:
- Type: Straight track
- Length: 200mm
- Position: (x1, y1)
- Rail type: Code 75

Template 2:
- Type: Turnout
- Angle: 1:6
- Radius: 900mm
- Position: (x2, y2)
- Rail type: Code 100

Layer Info:
- Layer 1: Visible
- Layer 2: Hidden

Background Shape:
- Shape type: Rectangle
- Dimensions: (width, height)
- Position: (x3, y3)

User Settings:
- Grid spacing: 10mm
- Measurement units: mm
- Display options: High contrast

Practical Usage​

In practice, users do not typically need to understand the internal structure of a box file unless they are doing advanced customizations or troubleshooting. The Templot software provides all necessary tools to create, modify, and save track plans without needing to manually edit the file. However, for those interested in the internal workings or developing complementary tools, a deeper dive into the binary format and specifics of the data structure would be required, often involving consulting with the Templot community or the software’s developer for more detailed technical documentation.


how does the track component get drawn on the ui

In Templot, the process of drawing track components on the user interface (UI) involves several steps, from user input to rendering on the screen. The software handles complex geometric calculations to ensure accuracy and flexibility in track design. Here’s an overview of how this process typically works:

1. User Input​

• Selection and Parameters: The user selects a track component to draw (e.g., straight track, curve, turnout) and specifies the necessary parameters (length, radius, angle, etc.).
• Positioning: The user places the track component at the desired location on the layout, either by clicking on the canvas or entering coordinates.

2. Geometric Calculations​

• Template Generation: Based on the user’s input, Templot generates a mathematical template for the track component. This includes calculating the precise geometric shapes and dimensions.
• Transformation: If the track needs to be rotated, mirrored, or otherwise transformed, Templot applies the necessary geometric transformations to position the track correctly.

3. Data Storage​

• Template Data Structure: The generated template data is stored in an internal data structure, which includes all the geometric details and parameters of the track component.
• Box File Update: If the user saves the layout, this data is serialized into the .box file format.

4. Rendering on the UI​

• Graphics Engine: Templot uses its graphics engine to render the track components on the UI. This involves converting the geometric data into graphical representations.
• Drawing Primitives: The software uses drawing primitives such as lines, curves, and shapes to represent the rails, sleepers (ties), and other track elements.
• Layer Management: Track components are drawn on different layers, allowing for better organization and visibility control (e.g., showing or hiding certain layers).

​

 

[nickom]

Part 2

5. Interactive Features​

• Manipulation Tools: Users can interact with the track components using tools to move, rotate, adjust parameters, and align with other tracks. These interactions are processed in real-time, with immediate visual feedback.
• Snapping and Alignment: Templot provides snapping features to help align track components accurately with each other, ensuring proper connectivity and alignment.

Example Workflow​

1. Selecting a Track Component:
   • User selects a turnout from the toolbar.
   • Inputs angle and radius for the turnout.
2. Placing the Component:
   • User clicks on the canvas to place the turnout.
   • Templot calculates the exact position and orientation.
3. Rendering the Component:
   • Templot’s graphics engine renders the turnout using lines and curves.
   • The turnout is displayed on the canvas, showing rails, sleepers, and guide marks.
4. Adjusting and Refining:
   • User adjusts the turnout’s position by dragging.
   • The graphics engine updates the rendering in real-time.

Technical Considerations​

• Precision and Accuracy: Templot’s calculations are highly precise to ensure that track components fit together correctly, which is crucial for realistic model railway layouts.
• Performance: The graphics engine is optimized to handle complex layouts with many components without significant performance degradation.
• User Interface Design: Templot’s UI is designed to provide detailed visual feedback and intuitive controls, despite the complexity of the underlying calculations.

Summary​

Templot combines precise geometric calculations with an efficient graphics engine to render track components on the UI. It allows users to design detailed and accurate model railway layouts, providing interactive tools for placement, adjustment, and alignment. The result is a powerful and flexible design environment tailored for model railway enthusiasts.


can you give a sample of the code involved

This isn't templot Pascal specific , more an algorithm.

Certainly! Here’s a simplified example to illustrate how track components might be drawn in a hypothetical UI environment similar to Templot. This example will be in Python, using a common graphical library like Tkinter for the UI and basic geometry for the track component.
Note that actual Templot code is likely far more complex and specialized, but this example should give you a general idea of the concepts involved.

Simplified Example Code​

1. Setting Up the Environment​

First, we need to set up a basic Tkinter window where we can draw our track components.

import tkinter as tk
from math import cos, sin, radians

class TemplotApp:
def __init__(self, root):
self.root = root
self.root.title("Templot Simplified Example")
self.canvas = tk.Canvas(root, width=800, height=600, bg='white')
self.canvas.pack()

def draw_straight_track(self, x1, y1, length, angle):
angle_rad = radians(angle)
x2 = x1 + length * cos(angle_rad)
y2 = y1 + length * sin(angle_rad)
self.canvas.create_line(x1, y1, x2, y2, fill="black", width=2)
self.canvas.create_text((x1+x2)//2, (y1+y2)//2, text="Straight Track", anchor="center")

def draw_turnout(self, x1, y1, length, angle, turnout_angle):
angle_rad = radians(angle)
turnout_angle_rad = radians(turnout_angle)
x2 = x1 + length * cos(angle_rad)
y2 = y1 + length * sin(angle_rad)
x3 = x1 + length * cos(angle_rad + turnout_angle_rad)
y3 = y1 + length * sin(angle_rad + turnout_angle_rad)

# Main track line
self.canvas.create_line(x1, y1, x2, y2, fill="black", width=2)
# Turnout line
self.canvas.create_line(x1, y1, x3, y3, fill="red", width=2)
self.canvas.create_text((x1+x2)//2, (y1+y2)//2, text="Main", anchor="center")
self.canvas.create_text((x1+x3)//2, (y1+y3)//2, text="Turnout", anchor="center")

# Initialize the Tkinter application
root = tk.Tk()
app = TemplotApp(root)

# Draw sample track components
app.draw_straight_track(100, 300, 200, 0) # Straight track starting at (100, 300), length 200, angle 0 degrees
app.draw_turnout(400, 300, 150, 0, 15) # Turnout starting at (400, 300), length 150, angle 0 degrees, turnout angle 15 degrees

root.mainloop()

Explanation​

1. Initialization:
   • A Tkinter window is created with a canvas for drawing.
2. Draw Straight Track:
   • draw_straight_track method calculates the end coordinates based on the start point, length, and angle.
   • A line is drawn on the canvas representing the straight track.
3. Draw Turnout:
   • draw_turnout method calculates the end coordinates for both the main track and the turnout branch.
   • Two lines are drawn, one for the main track and one for the turnout branch.

Customization and Extension​

This example can be extended and customized to include:

• More detailed rendering (e.g., sleepers, rail details).
• Additional track components (e.g., curves, crossings).
• User interaction features (e.g., dragging, rotating components).

Note​

This is a highly simplified illustration. Templot's actual codebase would involve more sophisticated geometry handling, user input processing, and rendering optimizations. This example is designed to show the basic principles of drawing track components on a UI canvas.


--------------------------------------

Hi Martin, is this accurate?

Could we make a curated chatgpt specifically for Templot, training it on the past questions and answers Martin has provided from the forum, we could have a system to answer a good proportion of the questions by an AI system.

Regards
Nick

 

[nickom]

The converter consists of three bits: A single lexer that tokenises each pascal file, a single parser that converts the stream of tokens into an in-memory representation of the file, and an emitter to output a file in the required syntax - in this case type script. Other emitters could be produced to produce Rust, C++, Go, Dart or C# versions, for example.

Each emitter has to deal with the broad and specific differences between pascal and the language in question. pascal uses 'uses'; C# uses 'using', C++ uses '#include' and for type script it's 'import'. There are so many other considerations, too many to list here and I'm not sure I've found them all yet.

And that's only part of the story. On the other side of each emitter additional code is required to implement the missing classes such as TObject, TForm or TListBox, for example, as well as metadata to describe attributes such as properties and methods for the emitter to render the correct syntax.

There's also the app that I need to build. I need to refresh my memory with Electron as it has gone through a few updates since I last used it. I'm many, many months away from this yet.



Yes. It will do.



In Electron, yes - or any linux distribution. A C# version could be used to output a MAUI multi-platform app, or a Uno multi-platform app. A Dart version could be used to build a Flutter app. On a desktop, Android and iOS tablet and mobile is all possible...



They, like LFM files, are text files so I just need to write a parser for them.



Yes. And write as well. This is easier in some languages such as C#. I *think* this is going to be quite a challenge in type script / java script. If there was one thing I would wish for it would be a text representation in BOX files, whether that's XML or JSON or some other simple format.

That's all for now. Fire away if you have any further questions...

Martin

Hi @NoIdea

Is the converter and code available on git?

Thanks
nick

 

[Martin Wynne]

Hi Martin, is this accurate?

@nickom

Hi Nick,

In a word, NO.

The introductory bit was very kind, but the rest is complete rubbish. It has assumed that Templot is a pick-and-place program, similar to XTrackCad or AnyRail. Which of course it isn't. The description of the BOX file format is all wrong -- it doesn't contain the background shapes or the user preferences, for example.

This AI stuff seems very impressive until you actually know something about the subject, when invariably it turns out to be rubbish. Just a fancified web search engine making guesses and usually getting it wrong. And I've noticed that almost any computer program is now called AI -- if I wrote a simple timer utility for my boiled eggs, it would now be called AI.

cheers,

Martin.

 

[NoIdea]

Is the converter and code available on git?

Hi Nick,

No, not yet at least. I'd like to get to version 1 first. I've rewritten the parser three times already as I learned pascal.

Martin

 

[nickom]

@nickom

Hi Nick,

In a word, NO.

The introductory bit was very kind, but the rest is complete rubbish. It has assumed that Templot is a pick-and-place program, similar to XTrackCad or AnyRail. Which of course it isn't. The description of the BOX file format is all wrong -- it doesn't contain the background shapes or the user preferences, for example.

This AI stuff seems very impressive until you actually know something about the subject, when invariably it turns out to be rubbish. Just a fancified web search engine making guesses and usually getting it wrong. And I've noticed that almost any computer program is now called AI -- if I wrote a simple timer utility for my boiled eggs, it would now be called AI.

cheers,

Martin

 

[nickom]

That's a shame; we need to clone you to help with user support. Automation could help with this when volunteer support ebbs and flows.