#15913: ui_init modifications patch for macports.tcl ----------------------------------+----------------------------------------- Reporter: armahg@macports.org | Owner: macports-tickets@lists.macosforge.org Type: enhancement | Status: new Priority: Normal | Milestone: MacPorts base enhancements Component: base | Version: 1.6.0 Resolution: | Keywords: ----------------------------------+----------------------------------------- Comment (by eridius@macports.org): This patch is intended to facilitate the !MacPorts Framework sending notifications, such as in [source:branches/gsoc08-framework/MacPorts_Framework/init.tcl#38132#L76 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. -- Ticket URL: <http://trac.macports.org/ticket/15913#comment:1> MacPorts <http://www.macports.org/> Ports system for Mac OS

#15913: ui_init modifications patch for macports.tcl ----------------------------------+----------------------------------------- Reporter: armahg@macports.org | Owner: macports-tickets@lists.macosforge.org Type: enhancement | Status: new Priority: Normal | Milestone: MacPorts base enhancements Component: base | Version: 1.6.0 Resolution: | Keywords: ----------------------------------+----------------------------------------- Changes (by armahg@macports.org): * cc: rhwood@macports.org (added) Comment: Replying to [comment:1 eridius@macports.org]:

This patch is intended to facilitate the !MacPorts Framework sending notifications, such as in [source:branches/gsoc08-framework/MacPorts_Framework/init.tcl#38132#L76 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? -- Ticket URL: <http://trac.macports.org/ticket/15913#comment:3> MacPorts <http://www.macports.org/> Ports system for Mac OS

#15913: ui_init modifications patch for macports.tcl ----------------------------------+----------------------------------------- Reporter: armahg@macports.org | Owner: macports-tickets@lists.macosforge.org Type: enhancement | Status: new Priority: Normal | Milestone: MacPorts base enhancements Component: base | Version: 1.6.0 Resolution: | Keywords: ----------------------------------+----------------------------------------- Comment (by armahg@macports.org): 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. -- Ticket URL: <http://trac.macports.org/ticket/15913#comment:5> MacPorts <http://www.macports.org/> Ports system for Mac OS

#15913: ui_init modifications patch for macports.tcl ----------------------------------+----------------------------------------- Reporter: armahg@… | Owner: macports-tickets@… Type: enhancement | Status: closed Priority: Normal | Milestone: MacPorts 1.7.0 Component: base | Version: 1.6.0 Resolution: fixed | Keywords: Port: | ----------------------------------+----------------------------------------- Changes (by jmr@…): * milestone: MacPorts Future => MacPorts 1.7.0 -- Ticket URL: <http://trac.macports.org/ticket/15913#comment:7> MacPorts <http://www.macports.org/> Ports system for Mac OS