Family Historian User Group

In the discussion on A simple to do list I made the following comment. I have since been told that it is probably more appropriate to pursue this in the plugin forum

arthurk wrote:After reading David's post it occurred to me that there's already something that could integrate with UK's Kalender: Jane's plug-in Create Individual Shortcut, which creates a small .cmd file. After trying this out, I can confirm that it appears to work: linking a reminder to the .cmd file as either a document or a command will open FH at the relevant person.

Still struggling to get this working under Linux/Wine!

1. Is this a known problem (i.e. expecting too much of Wine) or have I missed something?

davidf wrote: However if you can create a Windows cmd file, I would have thought that you could create a hyperlink (to the clip-board) which does the same thing - and which would be platform independent. It would also save you from littering your hard-drive with lots of little cmd files!

(As a general point the ability to jump into FH with a specific record opened could be useful for more that just ToDos - you could for instance write documents for distribution with the Read-only version of FH which have links that take you to the actual data.)

2. Anyone know if this plugin can form the basis for such functionality (lua is not within my skill set). I note from the same thread:

tatewise wrote:On point of fact, Jane's Create Individual Shortcut Plugin exploits a hidden command line feature of FH.
It can open any Individual record via the Focus Window.
It can open any Individual or Family record via the Records Window that may be showing Named Lists.
No other record types or windows are supported currently.

If this restriction blocks this use, how do we phrase a possible wish-list request to make it possible to hyperlink shortcuts into any record?

Hyperlinks only work with Web servers so would not work for this. Any linking would, as now, rely on other programs allowing command files to be attached.

From a technical perspective it is important to get a clear distinction between command line and hyperlink.

The feature exploited by this Plugin involves running FH V6 from a Windows Command File (.cmd).
The Plugin also relies on os.getenv("UserProfile") and the Desktop folder.
Both the above mitigate against the Plugin and Command File working in Linux/Wine!
The FH command line format is such as follows (but not literally):
Run "C:\...\fh.exe" "C:\...\Project.ged" Window=FocusWin Record=I6
As I stated, the Window options and Record options are currently severely restricted.
BTW: Does anyone know where that format is fully documented?

A hyperlink usually relates to an Internet URL not a Windows program application.

So the underlying mechanism for invoking FH to open a particular Record in a particular Window needs detailed investigation, both from the perspective of what other applications can use, and what Calico Pie can implement that works in Windows, Linux/Wine, Crossover, etc.

The only options I have details for are the ones used by the plugin.

They were added for a 3rd Party Project I was working on for a Chart Printing company to fully automate the use of Family Historian to Create PDF charts and send them back to the submitting user for approval via a web site.

It was never intended as an end user tool, hence the fact it's not documented in the public help.

The ini file used for control of FH has the options detailed in the Plugin


fh [/INI:<inifile-name>] [<gedfile-name>]

Format of Startup Inifiles

[Startup]
Window=FocusWin [or RecordWin]
Record=<record-id>

<record-id> must be the record id of an Individual or Family record to show at startup, and must be prefixed with an 'I' for Individual records or an 'F' for family records. The 'Window' is the startup window.

@DavidF

Question: "1. Is this a known problem (i.e. expecting too much of Wine) or have I missed something?"

I'm not quite sure quite what the question is but the 'problem' would be in converting the Windows Command Line script into something that Linux/MacOS can understand if the intention is to operate at the OS level, which is nothing to do with the capabilities of WINE. Both OS's understand BASH Script but the Windows Command Line is totally meaningless to them.

There are other options to the direct use of BASH Scripts to launch programmes in WINE, i.e. most of the 'front-end' GUI apps have some method of creating Run Commands which do use Windows Command Line instructions, but these still require User intervention and, obviously, an understanding of the Windows Command Line instruction set to set them up. e.g. for Crossover:

Yes, that is exactly one of the problems.
Even in Crossover, certain Command Line features are not supported, and upset some Plugins unless workarounds are implemented. I know from bitter experience with my Backup and Restore FH Settings Plugin.

