This thread seams to be moving towards a general discussion on how much technology consumers need to know, and how they acquire it.
This thread is about how topics of interest to mozilla-layout (internal implementation of rendering objects) are relevant to XPFE programmers. So far, I've not heard any XPFE programmers comment, though....
[ long discussion on valid ways to learn avoided ... ]
I appreciate that; it's really not relevant here.
The bottom line is, educators know that the average person does not benefit from learning styles that suit very talented learners.
Indeed.
John is a new learner. He knows Visual Basic and C or JavaScript, + XML.[long example snipped]
So the short of it is that <tree> and <template> are poorly documented and need a decent howto, and possibly a redesign of the interfaces they expose to XPFE programmers.
Like I said in my previous post, though, <tree> and <template> are very much special-cases; the vast majority of layout work is not focused on those tags (nor, indeed, on XUL at all).
In short, it all fell through on the complex XUL tags. This guy's trying but the technology's not assisting him. No point blaming him; more sensible to assist him with an implementation that appreciates that this kind of struggle should be avoided in the first place. He's drowning in a design that's less than ideal for learners.
The design's primary goal should be to be usable once learned (since there is no way to help that along). The secondary goal, agreed, is to be learnable, but decent documentation should help there...
It's entirely necessary to gain virtuousity in XUL. You should review the various tree/template/listbox/popup XBL/XPCOM APIs available to XPFEers, eg nsITreeView.
Is that me personally, layout programmers, or people who actually use those APIs (i.e. XPFE programmers)?
It is a myth to think you can bang out XUL tags and stop right there.
I never claimed you could stop there... (note my mention of XBL, which is all about scripting).
"Badly" above is perjorative
It was intended to be pejorative. The point of an API is to enable people to do things. If an API is failing to do that, it needs fixing.
XPFE programmers shouldn't have to go to LXR.
Agreed. None of the information you have mentioned John as needing to know involves the going to lxr or indeed knowing anything about the internal implementation of frames (eg does he really need to know about the ways trees cache style contexts? Does he really need to know about the precise details of how scrolling in trees is implemented, once that happens? No. He needs to know how to use the tree APIs to present his data).
Why such a programmer would need to learn frames: see the above example. He doesn't need to know all about frames; he just needs to appreciate something about them.
Indeed. The basic idea should be documented somewhere. It's not clear what the relevance of that to the layout engine is...
Only as long as you don't pay much attention, in my experience.
Can you tie your shoelaces?
Only as long as I don't pay much attention.
Perhaps you and I just disagree on where the boundaries of the layout engine lie and what changes would be considered "layout changes".... Changes to the public tree APIs are _not_ "layout changes" unless they actually involve changing how the guts of trees work, for example.
-Boris
_______________________________________________ Mozilla-layout mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-layout
