Tag: Programming

Note Editor

We reported extensively on the note editor in progress update #8. We spent a little more time on that task, in particular as it relates to when we save the changes you make to a note. First, we wanted to make sure that your edits get saved when you exit the app, so we provided a notification to the note editor that the app is about to exit so that it can save your work. (You probably think that just “happens” — and it does — but somewhere there’s a programmer who wrote the code to detect the fact that the app was closing and made sure that your work got saved.)

In addition we took more control over exactly when we sync an edited note to the server. When the note is open for editing, our other apps periodically sync to the server to make sure your changes get saved. This is potentially important on a mobile device where you might drift out of Internet coverage or the battery might die at any moment.

On the desktop, we can be a little more patient. We wait until you are done editing the note (say you switch to the viewer or the other editor), then we save all your changes to the server at that time. Of course locally we save your work every few seconds so that you don’t lose anything if the power goes out. But by waiting to sync with the server until you’re done editing, we make certain problems easier to solve when you have the note open on more than one device at a time.

Finally, when linking to a note from search results, we now highlight the searched-for word(s) in the note viewer. This may be a first for PocketBible. I don’t recall doing this in previous releases, though some of you with memories that extend back to the last century more clearly than mine do might remember it differently.

Note Search

Note searching is similar to book searching except there are no indexes and of course the text comes from a completely different place. The overall structure of the code is the same except for when you get down to actually looking for the word or words in the text. Book text comes from an LBK file which has a lot of indices to support searching, but notes come from a database with no indexing. We’re able to use exactly the same code until we get to that last step, where it branches depending on the source of the text being searched. As a result, a lot of the logic of searching was already done.

The display of note search results is similar to displaying book search results. What we didn’t realize going into this was that it is so similar that it can actually share the code. So the Note Search, Book Search, and Journal Search panels are just 3 instances of the same chunk of code (we call it an “object” rather than a “chunk-o-code”). So we spent some time throwing away some work we had done on separate panels for Note and Journal searches and adapted the existing book-searching code to account for notes.

Similarly, the Journal is just a collection of notes, so the work we do for regular note searches and note editing automatically applies to the Journal. So even though the Journal is an Advanced Feature Set feature, we’re doing the implementation now as we work through the general notes feature. (Other AFS features will likely be put of until work on the standard feature set is done.)

On the other platforms, when you do a search for a word in your notes, the search results will show an excerpt of your note, but it’s just the first couple of lines. You don’t see where the thing you’re searching for actually occurs in the note. In the Windows version, we’ve made it so that search words are highlighted in the note viewer and are also highlighted in the search results. And we’ve added a smart “excerpt” function so that if the word you’re searching for occurs later in your note than the first couple of lines, we’ll show you the portion of the note in which your word occurs.

Since the book search, note search, and journal search all turned out to be the same/similar code, when we added excerpts with highlighted search words for notes and Bibles, we were also able to add them for non-Bible books.

Study Panel

As a result of working on the note editor, we learned more about how to better handle layout of other panels. This is particularly related to the re-layout that happens when you resize the Study Panel or the entire PocketBible window. Previously we had been doing a lot of manual calculations to position buttons and text appropriately. It turns out there were some easy ways to allow that to happen more automatically.

Bookmarks

We’re just wrapping up work on managing (add, rename, and deleting) categories. This gets tricky when you’re syncing all that data to other devices, so we’ve had to do a lot of testing of the entire synchronization path from Windows to the server and from the server to other devices.

Book Display

We happened to notice while doing our own devotional reading that the book pane was not getting refreshed when you change the start date of a devotional. So now it gets refreshed to update the dates you see in the text.

Quite a bit of progress since the last report. Some of it (note editor) was re-implementing something we thought was already done, but that has to happen every once in a while.

Copy Passage

One of the major accomplishments of the last month has been what we call the “Copy Passage” feature. It allows you to enter a verse or passage reference and select a number of options for how you would like the text to appear, then press a button to copy it all to the clipboard with all your options.

With this feature in place, you can use Ctrl+C to just copy the selected text, Shift+Ctrl+C to go to the Copy Passage dialog to choose options, or, once you have the options configured the way you like them, Shift+Alt+Ctrl+C to immediately copy the selected verses with all the formatting options you’ve chosen.