The other problem is that the Plugin saves the script in the Windows Desktop folder that probably does not exist in WINE, or if it does the OS commands used by the Plugin to obtains its path are not supported.

Mike,

For info. There is a Desktop Folder inside WinApps (see attachment from a Crossover Installation) and the shortcuts created there are useable and work if they are copied to the Mac Desktop.

The remaining problem still lies in how long it takes to navigate to the Folder, especially as the location is initially 'hidden' in a Default MacOS setup in the same way that a Default Windows installation hides system folders/files. Presumably a Linux setup would be similar.

Mervyn

Bit more checking and I've located a 2nd Desktop Folder see the image below. Jane's Plugin mentioned stores its output in this location but, not surprisingly, it is a 'pure' Windows Command so there is no way to run it. On my system it simply opens the file in whatever Text Editing App recognises the file type.

Hope that's of some passing interest, if of no actual help!

Mervyn

Finding the 'correct' Desktop folder is surprisingly difficult even in Windows.
If the user has chosen the OneDrive > Settings > Auro-save option then the Desktop path changes, and to get the 'correct' Desktop the Windows Registry must be interrogated.
The current Plugin Store version 1.0 does not cope with that scenario.

For Plugin authors who do not have MacOS/Linux/Crossover/WINE it is impossible to know what features are supported and what are not.

So creating say a BASH command script to replace a Windows Command script is fraught.
Even identifying a Crossover/WINE platform versus genuine Windows is almost impossible.
One key difference is the path to the \Calico Pie\Family Historian\ customisation settings folders.
Crossover/WINE uses C:\Users\Public\Application Data\.
Whereas Windows uses C:\ProgramData\.
So Plugins must check that path to behave differently depending the platform, and hope that feature never changes.

I'm using Wine under Linux (Lubuntu 18.04 LTS) but not Crossover. I'm managing reasonably well and beginning to see what I originally classified as limitations as differences (e.g. modality/focus of dialogues).

Re "Windows Desktop". On my installation, it seems to shortcut back to my Linux Desktop.

Jane wrote:Hyperlinks only work with Web servers so would not work for this.

In respect of Jane's comment about hyperlinks, I may be using the wrong phraseology but I am looking for the ability to create a link in a document (Todo list, WP document, etc) that lives within my system to another document (or place within my document) - where this latter document is a fH file and the specific place is a specific record.

So if I have a plain HTML document (sample.html) in the same directory as another file, then within that second file something like file://sample.html (suitably wrapped) will create a link within that second file which when clicked will take me to that first file (if necessary opening the appropriate application - in this case my default browser). file://sample.html#SectionOne will even take me to a specific place in that first file. It does not have to be an html file. Within a spreadsheet I can "create a hyperlink" to another spreadsheet or Word-processor document . With some applications, however, this can get tricky. The way I have my Thunderbird email client configured is that all emails within say the inbox live in a single file, so creating a link to a specific email looks impossible. Thunderbird however has an addin Thunderlink that enables you to do just that. So I wonder if the same concept might be used to create the guts of a means to populate the "create hyperlink" functionality within other applications, but for links to records within an fH project?

