I know I said I was giving up on WPF.  Truth is, I keep telling myself "just one more try".  Its still not as fast as the GDI++ version, but I did manage to make the WPF interface go fast enough so that it is at least useable, if not still quite buggy.  I am convinced now that there is just something ridiculous that I am missing, and I will keep harping on it as I have time. 

In other news.  Firefox released Firefox 3 recently, and broke my Firefox Bookmarks plugin because bookmarks are now stored in an sqllite database.  I will be creating FireFoxBookmarks3 to adress this.  Also, there have been some requests for a Winamp "Remote Control" as well as some cooler Outlook functionality than just "Send as File Attachement".  

I also know that the "Priority Manager" screen is broken in Version 2.7. This will be fixed as well, along with a new splash screen and an option to turn it off if you do not like it.

Ive had enough. 

After months of digging into the inner workings of WPF, coding up crazy threading hacks and questionable bit logic trying to figure out why it was so doggedly slow for the litle amount of code I have put into it. I started wondering "am I really this bad of a programmer?"  Ive come to find out that the WPF dispatcher prioritizes  rendering operations higher than keyboard input: the opposite of Windows forms.  Ive also discovered that if you try to push the rendering priority lower than that of the input (you apparantly are not allowed to increase the user input priority) nothing ever renders.

Peachy.

What I was able to create, which looks rather good if you happen to be lucky enough to be running an uber fast computer with a good video card, is an attractive bezel interface with expand and contract animations depending on whether or not you are going to be using the parameters pane.  It also has a nice reflection effect on the icons in the panes.  The problem is, if you are running it on a laptop (even one with 2 gb of RAM) it takes like 300 milliseconds between keypresses to register that a key has been pressed.  Way to slow for an app called "Mercury".  

 I might as well rename it to DOMolasses.

Because of this, the fact that I am not and never wanted to be a UI designer (I like to code things that do things, not code that changes the way things look)  I am posting the WPF code I do have in the repository  (Bezel++) this weekend for someone else to troubleshoot and calling it a wrap.

I have had people submitting very good looking skins lately (Thanks David and tysiva) so I think I am content to let the interface stay as it is for a while.  I was losing a lot of DOMercury momentum dealing with that interface and I really missed programming new functionality into DOMercury.

 To show everybody that I definately have not abandoned DOMercury, I just released the GMail plugin today.  You can check it out on the Plugins Page 

Its pretty neat.  It imports your contacts from GMail and allows you to open Compose Mail windows directly to them from DOMercury.  It does some other stuff of course, like opening a blank compose window, opening to a search of your GMail, or just going to your inbox.  Ive found it very handy in the 4 hours I've been using it already.

 Side note:  Since I dislike writing code for aesthetics, the site redesign has been taking forever as well.  Sorry about that.

-Dominick

Apparantly, the reason my keyboard input was not being registered by my WPF interface prototypes was that I was not calling this function:

Since the main project was built originally on Windows Forms, calling a WPF window means that the keyboard input doesn't properly register with WPF, making text typed into text boxes not appear. Great.

After updating my program manager to include this call, it now takes 300 to 500 ms to register evey keyboard input to the WPF form.  Anyone have a fix for this?  Otherwise I am going to have to remove the call and ghost input for the form.  Other than this, and getting some 3D animations to trigger properly, the new WPF interface is coming along pretty good.  Sorry about making you all wait so long.

I pushed version 2.7 out to release today.  This should clear up A LOT of complaints that people have with DOMercury. 

Because many people had problems with the DOMercuryAliases.xml being corrupt, I would advise people that had this problem to uninstall DOMercury and delete the DOMercuryAliases.xml before installing DOMercury 2.7  Deleting the corrupt DOMercuryAliases.xml is important. 

Here is a quick recap of the new features of 2.7:

• Eliminated re-indexing time period where plugin items do not show up in index and priorities are not set

Up until 2.7, DOMercury had the problem where, every once in a while, DOMercury would lose its skin and priorities or plugin items.  This has been fixed.  Priorities will no longer reset, and your clipboard item you need to manage all those code snippets will no longer mysteriously dissapear.

• Edited Priority Scheme so smaller file names have a higher priority

This one was an idea from someone else that I am angry with myself that I did not think of before.  Basically, for every 4 characters in an Item's name, its priority is automatically reduced by one.  This means that items with small file names (such as Paint, or iTunes) will not get taken over by loads of files with longer file names at the same priority.  This was a big problem with SmartSearch, as longer file names have the ability to match more search patterns that smaller ones do.  Now that DOMercury returns the smaller result first (unless priorities get changed manually or with extensive use) this will no longer be a problem.

• Changed ParametersProvider to supply IItems rather than objects

This only matters to Plugin developers (all 3 of us at the moment) Before, the ParamersProvider would return a list of objects, now it returns a list of IItems.