Both the current Windows versions have some limited implementation of this feature. The implementation in the new Windows version is based on the macOS and iOS implementations, which have more features.

Note Editor

Writing a rich text editor for notes is not easy. Back when we were at Parsons Technology doing something similar for QuickVerse 5, we paid someone $200,000 just to implement this one feature.

A few years ago, the people who define how the Web works created technology that is present now in every browser that does a lot of this work for us. It’s far from perfect, but it’s pretty good. Since we use HTML (the “language” of the Web) throughout PocketBible and render it with built-in HTML functionality that is part of the underlying operating system, it wasn’t hard to integrate this functionality into PocketBible for Android, iOS, and macOS.

When we originally started looking into re-writing PocketBible for Windows, this was one of our concerns — would we be able to use this built-in feature for editing notes? We discovered that Microsoft’s development environment was sadly deficient in this area and it became one of our main reasons for going with the Electron system I talked about in update #3. Electron includes Chromium, the guts of the Chrome browser, to provide HTML rendering in every Electron app.

The HTML editing that is built into Chromium can be difficult to use. So initially, we implemented the note editor using a free component we found called TipTap. TipTap is endlessly reconfigurable and seemed like it would meet all of our needs. We even reported that note editing was complete back in update #4. But after we got digging into this, I realized that there were little things that weren’t working at all. For example, if you copied Bible text with superscripted verse numbers into a note, TipTap would remove the superscript. If you had a note that included a table, the row and column information about the table would be removed and you’d only see the text, all run together in a blob.

Turns out TipTap was “easily reconfigurable” but required custom programming to support every single HTML feature. So there was a custom plug in required to make text bold, another one for italics, one for superscript, and another one for tables. But on closer inspection it turned out that they were sorely lacking. For example, you could create a table, but you couldn’t put borders around the table cells. And TipTap would intercept all our Bible verse links, launch a browser, and try to direct you to a site like “http://John 3:16”, which of course didn’t work. Further, if you were reading a note that you created on another platform, like PocketBible for Android or iOS, anything that TipTap didn’t recognize would be stripped from your note.

At first it looked like we just needed to update TipTap from version 1 to version 2, but that didn’t fix anything. So we bit the bullet, removed TipTap entirely, and wrote our own HTML editor based on what we’d done for other platforms. This ended up working fairly well. It’s done except for wringing out the bugs at this point.

One of the little things we noticed that turns out is a problem no matter what platform you’re on is that if you use the note editor to change the color of your notes then choose a color scheme that causes the note editor to have a dark background instead of the traditional white background with black text, you may not be able to see your notes. So the new version has an easy way to switch to a light or dark background color in case you need it to accurately view your notes.

Registration

In update #6 I said we had implemented the ability to log into your account, which is true. But we didn’t prompt you to register when you first launched the app. So that’s been implemented. You can now log into an existing account or create a new one. And the account screen in PocketBible settings/preferences will show you your Advanced Feature Set subscription status and give you options for synchronizing your notes, highlights, and bookmarks.

Current Tasks

We’re currently working on some polishing of the bookmark feature. We previously had implemented the ability to set and clear bookmarks, but not create new categories, remove categories, or rename categories. We’re well into that now. We need to do similar work with respect to highlights.

We’re also testing and tweaking the features mentioned above. While doing one thing we often discover better ways to do things that affect other parts of the program. For example, over the last couple of days I’ve revisited the “go to” pane and significantly streamlined the way it works based on work we did while implementing the note editor. This has made it more reliable by removing a couple hundred lines of code that just gave it more places it could go wrong.

We’ll soon move from the note editor to implement note searches. We have the basic user interface in place; we just need to implement the actual searching.

One behind-the-scenes task that is happening is getting us positioned to be able to create what we call a “release build”. When we build the app in its current state, it’s really suitable only for development use. It has additional panes and windows that show our developers the internal workings of the code for debugging purposes. The version you get (the “release build”) won’t have those features, of course. I want to be able to create a release build sooner rather than later so that we have time to work the bugs out of that process and get set up for beta testing.

