ui_init modifications patch for macports.tcl

[armahg@…]

This patch is to allow users of the MacPorts Tcl API to redefine the default ui_init procedure found in macports.tcl. MacPorts.Framework needs this capability for its redefinition of ui_init which enables the sending of NSNotifications to clients of the framework in parallel with ui_$priority messages during port activity.

[armahg@…]

Patch for macports.tcl

[kballard (Lily Ballard)]

This patch is intended to facilitate the MacPorts Framework sending notifications, such as in init.tcl​. However, this is the wrong approach. It is a bad idea to send all the console messages as distributed notifications, especially since the clients really only care about things like invoking targets. As such, I am recommending not applying this patch unless a more benign use is found. The MacPorts Framework really ought to add status tracing to MacPorts itself and simply have it be a noop when the framework is not the client.

[raimue (Rainer Müller)]

These status messages could also be used in port(1) to set the Terminal title. Not only the Framework would benefit from such notifications.

[armahg@…]

Replying to eridius@macports.org:

This patch is intended to facilitate the MacPorts Framework sending notifications, such as in init.tcl​. However, this is the wrong approach. It is a bad idea to send all the console messages as distributed notifications, especially since the clients really only care about things like invoking targets. As such, I am recommending not applying this patch unless a more benign use is found. The MacPorts Framework really ought to add status tracing to MacPorts itself and simply have it be a noop when the framework is not the client.

I agree to some extent. Instead of sending all console messages as distributed NSNotifications, how about sending notifications for only ui_error and ui_msg (or at the very least ui_error) console messages? I think we should be able to use trace to notify for port activities like upgrade/installation/uninstallation of port foo has started/stopped. When something goes wrong however, we still need the ui_error message. We can narrow down to ui_error and ui_msg console messages only for those MacPorts API procedures that the Framework uses. What do people think of that idea? Also, any idea as to how to go about tweaking things so that the new ui_$priority methods are invoked only in procedures that the Framework uses?

[rhwood@…]

Please note that this patch does not allow notifications to be sent from the MacPorts API. All it does is allow an implementer of the MacPorts API to specify a ui_init function that would allow that implementer to override the default ui_$priority functions in much the same way that an implementer of the API can override the default ui_prefix and ui_channels functions.

[armahg@…]

Hi again, I am wondering if this patch can now be applied? At least one dev has been playing around with the Framework so far and I would like them to be using the most up to date version (which requires MacPorts compiled with this patch).

In response to earlier concerns:

• Notifications from ui_$priority are now local notifications instead of distributed notifications.
• I am adding some code to allow clients of the framework to be able to tell which Framework methods are responsible for the various notifications. That way they can choose if and when to respond to the various notifications based on the method responsible for sending them.
• The code is still in the works. Some possible modifications I am thinking of adding are:
  • More notifications flexibility on the Obj-C side of things so that notifications are sent only for a group of client predefined methods.
  • More notifications granularity so that a framework client can choose to only listen to for example an MP_configure_Msg_Notification as opposed to just any Msg notification.

Finally, as Randall pointed out, this patch only allows for the redefinition of ui_init and does not necessarily send notifications. Please let me know if there are any more concerns with this patch.

Thanks.

[rhwood@…]

In r38506