Suggestions based on v0.3

[philippe-hawi]

The new panels look good.

Some suggestions:

1- In the Installed panel, you changed the order of the groups? I suggest reverting to the older sorting (same as FileMeta, i.e. native groups at the top, then non native properties (3rd party) at the bottom

2- In the Saved panel, add some indication to which property is installed (bold face? different color? star?). Also, perhaps add an uninstall option in the context menu. It would be nice to have full install/uninstall control on my custom properties in the Saved panel, since that's where I actually try to control them. I never find myself looking at my properties in the Installed panel.

3- In the Saved panel, if I select property1 and right click on it, then right click on property2, the context menu is still for property1. The selection doesn't move to property2.

4- Clicking on a non-installed saved property in the Saved panel, the save button is available. Clicking on an installed saved property, the save button is grayed out. The only reason for that that I could see is if the save button EDITS a saved non-installed property, correct? However, it only does that if the property name is kept the same and other fields are edited. If the name is edited, it saves it to a new property, which i think it shouldn't, or at least there should be options like "save and replace" and "save to new property". In short, I think that for any non-installed saved property, the user should be able to edit all its info (including name) and also have the option to start with a saved property, make modifications and save to a new property (if the name is changed; if the name is kept the same, the user gets a prompt asking if they want to replace the old property, or keep both by renaming the new one to <oldname_i>).

[Dijji]

In response to your suggestions...

1. I agree with you, insofar as I prefer the original ordering too. However, there are technical reasons for the change. When you install a property, it finds the property in the tree and brings it into view. It turns out that this involves a low-level search of the tree from the top to where you find the item. This is incredibly slow: to search through all 1600 Windows installed properties takes of the order of 10 seconds. Hence the change, putting the custom properties first means the search is always quick.

2. I half agree. I can see the point of being able to tell in the saved tree whether or not the property has been installed, because if it has, then having a signal that you cannot edit it is useful. I'm not sure how visually to make it work, though. Font weight has been used for selection, and italic would look pretty horrible, and how would you know what a star on the end of the name meant? Any more thoughts? I don't think I want to go with uninstall on the context menu, though. It is important to think about the installed properties carefully and separately.

3. Agreed. Will be in the next version.

4. Here, I disagree. I inherit the thinking up from the installed properties. There is no editing them, you can only create or destroy. Once installed, they are immutable. And their name is their primary key. It follows that the saved equivalent must also be immutable until the property is uninstalled. And when it has been, I think that the primary key still needs to be considered as unchangeable, so that if you edit and reinstall you are not fundamentally changing the nature of the property.

I think that this chimes with the general Microsoft guidance on creating custom properties: be careful about their naming, and be parsimonious with changes. This is particularly important if the property is searchable, because the indexing apparatus builds the properties into its internal tables, and you don't have to mess around with them too much before you find yourself having to completely rebuild the index.

[philippe-hawi]

1- I see. Just to understand better, how come in earlier versions, custom properties were last and there wasn't this performance hit?

2- Maybe use colors? Display installed properties in red, and add a note under the title of that panel ("Properties in red are installed")? Or, separate the installed from the non-installed by perhaps splitting the "Saved" panel into 2 parts (or any other way that groups the properties based on whether they are installed or not).

4- I wasn't saying that installed properties should be mutable. Obviously, they shouldn't. I was referring to saved non-installed properties since editing them won't have any effects system-wise. I was just thinking that it could happen that users save a property but decide to change its name. The way to do it now is to change the name, save (to a new property) then delete the old property. It's just a matter of practicality, but I was thinking that as long as the property is not installed yet, editing it (name or other fields) amounts to editing some locally saved file so it shouldn't be any problem. But obviously you know the implications of this better than I do. As it is now, what I'm thinking about can be done with a few more clicks and staying conscious about how the program works, so it's not biggie.
One last note. When you say "... must also be immutable until the property is uninstalled. And when it has been, I think that the primary key still needs to be considered as unchangeable, so that if you edit and reinstall you are not fundamentally changing the nature of the property". I don't think you're really restricting anything but making the name unchangeable. If I currently want to change the name, I would uninstall, edit the name, save to a new property, install the new property. In the case of my suggestion, I would uninstall, edit the name, save and replace, install. Is there any difference between the two methods to the OS?

[Dijji]

1. This did not arise in earlier versions because I did not select the installed property after installation. Instead, to see it, you would have had to manually find it in the installed tree. Now, I am reading back the installed property from the system and displaying the results. This adds an interesting feature. After installation, the differences window will show the differences between the editor and the saved property, which is in most cases none. But if you click the radio button to compare with installed, you will see the differences between the editor and what has been read back from the system after installation, which typically and interestingly is not none.

2. Speaking as someone who does not see colours very well, and particularly red, it won't be red. But maybe blue, to indicate it is frozen.

3. You are exactly right, there is no difference in the end. However, I think I will persist in making you clone and delete a property to change its name just to encourage the right habits of thought. The name is the identity of the property, and not to be changed in the way you might change its other values.

After work for 2. and 3., the main remaining task now seems to be to undertake a review of the properties, making sure that I am harvesting everything I can from the system, and allowing everything important to be edited. Then there is just the drudge work of the help text, and a tweak to reuse Format Ids. I think the next version will be for final testing before I go to 1.0.

Dijji

[philippe-hawi]

Alright, sounds good. Looking forward to the next one.

[Dijji]

Okay, the next release has arrived. I have posted release 0.4 as the first release candidate. Please test as much as you can and report any problems.

[philippe-hawi]

I'll test thoroughly and report back. Might be a few days.

[Dijji]

I have now posted a version 0.5 with a few minor fixes for bugs found in my own testing, as documented in the release notes, to save you finding them again.