nib2cib now permanently refuses to build my cib properly (Error:NOT_FOUND_ERR: DOM Exception 8)

[Luke]

I have posted on this subject a few times before. As long as I have
been using Cappuccino I have had an issue where using nib2cib on my
MainMenu.nib (as it happens) intermittently refuses to build a good
cib, resulting in the error: Error: NOT_FOUND_ERR: DOM Exception 8
when the code is run. The problem appears to be something to do with
CPTabView (or CPTabViewItem) and when it fails, it fails with a stack
similar to this:

Error: NOT_FOUND_ERR: DOM Exception 8

-[CPView removeFromSuperview]
-[CPTabView selectTabViewItem:]
-[CPTabView initWithCoder:]
-[CPKeyedUnarchiver decodeObjectForKey:]
-[CPArray initWithCoder:]
-[CPKeyedUnarchiver decodeObjectForKey:]
-[CPView initWithCoder:]
-[_CPLibCustomView initWithCoder:]
-[CPKeyedUnarchiver decodeObjectForKey:]
-[CPResponder initWithCoder:]
-[CPView initWithCoder:]
-[CPControl initWithCoder:]
-[CPButton initWithCoder:]
-[CPKeyedUnarchiver decodeObjectForKey:]
-[CPArray initWithCoder:]
-[CPKeyedUnarchiver decodeObjectForKey:]
-[_CPCibObjectData initWithCoder:]
-[CPKeyedUnarchiver decodeObjectForKey:]
-[CPLib instantiateCibWithExternalNameTable:]
-[AppController applicationDidFinishLaunching:]
-[CPObject performSelector:withObject:]
-[_CPNotificationObserver postNotification:]
-[_CPNotificationRegistry postNotification:]
-[CPNotificationCenter postNotificationName:object:]
-[CPApplication finishLaunching]
-[CPApplication run]
-[CPAppBootstrapper performActions]
-[CPThemeBlend bundleDidFinishLoading:]
-[CPBundle connection:didReceiveData:]
-[CPURLConnection _readyStateDidChange:]
…

