Re: Size limitations for custom ui parameters
Re: Size limitations for custom ui parameters
- Subject: Re: Size limitations for custom ui parameters
- From: Stig Sandø <email@hidden>
- Date: Wed, 07 May 2008 23:35:59 +0200
Paul Schneider wrote:
So to me it seems like FCP
keeps/saves the initial size of the view the first time it is created
and is using that later, despite the plugin
handing over a view with a different size. This seems odd to me.
Maybe someone can elaborate?
unfortunately, the view dimensions are saved with the project in FCP.
If you change your view dimensions, you'll see the change if you add
new instances of your plugin, but older instances in saved projects
won't update.
And apart from doing internal version/size tracking there is no way for
an instance to query whether
its size has been previously set I presume. It did not seem to be part
of the exported xml of a timeline
at least, so an external app does not seem able to "change"/"upgrade"
the sizes that way either.
In our use-case we had hoped to have a dynamic size of this parameter
window, both depending
on what input options are relevant, as well as giving newer versions
of the plugin the opportunity
to adapt the view and view-size. In our case we only need one stored
parameter that keeps the
entire state.
Final Cut doesn't allow you to dynamically change the size of your
custom view. The user can change the width by dragging the column
header, but we don't update our layout if you change dimensions
programatically.
If you want to provide a dynamic UI, your best bet is to split your UI
into multiple custom parameters, which you can dynamically hide and
show using -setParameterFlags. We could definitely be more flexible
here in the future, but that is your best bet today.
In our case that workaround is quite clunky, so we'll have to consider
what to do here.
When testing in Motion however, it seems to accept and adjust to changes
of the size.
Allowing a custom UI component with any Cocoa widgets is quite flexible,
it's just odd
that it hasnt been followed up by allowing a parameter to decide the
size too. So we would
at least be very happy if we in a (near) future version would be allowed
to adjust the size
of the parameter ui based on the information it contains.
Cheers,
Stig
On May 6, 2008, at 1:44 PM, Stig Sandø wrote:
Hei,
I finally was able to have a look at this issue again after being
away for awhile. What I realised was that
I had been changing the frame size in -createViewForParm, but was
testing on the same plugin instance,
ie I used a symbolic link to to the build-dir and tested. So despite
recompiling with a different initial size,
(initWithFrame) the parameter view remained the same size, but the
content within was changing.
So eventually I tried a new plugin instance, with code that requested
quite a liberal height. And now it
got the request height. What had been wrong? So I changed the code
to use a more conservative height,
recompiled, restarted FCP but the instance kept it's earlier liberal
size. So to me it seems like FCP
keeps/saves the initial size of the view the first time it is created
and is using that later, despite the plugin
handing over a view with a different size. This seems odd to me.
Maybe someone can elaborate?
In our use-case we had hoped to have a dynamic size of this parameter
window, both depending
on what input options are relevant, as well as giving newer versions
of the plugin the opportunity
to adapt the view and view-size. In our case we only need one stored
parameter that keeps the
entire state.
A simple piece of example code to reproduce:
- (NSView *)createViewForParm:(UInt32)parmId {
NSView * view = NULL;
if (parmId == (SessionParamID)) {
// changing the height here should also update the size
of existing/deserialised plugins
view = [[NSView alloc] initWithFrame: NSMakeRect(0, 0,
60, 90)];
NSButton *editButton = [[NSButton alloc] initWithFrame:
NSMakeRect(0, 0, 140, 25)];
[editButton setTitle:@"Editor"];
[[editButton cell] setFont: [NSFont systemFontOfSize:
[NSFont smallSystemFontSize]]];
[editButton setBezelStyle:NSRoundedBezelStyle];
[editButton setTarget: self];
[editButton setAction: @selector(launchEditor)];
[view addSubview:editButton positioned:NSWindowAbove
relativeTo: nil];
NSButton *cfgButton = [[NSButton alloc] initWithFrame:
NSMakeRect(0, 30, 140, 25)];
[cfgButton setTitle:@"Config"];
[[cfgButton cell] setFont: [NSFont systemFontOfSize:
[NSFont smallSystemFontSize]]];
[cfgButton setBezelStyle:NSRoundedBezelStyle];
[cfgButton setTarget: self];
[cfgButton setAction: @selector(launchConfigure)];
[view addSubview:cfgButton positioned: NSWindowAbove
relativeTo: editButton];
[editButton release];
[cfgButton release];
}
return view;
}
Paul Schneider skrev:
Hi, all,
Darrin is right, you *should* be able to tell the host that your
view is as large as you want. However, FCP isn't quite that
friendly. We will use the initial height you specify, but we will
resize the view down to the width of the parameters column.
The user can make the parameters column wider or narrower by
dragging the column header, and we should dynamically resize your
view as the column changes size. You can't specify it
programatically, but you can tell your users to resize the column to
make your UI more usable - many developers are in this situation
currently.
We should use the initial height you specify, though. In testing
some other plugins (like the SimpleMatte SDK example), it looks like
this is working, so the problem may be with your nib or view.
- Paul
On Mar 10, 2008, at 12:07 PM, Darrin Cardani wrote:
On Mar 10, 2008, at 7:56 AM, Steve Christensen wrote:
On Mar 10, 2008, at 2:42 AM, Stig Sandø wrote:
we're seeing that in FCP 6 our custom UI parameters seem to be
restricted to a certain width, and more worryingly to a height of
about 30 pixels.
Is there a way to work around this to provide bigger/taller
custom UIs?
Unless I've been lucky, it sounds like the problem is with your
NSView. I have a custom view that contains a 160 x 67 pixel image.
The full height of the image is visible in the Viewer window,
although the right edge can be clipped if the Parameters column
width is reduced. Same behavior in both FCP 6.0.2 and FCE 4.0.
That's right. You should be able to tell the host application that
your view is as large as you want. Remember though, that users may
get annoyed if it's really large and they have to constantly resize
their parameter pane to see the whole thing. If you want to post
the code from your -createViewForParm: method, I could see if
there's anything obviously wrong with it. Are you creating the view
in code or using a .nib file?
Darrin
--
Darrin Cardani
email@hidden <mailto:email@hidden>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Pro-apps-dev mailing list (email@hidden
<mailto: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
_______________________________________________
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