I finally had some time a few days ago, so I downloaded b12 and started using it. I just updated to b13 a few minutes ago. Here are my comments so far:

When capturing, the progress bar in the activity window goes to full (100%) immediately at the start of the capture, and then it never changes after that. I have this same problem in the current release version of QRecall also. (Just as I was getting ready to post this message, an action started another capture, and this time the progress bar seems to be working correctly. Is that something you fixed in b13, or have I got some kind of inconsistent thing going on here?)

My old backup drive was getting a bit flaky, so I bought a new external drive, and set up new archives for beta testing. I have not yet tried to convert my old archives. When i opened the new archive window for the first time after the first capture, it opened in icon mode. There was a blank icon with my name under it. I had to double-click the blank area to open up a new view showing the hard drive, and then I got an icon on the drive. The lack of an icon to go with my name was disconcerting -- at first I didn't even see it and thought the archive action hadn't worked. Did you intend to have some kind of icon there, or was it supposed to be blank?

Will the capture assistant be updated to support the new event conditions? I like the new conditions. I'm testing the one that waits to back up my virtual machine folder until after VMware Fusion quits, and so far, it seems to be working.

Feature request: Two-column sorts of the Actions window. I'd really like to see actions sorted first by the Archive column, and then by either the Next or the Schedule column.

In the release notes, "scraping" should be spelled as "scrapping", with two "p"s. Mentioned so you can get it right in the help files.

That's all I've got for now.

-- Bruce

Bruce Giles wrote:

When capturing, the progress bar in the activity window goes to full (100%) immediately at the start of the capture, and then it never changes after that. I have this same problem in the current release version of QRecall also. (Just as I was getting ready to post this message, an action started another capture, and this time the progress bar seems to be working correctly. Is that something you fixed in b13, or have I got some kind of inconsistent thing going on here?)

That's not 100%, it's "indeterminate." OS X progress views have an "indeterminate" mode to indicate that the amount of progress is unknown or unknowable. When the look of OS X got "Yosemited." the familiar marching barber-pole pattern was replaced with an (very) subtle gradient that drifts slowly across the screen. On small controls, it's nearly indistinguishable from the progress view at 100%.

When QRecall begins a capture operation it starts two threads: the main capture thread and a secondary "estimate" thread. That second thread tries to quickly rattle through the directories and change history in order to estimate the amount of work the capture thread will actually have to do. Until the estimate thread is done, the progress indicator is set to "indeterminate." Sometimes the estimate can be made very quickly, but in other cases the estimate will take nearly as long as the actual capture, in which case you might not see the progress indicator move at all.

My old backup drive was getting a bit flaky, so I bought a new external drive, and set up new archives for beta testing. I have not yet tried to convert my old archives. When i opened the new archive window for the first time after the first capture, it opened in icon mode. There was a blank icon with my name under it. I had to double-click the blank area to open up a new view showing the hard drive, and then I got an icon on the drive. The lack of an icon to go with my name was disconcerting -- at first I didn't even see it and thought the archive action hadn't worked. Did you intend to have some kind of icon there, or was it supposed to be blank?

To state the obvious, that's a bug. I'm still not sure where the problem is, and I'm beginning to think there are several bugs. In some cases it appears that the icons for the volume and computer aren't being captured properly. In other cases, the static system icons for a volume and the computer that are supposed to display when a captured icon isn't available aren't loading for some reason. Its been difficult to resolve because neither of these problems occur on my system with any regularity. Regardless, it's on the short list of bugs to look into. The issue is entirely cosmetic, as the icons captured/displayed for items in the archive aren't used to recall them.

Will the capture assistant be updated to support the new event conditions? I like the new conditions. I'm testing the one that waits to back up my virtual machine folder until after VMware Fusion quits, and so far, it seems to be working.

I consider most of the new action schedules and conditions to be power-user features, so I don't have any plans to add them to the assistant—which is really just to get you up and running with QRecall as quickly as possible. The assistant in 2.0.0b13 does add the new power state conditions to the actions it creates so that most will stop automatically if the power capacity of the battery drops below 20%. (On desktop computers, these conditions will never trip.)

Feature request: Two-column sorts of the Actions window. I'd really like to see actions sorted first by the Archive column, and then by either the Next or the Schedule column.

