Adam,

Good suggestion. I am adding a place in the interface where this would fit perfectly.

Johannes wrote:Just for the records: revealing an item via Service or Spotlight brings up QRecall but not the item. I guess this is related to the not yet implemented search.

It's closely related. Just one of the "many other things" that aren't yet re-implemented.

Johannes wrote:I tried to check the behaviour systematically and all the time, when it "did not work" it was a selection in list or column view somewhere down the hierarchy. So it seems to behave accordingly to your programming. No bug then, but different philosophy than expected

That's a good observation, and I might change how the column view handles this. I was trying to be consistent (read, the application shouldn't do unexpected things) in preserving the current browser path across all views. I didn't think that changing the view should change the folder or volume you were anchored at, nor should it create history.

Apple's Finder has the same problem and they went with the 50/50 solution; the Finder is consistent half the time.

Apple's list view acts just like QRecall's. Expanding and selecting items in subfolder doesn't change the the path of the browser window. If you switch from list to icon view, the icon view shows the top-level items in that folder and any selected sub-items disappear.

Column view is different. The Finder treats selections in a sub-columns as navigation. If you drill three folders into a column view and then switch to the icon view, the icon view shows the folder with the selected items. Also, selecting folders in column view adds steps to the navigation history.

So the Finder takes the approach that expanding folders and selecting items in list view does not constitute navigation, but selecting folders in column view is navigation. It changes the browser window's root path and adds steps to the navigation history.

I have to say that the Finder's approach, while somewhat inconsistent, has merit and wouldn't be terribly difficult to emulate in QRecall.

Johannes,

First, please send a diagnostic report. Then try reindexing the archive. That should fix the problem.

This is an internal error that occurs when the names index has somehow gotten out-of-sync with the actual item names in the archive. Normally (i.e. in the release version), this situation is ignored and will eventually correct itself. The beta version, however, worries about such things and throws an exception.

Johannes wrote:One more suggestion on the path navigation placement:
Place the history arrows and an "up" Button at the left side between layers and browser.

All good suggestions. The UI is still in flux. I've also considered moving the history buttons to the toolbar, make them into keyboard shortcuts, add a column of navigation shortcut buttons to the left margin of the window, or any combination of those things.

So please keep your observations and suggestions coming.

Johannes wrote:The easiest and most user friendly way would be to restrict selection in the time view to one item (or items within on layer).

I also would hate to do that too, for a number of reasons.

I haven't given up on selecting individual historic items in the timeline. I implemented the current method simply because it was consistent with the other views and I knew it wouldn't create any complications. I'd still really like the ability to switch to the time view, zoom through time, pick out an older version of some file, and immediately recall it. I just have to figure out how to do that in a way that doesn't make other things so complicated that people's heads explode.

Too more things:
- I miss a toolbar item for instant recall

Noted

- I would prefer if switching browsers-styles would retain root, selection and layer shading

Whoa, it should be doing that now. If it's not, then that's a bug (or probably five).

When switching between views, the root folder should remain the same and QRecall will attempt to preserve the current selection. Now there are obvious limitations, as some views (like list and column) can select nested sub-items that can't be represented in other views. But at the top level of each view, the selection should be preserved when switching between views. If it's not, please note the circumstances and I'll try to fix the problem.

Johannes wrote:I played a little bit with the new views.
...
Nice work.

Thanks!

Some observations:
- I find myself always looking up when searching for the path bar. I know the Finder has it on the bottom too. But for me the top of the browser feels more natural.

I struggled with that myself. The problem is that if you put the path control above the item pane, it ends up between the item browser and the layers. The interface is already pretty busy there, and it gets obscured by the timelines. If you put it at the very top, now it's well away from the item views and feels disconnected from it.

- Hoovering over a dot in the browser no longer displays the Playback controls. Are they simply not jet implemented or is there a new way to reveal previous/next captured instances?

