On Dec 19, 3:50 pm, "Chris Mellon" <[EMAIL PROTECTED]> wrote:
> You have been done a disservice > by whoever wrote the Maya python bindings, as far as using this tool > to improve your knowledge and understanding of Python goes. No worries there. I'm definitely not using Maya as the way to learn Python. I'm using it as the reason to learn it, with additional supporting reasons being that it aids me in the shell, opens up libraries (and thus abilities) like PyGTK, and can help me create the kinds of tools I create for myself on Linux, but with a lot more power, and expressed more intelligently. > Yes, HTML is a very bad way of doing GUI layout. It's a textual markup > language, not a layout format. HTML per se has almost no layout > capabilities at all, and CSS while much better is still quite limited. Fair enough. I would say in this sense, it feels similar to the concept of duck typing to me. The UI sections of my MEL code looked (to me) like HTML, and were formed in the same way, and the output was essentially a 1:1 mapping of what similar, declarative, HTML-style markup might produce. That it was clearly *not* what it seemed to be was beside the point. It quacked like a duck for me, and always got the job done. But I'm ready for a real duck now. > This is the internet, we don't shy away from scoffing at millions of > misguided souls here ;) I wrote that bit, admittedly, with a dark grin on my face. I often find I disagree with the majority. I suppose I was being a *bit* defensive, though. After all, I was - ostensibly - doing the same thing in my code that one would do in HTML. That I was violating laws of code (codes of law?) was very much an extension of the fact that I really didn't have a choice. After all, I did try unsuccessfully several times (as have others) to create a system whereby I'd design the layouts in an editor, and save them out to some declarative format. However, in that I needed to create a rather intricate UI in MEL that could create UIs in MEL, with the terrible UI abilities in MEL, and using MEL itself, which is vastly underpowered, it was something more fit for an entire ship of fools to create, rather than one lone code warrior. It was just too much work. I think it will be not only possible, but end up rather powerful to create it in Python. > > ...and keeps on rolling with: > > "All those setParent calls! *shiver*." > > > Alright, I'll give you those :) I hated them for the first year. > > Still, they're basically just HTML close tags, with the added power > > that you can replace '..' with a specific layout to jump into that. > > You can also think of them as close braces in your choice of C-like > > languages. Don't be such a scaredy-cat. > > They aren't a close tag, they're state management, and the fact that > you have to litter your code with them is a real flaw in the GUI > toolkit. I agree. I've known that I'm simply manipulating states, but the overarching points here are that it was my only real option, and I managed to dress it up prettily enough that I could fool myself, and not be bothered by it. It helps that I own all my code, and that it's only been used by 2-4 people these past 6 years. Now that the company is growing, and I'm wanting more to share code, and build more powerful things, I'm eager to shed some of my youthful, carefree ways, and code properly, and powerfully. > > Jonathan Gardener promised this: > > "...let me try to explain why you'd never want to indent code that > > way, let alone write code that way." > > > But then never actually explained it. > > > He states: > > "...it's best to create functions and then nest the functions." > > > But never says why it's best - just that it is. None of you so far > > have said why your thoughts have any merit. So far, it's just all been > > declarative statements that your ways are better, that my ways are > > "terrible," and all with not one substantiation of either sentiment. > > Weren't any of you folks in debate club? I wasn't, but I think I'm > > winning :) > > I'm not him, but I'll say why *I* might have said this. What you're > doing with your nesting is creating and managing a stack of states. It > just so happens that you have a very powerful programming language all > ready to do this for you, because that's exactly what it does when you > make nested function calls. So rather than writing imperative code > that tries to look declarative, you can just write imperative code (or > you could use/invent a real declarative language for declaring these > GUIs, and load the UI from that. This is what GUI builders like Glade > do). Remember that you are *not* writing markup. You are writing code > in a real programming language and you have all the power of that > language at your disposal for breaking code down into small, easily > handled pieces. I too have written UIs that scale to hundreds of > individual GUI elements (although not neccesarily controls, because a > UI screen that cluttered is hard ot use) and the way to manage the > complexity is the same way you manage any other programming complexity > - by breaking it into pieces which you gradually compose together. That's where I'm leaning. As I mentioned to Grant earlier, it looks like I'm going to want to write wrappers that a parser can call out to build UIs based on UI data stored in XML. I still can't get away from the fact that somewhere, I need to setParent, but it can be tied up, and hidden in the basement, at least. So that's the next two questions: 1) Is it best/more standard to read in, and parse the XML into some kind of Python hierarchy first, and then build the UI out of the data in that structure, or call out UI commands as say, callbacks from the parser live - as it wades through the data? I lean toward the former, as it means having one standard set of functions to read in, and parse the XML data, which can then be used for anything, like displaying the UI to the client, or creating an editable version of the UI in the UI build tool. The modified version can then be saved back out as well. 2) Is XML fairly standard for this in Python? I recently learned about/ was frightened by pickling. Is that worth learning? Does anyone bother with it? Thanks, Chris. -g -- http://mail.python.org/mailman/listinfo/python-list
