PDA

View Full Version : ReBakoSynch



Adelphos
11-21-2011, 06:12 PM
ReBakoSynch (RBS) -- for use with BibleWorks.

RBS -- Restore, Backup, Synch -- for use with BibleWorks, is a virtual program that doesn't exist, and possibly never will. The name “RBS” is also only a suggestion at this point.

I've been thinking about this since early this afternoon, and here's what I've come up with --

Every single synch program that I have ever seen has a Folder-Tree/File-Tree display. I don’t know of a single synch application that doesn’t contain some sort of such a display, and such a display basically dictates that the user is going to have to navigate through a host of files, add them to a list, and then set them up to backup/restore/synchronize according to the parameters he has configured.

IOW, that program already exists hundreds or thousands of times over with differences being mainly those of style and format, and thus it would be superfluous for me to create another such program, even if it had some unique facets to it particular to BW.

On the other hand, there are several ideas I have that would forego all of this and allow the BW user a different but perhaps more effective resolution, especially to saving settings...

For example, I could parse certain things out of existing BW INI files and save/restore/synch them as desired.

Ergo, say that you wanted your “aliasfile” tag – which is in your main BW INI file – backed up or restored or synchronized. No problem.

I could make that part of one of a number of “settings configuration files” that you have set up through RBS so that that particular “aliasfile” and its INI tag was backed up, restored, or synchronized.

To demonstrate: in my main BW INI file the “aliasfile” tag reads this way --

aliasfile=C:\Program Files (x86)\BibleWorks 8\init\scottbooks.bna

In this case, I could not only restore or backup or synchronize this setting WITHIN your own main BW INI file, but I could also backup/restore/synchronize “scottbooks.bna” to a target/source location.

IOW, instead of attacking this from a folder/file tree perspective, which all synch programs already do, we could attack the various settings themselves and build the program from that perspective.

This is just one example. I know of other ways to apply something similar. I’m sure others have more ideas as well.

Even though this is still very muddy in my mind, it seems to me that any type of app along the lines of attempting to preserve the BW working environment would be much better served going down a road somewhat like this rather than a normal backup/restore/synch app that already exist by the truck loads.

Anyway, I’ll continue to think on it, and if anyone else has ideas, this is the place to air them.

Adelphos
11-22-2011, 02:06 PM
Well, Michael, you MAY have created a monster. I'm not promising anything, but I have been toying around a little. Here's what I would like --

if any of you have settings in one of your BW INI files that you would like to be able to save/restore/synch with a click of the mouse, then please tell me what settings you are interested in, and also the INI file that each setting is in.

For example, from my own demo yesterday, I used the "aliasfile" tag in the "bw800.ini" file, so if I were responding to myself in this post, I would write --

aliasfile, bw800.ini
searchpath, bwedit.ini

and so on.

As I said, I'm not promising anything, but ONE of the capabilities I would create if I were to actually produce this program for publication would be the capability to restore/backup/synch ALL of the tags in ALL of the INI files with a single click.. or maybe two clicks, but you get the idea.

The problem is, I don't have a clue as to which settings others might want to preserve. I could make a master list of tags from the existing INI files, but that would not only take forever for me to type them in so that I could put them in a list box, but they would likewise take the user forever to scroll through it once it was avaiable.

Thus, I need a master list of INI file tags that would be most likely the tags that BW users would like to preserve. Once we have a list of INI file tags that others might want to preserve, then I could customize it so that each user could choose which ones he wanted to preserve.

This INI file category is only one of several modules that would be available in the program if I ever decide to produce it, so that IF I end up writing and finishing this program for publication, it would attempt to be the only thing a BW user needed to preserve his BW working environment completely, or as close to "completely" as is possible.

Michael Hanel
11-22-2011, 03:48 PM
Well, Michael, you MAY have created a monster. I'm not promising anything, but I have been toying around a little. Here's what I would like --

Well hey, if you dream, dream big :) I guess I didn't think you would account for everything in one release, but if you tried a few small pieces and got feedback on whether those work or not, or do what people want, that would be beneficial. I personally only use BibleWorks on 2 computers and I tend not to do a lot of syncing because I do different work on each computer, but when I read Mark's post and knowing that I've seen other people ask questions here about syncing and knowing that you are good at creating these little applets, it all kind of came together.

The key thing for making it easier (in my opinion) is having basic options, like "Sync notes" and rather than the user knowing what files need to be copied, the applet can do that for them. I know what files need to be synced when I changed book names or version display order, but I'm not sure others always remember that kind of stuff.

So that's at least a little of what I was thinking.

Adelphos
11-22-2011, 04:26 PM
Yeah, synching notes would be a given, and also allowing (demanding, actually) the user to determine which folder is his "notes" folder, as well as restore/backup/synch a few other specific BW files, including just doing a straight restore/backup/synch on all BW INI files, or "selected" BW INI files, as well as the ability to configure it so that only certain settings from WITHIN the various INI files got synched.

To go back to my example with "aliasfile" and "scottbooks.bna", the ability here would be to not only write to the main BW INI file and place this info in it, but also to restore/backup/synch "scottbooks.bna" as well.

IOW, if I'm going to do this program, I want it to be comprehensive enough so that BW user can basically click two or three times total and have ALL of his settings and ALL of his files restored/backuped/synched so that he wouldn't have to manually go through each INI file to copy and paste each particular tag within that INI file, as well as having all of his own special files operated on, i.e., notes, bna, vlm, wlm, version order files, ermie files, x-ref files -- in short, EVERYTHING that affects the customization of the BW working environment so that instead of taking him a half hour to get everything straight, it will take him one or two mouse clicks and five or ten seconds.

