The Clipboard Bar

I'm re-thinking the purpose of the Clipboard Bar in ArsClip. Currently, it just shows the current clipboard contents like the old Clipbook Viewer application that used to be part of Windows. I think more people would find it useful if it has some flexibility in functionality.

My problem is that this window could do just about anything. It could show the popup window when hovered or clicked, similar to the Trigger Window. It could be used to drag the current clip to Explorer to save it as a file. It could show a context menu on right-click. It could set the current clipboard contents or edit the current clip. Pretty much any feature the program already performs could be used here as well.

The only thing I'm sure of is that the features would best fit a heavy mouse users. As such, it should be able do the Trigger Window's job - activate the popup menu via mouse. The system tray and the jumplist menus also fits into this usage.

ArsClip Revamp 3

The program is in feature freeze. Only changes will be made to fix any newly discovered bugs.

The changes for v4.12 can be summed up as: performance improvements and improved clip displaying. The performance changes are boring and already mentioned in earlier posts. The clips displaying changes are mainly geared towards making a better representation for Picture, RichText, and HTML Clips.

For Picture Clips, the new feature is smooth scaling. For RichText, the size of the text has been normalized and URLs are easier to read. For HTML Clips, the program will try to also get a copy of the clip in RichText to show on Tooltips.

ArsClip Revamp 2

Using a no-compression ZIP archive for just for reading clip caches was about 8 times slower, but this is probably because of Delphi's implementation. Other programs, like game engines, use uncompressed ZIP archives for loading gigs of data much more efficiently. Writing to the archives would be a bigger issue, so this isn't something that will work well.

Using in-memory compression for large clips was also slower than expected, even though it's still rather fast. The fastest compressing method for a 6MB clip took about 125 milliseconds, but decompression was three times faster. Showing 5 of these large clips on the popup added about 1/4th of a second to the display. While it sounds like nothing and a rare case, it's several times slower than normal. There just aren't any benefits here.

I, also, toyed with storing pictures internally using the PNG format. The results were slower than the compression test above.

There's not much left to test, so the remaining changes will be cleaning up the code and squashing any remaining bugs. Since loading, saving, and displaying clips is a major core feature of the program, this could affect many other parts of the program. This will require more testing than normal.

ArsClip Revamp

In the latest Public Beta uploads of ArsClip, I'm working on the guts of the program. Many of these routines were written a long time ago and were never very efficient. Since clips were small, this wasn't really an issue. They did scale decent enough, so I've never really paid much attention to them. The updates below are designed to improve on scaling and how the program performs on slower systems.

The icon cache was worked on first. A while ago, to help speed up loading, the icons draw next to a clip on the icon were cached so that duplicate versions all used the same file. This routine was updated recently to so that in-memory duplicates all used the bitmap. The speed improvements are very minor on a newer system, but it performs very well on my test virtual machine.

The Remove Clips cache was altered next. Since this cache is designed to grow very large, it resides on disk. This means that each item in the list generates about 4 file reads to be shown on the list. It, also, responded very slowly because of this. In the current version, the very least amount of data is loaded and cached to perform much faster. Also, this list also the icon cache to reduce file usage.

Lastly, the routines used to load and save clips have been updated. On my system, the loading and saving 40 clips took less than 80 milliseconds. Slower system, however, should see more of a benefit.

I've a few ideas for further updates, but nothing that's ready for a beta. First, I'm thinking of using a file archive for storing clips. This means all data would be stored in a single file, which would significantly reduce file overhead. This option would also mean that the Removed Cache could allow for deleting clips. Second, I'm experimenting with using compression for large clips. Unless this option can be made to perform extremely well, it won't be added.

The Wildcard Issue

Wildcard searches, aka subtitutions, in Rename Master are powerful, but very obscure. Older users that are comfortable with a command prompt are familiar with them, but newer computer users don't understand what the asterisk in "*.txt" represents. While I don't think I could do a good job teaching how to use wildcards, I can fix how the program discloses wildcard support.

