Review exported API and decide about labeling, strategy

[rcoreilly]

Everyone agrees we need to minimize the API -- use consistent names, remove things that don't need to be there. If the API is as small as possible, everyone is happy.

Randy favors adding an [API] label at start of method, field comments for key user-facing api.

The core Widget interface API has to be there, but users don't generally interact with that -- could label it too?

In any case, need further discussion and firm decisions prior to V2.

[kkoreilly]

Furthermore, we need to decide on our approach to chaining setters: should they be generated for low frequency things, should base widget things like Style, On, and SetCustomContextMenu be generated for every widget, etc.

[kkoreilly]

Also, we might want to consider reducing stuttering in some of our APIs (styles.Style, events.Event, SetAbilities(true, abilities.Hoverable), etc.

[kkoreilly]

We also need to make sure we clean up all of the old code like Props and other commented out things before v2.

[kkoreilly]

We have taken major steps toward cleaning up the API through PRs such as #971, #975 and #976. Also, we have decided to only generate setters for the proximate node/widget type, not all embedders, which also helps clean up the API. Moreover, we have decided to take a much more aggressive approach to unexporting things, which has resulted in various things being unexported so far. We need to continue this work with more unexporting and cleanup before the v1 release.

[kkoreilly]

I have finished API cleanup for packages core and texteditor (not including sub-packages). I will do filetree and plotcore, and then we will be done with API cleanup for the initial release. We will do API cleanup for all packages before the v1 release.

[kkoreilly]

I finished API cleanup for core, filetree, htmlcore, plotcore, texteditor, and all packages and sub-packages alphabetically before core. That is sufficient for the initial release, and I will do API cleanup of the remaining packages before the v1 release.

Just to be clear, we are not using some idiosyncratic labeling method as @rcoreilly proposed above; we are just only exporting things that need to be exported.