(Records in FH are identifiable so you can specify persistent links. Unfortunately I don't think you could easily specify a persistent link to a specific fact (say a residence fact), because if you then added an earlier (residence) fact your reference to (residence)[1] would get disturbed.)

David, what matters in the context of Plugins is how they can 'discover' that Desktop full file path and then save a text file there. The problem that Plugin authors face is that they cannot experiment on a Linux/WINE platform or a MacOS/Crossover platform without involving users such as yourself in the experiments. The only way forward is that a few such users work together, learn Plugin Lua script, and eventually post some plugins:code_snippets:index|> Plugin > Code Snippets that illustrate for example how to differentiate running on a Windows v Crossover v WINE platform, and how to 'discover' the Desktop file path on that platform.

Regarding 'hyperlinks', the examples you give are designed into the target application (HTML URL specification, LibreOffice product, Thunderbird Plugin). To achieve something similar with FH would require a design upgrade, but as you correctly say not all GEDCOM database components can be uniquely & permanently identified. Strictly speaking, not even records can be permanently identified by Record Id as that value can be changed.

tatewise wrote:David, what matters in the context of Plugins is how they can 'discover' that Desktop full file path and then save a text file there. The problem that Plugin authors face is that they cannot experiment on a Linux/WINE platform or a MacOS/Crossover platform without involving users such as yourself in the experiments. The only way forward is that a few such users work together, learn Plugin Lua script, and eventually post some plugins:code_snippets:index|> Plugin > Code Snippets that illustrate for example how to differentiate running on a Windows v Crossover v WINE platform, and how to 'discover' the Desktop file path on that platform.

Possibly we need a group of Linux users to be available to do specific testing - if only to be able to mark some plugins as "not suitable" or "not yet working" for Linux, so that users do not get frustrated from trying to get something to work.

(An option that the power lua plugin developers might want to look at is to run Linux (and Wine and FH) in a Virtual machine. That is what I did for a year before jumping from Windows to Linux 18mths or so ago. Virtual Box is a (free) Oracle Application which seem to run on almost anything (Windows, any Linux, Mac etc.) and allows you to very easily set up other operating systems running in a virtual computer on your system. So I have various versions of my current OS (Lubuntu) runnable in virtual computers as well the current versions of various other Linux Flavours - Debian, Ubuntu, Mint, etc.). Installing the main Freeware OSs (no licencing issues!) is remarkably easy. There is a (surprisingly low) performance overhead but on my old Pentium Windows 7 machine with 4GB of memory it ran satisfactorily.)

I accept that there is a problem in determining where locations are if you are writing to a file - but does that apply if you write to the clipboard (which is what I am envisaging?). I accept that is trying to avoid the problem rather than solving it - but ....

tatewise wrote:Regarding 'hyperlinks', the examples you give are designed into the target application (HTML URL specification, LibreOffice product, Thunderbird Plugin). To achieve something similar with FH would require a design upgrade, but as you correctly say not all GEDCOM database components can be uniquely & permanently identified. Strictly speaking, not even records can be permanently identified by Record Id as that value can be changed.

I did anticipate that this might be "the block" - although perhaps Thunderlink is an example of finding a way around the block.

Davidf wrote:If this restriction blocks this use, how do we phrase a possible wish-list request to make it possible to hyperlink shortcuts into any record?

Are we now at a position of saying this is now a potential wish list item rather than achieve-able via a plugin?

Previously I have (in the Commercial field) as an urgent kludge (to get round a development queue) managed to get round this sort of problem (in VBA) by "stuffing the keyboard buffer". Once FH has opened "{Alt-V}, {DOWN 3}, {RIGHT}, I" Gets you to the individual record pane. If the cursor started in the first input box (it does not! the focus is on the first record) {TAB 6} should then get you to the [Go To Record ID] Field. Put the required record number in the keyboard buffer, and you have got to a record. {Alt Enter} in the buffer then gets you to the properties window - which to me would be home and dry! (Worked for about 4 years between Excel and my then (major) employer's stock system! They then - eventually - got the Excel functionality built into the mainframe system).

The wishlist item might be program functionality rather than a specific feature. So instead of asking for a full "hyperlink a record to clipboard feature", we might ask for functionality which means we can copy a record ID to the clipboard via a right click; this can then be picked up by a plugin and used to format link text which would open the required FH file and then fire a keyboard macro; new functionality to permit keyboard macros might with a few changes then permit a less kludgy form of the above. (Keyboard Macros do have an issue should people do silly things with macros - certain features would need to be "Not keyboardable".)

There are some interesting ideas there.

If Plugin authors were keen enough, the virtual machine concept may be suitable for free products such as Linux and WINE, but probably not for MacOS and Crossover that cost money.

The plugins:code_snippets:clipboard_read_write|> Clipboard Read Write (code snippet) presumably would work on any platform.

Not sure how widely a "stuffing the keyboard buffer" method would be applicable.