The individual item playback controls have not been (re)implemented. I was debating whether to keep them or not. With the ability to automatically hide uninteresting layers, their utility is considerably lessened. As an alternative, I've considered a keyboard short-cut that hides/reveals the layers based on the currently selected items. Functionally, that would be identical to the old playback controls. It would be less intrusive (interface wise), and ultimately more flexible, since one could select multiple items and navigate them as a group.

- What is the meaning

42

- Hiding irrelevant Layers is a good idea. But I would suggest to place the Show hidden layers command in the layers menu as well.

Good suggestion.

- In time view I can't select a certain instance in time. QRecall always selects all instances (the whole lance of pierced instances). When I ercall I get the last captured instance.

I originally wanted to allow one to select individual items in the time view, but when it came time to implement the recall actions it became clear that such a selection would create some serious problems for QRecall. QRecall's database model centers around the concept of a single range of time, within which one can operate on one or more items. If you select a file from layer 4 and a folder from layer 19, there's no way for QRecall to frame that selection in terms of a single operation.

But just like the playback controls, it would also be easy to create a short-cut that would let you click on an item in the time view and automatically shade the layers so that the item you clicked on is now the latest item, ready to be recalled or restored. This would be vaguely similar to Photoshop's Command+Option+click shortcut, which jumps to the layer of whatever you click on.

- What is the meaning of the different colours of the layer labels in time view?

It means they happened on different days. QRecall arbitrarily color codes the layers so that it's easy to pick out layers from different days/weeks/months, and see groups of layers that occurred on the same day. Also, the depth of each layer is (logarithmically) proportional to amount of time encompassed by that layer. So week layers are thicker than day layers, which are thicker than hour layers.

Ralph Strauch wrote:Before I install v1.2.0(35) beta on the Snow Leopard machine I want to confirm that it's OK to run different versions on the two OSs.

Yes, you can use different versions.

If you want to open archives written with the lastest version (b35) on a system running Leopard, I recommend that you upgrade the computer running Leopard to version 1.2.0b34. This is a special release of b33 that accepts the larger icon data records written by b35. See the release notes for the gory details.

The new version (b35) doesn't change the format or structure of the archive in any way. It does, however, capture a lot more icon data than earlier versions. This had an unexpected consequence for earlier versions that assume a file's icon data record would never exceed 32K. The new icon data can easily exceed that (by several times), which causes versions earlier than b34 to be grumpy; they won't display icons of items with the large records (even though the icon data is compatible) and they refuse to verify the archive. Version b34 simply accepts that some data records can be larger than 32K; everything else works the same as it did before.

Other than that, the versions are interoperable. All of the really important actions (capture, recall, merge, compact) work across all versions. That's because a file's icon data record is only used for display purposes and is not considered to be an essential part of the file. QRecall, therefore, ignores any problems that it might encounter with a file's icon record and just keeps going.

Thanks, Steve. QRecall is supposed to insert the new "Browser Style" control into the toolbar once the first time you run the new version. Clearly, it's getting overzealous.

Scott,

When you restore (or recall) a folder, QRecall reconstructs all items contained in that folder, including invisible files, to the state that they existed when that folder was captured.

If you've used the layer shades in the archive browser to hide more recent incremental captures (i.e. rewind time), the entire folder will be restored the point in time being viewed. In this respect, QRecall works just like Time Machine. You can rewind entire folders (even entire volumes) to any captured point in time.

You always have the option, of course, of picking through the folder and retrieving individual items. But anything you do with a folder (capture, recall, restore, delete, ...) always means that folder and every item and subfolder it contains.

Scott Elliott wrote:Would Time Machine be a better solution? Why would I select QRecall over Time Machine?

While conceptually similar, QRecall does a number of things that Time Machines doesn't. Principally, QRecall intelligently compares every block of data being capture to what's already in the archive, and never duplicates any data. This makes it vastly more efficient than Time Machine, which blindly copies every file it finds and makes an additional copy of each whenever it changes.

In addition, QRecall is scrupulous about data integrity. Every block of data, and every bit of file metadata, is protected by data checksums and cross-checks. QRecall fanatically examines every block of data for consistency and possible damage during every phase of operation. QRecall lets you verify that your captured data is correct, has not been corrupted or altered, and can be successfully restored. Time Machine, and similar file-copy backup solutions, can make no such claim.