I'll add that to the list. Most of the UI enhancements are being addressed in version 2.1, so I'll probably get to it then.

In the release notes, "scraping" should be spelled as "scrapping", with two "p"s. Mentioned so you can get it right in the help files.

I bow to your superior skills in proofreading, but I have to call you out on this one. It's "scraping" (one 'p'), the noun form of "scrape": "to push or pull a hard or sharp implement across a surface or object so as to remove dirt or other matter..."

But it really doesn't matter. You can think of the new feature as "picking up scraps" that have already been captured, or "scraping off" items you don't want to keep on your hard drive.

James Bucanek wrote:

Bruce Giles wrote:

Feature request: Two-column sorts of the Actions window. I'd really like to see actions sorted first by the Archive column, and then by either the Next or the Schedule column.

I'll add that to the list. Most of the UI enhancements are being addressed in version 2.1, so I'll probably get to it then.

I thought one could get the same result by simply clicking on the Next or Schedule column first before clicking on the Archive column. No? Not that I'm against you doing anything about it. Just saying perhaps Bruce could achieve (most of) what he desires already before v.2.1 arrives.

In the release notes, "scraping" should be spelled as "scrapping", with two "p"s. Mentioned so you can get it right in the help files.

I bow to your superior skills in proofreading, but I have to call you out on this one. It's "scraping" (one 'p'), the noun form of "scrape": "to push or pull a hard or sharp implement across a surface or object so as to remove dirt or other matter..."

I thought as much, but didn't speak because English is not my first language.

The cause for confusion probably lies in the beta release notes, however. In the section titled "Excluding, Ignoring, and Scraping Items", "scrap"--not "scrape"--is used numerous times as a verb.

Ming-Li Wang wrote:I thought one could get the same result by simply clicking on the Next or Schedule column first before clicking on the Archive column. No?

Sadly, no. The sorting is relatively stable, so it might work until the table was updated again. But the next time the status of an action changes the entire table is reloaded, and the sub-order of items will change in unpredictable ways.

I thought as much, but didn't speak because English is not my first language.

English is my only language and I still find it confusing.

The cause for confusion probably lies in the beta release notes, however. In the section titled "Excluding, Ignoring, and Scraping Items", "scrap"--not "scrape"--is used numerous times as a verb.

LOL. I checked the interface so carefully, and completely missed this in the release notes!

People with dyslexia should not be allowed to write.