In the Renaming Script, any text box that is a "search" or a "find" text box supports wildcards. Unfortunately, there was no way to know that. In the current beta upload, I've marked these fields so they stand out. First, color of the text box is different. Second, the insert button was changed to match the icon used on the new Wildcards menu. Third, the "Wildcards" menu is now only enabled for fields that support it. I think this naturally and intuitively exposes where they are supported.

On the Wildcards menu, I've added three examples with descriptions. While technically there are only 2 wildcards (? and *), I added a third example that explains how using both changes the meaning. The concepts are "1 character exactly", "0 or more characters", and "1 or more characters" -- (?, *, and ?* respectively). This abstract concept is anything but natural and intuitive, but I don't think this is an obtainable goal.

As far as back references for simple wildcards, RM does some dirty tricks to optimize wildcards. The expression "*?" and "?*" are technically the same, so expression like "?*?*" are reduced to "??*". This means it's not possible to report the characters that are represented by each wildcard in the current version. Hopefully, the new Find and Edit step is a good substitute.

A New RM Beta

This upload contains the new Find and Edit script mentioned in the post below. Without using Wildcards, this step is almost the same as both the Add Before/After step and the Find and Replace step. I'm unsure how to document this, beside mentioning it on the help script.

Although "smoother visuals" doesn't sound like much of a change, the Renaming Script steps have been reworked for most events: disable, enable, delete, expand, collapse, move, etc. I'm still researching this for improvements.

A New Step

Shown above is what I've created for the new Find and Edit step. While it's no where near as expressive as back referencing, it should be flexible enough to cover common cases.

The first replace/insert option will add text using a position starting from the beginning or ending of the found phrase. This option is designed for targeting a substring with a known position and size.

The second insert options is more dynamic. It will do a nested find and add text or replace text. Like the initial find text field, the secondary find field also supports wildcards.

This should be available in the next Public Beta upload.

Rename Master Musings

Back Referencing

In the regular expression world, there's the idea of back referencing. For example, if you're searching for "30??", where ? represents two unknown characters, you may want to use the unknown characters as an option. For a regular expression, you use parenthesis to group patterns and \1 or $1 to reference the results of the first pattern.

RM tries to not use such obscure ways of performing tasks as "the normal". While RM include regular expressions as an option, it's only for a very specific and small group of users. My job is to come up with a way that's more intuitive. This is one of the reasons "Remove/Replace Expression" was created and "Split and Move". Both steps are simpler ways to do "regular expression"-like functionality, but are still very advanced concepts.

I recently had one user trying to use the simplified wildcards to do back referencing: replacing "30??" with "20??". The first part works, the second part does not. While it seems like a good idea to add this feature, so few users would know about this feature that it doesn't warrant the large amount of work required to support this.

Find and Alter

My idea to support back referencing would be a step specifically designed for this single task. The benefits are simple, it's easy to discover and should be easier to learn. The sacrifice is just as simple, it's not as powerful. For those that need more power, Regular Expressions are still an option -- so it's still balanced.

The problem I'm having is implementing this "simple" task. Currently, you can find a phrase and remove it, replace it, or add text before/after it using existing Renaming Steps. To be able to alter it, you need to specify specific parts of the found phrase. There are a ton of ways to specify the parts: the first/last X characters, the first/last X characters from a set, a specific substring at position X with length Y, starts with-contains-ends-with expressions, and so on.

The step can't implement all possible options, so it needs to address the most important and most common tasks. I think the "index and length" option and the "first/last X characters" would cover a lot of cases. It also may be possible to combine both options into a single options, since starting at index 1 with length 3 would be the same as starting with the first 3 characters. Using a length of zero to represent an insert instead of a replace may be a bit confusing. A second option could be inserting before or after a specific phrase. It may seem redundant, but the ability to find "ABCD" and insert after "AB" is a much more specific operation that a regular Add Before/After routine.

Currently, I don't have enough of a well formed idea to begin experimenting. I'm going to need to think about this problem some more before starting any work.