Based on that, a request was made to possibly add this to the API definition by extending the current function “Add_Pin”. As long time developers will recall, there have always been discussions around the API, and I don’t want to rehash them now! But, we also did say last summer as we worked on the documentation (see http://code.google.c...iki/wbcommonapi ) that:
Given that this is just an extension of an existing API functionality, it seem that this is a good time to propose (and use) a new process.
A process to better manage the API is also under development.
So, here we go…
- Any new functionality should be well documented, and well managed. At this point in time, and after some discussion with a few others, I have agreed to be that “manager”. It is my job to make sure that we keep this “professional” and on target.
- The process we will follow is that anyone who thinks that they have a good idea for the API should fully document it, and review it with me. After we cover the basics, and get the documentation prepared that fully describes the proposed functionality. I will work with a SMALL group of additional people during this process so that it is not just my opinion. The person making the proposal is free to also ask a few others to join that discussion.
- If it passes this hurdle, and is still deemed to be a “good idea”, it will be presented to the entire reboot.pro population for limited discussion – similar to a “Request for Comment or RFC”. At this point in time, we will be looking for any CONSTRUCTIVE comments or questions that need to be clarified, but we expect that if the smaller group has done their job, that it is not a question of it wit will be added to the API or not.
- After a short period of time, the documentation will be added to the API definition pages as a “Draft Standard”. At this point, it’s implementation is optional. This will allow any projects that need to create an implementation the time necessary to do this (although a sample implementation should accompany the RFC. After a suitable timeframe, it will be moved from draft status and become a part of the formal API definition.
This “RFC” will be “open” for the next two weeks. After that, the topic will be locked, and a final “draft definition” will be added to the WIKI. As I said above, we want this to be a professional process, and I intend to keep the discussion on track and focused. I will hide any posts that are inflammatory or that are not considered constructive and relevant this specific API enhancement. If you have something to say about the “process”, take it up with me via PM. As with most things here at reboot.pro, Nuno has final say over anything I do, so if you think I am out of line, feel free to add him to anything you have to say to me in you PM…i.e. leave it out of the general forums!
With that out of the way, we are ready to begin…
Proposal: Enhance the Add_Pin API
Enhance Add_Pin (which is used by PE2/3 projects only) so that it has an additional value for the “Type” of Pin to add - i.e. pin a link to the recently used program area of the start menu.
Note: Pin Adding is a feature of "Windows7 Explorer Shell", and may not be supported in other shells or projects. For details on the current syntax of this function, refer to the documentation on the web at http://code.google.c...er/wiki/add_pin[
The proposed syntax would be
In this case, the “order” (normally the second parameter for other types of pinning) is not important, Building off of the current API definition, the Path would be to a link on the start menu, so it would have “$Start_Menu\Programs\” as the first 21 characters of the path (Note: This can be used to validate if it is a proper path). Finally, the remaining parameters of the current API definitio0n are not applicable, since we are just pinning to an existing shortcut.
Here is an example, pointing at a shortcut that would be created by other existing mechanisims:
As mentioned above, there is more discussion on this process and how it was implemented in the original topic http://reboot.pro/15884/
Thanks to 2aCD for Add_Pin,RecentPrograms, to all the active developers here, and to the small team that helped me bring this forward to the larger community.
Questions / Answers:
- Q: Why not create a separate API entry instead of adding to this one?
A: That was considered, but the functionality and syntax constant (i.e. $Start_Menu) was already established by the Add_Pin command, so it seemed to make the most sense to add it here.
- Q: If recent programs can only be linked over to the “$Start_Menu\Programs\” area, why is it included on every call to the API?
A: This was also considered, and in the future, this may change, so it seem better to be complete, and include a full reference to the target in the API specification.