Fixed. (At least I'm pretty sure. Someone else will need to check it.)

James Bucanek wrote:That's not 100%, it's "indeterminate." OS X progress views have an "indeterminate" mode to indicate that the amount of progress is unknown or unknowable. When the look of OS X got "Yosemited." the familiar marching barber-pole pattern was replaced with an (very) subtle gradient that drifts slowly across the screen. On small controls, it's nearly indistinguishable from the progress view at 100%.

Well, raise my rent! I took another close look at it -- very close -- and sure enough, you're right. I don't think Apple could have made it any more subtle. I much preferred the old barber-pole pattern, but I realize that QRecall is just using what Apple provides there. OK, so we can ignore that one.

To state the obvious, that's a bug. I'm still not sure where the problem is, and I'm beginning to think there are several bugs. In some cases it appears that the icons for the volume and computer aren't being captured properly. In other cases, the static system icons for a volume and the computer that are supposed to display when a captured icon isn't available aren't loading for some reason. Its been difficult to resolve because neither of these problems occur on my system with any regularity. Regardless, it's on the short list of bugs to look into. The issue is entirely cosmetic, as the icons captured/displayed for items in the archive aren't used to recall them.

So, just out of curiosity, what icon was supposed to be there? I went back and looked at QRecall 1.2.3.8 which is still running on one of my other computers, to see what it did. In that case, the top level item is the name of the computer, as defined in the Sharing panel of System Preferences. It happens to be an old iMac, and the icon is an iMac icon, so that's appropriate. But in b13, the top level item isn't the computer's name, it's MY name. In fact, the computer name isn't even in the list. The next level below my name is the name of the hard drive. So what should the top level icon be -- a human silhouette, or something like that?

The assistant in 2.0.0b13 does add the new power state conditions to the actions it creates so that most will stop automatically if the power capacity of the battery drops below 20%. (On desktop computers, these conditions will never trip.)

But they will if the desktop computer is connected to a UPS (and monitoring the battery state via a USB cable), right? The release notes seem to indicate that.

I bow to your superior skills in proofreading, but I have to call you out on this one. It's "scraping" (one 'p'), the noun form of "scrape": "to push or pull a hard or sharp implement across a surface or object so as to remove dirt or other matter..."

I was going to argue back on this one. I was absolutely certain you had used the word "scrap" in several places, in which case, "scrapping" would be appropriate. I went back and looked again and couldn't find it. Then I read ahead and discovered that Ming-Li Wang noted it as well, and you've apparently fixed it. I have to say I prefer "scrap" and "scrapping" to "scrape" and "scraping". I think of "scrap" as a synonym for "destroy". For example, "The wrecked car was scrapped." I don't think of "scrape" that way. But it's really not a big deal either way. I can learn to live with it. If I really have to.

-- Bruce

Bruce Giles wrote:I don't think Apple could have made it any more subtle. I much preferred the old barber-pole pattern, but I realize that QRecall is just using what Apple provides there.

In the next iteration of the UI I was contemplating using the even-smaller progress indicator. I might have to include a free pair of reading glasses with every copy of QRecall.

So, just out of curiosity, what icon was supposed to be there? I went back and looked at QRecall 1.2.3.8 which is still running on one of my other computers, to see what it did. In that case, the top level item is the name of the computer, as defined in the Sharing panel of System Preferences. It happens to be an old iMac, and the icon is an iMac icon, so that's appropriate. But in b13, the top level item isn't the computer's name, it's MY name. In fact, the computer name isn't even in the list. The next level below my name is the name of the hard drive. So what should the top level icon be -- a human silhouette, or something like that?

At the top level of a QRecall archive are the owners. An owner is defined by an identity key and can be synonymous with you, the system, or the identity key. Everything captured using that identity key is contained within that owner.

The owner's icon is the "computer" icon from your system. The name is defined in the QRecall > Preferences > Identity Key. When you first enter your identity key, the name defaults to your computer's display name. You can change it to anything you want to identity the source of the captured items. Also note that you can later change the name of the installed identity key at any time, should you decide you want something else.

I spent some more time with this problem yesterday and I've determined that the legacy function I was using to obtain static system icons (like the icon for your computer system, the default icon for hard drives, and so on) no longer works reliably when the process is running as root—which is exactly what the QRecallHelper runs as during a capture. The call doesn't fail, but instead returns a completely blank icon, which QRecall (lacking any artistic judgement) dutifully captures.

Apple has provided a modern replacement for this function, but it's only available to processes running as the user and within the user's GUI bootstrap; QRecall capture processes don't meet either of these requirements.

I think I've developed a workaround, which I'm testing now. Unfortunately, if you've captured items and have a blank icon you're going to have to wait for those blank icons to get replaced with updated ones, which should happen during subsequent captures and merges.

But they will if the desktop computer is connected to a UPS (and monitoring the battery state via a USB cable), right? The release notes seem to indicate that.

If your UPS system has the software drivers and hardware required to communicate the status of the UPS to the power management system, then the answer is yes; QRecall will treat a desktop machine running off a UPS exactly as it would a laptop running off of battery power.

I was going to argue back on this one. I was absolutely certain you had used the word "scrap" in several places, in which case, "scrapping" would be appropriate. I went back and looked again and couldn't find it. Then I read ahead and discovered that Ming-Li Wang noted it as well, and you've apparently fixed it.

George Orwell would be proud.

I have to say I prefer "scrap" and "scrapping" to "scrape" and "scraping". I think of "scrap" as a synonym for "destroy". For example, "The wrecked car was scrapped." I don't think of "scrape" that way. But it's really not a big deal either way. I can learn to live with it. If I really have to.

I really wanted to make a statement about what QRecall was doing (scraping off items), not insinuate that the items being deleted were rubbish (scrap).

James Bucanek wrote:

Bruce Giles wrote:I don't think Apple could have made it any more subtle. I much preferred the old barber-pole pattern, but I realize that QRecall is just using what Apple provides there.

In the next iteration of the UI I was contemplating using the even-smaller progress indicator. I might have to include a free pair of reading glasses with every copy of QRecall.

I'm already looking through a pair of the finest reading glasses that WalMart can supply (3 for $7.98!), and trust me, it doesn't help.

Seriously, see the attached file for what it looks like on my old non-retina iMac screen. Maybe it looks better on newer, higher resolution screens, but to me, there's just BARELY some indication that the blue color might be very slightly "faded" in the center of the bar. More importantly, however, is that the faded area (if that's what it is), doesn't move. There's no pulsing going on. The faded area doesn't move from left to right or anything like that. Given that, it may be better to use one of the "spinner" type indeterminate progress indicators. Or do I have some kind of weird problem going on?

