Re: Size limitations for custom ui parameters
Re: Size limitations for custom ui parameters
- Subject: Re: Size limitations for custom ui parameters
- From: Paul Schneider <email@hidden>
- Date: Tue, 6 May 2008 14:14:13 -0400
Hi, Stig,
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.
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.
- Paul
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