Now, I also figured out a long time ago that if I re-ran the nib2cib
utility several times, testing the result each time, I would
eventually (usually after about 10 runs) get a working cib. I have at
various times kept the 'bad' and 'good' cibs, and there is a clear
difference in what is written out between the two. [I have also had
to adapt my development technique so I snapshot the known good cibs to
a directly and then restore these if I haven't changed the UI, because
the Xcode build script I use attempts to regenerate ALL the cibs...
but that's another story].

Anyway, I have just updated my Cappuccino framework/tools to the
latest version in order to get some of the newer goodies and fixes,
and now I can't seem to build a working cib from this xib file AT ALL
(or at least the period between getting whatever the 'good' timing is
for a working cib is now longer than I'm prepared to keep trying - I
have given up after about 30 attempts).

So, I'm a bit stranded at this point. I could try to revert back to
an older framework - but that's a pain and isn't going to stand me in
good stead for the future.

[Ross Boucher]

Luke, CPTabView probably isn't supported properly. Have you spent any
time trying to investigate the actual cause of the problem? It seems
like "hoping for the best" by building a bunch of times was definitely
going to be a recipe for disaster.

[Luke]

Hi Ross,

Yes, I do feel that I ought to be able to help diagnose a little more
here, and I'm prepared to stir the xib a little to see what
precipitates the problem.
Alan Rogers reported in a previous thread (http://groups.google.com/
group/objectivej/browse_thread/thread/
b7752c9496dee208/889e5d50be414f96?lnk=gst&q=DOM
+error#889e5d50be414f96) that he could induce the problem by not
having at least one child view in the view belonging to the
CPTabViewItem (as I understood his comment), though I made sure each
of my views had children and still experienced the non-determinancy.

I have previously provided Francisco with sets of good-bad cibs from
various runs. Looked at these in a basic side-by-side compare, there
are differences, which I think are relevant to the problem (as opposed
to just time stamps etc. - and of course the 'good' cib will
consistently work, whereas the 'bad' cib will consistently fail). I
think Francisco took a look at the issue, but I guess he has a lot on
his plate along with the rest of you guys(!), and it's certainly true
to say that this particular issue was never resolved as far as I'm
concerned.

At my current level of conversance with things Cappuccino I'm probably
not going to be too handy delving into the guts of nib2cib... though
necessity (desperation?) is the mother of invention of course.

Anyway, I'll start with messing with my xib a little and see if I can
figure out what the trigger is for my particular circumstance.

[Luke]

OK...

The trigger for this seems to be a CPCollectionView (well, a
CPCollectionView within its CPScrollView along with the scrollbars)
inside a CPTabView. The particular tab that contains this collection
view has a CPView ("custom view") as the child of the CPTabViewItem,
and then the collection view's CPScrollView as a child of this as I'm
intending adding other views as peers of the collection view.

As soon as I delete the collection view 'group' i.e. the hierarchy
including and beneath the scroll view, the cib generated from nib2cib
is good, and everything is peachy - apart from my damaged UI of
course! Put the collection view back in, and I'm back to what is now
effectively a guaranteed failure (whereas before this was non-
deterministic, with something like a 60% chance of failure).

Now this combination (tab and collection view) is exactly the
combination I provided to Francisco many weeks back. I think he did
stir the nib2cib code somewhat back then, and I'm sure he fixed some
problem, but obviously not this one! If I hadn't reached the point
where the UI wasn't compiling properly AT ALL, then I would probably
have soldiered on, but at this point I'm in something of an impasse.
I'm not sure that getting into the nitty gritty of nib2cib's workings
is going to be economic in terms of my time, and the fact that the
problem has manifested non-determinancy in the past suggests that it
might be something strange with timing, not a simple 'missing feature'
per se that a n00b might easily find.

So I guess I'm asking if anyone who is already familiar with nib2cib
will be able to take a look at this.

[angel imaz]

I have this set up working fine for a long time now.

A collection view added to a scrollview.

No problems so far. I simply use the scrollview as a container.

It would be nice if it work like in cocoa though. I am sure it will
soon.

Looking forward for the 15th.

Cheers,

Angel
El Nov 2, 2009, a las 2:13 AM, Luke escribió:

>
> Well, I've got back to a situation of at least being able to convert
> my xibs to workable cibs again by manually linking the local view
> group of the CPCollectionView (i.e. from its scroll view parent) to
> the placeholder custom view that belongs to the CPTabViewItem. I do
> this once the cib is loaded.
>
> The workaround entails having the collection view (in its scroll view)
> be a top level object in the nib, connected to a outlet on the
> AppController that loads the cib. The intended parent view (the
> custom view under the tab item) is also connected to an outlet. Then
> I do the obvious: [placeholderView
> addSubview:collectionViewHierarchy];
>
> So, this still ranks as my #1 most frustrating Cappuccino bug, but I
> guess I'm in a small minority of people who use cibs, use nib2cib to
> create cibs, AND have tabs with collection views in them (a fairly
> constrained set of circumstances!). Oh well.

[Luke]

Hi Angel,

Thanks, and yes I've come to the conclusion (over the weekend) that
the issue is more convoluted than I first thought.
Originally, my xib was in a state where indeed the removal or addition
of the collection view group of views would promote the problem.
However, I've since made some additions to the xib and have found that
things aren't so simple.

My current xib fails almost every time. Sometimes, after editing the
xib, I have found that it seems to have a better chance of
succeeding. This could be down to something about the structure of
the xib, perhaps some word alignment or something, or something more
esoteric like the data being knocked out of some cache, and therefore
changing timing, resulting in a chance of compiling.

I have managed to sample two cibs captured from the same xib, one that
happened to compile and one that didn't. There are a few discrete
differences in the data, but I'm not sure what they pertain to
specifically. A key thing here is the non-determinancy of the
compiler. When I had a smaller xib, I used to have a 10-20% chance of
success - enough to keep trying until I achieved a 'good' cib, which I
then kept safe until I needed to make another change. The problem I
have is ONLY with my large, complex MainMenu.xib file. I have around
10 xibs in all, and all the others are much simpler and compile OK
100% of the time, it seems! I sent some cib pairs to Francisco a
while back, but I'm not sure what he was able to make of the
differences, and indeed it may be difficult to infer why the compiler
is behaving non-deterministically from such snapshots of its
results.

In the last week or so, something in either the tools (which I
refreshed) or the xib (which grew) has caused my probability of
successful compilation to approach 0. I can't tell you how
frustrating this is. I have some slight chance of it compiling to a
useful cib, by employing 'witchcraft': adding or removing a button in
the xib to try to change it sufficiently to maybe get a 'good' cib.
If the compilation works though, it won't be repeatable and will work
once. Subsequent compiles will generate a 'bad' cib that produces the
"DOM Exception 8" at runtime. So the whole problem smacks of some
timing/concurrency issue.

Unfortunately, for me, the mysteries of nib2cib will probably have to
remain mysteries as I have very little time to try to learn the
intricacies (and nib2cib looks like a layered implementation with
narwhal in the mix). Like everyone else, I have deadlines and
priorities. I can see that the 280 North guys are still playing with
this tooling from time to time, and there seems to be some kind of
project to remediate parts of it (remove the "Java"?). So, I don't
know whether to expect this tooling to improve anyway.

It looks like I'm not entirely alone in experiencing this issue. In a
prior thread there was a least one other fellow with a nib/xib that
needed several tries to compile sometimes to generate a 'good' cib.
However... it looks like there aren't armies of us with this problem,
which is too bad for me as the problem is so egregious, even if it
doesn't afflict too many people.

Oops, long response... but that's my state-of-play, unfortunately.

[Francisco Tolmasky]

This is a lot of reading and I'm in the middle of other important
parts of code but want to get any big nib2cib errors happening
recently fixed before the merge. Can someone in like 2 lines tell me
what they're seeing, and more importantly, just send me their xib so I
can test it myself.

francisco At 280 north dot com

Thanks,

Francisco

> > >>>>> -[CPButton initWithCoder:]...
>
> read more »

[Luke]

Hi Francisco,

I can send you the latest version of the xib that causes the problem.

You may recollect that I sent you a xib and pairs of cibs (good/bad)
earlier - did those shed any light on any problems (because the issue
is essentially manifests in the same way as far as I'm concerned)?

I can probably send you a good/bad cib pair as well this time
(generated from the same xib that I'll send), if that helps.

Thanks

-- Luke

> ...
>
> read more »

[Luke]

... and I've sent you the files Francisco.

Here is something by way of a summary you asked for:
- Manifestation: nib2cib fails to create a correct cib from certain
xib files (such as the included one)
- Reproducibility: The problem as experienced is non-deterministic,
but the majority case on my system is failure. I have had xibs that
work 20% of the time. This particular xib seems to compile a 'good'
cib only about 2% of the time on my machine, but the exact criteria
affecting the outcome is uncertain.
- I believe that there is a difference between simply rerunning
nib2cib in an attempt to build a 'good' cib, and changing the xib
slightly (i.e. to add a button) and then retrying. Empirically, the
latter appears to increase the chances of success.
- If some change is made to the xib file, and nib2cib successfully
builds the 'good' cib, then rerunning the tool on the unchanged xib
will likely see it fail (build a 'bad' one). Thus, it does not look
like the problem is directly caused by a structural variance in the
xib file per se.

> ...
>
> read more »

[Francisco Tolmasky]

Yes, sorry, I got this thread confused with the other nib2cib thread.
I do have your files and I am looking into it as I fix the other bug
as well.

As a word of caution however, tab views are not very well supported
with nib2cib and probably won't be until we get a tab view rewrite.
TabView (and progressview) are the only "old" views remaining from
before theming was implemented, and thus do things in a very poor way
internally.

Secondly, I have also experienced the strangeness of nib2cib
"sometimes" working. I believe this is actually due to ibtool which we
run behind the scenes. ibtool takes a .xib and turns it into a .nib.
In the process it seems to either 1) modify the original file (namely
changing the order of the objects archived), or 2) simply creates a
slightly different .nib each time. The ordering is important because
this is almost certainly an issue with the order that we are reading
these objects out. We used to have *lots* of issues with this, but
have been progressively narrowing them down, and now the remaining
ones are hard to debug precisely for this reason that it is non
deterministic. I will be looking into this and the other nib2cib bug
reported more heavily tomorrow and hopefully I can make some headway.

Thanks everyone for the patience.

> > > > > >>> having at least one child view...
>
> read more »

[Luke]

Thanks for the note Francisco. It comes as something of a relief to
hear that you have a bead on the problem, and are aware of a general
non-determinism issue.

All the best with the diagnosis. I'll be cracking open a bottle of
champagne when this issue is licked :-) It has been a real thorn in
the side.

On the subject of Tab Views in general, they seem as supported as I
need them to be right now - insomuch as they live up to expectations
every time I manage to get a 'good' cib out of nib2cib! Good to hear
they can get functionally even better - but for me just getting so I
can reliably include them in my UI is a BIG step forward.

Cheers

-- Luke

> ...
>
> read more »

[Stefan Wallström]

The problem might be that CPTabView doesn't encode it's subviews while
the content view of CPTabViewItem does encode it's superview. And I
think this confuses addSubview: when the selected tab tries to add its
content view.

Not 100% sure yet, but with this patch I haven't seen the problem in a
little while at least:

diff --git a/Tools/nib2cib/NSTabViewItem.j b/Tools/nib2cib/
NSTabViewItem.j
index 74d915f..7b1abc9 100644
--- a/Tools/nib2cib/NSTabViewItem.j
+++ b/Tools/nib2cib/NSTabViewItem.j
@@ -33,6 +33,7 @@
_label = [aCoder decodeObjectForKey:"NSLabel"];

_view = [aCoder decodeObjectForKey:"NSView"];
+ _view._superview = nil; // zapp superview since CPTabView
doesn't encode _subviews

// doesn't exist in Cocoa
//_auxiliaryView = [aCoder
decodeObjectForKey:CPTabViewItemAuxViewKey]

