jv16's development blog

jv16

Alrighty, this is my personal development blog relating to the upcoming jv16 PowerTools 2010. I will be updating to this thread my day to day work with the new version (and with PT 2009 in a case some updates are still needed to it).

So what is jv16 PowerTools 2010 all about?

The main design goal is to make the product robust and smart. In English this means improvements to make everything work smarter, and safer.

Here is the list of the main improvements to be included in PT 2010:

1. The listing components will be uniformed. PowerTools 2009 uses 4 different types of lists to output its results to the user. This means there must also be 4 different pieces of code for handling the lists (Saving to file, printing, searching, selecting etc), and this is basically stupid and causes extra work and unneeded complexity. In PowerTools 2010, there will only be one list component, a custom component currently used in PT 2009's Registry Cleaner (structured view). This improvement also means, that the top panel of Registry Cleaner with all its features will also be available in other tools.

2. The program will be split to two user interfaces. There will be the basic user interface and the advanced user interface, the latter meaning basically the user interface of PowerTools 2009 and the first one meaning a more simplified user interface with less features and options. For example, when you start the Registry Cleaner, the basic user interface will only have probably the tabs "Engine settings", "Advanced options", "Search words" and "Ignore words" while the advanced user interface will show all the tabs currently in PT 2009.

3. A new section will be added to the main window's user interface, this will work as the "command center" of the application, allowing users to perform the most common tasks.

4. The Registry Cleaner engine will be updated to the 6th generation. The main differences being that the new version will be faster (hopefully a lot!) and safer. The entire engine will be re-designed to ensure that all parts of the engine are backed up with a redundancy system. This means that even if the engine would have a bug, the design will make sure that any single bug anywhere in the engine will not cause the engine to produce false positives.

5. A new registry access component that we hope will make all the registry features of the program faster.

6. One new tool. I can't yet tell you what the tool is about, but it is something that has been requested from us by our users since day one. Before we didn't want to implement it because it is a major undertaking, but we started its development before PowerTools 2009 and now it will be ready for PowerTools 2010.

jv16

My main task of today is to work with the new Registry Cleaner engine, it will be a major update and will require a lot of my time.

With PowerTools 2009 the engine consisted of two main components that did everything, and with the final analysis of the results being done within the GUI code. Not very elegant, but I didn't have time for a complete re-design earlier.

With PowerTools 2010 the engine consists of six main components, each one performing only one specific task but doing that very well. While this re-design will slow things down, I'm confident that the improved registry access component will balance everything out and hopefully make the new engine to work faster as the old one.

jv16

I had some connection problems so I was offline for two days. But I was able to work without any Internet access, this is what I did:

On monday I worked with the re-design of the Registry Cleaner engine. I usually prefer Bottom-Up design philosophy and that's what I have been using with this project as well. I have about 80% of all the new components done already, next I will have to create the remaining few components and put everything together. That's the easy part. The difficult part is to fine tune everything and test everything works.

But I also prefer not to work on a same thing for too long. So, on Tuesday I switched over to work on the uniforming of the program's result lists. This means a lot of work but the result will be more simple, use less code and easier to maintain. And better for the user to use as well.

jv16

Today was a long day at the office, 11 hours to be exact.

And I did get things rolling quite well, here is a preview of what the uniforming of the results list means in practice:screenshot_filetool.jpg

I find it looks rather nice! I'll still need to add the Top Panel (similar to the current Registry Cleaner that allows you to see the information of the currently highlighted item). The Top Panel is also now a component of its own, in PT 2009 the Top Panels were all implemented separately which ment overlapping work.

tullik

While you are delving into other tool results list redesign, here are some prior suggestions for your consideration:

File tools

http://www.macecraft.com/phpBB3/viewtopic.php?p=15599#p15599

http://www.macecraft.com/phpBB3/viewtopic.php?p=3666#p3666

http://www.macecraft.com/phpBB3/viewtopic.php?f=21&t=3818&p=20175&hilit=file+extension#p20175

Backup Tool:

http://www.macecraft.com/phpBB3/viewtopic.php?p=15370#p15370

New suggestion for the new lists -- show/hide categories:

Plusses:
*** Registry Cleaner -- completely eliminates the need for the "Raw list." Users who prefer that type list would simply chose "Hide categories" as the default.

*** All lists -- some analytical uses require viewing the results with different column sorts. Categories are not needed for all such uses. A "Hide categories" option in the menu would allow analysis across categories.