As I said, I've seen people refer to settings in their INI files many times before, but the main BW INI file itself runs to 33 pages in Word, and that's just the one BW INI file, so there is no way that I want to make every single tag a target. Rather, I would rather have a list of potential tags that deal with certain user customizations and target those specifically.

This INI file capability would be only one facet of the entire restore/backup/synch operation.

But I would really need to know what INI files settings, as well as which INI files themselves, most users would like to protect before I deal with the interal text of the INI files.

Of course, doing a simple restore/backup/synch of ALL BW INI files in one fell swoop is a given, as I said, but the real potential of RBS with regard to INI files would be its additional potential to auto-operate on the specific tags WITHIN each BW INI file.

For example, if you have 7 tags in the various BW INI files that you save so that you can restore them if needed, then you must MANUALLY open each of the INI files 7 times (unless you keep it open, of course), MANUALLY find the tag you want to alter, MANUALLY copy/paste that tag, MANUALLY save the file, then MANUALLY repeat the process 6 more times.

With RBS you could do all of that with a single mouse click, whether it be 3 INI changes or 50 INI changes.

And that doesn't even including operating on individual files that might be addressed in those specific INI tags, e.g., "scottbooks.bna" at the end of the tag would ALSO be backed up, in addition to the 7 INI changes themselves, and any other such files that were addressed in the INI file itself.

And then of course, RBS would still contain all of the other restore/backup/synch capabilities that would make preserving the BW workspace simple.

But I think the INI file capability is a key capability. It's just knowing which particular settings most BW users feel that they would like to preserve.

Lee
11-22-2011, 04:39 PM
I've been reading these posts not certain of exactly what you are looking to do. I'm still not certain I understand, but I think I'm getting the general gist. There are settings that I would love to take from one computer to another, but have no idea how. Including book names, copy window settings . . . that is what you are talking about, right?

Adelphos
11-22-2011, 04:55 PM
I've been reading these posts not certain of exactly what you are looking to do. I'm still not certain I understand, but I think I'm getting the general gist. There are settings that I would love to take from one computer to another, but have no idea how. Including book names, copy window settings . . . that is what you are talking about, right?

Yes. Essentially, ANYTHING that you have to configure when you go from one computer to another, or when you have to restore from a computer problem, or update proglem, or whatever.

The goal is to make a program that preserves the customizeable workspace/environment of BW. To do this, we would not only need to make sure that specific files were targeted, such as notes files, and so on, but also make certain that specific internal settings which BW retains in its INI files are also targeted.

IOW, ANY custom setting in BW should be a potential target, and due to the fact that BW utilizes INI files to retain most of this information, a great deal of the customization can no doubt be preserved.

Lee
11-22-2011, 10:35 PM
Sounds great to me--I'm definitely interested.

MGVH
11-23-2011, 02:48 AM
Well, I like where this is going, but I see what a challenge it might be...

I do know that I sometimes change my Synopsis files, so backing up all SDF files should be on your list. (These are usually stored in init directory, but these would be easy to move to their own subdirectory for easier backup.)
Saved Tabs: These are SWC files. It appears that BW generates a set for your last used ones in the init directory. I just tried, and as I suggested with the SDF files, I made a SavedTabs subdirectory under the init directory and stored my saved tabs there. OTOH, I suppose by backing/syncing the SWC files in the init directory, it would mean that if I close BW on one machine and open it on another (after syncing), I would be at the same tabbed workspace.
Version Display Order: These VDO files are important to me. I've created a number of them depending on the work I'm doing. Again, these are in the init directory. They could be saved from there or moved to their own subdirectory.

Where it would get harder is with the Resources since those are determined not by BW but by the CHM entry. Maybe there could be a backup option from your Resources Menu Editor!

Adelphos
11-23-2011, 01:56 PM
Well, I like where this is going, but I see what a challenge it might be... Where it would get harder is with the Resources since those are determined not by BW but by the CHM entry. Maybe there could be a backup option from your Resources Menu Editor!

Everything you're suggesting would be in there, and it wouldn't be complicated at all, i.e., SDF files, SWC files, and so on. All of these types of files (and others) would be covered, with a lot of flexibitilty as to what files/types to operate on, as well as where to put them re: source or target.

I'm just not sure I understand your last question. I thought RME (Resources Menu Editor) -- the file I put out the other day -- already backs up the CHD files. So I don't know what you mean, but whatever it is that you mean, I'm pretty sure it can be done.

I still insist on going after the INI file specs as well. I just need to work out a scheme for the INI files that will be most effective.

What I have pretty much decided to do is at first make a very BASIC mock-up of RBS and place it in a location so that you all can download it, just to give a basic form to this phantasm of what we're discussing.

Once I've got the mock-up there, it will at least provide a very BASIC platform from which the discussion can go forward.

After that, as I build the program, I will make "beta" versions so that as the program grows, much of its growth will be powered by input from everyone who cares to opine on the subject. IOW, I foresee this as being a participation-built program so that all foreseeable and desired options are covered.

I've already begun to make a little mock-up. When I get that up I'll post back here under a new thread called "RBS Mockup" and we can take it from there.

Anyway, if you care to elaborate on what you mean by your last statement, I feel certain that whatever it is can be addressed without too much trouble.

MGVH
11-24-2011, 02:30 AM
Yes, I wasn't entirely clear. I guess I was making a distinction between changes in files that are made within BW (e.g., tabs, synopsis, vdo, etc) and ones made outside the program (e.g., the CHM files). In terms of backing up and syncing, however, that really doesn't make any difference. Thanks.