Dogfooding 2

In the latest beta, I've added drop support to the Clipboard Bar. This is first unique feature of the Clipboard Bar, the ability to quickly paste the contents of a file to the clipboard. The supported files type list is currently rather limited, but that can be changed if there's interest.

I had an idea for expanding the usage of the Clipboard Bar, but I've not got passed the design phase. The idea is to dynamically add to the interface as needed. In this case, when the bar is hovered or maybe clicked, a small horizontal toolbar with small buttons would appear. This still keeps the goal of a minimal and compact window, but allows for more functionality.

What I'm currently stuck on is what functions to place on this new toolbar. The obvious choices are things to do with the current clipboard - similar to the Clip Menu. The secondary choices would be utility features, like showing the popup or system tray menu.

Dogfooding

I normally don't show the bar on my system, so I'm dogfooding the Clipboard Bar for ideas. In the latest Public Beta, I'm testing out drag support (as requested by a user).

Dragging fits under the pattern of a heavy mouse user. Unlike right-clicking in a program and selecting paste, the drag can be performed almost mindlessly. There's no mental navigation of a list of items required. The action is more like a gesture and fits well in a touch-screen scenario.

The problem with drag is it's an advanced feature and less commonly used in Windows. One major issue with Windows is that there's usually no visual cue to let you know that something can be dragged. The only thing I could think of was to show a tooltip that just says "Click - Right Click - Drag".

Drag results in one of two results. The target program still decides what to do with the clip, but the usual result is the clip is pasted. The second result is to create a new file in an Explorer type program. Drag and Drop is very similar to how the clipboard works. The target program looks at a list of formats and picks the format that it wants or supports.

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.