[Stefan Wallström]

Still no problems, so I think this is it. Or at least one problem
causing this.

The problems is that in encodeWithCoder: in CPTabView, it doesn't
bother encoding the subviews. Instead CPTabView recreates its subviews
(3 bezel views and the content view of the currently selected tab) in
initWithCoder:. When the selected tab in the cib is activated,
CPTabView calls addSubview: to add the content view of the tab. The
content view has the superview set to the tab view already which
causes addSubview: to do nothing (it doesn't bother checking if it is
among it's subviews already).

The nicest way to fix this is probably to make CPTabView encode it's
subviews. You need to add CPCoding to _CPTabLabelsView etc so it's
probably the fix requiring most work.

Or you could make addSubview: of CPView check if the view is in
_subviews instead of just checking that superview == self.

Or have nib2cib unset the superview of tab items like in my patch
above.

Or have initWithCoder: in CPTabViewItem unset superview in _view.

[Stefan Wallström]

There's a bug report for this issue here:
http://github.com/280north/cappuccino/issues/#issue/275

On 9 Nov, 19:34, Stefan Wallström <st...@lysator.liu.se> wrote:
> Still no problems, so I think this is it. Or at least one problem
> causing this.
>
> The problems is that in encodeWithCoder: in CPTabView, it doesn't
> bother encoding the subviews. Instead CPTabView recreates its subviews
> (3 bezel views and the content view of the currently selected tab) in
> initWithCoder:. When the selected tab in the cib is activated,
> CPTabView calls addSubview: to add the content view of the tab. The
> content view has the superview set to the tab view already which
> causes addSubview: to do nothing (it doesn't bother checking if it is
> among it's subviews already).
>
> The nicest way to fix this is probably to make CPTabView encode it's
> subviews. You need to add CPCoding to _CPTabLabelsView etc so it's
> probably the fix requiring most work.
>
> Or you could make addSubview: of CPView check if the view is in
> _subviews instead of just checking that superview == self.
>

> Or havenib2cibunset the superview of tab items like in my patch