By the way, this brings up another issue that's not specific to the beta, as I've seen it in Rev 1 of QRecall as well. Note that the attached screenshot shows it's capturing a file called "screenshot_0000.png". That QRecall capture has now been running for more than 24 minutes, and the activity window STILL shows it working on screenshot_0000.png. I've checked the actual size of that screenshot, and it's only 281K, which QRecall ought to be able to capture in a fraction of a second. So what is QRecall really doing? There's no indication in the log file of any problem. It just now finished, and the log file says:

Schedule 2015-09-11 18:11:35 Action 'Capture Virtual Machines to Virtual Machines.quanta' set to run at Today 6:11 PM
Action 2015-09-11 18:11:36 ------- Capture to Virtual Machines.quanta
Action 2015-09-11 18:11:36 archive: /Volumes/iMac 24 Backup/QRecall Backups/Virtual Machines.quanta
Action 2015-09-11 18:11:44 Capture Virtual Machines
Action 2015-09-11 18:11:44 Macintosh SSD:/Users/bgiles/Documents/Virtual Machines/
Action 2015-09-11 18:36:53 Captured 1706 items, 58.4 GB (58% duplicate)
Action 2015-09-11 18:36:53 captured: 58.4 GB (58,463,957,153 bytes)
Action 2015-09-11 18:36:53 written: 10.9 GB (10,910,757,248 bytes)
Action 2015-09-11 18:36:53 duplicate: 33.9 GB (33,918,316,347 bytes) 58.02%
Action 2015-09-11 18:36:53 rate: 2.32 GB/min
Action 2015-09-11 18:36:53 files: 1,738
Action 2015-09-11 18:36:53 folders: 133
Action 2015-09-11 18:36:53 icons: 18
Action 2015-09-11 18:36:57 ------- Capture finished (25:13)

If the activity window ever switched from an indetermine progress bar to one showing actual progress, it must have done so in the last few seconds, and I wasn't watching it at the time, so I can't say for sure if it did or not.

If QRecall spent all that time doing some kind of maintenance on the archive file, it seems like it ought to say so in the log and in the activity window.

-- Bruce

Bruce Giles wrote:I'm already looking through a pair of the finest reading glasses that WalMart can supply (3 for $7.98!), and trust me, it doesn't help.

I've added a to-do item for the UI rework to make the "indeterminate" state of the progress indicator more obvious. I'm considering disabling the view instead of using its indeterminate state, or try setting a different color at the same time (with apologies to the color blind), so that the indeterminate state would appear grey or clear. I might even make the choice an advanced option, should you prefer one solution over the other ...

By the way, this brings up another issue that's not specific to the beta, as I've seen it in Rev 1 of QRecall as well. Note that the attached screenshot shows it's capturing a file called "screenshot_0000.png". That QRecall capture has now been running for more than 24 minutes, and the activity window STILL shows it working on screenshot_0000.png. I've checked the actual size of that screenshot, and it's only 281K, which QRecall ought to be able to capture in a fraction of a second. So what is QRecall really doing?

There are a couple of reasons, much of which is boring technical details about how QRecall's different threads communicate with each other and how they communicate what they're doing with the activity monitor process.

There is one, really big, status message flaw that has been only recently addressed in the QRecall beta. During a capture, an item's icon and display name are gathered by a separate process. In the not-too-distant past, and so that this doesn't slow down the capture thread, the item's icon and data are captured in parallel. The side-effect of this arrangement is that the message (containing the item's icon and display name) weren't displayed until after the item was captured. So the messages really should have said "Captured file.txt" not "Capturing file.txt".

In the beta, the capture message is now updated as soon as the first thread collects the item's display information. So (for larger items) it will now accurately reflect the item currently being captured.