Steven M. Alper wrote:... I'm attaching an excerpt from the log with the rather sad sounding exception, "Failure failed."

Thanks, Steven, for the post.

Yes, you did encounter an internal error, but one I'm at a loss to explain. I can tell you what happened, just not way.

There's a temporary table build during the verify process that's used to verify that the number of the bytes in every file agrees with the length that it's supposed to be. It writes this information incrementally while it's busy checking other things.

When it comes time to verify the file lengths (you'll see the message "Checking file lengths"), it reads this information back into memory. In your case, the file read back was 16 bytes shorter than it was supposed to be:

Details shortListData.length (12179240) disagrees with shortListCount (1522407*8)

I can't suggest any reason why this would happen. I suggest repairing your startup volume and trying again.

Mikael wrote:What is so special about the structure of wizard actions that the can't be treated like usermade actions?

There's nothing different about them. Actions created by the capture assistent are no different than manually created ones, and should be fully editable.

Please describe what is preventing you from editing these actions.

I should point out that the action window is divided into sections (Archive, Action, Schedule), and in the title of each section is a disclosure triangle. Click on the triangle to expand the section and edit the details.

I point this out because, depending on which version of QRecall and OS X you are using, you might have one of the combinations where the color of the disclosure triangle the the color of the section title's background are the same, making the disclosure triangle all but invisible. (Apple is always fiddling with the colors of the UI.) Look hard, or just click to the left of the title, if you don't see it.

Offhand (i.e. without looking at that code), I don't see why a "cancel" Growl notification couldn't be added. I've added this to the to-do list for 1.2.

Damian Huxtable wrote:What does a red exclamation mark to the left of an action in the actions window mean?

Hover the cursor over a status icon in the actions window and a help tag will describe its status and/or its problem(s).

Typically, it's because the action hasn't been fully defined or the destination archive can't be found. Sometimes the latter is misleading because QRecall can automatically mount some external and network volumes before starting the action, which means the archive doesn't have to be on-line now for the action to run successfully—but the actions window can't know that.

More generally, is there a part of the manual or help pages that details what all the symbols on each window mean?

No, I just realized that there isn't! I'll put that on the to-do list.

Bob Tyson wrote:If I keep backing up to the same archiive I worry that corruption will creep in.

There are lots of good reasons to split (or combine) your backups amongst archives, but trying to protect against corruption isn't one of them. The important information in an archive is stored in the primary repository file. When you capture files, new data is added to this file, but the existing data is never overwritten. The data already captured is just as safe whether it's in the archive you're capturing to or another archive on the same volume. If you're worried about data integrity, schedule a verify action to run regularly.

It's true that some archive index files get rewritten whenever you capture new items, and the more often you capture, the greater the chance there is for something to go wrong and trash one of them. But all of the information in the index files is redundant and can be reconstructed from the data in the primary repository file.

I prefer not to back up the whole volume because if I do the time to do incremental updates may become long, with QRecall picking up on a zillion new changes through the System, Library, Applications and such.

Unless you've just run a major system upgrade, your core OS and application files don't really change that much.

There are clear advantages, and disadvantages, to subdividing your backups. But it's hard to make any broad recommendations. Instead, I suggest you develop a backup workflow. I like to start by considering what could go wrong:
- Accidental damage, overwrite, or deletion of my files
- Failure of working system or drive
- Failure of backup storage device
- Failure of secondary backup storage device (if any)

Then, for each of these situations, consider what steps you'd have to take to recover the files you need, restore you boot system, replace you backup drive, and so on.

Then consider what steps or processes you'll need to perform every day to maintain your backups.

Every decision you make will impact one or more of these three areas. For example, consolidating all of your backups into a single archive simplifies every aspect of your backup workflow, but puts "all of your eggs in one basket." Conversely, separately backing up your system and user documents might make it quick and easy to restore your OS in the case of a total system failure, but that might be little comfort if you can't also restore all of your documents.