#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