Bob Tips -- Session 1

[@TiddlyTweeter]

Jed's Bob is great. Since it interacts with the OS environment I thought it worth making a few points that he's likely not to know about in usage. I only use Windows so my tips are limited. Here is a start ...

_CONSOLE SIZE_

On Windows I set the Properties for the console for Bob like this ...

The very wide width of the console makes Bob's messages more readable as they don't wrap ... for instance ...

 

You have tips too?

Josiah

[@TiddlyTweeter]

_NOTES ON WINDOWS PROGRAM LAUNCHING IN BOB_

Some time ago (the problem, here on) we found out that if you launch a command-line program--i.e. not a windows GUI program--in Bob it crashes Bob on completion. This is because on exit it sends a message to the OS saying "done".

The way round this is to use BATCH or CMD files. These are child processes that don't crash Bob. Those files can also be used to launch completely separate command processors if needed, rather than children.

A couple of things are worth noting ...

1 -- you can DIRECTLY launch a Windows GUI program from Bob easily without issue. But note when you close Bob that program will terminate too. Terminating the program does not terminate Bob, but terminating Bob will always terminate it IF it was launched directly via a command line. Depending on the use case this could be useful or not.

2 -- To avoid issues in (1), if you need to, you can launch BATCH or CMD files that can be set to create new command processors. You have to play a bit to work out if they persist when Bob closes. (I haven't quite worked out yet exactly when the "/K" [force new command processor] is actually needed or not, though that's the most robust option). FWIW, I am able to launch TiddlyDesktop instances, both singularly and in bulk from Bob that persist beyond the session without special options ...

Straight command-line processor commands via BATCH or CMD files also work well. Both correctly inherit command line options you can define via Bob. They also correctly inherit any environment variables that the mother command processor holds.

You have Bob tips?

I'd be interested (they don't have to be for Windows; actually I'm interested if the other platforms have the issues above too).

Josiah

[TonyM]

Josiah,

Thanks for sharing, I am keen to do this soon and are thankful for your guidance,

My Trivial tips are;

• Set bob  (and tiddlyServer) to a different port number like 8084 8085 8088 so that any other install that uses port 8080 automatically will not compeat
• Place {{$:/plugins/OokTech/Bob/Wiki Listing}} in your home tiddler for a quick directory to other bob wikis
• Using bob allows you to accidentally open the same wiki without problems, this allows you to open your additional wikis only when you need them, rather than checking if the are already open 
• Using Bob you can access another wiki via an iframe, at the bob address because dragging and dropping between wikis do not cause problems if the wiki is in another window/tab

I will share more once I build my Desktop automation tools

Regards

Tony

[@TiddlyTweeter]

Ciao TonyM

Good stuff. Useful for Bob users to be aware of ...

TonyM wrote:

• Set bob  ... to a different port number like 8084 8085 8088 so that any other install that uses port 8080 automatically will not compete

• Place {{$:/plugins/OokTech/Bob/Wiki Listing}} in your home tiddler for a quick directory to other bob wikis

• Using bob allows you to accidentally open the same wiki without problems, this allows you to open your additional wikis only when you need them, rather than checking if the are already open

I assume you mean here that Bob's "locking" mechanism prevents problems with two or more instances of the same wiki open? Such that if you editing a Tiddler in one instance the other instance(s) are locked for THAT Tiddler, but open for edit on others?

• Using Bob you can access another wiki via an iframe, at the bob address because dragging and dropping between wikis do not cause problems if the wiki is in another window/tab

Best wishes
Josiah

[TonyM]

That's how I understand it Josiah,

But it is also in comparison to a file based wiki, because they are not tiddler based and the last wiki wins.

I am yet to rigorously test it, but it seems to work well. I sometimes have to leave the wiki with "unsaved changes" even although they are all saved.

Regards
Tony

[@TiddlyTweeter]

TonyM wrote:

... I am yet to rigorously test it, but it seems to work well.

Agree. I haven't had any problems on working that way. One small issue is about ...

I sometimes have to leave the wiki with "unsaved changes" even although they are all saved.

.. exactly. Its saved actually, but the "talk between" the wikis on multi-instance isn't perfect on the "state-of-play". But the actual mechanism on save looks very robust. I have had no issues with it and lost nothing.

Josiah

[@TiddlyTweeter]

_RELATIVE PATHS AND BOB "SCRIPTS"_

"Scripts" in Bob provide the main gateway to the OS ... Defined under: 'Bob Settings > Manual Settings > "scripts"' in the MAIN wiki. These are usable from any Wiki run by Bob... For example ...


In a wiki you launch a "script" via...

<$action-websocketmessage $type=runScript name=xxxxx opt1=yy opt2=zz .... />

The "runScript" action is executed always in the directory where the Bob executable is (WBEI). This means that relative pathing to a program you are invoking is always reliably relative to WBEI.

NOTE: Something you need to notice is that the program invoked may run itself in WBEI. But it may NOT. It depends on the program. Some Windows programs will only execute in their home directories, not in WBEI.

What is the significance? It means if you are using relative addressing, if you pass parameters on "files to use" to the program the path to them needs to vary according to whether they run in WBEI or from their home directory.

If this is unclear please ask for examples. Its an example of interacting with the OS that can come into play when you start accessing the OS through Bob.

[@TiddlyTweeter]

_RELATIVE PATHS AND BOB's "buildHTMLWiki"_

Its simply worth noting that for ...

<$action-websocketmessage $type='buildHTMLWiki' outputFolder=<<sfTo>> outputName=<<sfName>> excludeList=<<getSetting excludeList>> />

... that the "outputFolder" is created through an address "Relative to the Wiki" being built, NOT relative to the executable that runs Bob.

[@TiddlyTweeter]

_RE-ENTRANT EASY USAGE OF BOB WIKIS_

Lets say you have five TW created in Bob ... But you only work with them in Firefox--even though your default browser is Chrome. Its easy to set up so Chrome won't get in the way ...

•  In FF you open all the Bob TW you want to use (manually).

• You set it (either via an add-on or just "Open last session on startup") so that when FF starts it goes auto to all those addresses. If you initiate Bob first, before the FF browser, its will work easily and load them. Done. Absolutely no need to open them one by one from Bob.
  

• Once you can see it works add this to Bob settings ...

• "suppressBrowser":"true"
  

This will stop Bob from trying to open in the default browser.

Ask if this is unclear.

Do you have Bob tips? Now or later. Welcome.

Josiah