There's still another issue, however, in that the status message only updates when there's something to report. And by "something" I mean a file to capture or other maintenance activity ("closing archive", "updating indexes", and so on). So if there are a large number of items that haven't changed, the last "Capturing ..." message may stay in the status window for an inordinate amount of time while QRecall searches for the next item to capture. Furthermore, the progress indicator bar is only updated when the status message changed, so that too will remain unchanged.

The way to address this would be to add a "Searching for changes..." or some similar message that would appear during long gaps between captured items. My reaction to this is roll my eyes and say "Oh, great, something else to slow down the capture process," but it might be worthwhile if it keeps the interface from being confusing.

If QRecall spent all that time doing some kind of maintenance on the archive file, it seems like it ought to say so in the log and in the activity window.

It does, but more than likely the capture was just looking for the next item to capture and didn't really have anything else to say.

Well, it's two and a half years later, and now I'm testing beta 2.1.0.32, but I thought I'd note that both things I mentioned in the previous reply are still issues:

1) The indeterminate progress bar in the Activity window is still nearly impossible to tell from a 100% full progress bar. I realize that's an OS issue, not really a QRecall issue, but Apple has apparently decided this isn't enough of a problem for them to do anything about it.

2) I'm doing a new backup, to a new archive, of my VMWare Fusion virtual machine file. It's been running for about 42 minutes so far, and backed up about 130 GB, and for the entire time (except for perhaps the first few seconds), the Activity window says "Capturing screenshot_0000.png", which is only a 1.9 MB file. I'm sure it's backed up way more than that, but it just seems a little odd. Is there anything you can do in the new version of QRecall to help with that?

-- Bruce

Bruce Giles wrote:1) The indeterminate progress bar in the Activity window is still nearly impossible to tell from a 100% full progress bar. I realize that's an OS issue, not really a QRecall issue, but Apple has apparently decided this isn't enough of a problem for them to do anything about it.

While I can't do anything about Apple's control design, you'll notice that the collapsed version of action (click to toggle between the two) has a new-and-improved background progress indicator of my own design, which I hope clearly distinguishes between these two states.

2) I'm doing a new backup, to a new archive, of my VMWare Fusion virtual machine file. It's been running for about 42 minutes so far, and backed up about 130 GB, and for the entire time (except for perhaps the first few seconds), the Activity window says "Capturing screenshot_0000.png", which is only a 1.9 MB file. I'm sure it's backed up way more than that, but it just seems a little odd. Is there anything you can do in the new version of QRecall to help with that?

I've looked that this code a lot and don't see why it should be doing that. Having said that, I've recently made performance improvements in the code that updates the activity monitor with the status of the running action; one side effect is, I hope, more timely updating of the actual status. See if the next (post 2.1.0b32) version improves anything.

James Bucanek wrote:While I can't do anything about Apple's control design, you'll notice that the collapsed version of action (click to toggle between the two) has a new-and-improved background progress indicator of my own design, which I hope clearly distinguishes between these two states.

Oops, I didn't really look very hard at that one. The first time I saw the new Activity Window, I immediately decided I wanted more detail, so I clicked on it to bring back the "old" style window. I just now ran a backup of my home directory, hoping to see the new progress indicator in action, but it immediately jumped to about 95% complete, and then stayed there for most of the rest of the time until the backup completed, so I still didn't get a good look at the new indeterminate indicator. I'll keep watching for it.

I've looked that this code a lot and don't see why it should be doing that. Having said that, I've recently made performance improvements in the code that updates the activity monitor with the status of the running action; one side effect is, I hope, more timely updating of the actual status. See if the next (post 2.1.0b32) version improves anything.

At first I thought it might be because I'm backing up a folder that contains only a single enormous file -- the VMware virtual machine file. But that file is actually a package containing many files, only one of which is screenshot_0000.jpg. There are also a bunch of hard drive "chunks" inside the package, and I never saw any of those listed in the Activity Window, but they did get backed up. So I'm not sure what's going on there either.

-- Bruce

Bruce Giles wrote:At first I thought it might be because I'm backing up a folder that contains only a single enormous file -- the VMware virtual machine file. But that file is actually a package containing many files, only one of which is screenshot_0000.jpg.

Ah yes, packages.

This reminded me that I've had a bug report on the books for eons that the file progress doesn't update correctly inside of packages (and I suspect invisible folders).

I started looking into this, and it was like pulling a thread on a sweater; the more I pulled, the more the logic didn't make any sense.

