• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: XML: Wouldn't it be nice...
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: XML: Wouldn't it be nice...


  • Subject: Re: XML: Wouldn't it be nice...
  • From: Eryk Vershen <email@hidden>
  • Date: Mon, 3 Aug 2009 17:11:50 -0700

Rainer,

You don't need to do all that work. If you generated an object via a SendXML with no project specified then doing a GetTOC with no project specified will return the TOC for the same project, so you don't need to search all projects. And, of course, you can generate your own UUID and send it along, so you don't need to search to find the uuid. True, the user could have done something in between, but in that case you shouldn't be using no project.

However, if the project is a brand-new project (never saved) then you won't be able to to do a select or open because those events still require a projectFileKey. One can argue that they should be able to handle no project key, feel free to put in a bug report...

You can do a getTOC with no project and find the name of the front- most. This with ListProjects gets you part of the way there, as long as you don't have two projects with the same name open. There is, however, a fundamental disconnect since unsaved projects don't show up in the ListProjects, nor is there a way to reference an unsaved project (other than when it is the frontmost project).

All in all, the current state of affairs is "less than ideal". Having a project URL, doesn't completely solve the problem.

Another suggestion is to have a project uuid. This would be a uuid associated with all open projects (even unsaved ones). You couldn't use it to open a closed project, since it wouldn't (necessarily) persist from one opening of a project to the next. That way you could do getTOC to get the project uuid for the frontmost project and then use that from then on. You'd want the projectURL returned (if it existed) as well since that would give you a more persistent identifier.

-eryk


On Aug 3, 2009, at 12:19 PM, Rainer Standke wrote:

Hello all,

the timing might be not to fortunate for this, since FCP 7 just came out, but here goes anyway:

If you make a new item by generating an appropriate XML doc (or by modifying an existing item), then send that into FCP via Apple Events, then it would be nice to select it in the browser, or load into the viewer or canvas. The trouble is that to do either of that (again, via AE) you need to know what project the item ended up being sent to. If you simply send it to the frontmost project then you have no way of knowing its filepath, which is what you'd need for the AE that selects or loads the item. (Am I wrong about this?)

In FCP 7 you could ask for a list of all open projects, then for a table of contents for all of those, then you could search for for the item by uuid, and thus derive the project it lives in. It would be a lot more straight forward if the sequence would contain a project identifier, such as <projectURL>, wouldn't it?

What do you think of that as a feature request?

Rainer
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Pro-apps-dev mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden

_______________________________________________ Do not post admin requests to the list. They will be ignored. Pro-apps-dev mailing list (email@hidden) Help/Unsubscribe/Update your Subscription: This email sent to email@hidden
References: 
 >XML: Wouldn't it be nice... (From: Rainer Standke <email@hidden>)

  • Prev by Date: Re: XML: Wouldn't it be nice...
  • Next by Date: At SIGGRAPH
  • Previous by thread: Re: XML: Wouldn't it be nice...
  • Next by thread: At SIGGRAPH
  • Index(es):
    • Date
    • Thread