• Posts 5
  • Member Since
  • Last Active
  • Birthday January 02,2017 (1 year)
  • Location: Boston
  • Occupation: Engineer
All Posts Topics Started
TB9 - Support for tables in the native Notes feature (#4504)

Use case:
Taking notes on a topic and want to store it as tabular data.

I run into this every time I use thebrain and it gets in the way for me.

I know that I can link out to a word doc, or excel, or a google doc (It looks like that is working now)
However, I like being able to take notes without having to open an external app or link for most things. The reason is it's just plain quicker, less clicks and less cumbersome.

I use other tools where the text editor has a WSIWYG option and it supports tables. JIRA comes to mind. The tickets are written in WIKI notation but it has a WSIWYG add on.

It's just that tables are what really differentiate a text file from a rich text file for me.


Maybe add a wiki engine in place of what is behind the scenes now? If you do that  I wouldn't even mind having to hand code the symbols in the WIKI markup language.

Google docs with embedded browser ? paste does not work (larger question is about inline editor) (#3109 and #3531)
Tables in the internal notes makes the notes simple and complete.
That's mostly how I'll ever use it for studying and tech notes.

Are you planning to support the google docs interactively?
Having the ability to edit google docs in-line would be really cool!
Google docs with embedded browser ? paste does not work (larger question is about inline editor) (#3109 and #3531)
Here is an example of why I care about tables for technical notes.
In this (real) example, I am studying openflow commands and concepts.
I've always used tables to break out the complexity of what I'm studying.
Notes without tables is like a new england winter without snow. [wink]+
Google docs with embedded browser ? paste does not work (larger question is about inline editor) (#3109 and #3531)
Hello all,

I did some searching and did not see this issue raised yet.


I use TheBrain as a technical notebook.
The built-in editor does not support tables which is really helpful when taking notes.
I tried using word (I have office 2010) but I can't edit documents inline.
I saw someone else on the boards is using the embedded browser for gmail so I gave it a shot with google docs.
I was able to log into my google apps account after pasting in a shared link to a notes document.
I am able to edit the document.

The Issue:

I can't cut/paste into the document that I'm editing.
I get the popup letting me know I need to install something and that's as far as I get.
A popup window comes up but there is no way to install extension. (see below)

(1) Is there going to be in-line table support in the built-in editor ? (If so then I don't care so much)
(2) If there is not going to be table support in the built-in editor, is there going to be built-in support for editing google docs inline?
(3)  If not 1 or 2, then (worst case) will there be support for editing word documents inline?

Thanks for any help on this.

The Brain:
Windows 7 X64

Capture.PNG Capture2.PNG 
Notes on putting theBrain9 on an encrypted mount point
I put these notes together over the past week or so and I want to post them here in case they help someone else.  I make no claims that this is the only or the best way to handle this, but it works for me.  

The environment:
() Windows 7 X64

The problem:
() I travel with my PC. It is possible that the PC may be stolen or forgotten on a plane, etc. If this occurs I do not want the privacy of company or personal data to be compromised.

The Solution:
() I use Symantec Encryption Desktop. I create PGP disks that can then be mounted as sub-directories or as virtual hard drives.  I mostly mount them as subdirectories.  (I choose not to use full disk encryption based on early negative experiences with it.)

The problem for theBrain
() The brain is stored in an encrypted directory.
() The brain uses the Windows indexing service as it's search service.  If the indexing service database is not encrypted, you've got data leakage.

The solution:
I chose to move the windows index to a RAM drive. I chose to recreate the RAM drive and the index at each boot of my PC.

What follows may be somewhat specific to my environment.  There were some behaviors that I encountered with respect to the indexing service that might not be encountered on someone else's machine.

This requires your user has admin rights on the machine.

() Create the RAM disk that will hold the index and mount it.  Mine is mounted to
C:\Users\XXXX\Documents\ENCRYPTED\indexed. It is setup to mount on startup.
- Ignore that the word encrypted is in the path. It was an arbitrary choice by me.
- A RAM disk will be mounted at the directory "indexed", not a PGP drive. 

() in Explorer, create a new library. I called it "notebooks". Add to that library the mounted encrypted director where your brain data lives. Mine is:
-This was one of the first places I hit a quirk.  Windows indexer won't normally index directories that are mounted as subdirectories. 
-The cleanest workaround I saw on the web was this one; add a library, then add the mounted directory to the library.

() Bring up windows "indexing options" and click modify and select the "Notebooks" library as an indexed location.

() Bring up windows "indexing options" and under advanced,  set the "New location after the service is restarted" to
- I hit another potential quirk here though I haven't fully explored it.
- I believe I saw behavior (and saw it mentioned in a forum) that for some reason that if windows restarts the indexing service and the new directory is not empty, it will revert to the default index database location.  I'm not 100% sure I saw this behavior or not, but by that point I was going down the road of a RAM drive so I didn't care to spend more time on it.

This is where the really quirky behavior began on my machine with respect to the indexing service. 

First , to summarize where we are now:
() The RAM drive is created and mounted.
() The new library that points to the root of the brain location is created.
() That new library is added to the indexing service.
() The index has been pointed to the new RAM drive location.

The next thing that has to be done is to make sure that things start up in the following order:
() Machine boots.
() the brain directories are mounted.
() the RAMdrive is mounted.
() The indexing service is started.

What I found was that even if I disabled the indexing service something re-enabled and started it very soon after windows started, and the index would drop back to the default location.

Here is the startup sequence to avoid this.
Mount the PGP encrypted subdirectories - This is an interactive process via a GUI

Mount the RAM drive where the indexes will be created.
REM Create the RAM disk
imdisk -a -s 1G -p "/fs:ntfs /q /y"

REM Mount it to the index location I selected.

C:\bin\util\small\junc C:\Users\XXXX\Documents\ENCRYPTED\indexed \Device\ImDisk0\

Start the indexing service.
REM Set the service to run as the special localsystem user. It won't run correctly otherwise.

sc config WSEARCH obj= .\LocalSystem
sc config WSEARCH start= auto

Start the service
sc start "WSearch"

REM Once the service is started, disable it, and make sure it stays disabled for the next reboot.
REM Here .\XXXX is the name of a local account on the machine that has user privileges.
timeout /t 10
sc config WSEARCH start= disabled
sc config WSEARCH obj= .\XXXX

So what happened?

At this point, the service is started but is also disabled.  When the system is next rebooted it will be "magically" changed to "auto" from disabled, but since the user is not .\LocalSystem the service will not be able to start until the commands above execute ad admin priviledge.

I found that whatever process is starting the service is able to re-enable it, and then start it, but it is not smart enough to change the user.

That's it.
It's been working pretty good for me so far.
One caveat is that I do not have an enormous brain as of yet.


count post selected

Add a Website Forum to your website.