• Created two new interfaces: IDOMercury and IDOMercuryUserInterface for plugin interface extensibility

DOMercury's functonality is not the only thing that is plugin extensible anymore!  Now User Interfaces are as well.  A user interface in can be made for DOMercury using any .NET technology.  As you probably know if you are reading this far, I am (slowly) creating a WPF version of the DOMercury Interface.  After I get the hang of it, more will follow.

• Changed Options Form to accomodate multiple interfaces

This has to do with the above.  Now any options that have to do with specific interfaces will be handled by clicking the "Display Options" button in the Options Form.  This is currenlty where you will now go to change your skin.  Where the Skins tab used to be, there is now a new Tab called Interfaces, where you will be able to choose your DOMercury Interface.

• Added an EngineCore Interface to the DOMercuryInterfaces dll, the potential power of plugins has just increased drastically!

This again only pertains to developers, but it is a BIG deal if you happen to be interested in programming plugins for DOMercury.  Before you used to only be able to give DOMercury Items and actions.  Now, with the EngineCore methods exposed, You have access to functions that affect the state of the DOMercury Engine, such as setting sub indexes, retrieving Items form DOMercury's current index or main index, reactivating the DOMercury form, and so on.  This sounds both awesome, but a little scary as well, as a badly written plugin could potentially cripple DOMercury.  It will be known, however, that any plugins posted on the official Plugins page will have had its code specifically reviewed by me, and will be safe for your download and use.

I have some good news and some bad news.

The good news is that there will be a new release of DOMercury within the next few days.

The bad news is that it will not be 3.0, it will be 2.7

 What does this mean?

 The increased priority handling implemented by me, andthe quicker search results implemented by Tao Klerks will be available.  Tao did some sweet code to the searching engine which allows you to drop the search delay down to 100ms or lower without any lag (amazing!)  This will be a big increase in your ability to peruse objects in DOMercury.

 For plugin developers, the DOMercury.EngineCore.Interface class will be there to "supercharge" the functionality that plugins can do.  And documentation should be up soon for that as well.

 What 2.7 will not contain is the DOMercury WPF interface I have been fighting with.  It is not that WPF is all that difficult, rather the problem is that I am trying to build a masterpiece sculpture after just coming out of "Carving 101".  And I am doing it on maybe 3 or 4 hours of free time a week.  Ive been doing alot more training and competing (if you like Judo then check out some of my matches on youtube:  search for "msoe judo dom") and of course spring cleaning the house and such.

However the installer has been broken for way to long, and loyal users of DOMercury deserve the performance improvements that have been coded for over a month.  So I am going to devote my free time over the next couple of days to rebuilding the installer code that I lost and releasing DOMercury 2.7

DOMercury 3.0 development has not stopped, but it may be another month or so before you see a shiny new WPF interface over DOMercury.  Sorry.

Back from my vacation (which was nice by the way), back to work, and of course, back to DOMercury development. 

DOMercury 3.0 is well into development.  Here are a number of updates and new features you can expect from 3.0:

Fixes:

• Reindexing will be fixed.  You no longer temporarily lose priorities or items during reindex.
• Items with smaller names will now have a higher priority than items with longer file names.  This has turned out to be a drastic improvement to DOMercury's searching ability.  Its never been easier to find items.
• DOMercury's plugin extensibility now extends to User Interfaces, meaning anyone with .NET programming experience can make thier own front end for DOMercury!
• Speaking of plugins, an interface to DOMercury's Engine Core functionality is now provided in the DOMercuryInterfaces dll.  The potential power of plugins will be drastically increased over what it already was.
• Also on a minor plugins functionality note, the IParametersProvider interface will now provide IItems as well.
• The WPF interface that will be provided with DOMercury 3.0 is starting to take shape. It has cool animations, Reflection effects, 3D effects, and all the other eye candy you could ask for, while staying simple and attractive.

Besides the WPF interface, everything else is already coded and tested in development without issue.

 Look forward to the new DOMercury 3.0 soon!

 -Dominick

P.S. People besides me have started writing plugins for DOMercury now.  I will start uploading them to the Plugins Page in the near future.

If there are any other multicultural temporary fixes that you have discovered, please post them in the forums.

Lastly, I am going to be on vacation next week, so while there are a lot of cool things down the pipeline, they may not be released for a while, as even though programming DOMercury is a hobby for me, it is not one I will be able to take with me on vacation.  I will have too much vacationing to do next week for me to be programming.  So Enjoy DOMercury 2.6 at the moment, but the next version will be even sweeter.

Dominick

You may have already noticed the forums are different.  You have also obviously noticed that a blog exists now. These are the first steps in the major redesign of the DOMercury web site. It is going to look very different, hopefully very soon. 

Also, I am toying with WPF.  The ability to make different skins does not seem interesting enough to many people, who want for more bells and whistles whilst using DOMercury.  There may be a 3.0 release in the near future with DOMercury itself looking radically different.

