Dogfooding 4

There are 4 button on the new toolbar of the Clipboard bar. Three are grouped together to signify that they all show dropdown lists. I should probably change the icons to use standard cues (like arrows), but these icons are currently just place-holders. Each button will trigger a hint tooltip when hovered.

The first quick button is Edit. This triggers the routine that edits the current clip in an associated editor (notepad, paint, wordpad, etc.).

The "Alter Clip" dropdown menu on the is the second unique feature for the Clipboard Bar. It basically executes commands found in a Permanent Clip that edit the contents of the clipboard. The "Make Permanenent" dropdown menu is just another place were you can save a clip to a Permanent Group. The "System Menu" is the odd-ball. It doesn't have anything to do with the clip on the clipboard and is just a utility menu.

---

One feature that I'm using frequently really doesn't fit the purpose of the Clipboard Bar. That feature is the ability to show the popup when clicked. It's, however, too nice a feature to remove so I make this an optional feature.

Dogfooding 3

The current toolbar prototype shown above.

I'm replacing the right-click action so that it toggles the toolbar on the Clipboard Bar. The spirit of the right-click context is still preserved, but it much more flexible than a single popup menu.

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.