pjc

Are you going to include a Full Registry BackUp/Restore Tool?

jv16

pjc wrote
Are you going to include a Full Registry BackUp/Restore Tool?

No, because I do not think it's needed. Mainly because such feature ships with every Windows nowdays, namely the System Restore. Secondly, implementing just a full registry backup can be dangerous.

How on earth a backup feature could be dangerous one might ask. Well, think about the following scenario: An user takes a full registry backup, after a few days he makes some changes to the system such as installs new software to try it out. But something goes wrong and he decides to restore the full registry backup he made a few days earlier. But after that, the system has been changed (i.e. filesystem) but now the registry is back to original. Because a full registry backup does not also restore the previous state of the system, in a worst case scenario the user ends up with Windows that no longer start. Only because he used a full registry backup and restore instead of System Restore.

And thirdly, if you really really want to use full registry backup and restore, there already is a good freeware tool that can do it. Three reasons for me not to implement one.

pjc

"if you really really want to use full registry backup and restore,

there already is a good freeware tool that can do it."

What's the freeware tool?

ERUNT ???

http://www.larshederer.homepage.t-online.de/erunt/

jv16

pjc wrote
"if you really really want to use full registry backup and restore,

there already is a good freeware tool that can do it."

What's the freeware tool?

ERUNT ???

http://www.larshederer.homepage.t-online.de/erunt/http://www.larshederer.homepage.t-online.de/erunt/

Yes, that's it.

jv16

tullik wrote
While you are delving into other tool results list redesign, here are some prior suggestions for your consideration:

All of these are excellent ideas, I'll do my best to get as many of these included to PT 2010 as possible.

jv16

Today I worked on updating the Registry Tool, the Registry Tool is a generic tool that lists the results of most registry tools of the program, such as the results of the Registry Finder and Registry Monitor.

Things are moving along nicely, I'm hoping to get the first versions of the program ready for in-house later in this month and start the beta testing in next month.

jv16

After a half day of more work the Registry Tool is also now converted to the new uniformed result list. This is how it looks with the Registry Finder:

reg_finder.jpg

These screenshots still lack many features, such as the Top Panel. It's still way too buggy to be shown (graphical problems), a fixed version should be available for me in next week. I will have to think about the grouping aspect, perhaps I should let the user to decide whether the grouping should happen e.g. based on the root key, the full registry key or not at all.

I think I had it with the uniforming for now, as I said I don't like to work on the exact same thing for too long because that tends to slow down my momentum. So I will be moving to work with the new very exciting new component that I am hoping to give the PT 2010 a major performance boost over any previous versions. The component is a new registry access component that should be able to give a really nice performance gain to all the registry accessing features of PowerTools.

I'm hoping to give you some early reports of the performance gain later today.

tullik

jv16 wrote
... I will have to think about the grouping aspect, perhaps I should let the user to decide whether the grouping should happen e.g. based on the root key, the full registry key or not at all. ...

For the Registry Finder, I think "not at all" makes sense most of the time.

I can think of case where a particular grouping could be very useful. Namely, group by the GUID when present in the search hits, whether it occurs in the key, the entry name, or the data.

That would be quite a challenge. For example::

Sometimes it's enclosed by braces ( { } ), sometimes it's not.

Sometimes it contains hyphens, sometimes it doesn't.

And what if the data contains a table of GUIDs?

And what if there are two or more different GUIDs in the key/name/data?

jv16

I was naughty and worked during the weekend, I couldn't help myself but I wanted to see if the new registry access was going to give any speed advantage.

Now I know. Oh boy is it fast! With a very rough first version I am able to search the entire HKEY_CURRENT_USER root with any search word (searching in key names, registry entries and the values of the entries) in about 1 second, with PowerTools 2009 this takes 8 seconds in my computer. I can't wait to get some more testing done and see what this puppy can really do 8)

jv16

Today morning I continued my work on the improved registry access component and it's pretty much done now, some minor fine tuning and it will be ready for prime time. And it's very, very fast! After I plug it in to PowerTools I can say for sure how fast, but I'm hoping to cut down the time of a registry scan with the Registry Cleaner to half.

Rest of the day I worked on uniforming the result lists, a few more tools are now converted. Many more to go. I'll continue this tomorrow, my goal is to have all the tools converted to the new result list in this week.

jv16

tullik wrote

I can think of case where a particular grouping could be very useful. Namely, group by the GUID when present in the search hits, whether it occurs in the key, the entry name, or the data.

