Jump to content











Photo
- - - - -

Enhance Add_Pin Definition in the API

rfc api

  • This topic is locked This topic is locked
8 replies to this topic

#1 sbaeder

sbaeder

    Gold Member

  • .script developer
  • 1338 posts
  • Location:usa - massachusettes
  •  
    United States

Posted 11 December 2011 - 08:54 PM

A few weeks ago, board member 2aCD figured out how to “Pin” shortcuts to the recently executed programs area of the start menu as discussed in this post http://reboot.pro/15884/

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:

A process to better manage the API is also under development.

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.

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

Add_Pin,RecentPrograms,,<path_to_link>

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:

Add_Pin,RecentPrograms,,$Start_Menu\Programs\Accessories\Notepad.lnk

As mentioned above, there is more discussion on this process and how it was implemented in the original topic http://reboot.pro/15884/



References:
http://www.autoitscr...howtopic=116641
http://reboot.pro/15884/
http://www.autoitscr...ateShortcut.htm
http://www.autoitscr...ctions/Send.htm

Credits:
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.
If there are additional questions or constructive concerns, please post them to this topic. As mentioned above, I expect to lock this topic on 12/25/11 (Merry Christmas :newyear: )

:cheers:
Scott

#2 paraglider

paraglider

    Gold Member

  • .script developer
  • 1729 posts
  • Location:NC,USA
  •  
    United States

Posted 12 December 2011 - 02:51 AM

Don't believe this should be part of add_pin as a pin is permanent whereas recent programs is dynamic and is updated as programs are run.

#3 homes32

homes32

    Gold Member

  • .script developer
  • 1030 posts
  • Location:Minnesota
  •  
    United States

Posted 12 December 2011 - 02:59 AM

I see the point. its really not a "pin"
should it rather be a "folder option" under Add_shortcut?

#4 paraglider

paraglider

    Gold Member

  • .script developer
  • 1729 posts
  • Location:NC,USA
  •  
    United States

Posted 12 December 2011 - 01:02 PM

Its not a pin - it uses a totally different mechanism. Its not a shortcut - again uses a totally different mechanism. A precedent was created with add_pin i.e. a new command for a new feature even though it uses the same taskbar / start menu. I think the same should be true for recent programs - a totally new command should be created.

#5 sbaeder

sbaeder

    Gold Member

  • .script developer
  • 1338 posts
  • Location:usa - massachusettes
  •  
    United States

Posted 12 December 2011 - 03:50 PM

@paraglider

This is a good point, and one we need to consider.

In some ways, even if it uses a different internal mechanism, I see it as a "pin" like operation. It "pins" the link to a start menu item...It just happens to put it into the recent programs area of the start menu. This is similar to the "pin" to the start menu, but gets around some of the limitations of it, since we are "pinning" to a .LNK in the start menu, and not to an actual program that needs to exist, and not on removable media, etc.

And since this is pre-defined, or "pinned" during the creation of the PE, I can see the argument for adding it to the "Add_Pin" API. Yes, it is dynamic, but only after the PE is running, and since it is a PE, running from Ram, it isn't permanent, and on the next boot of the PE, would be back to the original set of "pinned" values. So in a sense, it is permanent INSIDE the PE...

BUT, I can see both sides of the discussion here...i.e. there is some value in making it be just another type of "PIN"...and...there is value in making it be a new API - possibly "Add_Recent". And while we did consider this during the preliminary discussion, you have brought up new points of view on this. (And, done so in a very positive, professional way - so thanks!)

I would like to hear from others as well on this...

:cheers:
Scott

#6 pscEx

pscEx

    Platinum Member

  • Team Reboot
  • 12707 posts
  • Location:Korschenbroich, Germany
  • Interests:What somebody else cannot do.
  •  
    European Union

Posted 12 December 2011 - 04:57 PM

I do not want want to introduce a discussion about pinning in a PE.
For me, my projects are thought to give help in emergencies. For that a simple startmenu construction is sufficient.
Others want to clone the real OS as perfect as possibly, including multimedia etc. Everybody is free to create a project of his own design.

Sorry, because the "Pin" theme did not have (and still does not has) my interest, I made the first look into the according Help some minutes ago, pushed by this topic.

Here I have concerns:
Example "StartMenu" (also valid for QuickLaunch etc.):
We already have two API code words "StartMenu" (full) and "SM" (abbreviated).
What is the reason to introduce $StartMenu?

Just to confuse the user and let him look on every command using <Startmenu> into a table, which code is valid for the current command? :frusty:
More: In parameter #x there is StartMenu. In parameter #y there is $StartMenu. :magic:

Peter

#7 sbaeder

sbaeder

    Gold Member

  • .script developer
  • 1338 posts
  • Location:usa - massachusettes
  •  
    United States

Posted 13 December 2011 - 10:07 PM

Also a good point...Maybe offline, you can send me more info (or I can just go search :) ) on the various places "Start Menu" is referenced, and we can work to fix that as well (i.e. defining the desired way going forward and deprecating the others to allow them to "phase out".

I have not history on why $StartMenu was chosen...And have no real preference over it or "StartMenu"....Not fond of SM too short for "users"...(OK internally if someone just has to use less characters)...

Scott

#8 pscEx

pscEx

    Platinum Member

  • Team Reboot
  • 12707 posts
  • Location:Korschenbroich, Germany
  • Interests:What somebody else cannot do.
  •  
    European Union

Posted 14 December 2011 - 07:48 PM

I have not history on why $StartMenu was chosen...

There is no history!
Make a forums search about "StartMenu" and in the result make a browser search about $StartMenu.

The only appearences of $StartMenu are in this topic! It has never been discussed anywhere in this forum.

I'm (for many 'creative' people) a stupid technician, and therefore my (maybe also) stupid technical conclusion is:

The "$StartMenu" is coming either from the heaven (maybe some angels or alians) or from the hell (maybe some craftsmen like carpenters, shoemakers or bakers).
But it is surelly not a result of some development in this forum!

Logical question: Why in this forum it is in the API documentation / definition?
And: Why should reboot.pro authors implement that external functionality?

Peter

#9 sbaeder

sbaeder

    Gold Member

  • .script developer
  • 1338 posts
  • Location:usa - massachusettes
  •  
    United States

Posted 07 January 2012 - 04:59 PM

OK, Sorry I didn't get back to this sooner, but it's time to close this issue out...

Based on the feedback, which was all positive and constructive (THANKS), it is down to a matter of choice to some extent on those issues. SO, at this time, we are going to move forward and make this a "provisional" part of the API. This means that it SHOULD be added to any API implementation, but developers using it should be aware that it might not be support YET. My current plan is to make it a full part of the API starting in July. This gives those people that need time to implement it in the API used by their project the time to look at the reference implamantation (provided in the WInPE_SE project) and adopt it (or modify it if necessary) into their projects.

The docs will be updated soon (probably later today) and will include recent developments (as posted in the other thread on this listed above) that allow "pinning" recent items to the desktop as well as the start menu.

Again, thanks to all who made comments and worked on this!

:cheers:
Scott

p.s. will lock thread at this point...





Also tagged with one or more of these keywords: rfc, api

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users