This thread seams to be moving towards a general discussion on how much technology consumers need to know, and how they acquire it.
Well, they think in terms of the things they can see, which are indeed the visible representations of the layout objects. What matters is the behavior they observer, which follows the rules in the CSS specification or in the XUL documentation. No changes to the back end should change any of this behavior....
This is a personal activity style only. Highly talented learners (such as many humble folk here) may use an experimental style of learning with tight feedback loops, reference documents, and critical visual observation for brand-new material, but that is very atypical.
[ long discussion on valid ways to learn avoided ... ]
The bottom line is, educators know that the average person does not benefit from learning styles that suit very talented learners.
Couple that with the fact that the XPFE environment is highly attractive to less talented programmers because it is at first blush easy (XUL, CSS, JavaScript). The clear consequence is that extreme care is required to make sure that that attractiveness is supported right down the line, for *ordinary* programmers and their learning styles, since such programmers form the overwhelming majority.
What are people trying to learn, exactly? Perhaps if you gave some examples of this, it would be easier to see what problem we are trying to solve?
John is a new learner. He knows Visual Basic and C or JavaScript, + XML. Tcl's syntax scares him because its not in the C-family of languages. .NET is too big and hard. He heard you can do UIs with Mozilla. He looked into it. He realised he has to learn XUL tags. So he started.
<box>, <description>, <label>, all easy. <button> easy. etc etc. Now he wants to do something non-trivial with data. Either he avoids <tree> and <template>, using XUL like HTML, or he learns them. He figures he'll learn them, he'll know all about XUL then. He will have mastered XUL - an achievement.
<tree> has a complicated set of content-oriented tags. He gets past that eventually. But he can't figure out how to go from static to dynamic trees. WHY doesn't his tree appear (default height: 0px). WHEN does it get updated (builder related), WHY is that not always automatic (datasources)? Also RDF is hard! isn't there an easier way (views). He find views. But the visible tree doesn't update when he changes the view's data (failure to dirty the right content using the view API). The content was already tricky, what with wierd style support for trees and no debugging crutches. All these other concepts (in brackets) just make it harder. They conflate layout with already challenging matters of content. If, in addition, he's not *allowed* to know them, then his learning job goes from hard to impossible.
He gives trees up. Maybe templates are easier. He looks at templates. ok, template tags intermingle with content tags. That's tricky but stick with <box> content, it'll be alright. No it won't. WHY doesn't his template refresh automatically and consistently. WHAT is this builder thing hanging off the template. He can make his OWN builder? How does that work? Special building cases for trees+templates - argh. He can't understand, and he can't work on the basis of "trust me", because there are special cases to be understood. Another programmer lost to mozilla.org, if Neil Rashbrooke or others are too busy to provide assistance.
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. Low signal-to-noise for his needs.
<tree> and <template> are very much special cases (especially <template>) which tie very deeply into the guts of XUL. Understanding how they work is neither necessary for using them, not for creating custom tags via XBL bindings (eg <tabbrowser>).
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. XUL programmers need to understand that stuff, and have perspective on what makes it go and why. They need to understand the concepts behind that stuff. It is a myth to think you can bang out XUL tags and stop right there. Scripting associated objects follows automatically.
I'm not familiar with MVC, to be truthful, so I don't know how it's relevant here....
Model-View-Controller is a design pattern that is widely-established tool used to inform the building of GUI-based applications. Mozilla proposes no drop-in alternative, so Mozilla concepts (builder, layout etc) must be weighed against that well-established and proved concept if learners are to comprehend what's going on. MVC is taught at schools and uni.
Since we can't point to direct and explicit MVC support in Mozilla, and walk away on that basis, we must be at pains to explain what is there so that learners can relate it to those more well-known concepts.
In short, MVC is a little tyrant for any GUI-based development tool.
I'm not implying they do interact *directly*, just that they are end-users on whom the layout system has *some* impact.
Yes, but the impact is strictly defined by a third party and thus any changes made in layout should have no effect on them.....
The fact that "finished rules exist" is of no help at all to learners. It's the ease of adopting those rules that is the overriding criteria,
not where those rules are or their political stance.
And in the example above, clearly there is a great deal of impact that derives from Mozilla-specific concepts that are not strictly defined anywhere. Rather, these concepts have grown somewhat organically.
You can't stop internal information leaking out.
Actually, you can. This is precisely the point of good API design. Now it may be that the APIs in question are badly designed... Again, the question is not whether an XPFE programmer can learn about frames -- lxr.mozilla.org covers that angle. The question is why he would need to.
I'll modify my statement to say "there are many cases where you can't stop information leaking out". These cases revolve around simple deductive processes and also emergent effects. "information hiding" is an idealised arrangement, that is rarely perfect in practice. At minimum, the performance of an API is information readily deduced and impossible to hide. There are many such examples.
"Badly" above is perjorative, rather: "needs enhancements for better learning outcomes".
XPFE programmers shouldn't have to go to LXR. They are not interested in trekking through buckets of C++ code. They want to build a groovy application using Web- and COM-like technology. LXR is a very poor option for such purposes - time intensive, cryptic and foreign to many. Their information source must be elsewhere.
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.
Although the world is infinitely complex, small portions of it can be easy.
Only as long as you don't pay much attention, in my experience.
Can you tie your shoelaces? Our minds are designed a certain way. When used that way, many parts of the world are simple to understand and manage. Our ability to summarise, abstract and leap to generalisations may sometimes be a curse, but it is also a powerful tool. Software that fits that picture is better software. The act of drilling down deeply is still noble, it just not mandatory, efficient, or even universally appropriate.
The bits of layout that poke up into XPFE programmers' experience should be easy, whether they're explicit or implied.
Again, these portions are already defined in existing specifications....
I'd like to think this post has made it clear that its not entirely a matter of specification. It is more a matter of enabling a digestible implementation. People must be able to easily comprehend what they work with. No amount of "line-in-the-sand" policy will stop them needing concepts that are central aspects of implementation. Their needs might not extend to a specific API, but even there I think you would be surprised the number of places where layout concepts inform and ease the use of existing concrete interfaces.
- Nigel.
_______________________________________________ Mozilla-layout mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-layout