Construction Project

I see it’s been over 3 months since I updated you on the view out our front windows. As you recall the city completely shut down and rebuilt the main street through town, which passes in front of our building. At the same time, the strip mall across the street was torn down and a new combination retail/residential building is going up in its place. Our entertainment for the last 9 months has been watching (and listening to) the construction.

The street re-opened around Thanksgiving. Work on the building continues. The exterior appears to be completely framed. Windows are being installed and bricking has begun. Something is happening on the roof but we can’t see it well enough to tell what it is — perhaps an insulation layer that goes down under what I assume will be a rubber membrane style roof. On the inside we can see electrical work being done and also fiberglass tub/shower inserts in each apartment.

A similar build is being behind this one, which will have parking underneath and 2-3 floors of apartments. We won’t be able to see that one being built

Christmas break and some changes in the availability of team members have taken a toll on productivity, but work continues on the app.

Navigating: The Go To Tab

A lot of time has been spent implementing what we call the Go To Tab in the Study Panel. It’s where you go to navigate through a Bible or reference book. There are 3 different configurations of this pane. For Bibles, you have the ability to enter a Bible reference or choose book, chapter, and verse from drop-down lists. In addition, a list of your most recently visited verses is displayed.

For devotional books, the main interface is the ability to navigate to the first unread reading, previous and next readings, and to the reading for a specific date. A list of readings that are highlighted to indicate whether or not you have read them is displayed. Functionality is provided to “start over” on a devotional by setting the start date and clearing your existing reading progress data. Related to the implementation of the Go To Tab for devotionals is the ability to click on a heading over the reading for a given date to mark that readings as “read” or “not read”.

For all other books, a hierarchical table of contents is displayed, and your current position in the book is highlighted.

Study Panel and Toolbar Position and Size

While we were working on the Study Panel, we made it so you could have it positioned on either the left or right side of the screen. (You’ve seen it on the left side in every screenshot to date.) We also save the width of the Study Panel and allow you to double-click on its border to rotate between its minimum width, the width you’ve set it to, and its maximum width. This is in addition to being able to either show or hide the panel.

Related to the position of the Study Panel, we also made it so you can display the toolbar either at the top or at the bottom of the screen. We think this might be handy when using PocketBible on a Windows tablet. While doing that, we made both the toolbar position and contents persistent (saved in your user preferences).

Navigation History

We spent some time on a rough implementation of what we call “navigation history”. This is the data that lies behind the “back” and “forward” buttons on the toolbar. This is significantly more difficult in PocketBible than in something like a browser. In a browser, your back/forward buttons take you through the history of the current browser pane or window. PocketBible can have multiple panes and multiple books open in each pane. The history database needs to keep track of all of that.

We call this a “rough” implementation because there are a lot of places in the code where we need to “capture” history because the position is about to change. Further, there are a lot of places where we don’t need to actually capture history but we need to somehow mark the book or pane as “dirty” and in need of being saved. We believe we have identified most if not all of these places. Further testing is required.

A Few Smaller Things…

The ability to highlight a word and right-click to look up its definition is implemented.

The search field now displays a list of recent searches.

You can specify a range of verses to search when searching a Bible.

The range of font sizes you can select has been expanded.

We spent a lot of time (and continue to spend a lot of time) working on internal, non-user-facing elements of the code. Some of these are to accommodate updates to third-party libraries used by the app. Others are to flesh out implementations that were started with the idea we’d finish when we knew more about what they needed to do. Some are tweaks to the user interface that we’re getting around to as we pay attention to different aspects of the program.

Schedule

I have a hard time coming up with different ways of saying “we’ll be done when we’re done”. We go through periods where we make a lot of progress and others where we have a problem we just can’t figure out and get past. As I’ve said before, we don’t work with a specific release date in mind. We just keep working our way through the list.

A few of you have offered suggestions. We appreciate but can’t always implement those. That being said, the reason the toolbar can be moved to the bottom of the screen is because a PocketBible user asked us if we could do it. We had one false start that led us to believe we couldn’t, but then we backed up and took another run at it and the result is what you see above. So if you have suggestions, feel free to pass them along either here in the comments or to tech support. We are locked into some decisions but will always think and talk about good ideas, regardless of the implications.

