[PD-dev] bug when redrawing gop within gop inside a closed sub-patch

[Ivica Ico Bukvic]

> That's not a reason for removing it.

I never said it was. It was simply icing on the cake, if you like:
pd-extended exhibits a problem that pd-vanilla doesn't exactly because of
this one line. Namely, this is the culprit for profuse canvas errors every
time an object is updated that is visible on a GOP of a closed sub-patch
(and hence it is not really visible). Please see my previous email regarding
this.

On the flip-side, I am sure there must be a reason why this thing was put in
there in the first place, it is just that I am unable in my set of tests to
reproduce its relevance beyond the said regression. So, if anyone is aware
of the reason for its placement, it would be most helpful to learn more
about that before making the final decision whether to keep/remove it.

> 
> > What really eats a lot of time, is lack of comments/annotations in the
> > code making it rather difficult to trace things down...
> 
> What would those comments tell you?

What things like "&x->x_obj.te_gobj.g_pd" (to use your example) mean (e.g.
struct structure and function of g_pd vs. te_gobj vs. x_obj etc.) and how
and why they are being used. As it is right now, it takes forever to grep
the stuff and figure out what each line/call actually does. Even a good
chunk of calls have IMHO vague descriptions (like canvas_map call, if I
recall correctly the name). Unless I am mistaken (and please do correct me
if I am wrong) this call is for both mapping and unmapping, yet the
description suggests it is about mapping only.

All that said, I may have very well missed something, so if there is a good
resource that shows the code tree and basic API information, that would be
certainly very helpful and most appreciated.

> If those comments are wrong or eventually went wrong by lack of
> updating,
> who would actually take the time to update those comments? What
> would
> ensure that those comments stayed right? And what's the damage
> caused by a
> wrong comment compared to no comment?

I think we're already there. Please see my comment above. Besides, "no
comment" is just as bad as "bad comment" if you have no easy way to
understand the api/variables and their functions. It's like asking a
question if you were lost in a jungle, would you prefer no map or a
misleading map. My answer would be neither.

> What about removing distracting stuff like unused variables, struct
> member
> prefixes and struct nesting like &x->x_obj.te_gobj.g_pd instead of just x,
> and stuff like that?

If it makes it more legible without breaking the code, I am all for it. That
said, I don't feel I am up to the task until I am able to fully understand
the api/code as I have no idea even which of these are unused/obsolete
and/or what is their primary function/role. Hunting for these three bugs
alone has taken up 40+ hours of my time, most of which was used to trace
what each call/variable does.

I would love to contribute more, but time is a precious commodity we are all
short on. So, for the sake of making contributions easier, IMHO I think it
would be a great idea to overhaul the code to the point where it is possible
to make such contributions much more efficiently. I am hoping that this is
what Hans is trying to do with the gui rewrite.

Best wishes,

Ico