On 26. Jul 2007, at 10:01, Hans-Jörg Bibiko wrote:
[...] What do you mean with "... I probably won’t work much on tm_dialog until Leopard"? Will be there a change for tm_dialog in TM 2.0?
Well, Leopard has a spiffy new interface builder and lots of Cocoa improvements, so it would be strange if it did not at least receive an update :)
[...] tm_dialog -f
Just a general thought, not directly related to your request, but IMO tm_dialog is started to get too complex with respect to arguments, and we have already sort of gathered some legacy stuff ;)
Maybe we should rethink the argument format before adding more. E.g. switch to a system like “tm_dialog «action» «arguments»” so the action is the namespace specifier for the arguments.
I’d also like to change the convention related to the plist returned -- returning the full model isn’t useful when binding arguments to the action button. But maybe a better idea is to write a new shell command with a much cleaner API and still just provide tm_dialog as-is for backwards compatibility -- if this is done, it might be one of those things which is best done when making a major version change.
I see. The OPTIONS -cnmqaltxw are really options for tm_dialog displaying a nib. Then I understood your suggestion in that way:
tm_dialogAPI ShowAlert {paramsAsPLIST:=title, message, style} tm_dialogAPI ShowMenu {paramsAsPLIST:=items} tm_dialogAPI OPTIONS ShowNib {paramsAsPLIST:=nibFile, defaults} if nibFile=OpenPanel then {paramsAsPLIST:=nibFile, defaults, [AccessoryViewNib]}
'OpenPanel' is a dummy for Cocoa's NSOpenPanel. Maybe one could also add SavePanel, PrintPanel, ColorPanel, FontPanel, DatePicker, ... ;)
Yes, something along those lines.