I apologize for the delay getting an update out. We get busy and we are always thinking that after we implement the next big thing would be a good time for an update. Next thing you know several big things have been implemented and no update.

Since the last time you heard from us:

Notes can be edited, saved, and sync’ed to the server. The note links in the text open the note in the editor.

Bookmarks can be created and lists of bookmarks in a given category displayed. You can select a bookmark to go to it in the text.

Highlights can be created but they’re not yet visible in the text. You can see a list of them and select from the list to go to the verse.

The option to sync Bibles and commentaries has been implemented, so commentaries and other Bibles will follow along as you scroll through the Bible text. There’s a separate option to sync dictionaries so that any request for one dictionary to go to an article for a word will result in all dictionaries responding, and another option for all devotionals to go to today’s reading when any one devotional goes to today’s reading. Here’s a little demonstration:

The scrollbar is implemented. As you drag the scroller up and down, there’s a tooltip that tells you where you’re at in the book. When you release the mouse button, the text goes to that location. There’s an option to scroll by pages or scroll by chapters in the Bible. Other types of books have similar options.

The program saves its display state, window size, and position between sessions. If  you have more than one monitor, it remembers which monitor it was on. If you unplug a monitor or switch to one with different resolution, it adjusts its size and position accordingly.

There are other little things that get done along the way, of which I may not have made a note.

We’re currently working on implementing searches. There are interesting technical challenges porting that code from Mac/iOS/Android to our environment in Windows. On the other platforms we launch a dozen parallel activities to perform a single search. The Electron environment is single-threaded. There is a way to create multiple processes but the communication between them is rudimentary. We’ve settled for trying to make it so the user interface (mainly mouse movement and interaction) doesn’t stutter during a search, but searching may be more of a serial, rather than a parallel, operation. I’m guessing nobody will notice. Searches will still be fast.

An interesting complication that arose during implementation of searching was being able to support finding words with the same root word as the one you are looking for. The algorithm that reduces words to their root words is written in an esoteric programming language that was created specifically for this one purpose. In order to translate that language into what we need (Java for Android, C for iOS and macOS), we have to use a custom transpiler that converts from the weird root-word language into Java or C. The new version of PocketBible is being written in JavaScript, which would require that we write a custom back-end for the transpiler. This was disappointing as we figured it would take several days, if not more, to implement. Fortunately, the next day we found that someone had already converted the code by hand to JavaScript. We added our modifications to support Early Modern English (KJV language) and we were back on schedule.

One of the things that happens during development is that you sometimes get to do things twice. We were using a very basic method of displaying lists like your list of bookmarks, notes, and highlights. This method worked fine (and is working now) but in those rare cases where you have 20,000 search results, it will get bogged down. So we’re replacing the already-working list mechanism with a new one. It’s one of those things that, once it’s done, you won’t notice the difference. But it requires careful surgery to remove one method and replace it with another. This is being done to support search results but other areas of the program will benefit. Most people don’t have 20,000 bookmarks, but for those who do, this will be a noticeable improvement (at least it would be noticeable if they had seen it before and after, which they won’t.)

As some of you know, last August our city was hit by a rare wind storm known as a derecho. Sometimes called a “land hurricane”, a derecho has straight-line winds that exceed 100 MPH. Our city experienced winds as strong as 140 MPH. And while a tornado has stronger winds, it generally only affects a narrow path, maybe a couple hundred yards wide. This derecho caused wind damage over an area 100 miles wide and 700 miles long.

The office build we were in took significant damage. The roof had to be replaced along with all the flooring, all the ceiling, and a good portion of the walls. We were able to continue working there while roof repairs were made and most of the interior was removed, but in mid-February we had to move out. We spent 3+ months working from home with some negative impact on productivity. Then in mid-May, a new office suite became available just 2 blocks from our old location. By the end of the month we’ll be in a beautifully restored 19th century building with exposed brick walls, original wood floors, and 12′ ceilings.

That’s where things stand as of today. Thank you again for your interest and support of this project.