...

And what if the data contains a table of GUIDs?

And what if there are two or more different GUIDs in the key/name/data?

This is an interesting idea but I'm afraid it would be impossible to implement due to the issues you also mention. I will add an option to each tool for the user to select the grouping method.

Today I worked on the uniforming the result lists the morning. Registry Finder, Registry Monitor, Registry Compactor, Registry Cleaner, File Finder, File Cleaner and Duplicate File Finder now all use the very same component to list the results and Directory Finder and Directory Tool are underway.

The process of converting all the tools to use the same list component is rather easy because the new custom developed list component is so well designed and handy to use. It's easy, but it still takes quite a lot of work. But it is well worth it, not only is the new better for the user, it will also be so much easier to develop and maintain. All the related features, like printing, saving to file or searching from the list use the very same code. If it works with one tool, it should work with every other tool as well.

Per user feedback, the custom list component has itself been developed further. A greatly requested feature of being able to resize the columns by double clicking the space between columns has now been implemented. Other new features include the ability to resize also the last list column.

I'm hoping to post some new screenshots later today. Stay tuned.

tullik

jv16 wrote
tullik wrote

I can think of case where a particular grouping could be very useful. Namely, group by the GUID when present in the search hits, whether it occurs in ...

This is an interesting idea but I'm afraid it would be impossible to implement due to the issues you also mention. I will add an option to each tool for the user to select the grouping method. ...

I trust "no grouping" will be one of the options ...

And the GUID grouping idea is essentially a "Bill of Material/Where used" problem. I'm afraid the registry does not have the database discipline required to allow such software to work well even if it were written.

... Today I worked on the uniforming the result lists the morning. Registry Finder, Registry Monitor, Registry Compactor, Registry Cleaner, File Finder, File Cleaner and Duplicate File Finder now all use the very same component to list the results and Directory Finder and Directory Tool are underway. ...

A dynamic regrouping choice capability is implied (I think ...), if the File Tool and Directory Tool are part of this. Is that correct? If so, will it be there for all the tools with the list components?

... Per user feedback, the custom list component has itself been developed further. A greatly requested feature of being able to resize the columns by double clicking the space between columns has now been implemented. Other new features include the ability to resize also the last list column. ...

Great!

jv16

tullik wrote

I trust "no grouping" will be one of the options ...

Of course. Especially since the whole concept of grouping the results doesn't fit very well with certain tools, the Registry Compactor for example. I cannot think of any point in grouping the results. Therefore the "no grouping" will be the only option available for this tool.

tullik wrote

A dynamic regrouping choice capability is implied (I think ...), if the File Tool and Directory Tool are part of this. Is that correct? If so, will it be there for all the tools with the list components?

I wasn't mean to imply that but it might be a good idea.

I promised screenshots and here's one: the new Directory Finder

dirfinder.jpg

As we can see, the grouping is rather handy here. If you are searching data from many hard disk drives it's very logical to group the results based on the disk drive letter as well. At the top you can see the new Top Panel component, still some funky graphic errors (incorrect fonts on some strings) but my collegue is working on that. If I would press down the ctrl key and move the mouse cursor over the Directory field of the Top Panel I could launch Windows Explorer to the directory in question, or to any of its sub-directories (i.e. only F:\ in this case).

The entire Top Panel is 100% dynamic. Meaning that it will work automatically with any set of columns and with any tool, without me having to write a single line of new code. And any improvements made to e.g. Registry Cleaner's Top Panel will automatically become available with all the other tools as well. One thing that is still missing is a small button from the top right corner of the Top Panel that allows you to collapse and expand it, in case you don't want to see the panel in some tools.

tullik

jv16 wrote
tullik wrote ... A dynamic regrouping choice capability is implied (I think ...), if the File Tool and Directory Tool are part of this. Is that correct? If so, will it be there for all the tools with the list components?

I wasn't mean to imply that but it might be a good idea. ...

Since those tools don't have "preference saving" capability, I was assuming the grouping would be specified from some sort of menu in the list.

jv16

tullik wrote
jv16 wrote
tullik wrote ... A dynamic regrouping choice capability is implied (I think ...), if the File Tool and Directory Tool are part of this. Is that correct? If so, will it be there for all the tools with the list components?

I wasn't mean to imply that but it might be a good idea. ...

Since those tools don't have "preference saving" capability, I was assuming the grouping would be specified from some sort of menu in the list.

Good point, I'll have to think about it.