-Dom 

 I released DOMercury 2.6 this evening, along with a pile of other updates. (3 new plugins)

Why should you upgrade to 2.6?  I'll give you a few big reasons, and then a pile of smaller ones.

First is the index filtering.  Every time I wanted to search for a word document I had to deal with four or five "temp" files that were at the top of the list (the ones that start out with a ~/whatever).  Also if I was looking for a Visual Studio Solution file, I didn't need all the individual .cs, .h, .cpp, .dll etc.  that would show up in the index.  I figured if they were annoying me, they have got to be annoying you guys too.  So I built in the Index Filtering functionality: Options -> Index Filters, which allows you to add file extensions for files that you want to exclude from being indexed.  SImple as that.  Its a great way to prune the index and help you get to the programs and files you want to get to faster.  

 Speaking of the Options form, did I mention that DOMercury no longer freezes if you invoke it while its Options form is displayed?

 Ctrl + T:  You guys are going to love this.  It forces whatever you are typing to text.  Not only will it make it easier for you to run command prompt commands (ipconfig, ping 127.0.0.1, etc) but it will make interacting with the Window Desktop Search plugin (mentioned below) oh so much more fun. 

DOMercury now lets you know when it is digging for a sub index.  This is nice, especially for plugins that interact with the web (Todoist, Voo2do) and plugins that must search your hard drive (see below) 

I made some changes to the Plugins screen in the Options Form, so hopefully modifying plugin options will be easier to do now.  A lot of people had told me that they didn't even know advanced functionality options (Such as the FolderIndexor Plugin) existed because it was buried so deep within the Options Form.  I tried to make it easier to understand.

Append to text file:  Manage your own todo list?  its made even easier now with the Append to Text File action that exists on text files and csv files.

New Folder action allows you to create a new folder within a selected folder as well.

Now for the plugins:

Windows Desktop Search Plugin:  I'm real excited about this one.  It has already served me greatly and I've only had it working for about 2 days now.  What it does is it puts a sub index on a text item (which you can create easier with the Ctrl + T keystroke) which gives you back Windows Desktop Search Results based on a search done on the text entered.  You can then perform any DOMercury actions on any of the WDS results.  This is great for finding specific folders to dive into, or sets of solution files or code files.  If my description was hard to understand, you'll have to see the video in the Videos Section.

 Clipboard Plugin BETA:

The clipboard plugin is another plugin that I have come to love for its usefulness.  It keeps a history of all text you copy to the clipboard, and you can call up the "Clipboard" item in DOMercury, select a clip in the history, and make it the current clip on the clipboard.  It is great for code snippets or multiple pieces of text you have to copy from one place to another.

This is the first time I've ever released a Beta plugin, and the clipboard plugin has some issues, but its usefulness is too great to hold back. 

For Vista Users:
    Download this plugin and use it! IIn Vista, this plugin works just fine. 

For WIndows XP users:  
    This plugin has some issues in XP however.  It functionally works fine in Windows XP, but the Clipboard plugin slowly steals memory as it runs.  This needs to be fixed for it to become stable for users on Windows XP.  My tests on XP show that it works for about 2 days before DOMercury needs to be restarted to save your system performance.  If you never leave DOMercury running for more than a few hours or so, you may have no trouble with this plugin, but if you are someone who leaves your computer running for days, you may want to wait until it becomes more stable for XP users.

iTunes Plugin BETA:
    People have been asking for an iTunes plugin for a while.  Well here it is!... mostly.  You can call up the "iTunes Controller" to Play, Pause iTunes, move to the next or previous track, or even display current track information.  You can also dive into the iTunes Controller and peruse albums or artists, play them, or play specific tracks.

Why Beta:  For some reason, if iTunes is not open while DOMercury starts up with this plugin, iTunes gets opened.  Also, the album art is finicky on whether or not it wants to appear.  These are annoyances, not complete failures, so I am releasing the plugin as Beta for Early Adopters and those who want to view and modify the source.

As you may or may not have noticed, the phpBB forums no longer exist.  They were especially suseptible to spam, and I really couldn't do alot with them except manage some forums.  I just made the switch to Community Server.  The DOMercury site is under redesign now, and by teh end of this weekend I should have released a few new plugins ( iTunes BETA, Clipboard BETA, and Windows Desktop Search.)  WIth any luck DOMercury 2.6 will be out soon.  Ive been playing with WPF, trying to get over my glaring weekness of making "ugly as sin" front ends, and I'm really enjoying playing around with Expression Blend, so there may be a .NET 3.5 version of DOMercury released.  I am also toying with the idea of releasing the engine-behind as its own separate assembly, so people can make interfaces with basically unrestricted opportunities.  Look for lots of updates in the next few weeks, Ive been putting my time into DOMercury lately...