So I rewrote it all today. Here's how it work (in the next beta). This is a little on the experimental side, so I'm looking for feedback.

QRecall no longer reports the progress of individual items inside a directory if that directory is either opaque (package, application, bundle, etc.) or if it is either invisible or inaccessible as a regular user. Instead, it will simply report that it is capturing "Private Folder" or "Adobe Photoshop.app".

Also—and this is the experimental part—it will no longer collect icon or localized display information about these files. The advantage is a (marginal) capture performance improvement. But it also means that if you enable the viewing of invisible items or packages in the archive browser, you won't see pretty icons or localized names for those items.

Finally, if you like this kind of detail there are two new advanced settings: QRMonitorOpaqueFolderProgress and QRMonitorInvisibleFolderProgress. Set them to true to enable the progress reporting of those items (although this doesn't change the display metadata collection).

James Bucanek wrote:This is a little on the experimental side, so I'm looking for feedback.

QRecall no longer reports the progress of individual items inside a directory if that directory is either opaque (package, application, bundle, etc.) or if it is either invisible or inaccessible as a regular user. Instead, it will simply report that it is capturing "Private Folder" or "Adobe Photoshop.app".

Also—and this is the experimental part—it will no longer collect icon or localized display information about these files. The advantage is a (marginal) capture performance improvement. But it also means that if you enable the viewing of invisible items or packages in the archive browser, you won't see pretty icons or localized names for those items.

I'm fine with the package part of this. If a package is large, like a large app or a virtual machine file, I probably already know it's large, and I probably rarely, if ever, see the contents inside the package. So if I see in the activity window that, say, "Windows 10 x64.vmwarevm" is taking a long time to back up, that matches my expectations.

I'm less sure I like that behavior with invisible folders. I may be misunderstanding your intent here, so let me ask a direct question. If I'm backing up my entire hard drive, then am I just going to see "Private Folder" for the entire time while it backs up /bin, /cores, /dev, /etc, /home, /mach, /net, /opt, /private, /sbin, /tmp, /usr, and /var? If that's correct, that would NOT match my expectations. If I saw "Private Folder" listed in the activity window while it did all that, I'd probably be wondering what was wrong.

That said, I'll admit that many users probably have no idea those invisible folders even exist. Maybe most people would be more disturbed at seeing a list of folders go by that they didn't even know they had. Also, I can't recall what the current QRecall actually does with top-level invisible folders, so I don't know if what you're proposing is actually much of a change or not.

Finally, if you like this kind of detail there are two new advanced settings: QRMonitorOpaqueFolderProgress and QRMonitorInvisibleFolderProgress. Set them to true to enable the progress reporting of those items (although this doesn't change the display metadata collection).

Sounds like the new settings will allow me to get exactly what I want (once I figure out what that is. ) I'll definitely have to play with the new settings, and I'll let you know what I think after I've tried it out.

-- Bruce

Bruce Giles wrote:I'm less sure I like that behavior with invisible folders. I may be misunderstanding your intent here, so let me ask a direct question. If I'm backing up my entire hard drive, then am I just going to see "Private Folder" for the entire time while it backs up /bin, /cores, /dev, /etc, /home, /mach, /net, /opt, /private, /sbin, /tmp, /usr, and /var? If that's correct, that would NOT match my expectations. If I saw "Private Folder" listed in the activity window while it did all that, I'd probably be wondering what was wrong.

Let me clarify. The "Private Folder" was just a hypothetical example; the status will display the actual name of whatever invisible or unreadable folder is being captured. When the capture encounters an invisible (/private) or unreadable (/Users/somebodynotyou/Desktop) directory, it will display that directory's name ("private" or "Desktop") until it's finished with that directory subtree.

Now (well, soon) the idea is that the items displayed in the capture progress are whatever you could normally encounter by browsing in the Finder (without using any hacks or special Finder commands like Option+Command+L or "Show Package Contents").

Examples would be a .git folder (all dot named directories are implicitly invisible) and ~/Library, because that folder is explicitly made invisible.

I like this because the default will be to honor the access restrictions for the regular user. So even though your QRecall account might, technically, have permission the access all of the documents for other users, it seems polite not to have those filename flashed on the screen.

Anyway, you're welcome to set QRMonitorInvisibleFolderProgress if you don't like it.