Re: Multiple instances of a nib without multiple loads?
Re: Multiple instances of a nib without multiple loads?
- Subject: Re: Multiple instances of a nib without multiple loads?
- From: Michael Latta <email@hidden>
- Date: Tue, 22 Jul 2003 13:31:24 -0700
Flexibility always comes at the cost of performance. The trick is to
balance the two. But, loading nibs is not the performance issue so
much as the number of NSView objects. The nibs sound pretty small, and
so will end up in the cache. The time to interpret the nib file is not
that significant as it is done once for each object, not once for each
display of each object. The number of NSView objects results in
overhead on every redisplay. You need to simplify the structure for
each row, down to 1 nib at a minimum. If you expect to use a large
number of rules, then consider using a single display only view for
each row, or better yet a cell renderer, and then having the editable
nib loaded only for the selected object. This is the traditional
solution for large lists, select the row, and edit in a separate area.
Trying to display thousands of NSView objects will never scale no mater
how many nibs they come from.
Michael
On Tuesday, July 22, 2003, at 12:51 PM, James Farwell wrote:
Greetings all,
I am writing my own custom "Rule List View" which attempts to mimic
the rule
lists like those in iTunes' smart playlists, Finder's advanced find,
and
Mail's filters. The catch is, I am writing my list for an application
which
adds new rules from 3rd party plugins, so I need to account for the
contents
of the rules being completely dynamic. My current implementation makes
pretty liberal use of loading nibs on the fly, and while it does not
seem to
impact performance for the short lists (< 15) of rules I have been
testing
with it, I am aware it does not scale very well.
In my implementation, each "row" of the list is defined by 2 nibs. The
first nib is simply an NSView which contains the elements which are
constant
in each row: the drop down list of all possible rules, and the buttons
to
insert and remove rows. It also has a custom view for the controls
that
define the rule.
(bad ASCII art)
_________________________________
| _________ ############# _ _ |
||v|__list_| #Custom View# |+||-| |
|____________#############________|
When a rule is chosen from the list by the user, the program creates a
new
instance of the rule class (this is necessary due to the fact that each
instance of a rule in the list has its own nib, so the IBOutlets have
to
connect to a unique instance somewhere in order for me to use them),
which
in turn loads its respective nib (another simple NSView containing
whatever
controls the rule needs) and sets it as the custom view. The rules
themselves are pretty simple. They get passed in data from the app,
perform
their action on the data (using the contents of their controls, hence
why
the IBOutlets are necessary) and then return the result.
So, now that I've explained the basic mechanics, it is pretty plain to
see
that there is not only quite a bit of nib loading here, but also a lot
of
nib duplication. If a user made a list with 5 different instances of
the
same rule, then there would be 5 different instances of that rule
class and
5 separate loads for the 5 separate instances of the nib for that rule.
Can anybody think of a way to simplify this setup without impacting its
flexibility? The rule classes themselves could almost be made
entirely of
class methods except for the fact that they need to access the
IBOutlets of
their nibs. It almost make more sense to have them be class methods
and
just pass in a dictionary of the contents of the rule, except then
there
would still need to be a new instance of some class to hold the
IBOutlets,
so what's the point in complicating it by splitting it into 2 classes.
Is
there any way to have instances of the same rule to somehow share a
nib, yet
have separate IBOutlet connections?
Thanks!
- James
email@hidden
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.