Closed Bug 395711 Opened 17 years ago Closed 3 months ago

Can't "make new tab" with AppleScript

Categories

(Camino Graveyard :: OS Integration, defect)

Product:
Camino Graveyard
Component:
OS Integration
Platform:
PowerPC
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED INCOMPLETE

People

(Reporter: alqahira, Unassigned)

References

(
URL
)

Details

For reasons described in the above blog post, "make new tab" won't work.  This is less-than-ideal since it makes it hard do a lot of useful stuff with tabs :(
Removing from the SoC project because it's *way* to big.  Hopefully I'll get to it relatively soon anyway, after the project.
No longer blocks: 382493
[4:11pm] <cl> just thinking out loud here...what if we implemented -init: on BrowserWrapper/BrowserWindow and had it call the designated initializer with some set of default params? Is that kosher, or is it more complicated than just AppleScript wanting the class to have a method called "init" ? In other words, does AppleScript call [[foo alloc] init], or does it call [[foo alloc] (whatever Foo's designated initializer is)] ?
[4:15pm] <peeja> my understanding was that creating a window was more complicated than an -alloc, -initWithStuff
[4:15pm] <cl> likewise with tabs?
[4:15pm] <peeja> that was my understanding
[4:15pm] <peeja> I'd love to be wrong
[4:16pm] <peeja> it would certainly be the nice OO interface to have
[4:16pm] <cl> i'd be curious to know what would happen if we implemented an -init method that just called the designated initialiser with some default params
[4:16pm] <cl> and then tried "make new browser window" again
[4:16pm] <peeja> try it
[4:16pm] <peeja> I just thought there was more setup involved than an initializer
[4:16pm] <peeja> but I don't remember the code very well or have it right now

ccing hendy, too, in case he gets interested in this.
[11:30pm] smorgan: Really, the "tab" object for AS should be a  BrowserTabViewItem, not a BrowserWrapper
[11:33pm] smorgan: Do we currently support anything beyond URL/set URL and 'close' for tabs?
[11:34pm] sauron: title, url, source, text, selected {souce|text}
[11:34pm] smorgan: Ugh
[11:34pm] smorgan: Okay, let's hack it [bug 502407] in then I guess
[11:34pm] sauron: haha
[11:35pm] sauron: eventually we'll have to rearchitect to get "make" to work, so we can fix the hacks then :p
(In reply to Chris Lawson from comment #2)

Just a thought, instead of trying to make 'make' work, what if we invented a new verb (say, 'create') for the purposes of this bug that we could code especially to do the right thing?

It sucks to be inconsistent (with the rest of the world, and with things like 'make new bookmark' that do work), but I think it sucks more to not be able to create new tabs and windows via AppleScript.
There's an interesting comment in Matt Neuberg's tutorial http://www.apeth.net/matt/scriptability/scriptabilityTutorial.html (search for "But key-value coding slams into your existing application like a sudden side wind, ignoring your architecture and surprising your code.") that sounds like he's describing a way not to work around the KVC mess but to clean up after it, except I don't really follow.

From what I gather, though, if we added an -init method that called the "real" BW/BW initialization methods with default params, as cl suggests in comment 2, that ought to make AppleScript happy (whether our code will be happy is another question).  So

"make new browser window" --> [[BrowserWindow alloc] init]
… "with properties" {url:"http://example.com"} --> [BrowserWindow [howeverWeGetCurrentBrowserWrapper setCurrentURI:@"http://example.com"]]

(That may not fix positional calls like "make new browser window after browser window 1", but some degree of working is better than none, right? :P )
Thought #2: To fix bug 394821, we subclassed NSMoveCommand to prevent it from eating bookmark folders when moving bookmarks to them.  Perhaps we can also subclass NSMakeCommand to instead call the "real" BW/BW initialization methods instead of adding a dummy -init method to those classes (which sounds really messy).
(In reply to Smokey Ardisson (not following bugs - do not email) from comment #6)
> Thought #2: To fix bug 394821, we subclassed NSMoveCommand to prevent it
> from eating bookmark folders when moving bookmarks to them.  Perhaps we can
> also subclass NSMakeCommand to instead call the "real" BW/BW initialization
> methods instead of adding a dummy -init method to those classes (which
> sounds really messy).

http://lists.apple.com/archives/applescript-implementors/2005/Jul/msg00115.html
http://lists.apple.com/archives/applescript-implementors/2005/Jul/msg00117.html
FWIW, http://developer.apple.com/library/mac/#documentation/Cocoa/Reference/Foundation/Classes/NSCreateCommand_Class/Reference/Reference.html is pretty clear these days about exactly how "make" works.  In part:

When an instance of NSCreateCommand is executed, it creates a new object using [[theClassToBeCreated allocWithZone:NULL] init] (where theClassToBeCreated is the class of the object to be created), unless the command has a with data argument. In the latter case, the new object is created by invoking [[NSScriptCoercionHandler sharedCoercionHandler] coerceValue:theDataAsAnObject toClass:theClassToBeCreated]. Any properties specified by a with properties argument are then set in the new object using -setScriptingProperties:.

So as long as we can subclass NSCreateCommand to handle cases where we're asked to create a browser window or tab, then create a BW or tab with default parameters ("about:blank"), and handle setScriptingProperties in the BW/tab classes (basically, the only settable property is URL), we should be in business.
Status: NEW → RESOLVED
Closed: 3 months ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.