Allowing Arbitrary Indentation in Python

S

Sam

A friend of mine is picking up some Python and is frustrated by
Python's indentation rules (http://greatbiggary.livejournal.com/
260460.html?thread=1835884#t1835884). Personally, I've never had any
issues with Python's ways of indentation, but that conversation got me
thinking about the issue.

Consider the following indentation rules:
1. Blocks begin with a line ending in ":"
2. A line on the same indentation level or lower ends a block.

Under those rules, this would work:
layouts = ['column', 'form', 'frame']
cmds.window(t='gwfUI Builder')
cmds.paneLayout(configuration='vertical3', ps=((1, 25, 100), (3, 20,
100)))
cmds.paneLayout(configuration='horizontal2')
cmds.frameLayout(l='Layouts')
cmds.scrollLayout(cr=True)
cmds.columnLayout(adj=True, cat=('both', 2))
for i in layouts:
cmds.button(l=i)
cmds.setParent('..')
cmds.setParent('..')
cmds.setParent('..')
cmds.setParent('..')
cmds.setParent('..')
cmds.showWindow()

Do such rules make sense? Is there any way to make code work that way
in Python? Should there be? Does that make this sort of code more or
less readable?

P.S. I'm definitely not looking for a tabs vs. spaces flamewar here.
That's a different issue.
 
G

Grant Edwards

A friend of mine is picking up some Python and is frustrated by
Python's indentation rules (http://greatbiggary.livejournal.com/
260460.html?thread=1835884#t1835884). Personally, I've never had any
issues with Python's ways of indentation, but that conversation got me
thinking about the issue.

Consider the following indentation rules:
1. Blocks begin with a line ending in ":"
2. A line on the same indentation level or lower ends a block.

Under those rules, this would work:
layouts = ['column', 'form', 'frame']
cmds.window(t='gwfUI Builder')
cmds.paneLayout(configuration='vertical3', ps=((1, 25, 100), (3, 20,
100)))
cmds.paneLayout(configuration='horizontal2')
cmds.frameLayout(l='Layouts')
cmds.scrollLayout(cr=True)
cmds.columnLayout(adj=True, cat=('both', 2))
for i in layouts:
cmds.button(l=i)
cmds.setParent('..')
cmds.setParent('..')
cmds.setParent('..')
cmds.setParent('..')
cmds.setParent('..')
cmds.showWindow()

And you think that example is an argument in _favor_ of what
you propose?
Do such rules make sense?

IMO, no.
Is there any way to make code work that way in Python?
no.

Should there be?

God no.

Code should work the way it looks and look the way it works.
Changing the language in order to allow authors to mislead
readers is a bad thing.
Does that make this sort of code more or less readable?

You must be joking.
 
J

Jonathan Gardner

layouts = ['column', 'form', 'frame']
cmds.window(t='gwfUI Builder')
cmds.paneLayout(configuration='vertical3', ps=((1, 25, 100), (3, 20,
100)))
cmds.paneLayout(configuration='horizontal2')
cmds.frameLayout(l='Layouts')
cmds.scrollLayout(cr=True)
cmds.columnLayout(adj=True, cat=('both', 2))
for i in layouts:
cmds.button(l=i)
cmds.setParent('..')
cmds.setParent('..')
cmds.setParent('..')
cmds.setParent('..')
cmds.setParent('..')
cmds.showWindow()

While Grant is pulling his hair out and yelling obscenities at the
moon, let me try to explain why you'd never want to indent code that
way, let alone write code that way.

In cases where you have to run a sequence of code in a nested way,
like this, it's best to create functions and then nest the functions.
Of course, I'm thinking more of a lisp solution and less of a C one.

In this case, you're going to have to have objects (or data
structures) that know what to do to execute the commands necessary.
When you get them all assembled, you simply run them in a recursive
way.

For instance:

cmd.build(('pane', dict(configuration='horizontal'), ('frame',
dict(l='Layouts'), (....))))

You can indent these arbitrarily. Plus, you don't have to worry too
much about matching setParent and the other commands.
 
S

Sam

A friend of mine is picking up some Python and is frustrated by
Python's indentation rules (http://greatbiggary.livejournal.com/
260460.html?thread=1835884#t1835884). Personally, I've never had any
issues with Python's ways of indentation, but that conversation got me
thinking about the issue.
Consider the following indentation rules:
1. Blocks begin with a line ending in ":"
2. A line on the same indentation level or lower ends a block.
Under those rules, this would work:
layouts = ['column', 'form', 'frame']
cmds.window(t='gwfUI Builder')
cmds.paneLayout(configuration='vertical3', ps=((1, 25, 100), (3, 20,
100)))
cmds.paneLayout(configuration='horizontal2')
cmds.frameLayout(l='Layouts')
cmds.scrollLayout(cr=True)
cmds.columnLayout(adj=True, cat=('both', 2))
for i in layouts:
cmds.button(l=i)
cmds.setParent('..')
cmds.setParent('..')
cmds.setParent('..')
cmds.setParent('..')
cmds.setParent('..')
cmds.showWindow()

And you think that example is an argument in _favor_ of what
you propose?
Do such rules make sense?

IMO, no.
Is there any way to make code work that way in Python?
no.

Should there be?

God no.

Code should work the way it looks and look the way it works.
Changing the language in order to allow authors to mislead
readers is a bad thing.
Does that make this sort of code more or less readable?

You must be joking.

Well, using tabs to lay out GUI elements in a hierarchy is something
I've seen before in other programming languages, so it seems that
_some_ people would find that more readable. Admittedly, I don't find
the oddly tabbed code easier to read (it strikes me as about the same
level of readability). The code provided as an example of some non-
Python language being "more readable" (also in the post I linked to)
struck me as far less readable, but I assumed that was only because I
didn't know the language in question.

The question that interests me more is how much power Python
programmers have to alter how the compiler deals with indentation and
so on (within Python, without altering the source code of the compiler
itself or something like that). I couldn't find anything that
indicated that such power exists, but I'm still relatively new to
Python, so I thought that someone on CLP might have a more decisive
answer.

Anyways, thanks for your reply.
 
S

Sam

layouts = ['column', 'form', 'frame']
cmds.window(t='gwfUI Builder')
cmds.paneLayout(configuration='vertical3', ps=((1, 25, 100), (3, 20,
100)))
cmds.paneLayout(configuration='horizontal2')
cmds.frameLayout(l='Layouts')
cmds.scrollLayout(cr=True)
cmds.columnLayout(adj=True, cat=('both', 2))
for i in layouts:
cmds.button(l=i)
cmds.setParent('..')
cmds.setParent('..')
cmds.setParent('..')
cmds.setParent('..')
cmds.setParent('..')
cmds.showWindow()

While Grant is pulling his hair out and yelling obscenities at the
moon, let me try to explain why you'd never want to indent code that
way, let alone write code that way.

In cases where you have to run a sequence of code in a nested way,
like this, it's best to create functions and then nest the functions.
Of course, I'm thinking more of a lisp solution and less of a C one.

In this case, you're going to have to have objects (or data
structures) that know what to do to execute the commands necessary.
When you get them all assembled, you simply run them in a recursive
way.

For instance:

cmd.build(('pane', dict(configuration='horizontal'), ('frame',
dict(l='Layouts'), (....))))

You can indent these arbitrarily. Plus, you don't have to worry too
much about matching setParent and the other commands.

That makes sense to me. The library that was being used in that
example didn't strike me as very Pythonic (what with the using one
command object for everything and calling setParent('..') to point to
the next object up in the hierarchy). But there's no reason (as far
as I know) that he couldn't create helper functions to wrap that with
something more sane.
 
J

Jason

layouts = ['column', 'form', 'frame']
cmds.window(t='gwfUI Builder')
cmds.paneLayout(configuration='vertical3', ps=((1, 25, 100), (3, 20,
100)))
cmds.paneLayout(configuration='horizontal2')
cmds.frameLayout(l='Layouts')
cmds.scrollLayout(cr=True)
cmds.columnLayout(adj=True, cat=('both', 2))
for i in layouts:
cmds.button(l=i)
cmds.setParent('..')
cmds.setParent('..')
cmds.setParent('..')
cmds.setParent('..')
cmds.setParent('..')
cmds.showWindow()
While Grant is pulling his hair out and yelling obscenities at the
moon, let me try to explain why you'd never want to indent code that
way, let alone write code that way.
In cases where you have to run a sequence of code in a nested way,
like this, it's best to create functions and then nest the functions.
Of course, I'm thinking more of a lisp solution and less of a C one.
In this case, you're going to have to have objects (or data
structures) that know what to do to execute the commands necessary.
When you get them all assembled, you simply run them in a recursive
way.
For instance:
cmd.build(('pane', dict(configuration='horizontal'), ('frame',
dict(l='Layouts'), (....))))
You can indent these arbitrarily. Plus, you don't have to worry too
much about matching setParent and the other commands.

That makes sense to me. The library that was being used in that
example didn't strike me as very Pythonic (what with the using one
command object for everything and calling setParent('..') to point to
the next object up in the hierarchy). But there's no reason (as far
as I know) that he couldn't create helper functions to wrap that with
something more sane.

Let me add that, for lots of GUI layout, most programming languages
are the wrong tool for the job. GUI layout involves tons of nested,
almost boiler-plate type data. Use a tool to generate the layout that
the code can load, and perform the few tweaks that you might need.
This makes things far more sane, especially for anyone who has to
maintain the layout later.

The lack of such a layout tool is a weakness of your GUI library, not
necessarily a problem with the program language.

--Jason
 
G

Grant Edwards

layouts = ['column', 'form', 'frame']
cmds.window(t='gwfUI Builder')
cmds.paneLayout(configuration='vertical3', ps=((1, 25, 100), (3, 20,
100)))
cmds.paneLayout(configuration='horizontal2')
cmds.frameLayout(l='Layouts')
cmds.scrollLayout(cr=True)
cmds.columnLayout(adj=True, cat=('both', 2))
for i in layouts:
cmds.button(l=i)
cmds.setParent('..')
cmds.setParent('..')
cmds.setParent('..')
cmds.setParent('..')
cmds.setParent('..')
cmds.showWindow()

While Grant is pulling his hair out and yelling obscenities at the
moon,

Damn. I thought that webcam was shut off...
 
G

gDog

Hi, Sam-

I'm not wanting to start a flame war, either, but may I ask why does
your friend want to do that? I'm always intrigued by the folks who
object to the indentation rules in Python, even though I've always
tried to keep consistent indentation in all the languages I've used
(and I've been at this since the 1980's). Even my Perl coding friends
tend to insist on indents being aligned. I'm just curious, that's
all.

Thanks,
--greg
 
S

Sam

Hi, Sam-

I'm not wanting to start a flame war, either, but may I ask why does
your friend want to do that? I'm always intrigued by the folks who
object to the indentation rules in Python, even though I've always
tried to keep consistent indentation in all the languages I've used
(and I've been at this since the 1980's). Even my Perl coding friends
tend to insist on indents being aligned. I'm just curious, that's
all.

Thanks,
--greg

His comments on the subject are in the LiveJournal comment I linked to
in my original post. I think it's mostly an idiosyncratic thing; he's
used to laying out GUI elements in a hierarchy using tabs (in some
language that allows arbitrary tabs) and now that he's experimenting
with the (new?) Python API for the same toolkit, he wishes he could
use the same coding style.
 
C

Chris Mellon

His comments on the subject are in the LiveJournal comment I linked to
in my original post. I think it's mostly an idiosyncratic thing; he's
used to laying out GUI elements in a hierarchy using tabs (in some
language that allows arbitrary tabs) and now that he's experimenting
with the (new?) Python API for the same toolkit, he wishes he could
use the same coding style.


It's interesting that the solutions "move away from the terrible
abomination of a GUI toolkit" and "write Python wrappers that don't
cause actual physical pain" never occur to him. He's got a lot of
years invested in this layout so I understand the hesitance to move
away from it, but seriously - this is a really terrible way to do GUI
layout. The context manager solution is probably the best way to
maintain something close to the style he's used to.

All those setParent calls! *shiver*. I notice he retreats to the
"well, *I* can read it, so it's not unreadable" defense, which of
course applies to anything (I know people who can read x86 assembly
directly from hex dumps) without really addressing the merits of a
particular case.
 
G

Gary

Hi! I'd like to join the fray, as the person who posted that original
LJ rant. First, some full disclosure, and stampings out of what seem
to me to be misconceptions...

1) I am not a CS major. I majored in Computer Animation at an art
college. I'm quite well aware that I don't know all there is to know
about scripting, let alone programming. I've always been rather
technically minded, and many have wondered why I didn't just go the CS
route, but I think I'm too much of a hippy artsy type for it.
2) I started in gw basic, and Qbasic, in '92, but have also used a bit
of C++, x86 Assembly, PIC Assembly (PIC Microchips), many BASICs for
software and hardware (e.g. DarkBASIC, PBasic (Parallax BASIC Stamps),
TI BASIC for calculators, etc), lots of Perl for several years,
Actionscript/Javascript, a bit of Java, of course many of the web
languages, some bash script, pretty much anything that exposes some
scripting tools to me, and have even toyed lightly in Lisp, and am
curious about Haskell. I'm certainly no expert programmer, but I've
been around the block, and at least know a bit of, and about what's
out there.
3) I'm not at all married to anything. I've been on 4 different
Windows since '92, and used Macs between '95-'99, but switched
entirely (at home) to Linux over a year ago. I've since mostly given
up on GUI text editors, preferring the sleekness of Vim, and the power
of work in the shell. Now that Python is available to me in Maya, I'm
VERY interested in leaving MEL behind :) Clearly, I'm capable of
change, and even do so rather willingly at times.
4) I know deep down that you may all be right, and that I could even
be completely insane, making any of my thoughts the irrational
mumblings of a crazed man, but in order to accomplish anything, like
getting out of bed in the morning, I must at least believe I am
capable of rational thought, learning, and self-improvement. As an
example, I believe this point #4 to be at least a somewhat rational
set of statements.

Grant Edwards said:
"Code should work the way it looks and look the way it works."

I fully agree. To that end, the MEL UI code I write does look exactly
like how it works to me. To me, the layouts are a stack of a
containers, which can be thought of in 3D like this (example found
online):

http://homepages.inf.ed.ac.uk/group/slip0506_a/shen/img/gui_layout.jpg

....which look quite like indented blocks in that view, with siblings
indented the same amount beyond their parent. Here's the thing that
really gets me, though about everyone's total consternation here: What
I'm doing in MEL is not a new concept, or even a strange concept. It's
not even what a huge chunk of the populace would call a *bad* concept.
It's ostensibly HTML. HTML is a declarative language. The way I'm
using the MEL UI code here is very much that - declarative. Perhaps
the problem here is that you're all steeped in imperative thoughts,
but honestly, I don't see much of a difference here. The examples so
far in the group are nests of functions that are honestly, woefully
less readable to me than simple indentations to 'declare' (to myself,
visually) how things line up in the hierarchy, which when it comes
down to it, is all that UIs are - they're hierarchies of containers -
but they don't ultimately change what I'm doing, or express anything
much differently. You're still creating a nesting, or a hierarchy of
controls and layouts. You just seem to want to wrap them all in
functions, which then all nest each other to create the layout. I
don't get what I win by doing that, but I do see something perhaps
minor that I clearly lose by doing that - readability (sorry, but I
do). Hierarchies are by-and-large expressed with indentations. Here's
a perfect example:

http://borumat.de/bilder/dreamweaver/html-quellcode-und-wysiwym-editor.png

Knowing only one thing about HTML itself - namely, that tags tend to
have a closing version of themselves - anyone can see immediately
what's going on. For example, I could tell in 2 seconds that the ul
element had 2 li elements, the second of which seems to have a table
element, which itself has 2 tr elements. I don't even need to know
what those are, but I can see them, and clearly, and immediately.

But why stop there? How about XML? Here's another example:

http://www.redversconsulting.co.uk/cobol/xml/cobol-xml-sample.gif

Right away, I can see that there's a TRAIN that has a LOCOMOTIVE, and
2 CARRIAGES. So can you. So can anyone, which is why they came up with
the concept of indenting blocks of siblings under their parents in
this fashion. It makes sense. It's natural.

Glade - a cross-browser UI building toolset primarily for Linux uses
XML now to store the UIs you build. Because of this, it's highly human-
readable. You can read the files it saves out just as in my examples
above, because of the indents that visually group everything. This
also means you can easily tweak things after the fact, say on apps you
download - and I have, and it was fun, and simple. Also, Glade can
load up the XML, parse it, and rebuild the UI so you can further
visually edit things, and save them back out to the XML, and the
library now works directly with the XML, instead of generating a mess
of nested code, which was the old way. The library is what you include
in your app, and you point it at the XML for your particular UI, and
it parses it when you load the program. It's elegant - the same XML is
used for 3 different purposes, and provides a helpful 4th, namely
being elegantly human-readable. Also, when you're editing in Glade,
the UI elements are presented in a tree, which shows up visually as
get this - *indented items*:

http://www.linux.ie/articles/gimp-plugin/part3/glade-tree.png

These helpful indents seem to be everywhere! :) Sorry, I don't mean to
be an ass about it.

Grant Edwards also said:
"Changing the language in order to allow authors to mislead readers is
a bad thing."

I'm not sure exactly what you mean by this, but I'm not really asking
for the language to be changed. I think mostly I'm simply pointing out
that it was very easy in MEL to express what I wanted in a simple,
straightforward, very readable way, but in Python, this seems not to
exist. I was looking for the Pythonic way to do it, but every example
so far takes this very simple concept, and makes it a rather
complicated affair, IMHO.

Jonathan Gardener said:
"cmd.build(('pane', dict(configuration='horizontal'), ('frame',
dict(l='Layouts'), (....))))"

Holy sh*t! Sorry, but that's waaay less readable. Imagine that
swelling up to hundreds of controls and layouts, all with flags, and
flag arguments. Very Lisp-like, though! I did indent that out, as you
suggested could be done, and it was passable. It still wasn't as
simple, and yes, readable as what I've been doing, which again is a
very short jump from straight XML, or HTML, but it was something I
could live with. Congrats on that.

Jason said:
"Let me add that, for lots of GUI layout, most programming languages
are the wrong tool for the job."

I can probably agree with that, but I'd like to point out that the few
that are typically used primarily for GUI layout do precisely what
I've been doing with the MEL - they indent it in a similar fashion.

He also said:
"The lack of such a layout tool is a weakness of your GUI library, not
necessarily a problem with the program language."

I don't know that the GUI library is to blame. Python came along a
decade later for Maya, where MEL had already established a simple
method for building UIs for that decade as well as it could, given its
simplicity, and limitations. Python, while not wrapping the MEL,
sought to emulate it directly, so the learning curve was minimized.
This lead to certainly non-Pythonic methods, but I don't blame the UI
for that. This was an attempt to quickly drop in another language to
give us Maya users a second option. If anything, I think it's Maya
that should provide the UI builder, because it's Maya that included
the Python, and it's for Maya that the UIs would be built,
exclusively.

However, I believe there should be a tool, and am trying to use Python
to build that tool. I've wanted it for years, and have tried a few
times in MEL, as have a few other folks, but nothing's ever come of
it, because there are no good data structures in MEL, so you first
have to do something crazy, like emulate lists, and/or dictionaries,
which I've done, but it's thousands of lines of code that took me a
year of off-and-on work to create, and it still isn't really where I
need it to be. I was eager specifically because of this to switch to
Python, but it's been a depressing, uphill battle. None of the other
languages I've used have seemed so erratic - even Perl! Don't get me
wrong, though, I do love lots of little things so far about Python,
and am still interested. I'm also interested in the possibility that
more knowledge will wipe away some of my disappointments.

gDog said:
"...I'm always intrigued by the folks who object to the indentation
rules in Python..."

But see... I don't. I LOVE that it forces proper indentation. It's
actually creates one of the warm spots in my heart in regards to
Python. I never said that Python's indentations were a bad thing. I'm
saying UI layout indentations are a GOOD thing :)

....and continues:
"...even though I've always tried to keep consistent indentation in
all the languages I've used..."

Me too. If you look through any of the quite literally tens of
thousands of lines of MEL code in my personal SVN repo, every last
line is perfectly indented. I'm manic about it. I'm the kind who will
occasionally take 15 minutes just to run through a few thousand lines
of code to double-check that it's all absolutely perfect, so I feel
better. It goes well beyond that. I even hate trailing spaces. I check
for, and trim trailing spaces all the time, and have qualms over using
anyone's code that doesn't seem to be so rigid in their clean layouts,
because it feels indicative of sloppiness in thinking to me. I have a
full style I've refined over the last decade that takes in everything
from whitespace, and capitalizations, to naming conventions, and even
spelling - all my variables are always properly spelled. My style must
absolutely be adhered to, and I fight with people to keep it all up to
spec, and don't let iditos in my code. If there's ever a problem in my
code, it will always be a logical slip-up, or as I would like to call
it - a 'true error.' It hasn't for 6 years in MEL ever been something
trivial like a typo (after the initial write/test phase).

That said, I'm almost 100% on-board with Python's style. Almost all of
it I like. I love dropping the need for all the curly braces around my
blocks, and not having to end anything beyond unindenting. It's
[usually] very freeing to code in Python, sans a few of my sticking
points.

Chris Mellon writes:
"""It's interesting that the solutions "move away from the terrible
abomination of a GUI toolkit" and "write Python wrappers that don't
cause actual physical pain" never occur to him."""

Oh, but they have, and almost immediately. You're assuming, perhaps,
however, that I have the chops for that at such an early stage in my
new Python life, or that I'm excited about the prospect of jumping
right into a new library, only to have to virtually start over,
wrapping some 15-20 layouts, and maybe 50+ controls in wrappers. In
either case, you would assume wrong.

....and continues:
"He's got a lot of years invested in this layout so I understand the
hesitance to move away from it..."

Yes! I have lots of years invested! But, no! I'm not hesitant! I'm
ready! Let's go! I'm totally prepped to be done with MEL :)

....and furthermore states:
"...but seriously - this is a really terrible way to do GUI layout."

Oh, c'mon, no it's not. It's nearly the same thing as HTML, as I said.
Are you going to seriously denounce more than a decade of that, and
tens of thousands, if not millions of people using it in every
language, in countless implementations the world over? I'm not saying
it can't be better, but *terrible?* Yes, I'm being declarative of my
layouts right inside my code, which might be weird, but that's only
because I'm adaptable, and it was the best way to do it in MEL, which
has been my only option in Maya since the mid 90s. It's been solid for
me, and honestly, once you're past a bit of the strangeness of it, is
very straightforward, and simple. It's not the best, but it's not
*terrible.*

....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.

....will he ever stop? I don't know:
"I notice he retreats to the "well, *I* can read it, so it's not
unreadable" defense..."

I can read it, because it's a natural style, as seen all over the
place in HTML, XML, many UI layout tools, folder trees, complicated
task lists, book outlines, and the list goes on. Seriously, what is
with you people?

....and is almost done with:
"I know people who can read x86 assembly directly from hex dumps"

I rather enjoyed coding in x86, and once created a SWF file (compiled
Flash binary), by hand, entirely at the *bit* (not byte) level. It
took hours to get only several hundred bytes, but it worked! This, I
realize, is not a good argument in my favor.

....and FINALLY finishes:
"without really addressing the merits of a particular case."

But I have, over and over. It's very readable. It's a hierarchy of
layouts and controls, expressed in a hierarchy of indented blocks that
match up 1:1 with each other.

What I've noticed is that no one in here as yet has backed themselves
up. Let me pick one, without creating an exhaustive list:

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 :)

Please don't regard any of the above as the embers of an impending
flame war. I'm not interested in fighting, really. I'm here
specifically because I'm interested in Python now, and it sounds like
you guys might know something important that I don't, and I'd like to
know what that might be. I'm always interested in learning, so teach
me already! Thanks for reading all of this, if you did indeed do so.
 
G

Gary

Hi! I'd like to join the fray, as the person who posted that original
LJ rant. First, some full disclosure, and stampings out of what seem
to me to be misconceptions...

1) I am not a CS major. I majored in Computer Animation at an art
college. I'm quite well aware that I don't know all there is to know
about scripting, let alone programming. I've always been rather
technically minded, and many have wondered why I didn't just go the CS
route, but I think I'm too much of a hippy artsy type for it.
2) I started in gw basic, and Qbasic, in '92, but have also used a bit
of C++, x86 Assembly, PIC Assembly (PIC Microchips), many BASICs for
software and hardware (e.g. DarkBASIC, PBasic (Parallax BASIC Stamps),
TI BASIC for calculators, etc), lots of Perl for several years,
Actionscript/Javascript, a bit of Java, of course many of the web
languages, some bash script, pretty much anything that exposes some
scripting tools to me, and have even toyed lightly in Lisp, and am
curious about Haskell. I'm certainly no expert programmer, but I've
been around the block, and at least know a bit of, and about what's
out there.
3) I'm not at all married to anything. I've been on 4 different
Windows since '92, and used Macs between '95-'99, but switched
entirely (at home) to Linux over a year ago. I've since mostly given
up on GUI text editors, preferring the sleekness of Vim, and the power
of work in the shell. Now that Python is available to me in Maya, I'm
VERY interested in leaving MEL behind :) Clearly, I'm capable of
change, and even do so rather willingly at times.
4) I know deep down that you may all be right, and that I could even
be completely insane, making any of my thoughts the irrational
mumblings of a crazed man, but in order to accomplish anything, like
getting out of bed in the morning, I must at least believe I am
capable of rational thought, learning, and self-improvement. As an
example, I believe this point #4 to be at least a somewhat rational
set of statements.

Grant Edwards said:
"Code should work the way it looks and look the way it works."

I fully agree. To that end, the MEL UI code I write does look exactly
like how it works to me. To me, the layouts are a stack of a
containers, which can be thought of in 3D like this (example found
online):

http://homepages.inf.ed.ac.uk/group/slip0506_a/shen/img/gui_layout.jpg

....which look quite like indented blocks in that view, with siblings
indented the same amount beyond their parent. Here's the thing that
really gets me, though about everyone's total consternation here: What
I'm doing in MEL is not a new concept, or even a strange concept. It's
not even what a huge chunk of the populace would call a *bad* concept.
It's ostensibly HTML. HTML is a declarative language. The way I'm
using the MEL UI code here is very much that - declarative. Perhaps
the problem here is that you're all steeped in imperative thoughts,
but honestly, I don't see much of a difference here. The examples so
far in the group are nests of functions that are honestly, woefully
less readable to me than simple indentations to 'declare' (to myself,
visually) how things line up in the hierarchy, which when it comes
down to it, is all that UIs are - they're hierarchies of containers -
but they don't ultimately change what I'm doing, or express anything
much differently. You're still creating a nesting, or a hierarchy of
controls and layouts. You just seem to want to wrap them all in
functions, which then all nest each other to create the layout. I
don't get what I win by doing that, but I do see something perhaps
minor that I clearly lose by doing that - readability (sorry, but I
do). Hierarchies are by-and-large expressed with indentations. Here's
a perfect example:

http://borumat.de/bilder/dreamweaver/html-quellcode-und-wysiwym-editor.png

Knowing only one thing about HTML itself - namely, that tags tend to
have a closing version of themselves - anyone can see immediately
what's going on. For example, I could tell in 2 seconds that the ul
element had 2 li elements, the second of which seems to have a table
element, which itself has 2 tr elements. I don't even need to know
what those are, but I can see them, and clearly, and immediately.

But why stop there? How about XML? Here's another example:

http://www.redversconsulting.co.uk/cobol/xml/cobol-xml-sample.gif

Right away, I can see that there's a TRAIN that has a LOCOMOTIVE, and
2 CARRIAGES. So can you. So can anyone, which is why they came up with
the concept of indenting blocks of siblings under their parents in
this fashion. It makes sense. It's natural.

Glade - a cross-browser UI building toolset primarily for Linux uses
XML now to store the UIs you build. Because of this, it's highly human-
readable. You can read the files it saves out just as in my examples
above, because of the indents that visually group everything. This
also means you can easily tweak things after the fact, say on apps you
download - and I have, and it was fun, and simple. Also, Glade can
load up the XML, parse it, and rebuild the UI so you can further
visually edit things, and save them back out to the XML, and the
library now works directly with the XML, instead of generating a mess
of nested code, which was the old way. The library is what you include
in your app, and you point it at the XML for your particular UI, and
it parses it when you load the program. It's elegant - the same XML is
used for 3 different purposes, and provides a helpful 4th, namely
being elegantly human-readable. Also, when you're editing in Glade,
the UI elements are presented in a tree, which shows up visually as
get this - *indented items*:

http://www.linux.ie/articles/gimp-plugin/part3/glade-tree.png

These helpful indents seem to be everywhere! :) Sorry, I don't mean to
be an ass about it.

Grant Edwards also said:
"Changing the language in order to allow authors to mislead readers is
a bad thing."

I'm not sure exactly what you mean by this, but I'm not really asking
for the language to be changed. I think mostly I'm simply pointing out
that it was very easy in MEL to express what I wanted in a simple,
straightforward, very readable way, but in Python, this seems not to
exist. I was looking for the Pythonic way to do it, but every example
so far takes this very simple concept, and makes it a rather
complicated affair, IMHO.

Jonathan Gardener said:
"cmd.build(('pane', dict(configuration='horizontal'), ('frame',
dict(l='Layouts'), (....))))"

Holy sh*t! Sorry, but that's waaay less readable. Imagine that
swelling up to hundreds of controls and layouts, all with flags, and
flag arguments. Very Lisp-like, though! I did indent that out, as you
suggested could be done, and it was passable. It still wasn't as
simple, and yes, readable as what I've been doing, which again is a
very short jump from straight XML, or HTML, but it was something I
could live with. Congrats on that.

Jason said:
"Let me add that, for lots of GUI layout, most programming languages
are the wrong tool for the job."

I can probably agree with that, but I'd like to point out that the few
that are typically used primarily for GUI layout do precisely what
I've been doing with the MEL - they indent it in a similar fashion.

He also said:
"The lack of such a layout tool is a weakness of your GUI library, not
necessarily a problem with the program language."

I don't know that the GUI library is to blame. Python came along a
decade later for Maya, where MEL had already established a simple
method for building UIs for that decade as well as it could, given its
simplicity, and limitations. Python, while not wrapping the MEL,
sought to emulate it directly, so the learning curve was minimized.
This lead to certainly non-Pythonic methods, but I don't blame the UI
for that. This was an attempt to quickly drop in another language to
give us Maya users a second option. If anything, I think it's Maya
that should provide the UI builder, because it's Maya that included
the Python, and it's for Maya that the UIs would be built,
exclusively.

However, I believe there should be a tool, and am trying to use Python
to build that tool. I've wanted it for years, and have tried a few
times in MEL, as have a few other folks, but nothing's ever come of
it, because there are no good data structures in MEL, so you first
have to do something crazy, like emulate lists, and/or dictionaries,
which I've done, but it's thousands of lines of code that took me a
year of off-and-on work to create, and it still isn't really where I
need it to be. I was eager specifically because of this to switch to
Python, but it's been a depressing, uphill battle. None of the other
languages I've used have seemed so erratic - even Perl! Don't get me
wrong, though, I do love lots of little things so far about Python,
and am still interested. I'm also interested in the possibility that
more knowledge will wipe away some of my disappointments.

gDog said:
"...I'm always intrigued by the folks who object to the indentation
rules in Python..."

But see... I don't. I LOVE that it forces proper indentation. It's
actually creates one of the warm spots in my heart in regards to
Python. I never said that Python's indentations were a bad thing. I'm
saying UI layout indentations are a GOOD thing :)

....and continues:
"...even though I've always tried to keep consistent indentation in
all the languages I've used..."

Me too. If you look through any of the quite literally tens of
thousands of lines of MEL code in my personal SVN repo, every last
line is perfectly indented. I'm manic about it. I'm the kind who will
occasionally take 15 minutes just to run through a few thousand lines
of code to double-check that it's all absolutely perfect, so I feel
better. It goes well beyond that. I even hate trailing spaces. I check
for, and trim trailing spaces all the time, and have qualms over using
anyone's code that doesn't seem to be so rigid in their clean layouts,
because it feels indicative of sloppiness in thinking to me. I have a
full style I've refined over the last decade that takes in everything
from whitespace, and capitalizations, to naming conventions, and even
spelling - all my variables are always properly spelled. My style must
absolutely be adhered to, and I fight with people to keep it all up to
spec, and don't let iditos in my code. If there's ever a problem in my
code, it will always be a logical slip-up, or as I would like to call
it - a 'true error.' It hasn't for 6 years in MEL ever been something
trivial like a typo (after the initial write/test phase).

That said, I'm almost 100% on-board with Python's style. Almost all of
it I like. I love dropping the need for all the curly braces around my
blocks, and not having to end anything beyond unindenting. It's
[usually] very freeing to code in Python, sans a few of my sticking
points.

Chris Mellon writes:
"""It's interesting that the solutions "move away from the terrible
abomination of a GUI toolkit" and "write Python wrappers that don't
cause actual physical pain" never occur to him."""

Oh, but they have, and almost immediately. You're assuming, perhaps,
however, that I have the chops for that at such an early stage in my
new Python life, or that I'm excited about the prospect of jumping
right into a new library, only to have to virtually start over,
wrapping some 15-20 layouts, and maybe 50+ controls in wrappers. In
either case, you would assume wrong.

....and continues:
"He's got a lot of years invested in this layout so I understand the
hesitance to move away from it..."

Yes! I have lots of years invested! But, no! I'm not hesitant! I'm
ready! Let's go! I'm totally prepped to be done with MEL :)

....and furthermore states:
"...but seriously - this is a really terrible way to do GUI layout."

Oh, c'mon, no it's not. It's nearly the same thing as HTML, as I said.
Are you going to seriously denounce more than a decade of that, and
tens of thousands, if not millions of people using it in every
language, in countless implementations the world over? I'm not saying
it can't be better, but *terrible?* Yes, I'm being declarative of my
layouts right inside my code, which might be weird, but that's only
because I'm adaptable, and it was the best way to do it in MEL, which
has been my only option in Maya since the mid 90s. It's been solid for
me, and honestly, once you're past a bit of the strangeness of it, is
very straightforward, and simple. It's not the best, but it's not
*terrible.*

....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.

....will he ever stop? I don't know:
"I notice he retreats to the "well, *I* can read it, so it's not
unreadable" defense..."

I can read it, because it's a natural style, as seen all over the
place in HTML, XML, many UI layout tools, folder trees, complicated
task lists, book outlines, and the list goes on. Seriously, what is
with you people?

....and is almost done with:
"I know people who can read x86 assembly directly from hex dumps"

I rather enjoyed coding in x86, and once created a SWF file (compiled
Flash binary), by hand, entirely at the *bit* (not byte) level. It
took hours to get only several hundred bytes, but it worked! This, I
realize, is not a good argument in my favor.

....and FINALLY finishes:
"without really addressing the merits of a particular case."

But I have, over and over. It's very readable. It's a hierarchy of
layouts and controls, expressed in a hierarchy of indented blocks that
match up 1:1 with each other.

What I've noticed is that no one in here as yet has backed themselves
up. Let me pick one, without creating an exhaustive list:

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 :)

Please don't regard any of the above as the embers of an impending
flame war. I'm not interested in fighting, really. I'm here
specifically because I'm interested in Python now, and it sounds like
you guys might know something important that I don't, and I'd like to
know what that might be. I'm always interested in learning, so teach
me already! Thanks for reading all of this, if you did indeed do so.
 
G

Grant Edwards

Grant Edwards said:
"Code should work the way it looks and look the way it works."

I fully agree. To that end, the MEL UI code I write does look
exactly like how it works to me. To me, the layouts are a
stack of a containers, which can be thought of in 3D like this
(example found online):

The problem is that to everybody else in the world, indentation
in Python represents control flow nesting, not GUI widget
nesting.

Even assuming people can learn new things (in my experience an
assumption to be somewhat avoided if possible), under your
proposal indentation _sometimes_ represents control flow
nesting, and sometimes doesn't. That imposes a much greater
burden on the reader: they've got to spend a lot more mental
energy to figure out whether the indentation of each line
represents control flow or something else. That's a bad thing(TM)
 
G

Gary

The problem is that to everybody else in the world, indentation
in Python represents control flow nesting, not GUI widget
nesting.

Thanks, Grant. That's the first solid reasoning I've seen, and it's a
very solid argument, as well. To that end, I'm thinking a few things.
For one, your argument correctly puts forth that using the code in 2
separate ways is not good. Despite doing just that for 6 years with no
problems, I can agree with you on that point. For another, I don't
really think the proposals, or hints at how to do it in Python are all
that great, either, because they create what I believe to be a bigger
mess.

I'm kind of leaning toward a Glade approach, wherein I wrap the UI
elements up with an XML parser (I'm sure those exist for me already),
and have some set of UI building functions build the UI for me with
the crappy Maya calls underneath, based on data extracted from the
XML. Then the UIs would be built as part of the parsing effort. This
sort of hides the ugly stepchild of the Maya method of creating UIs
under calls that each only do one thing, which rids the need to nest
anything directly in Python, and separates out the UI data into XML -
a language specifically made to be indented in a readable fashion,
perfect for UI information. The extra benefit is that UI snippets can
then be reused in the manner of templates, and even 'widgets,' from
which all of my UIs can potentially benefit. I'm sure there's more to
think about in regards to all of this, but it's not only the basis for
a game plan, but it has precedent in places like Glade, to suggest
that it's a viable, and decent option.

Again, thanks.
-g
 
C

Chris Mellon

Chris Mellon writes:
"""It's interesting that the solutions "move away from the terrible
abomination of a GUI toolkit" and "write Python wrappers that don't
cause actual physical pain" never occur to him."""

Oh, but they have, and almost immediately. You're assuming, perhaps,
however, that I have the chops for that at such an early stage in my
new Python life, or that I'm excited about the prospect of jumping
right into a new library, only to have to virtually start over,
wrapping some 15-20 layouts, and maybe 50+ controls in wrappers. In
either case, you would assume wrong.

I overestimated your Python experience when I read the first (last?
most recent) post. After I sent the email I went back through your LJ
post where your level of experience with Python is made much more
plain. I don't mean this in a bad way - you're a beginner and that's
fine - but you don't have a grasp on Pythons fundamentals and thats
why so many things about it seem strange to you. All of the things in
your first post have reasons why they are that way, and there is
internal consistency in all of them. 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.
...and continues:
"He's got a lot of years invested in this layout so I understand the
hesitance to move away from it..."

Yes! I have lots of years invested! But, no! I'm not hesitant! I'm
ready! Let's go! I'm totally prepped to be done with MEL :)

...and furthermore states:
"...but seriously - this is a really terrible way to do GUI layout."

Oh, c'mon, no it's not. It's nearly the same thing as HTML, as I said.
Are you going to seriously denounce more than a decade of that, and
tens of thousands, if not millions of people using it in every
language, in countless implementations the world over?

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.
This is the internet, we don't shy away from scoffing at millions of
misguided souls here ;)
I'm not saying
it can't be better, but *terrible?* Yes, I'm being declarative of my
layouts right inside my code, which might be weird, but that's only
because I'm adaptable, and it was the best way to do it in MEL, which
has been my only option in Maya since the mid 90s. It's been solid for
me, and honestly, once you're past a bit of the strangeness of it, is
very straightforward, and simple. It's not the best, but it's not
*terrible.*

It's very much like writing HTML using only the DOM apis, and not
HTMLs syntatic markup, which *is* terrible.
The structures you're defining are quite reasonable, it's the API
that's bad. I tend to group stuff into categories of "good",
"adequate", and "terrible". This, from the API alone, falls squarely
into "terrible" for me.
...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. You'll note that my language of choice is Python, a language
which explicitly *excluded* the need for an "end block" marker. I'm
pretty sure that there's a way to write Python that looks like the UI,
but it's not using the API you have.
...will he ever stop? I don't know:
"I notice he retreats to the "well, *I* can read it, so it's not
unreadable" defense..."

I can read it, because it's a natural style, as seen all over the
place in HTML, XML, many UI layout tools, folder trees, complicated
task lists, book outlines, and the list goes on. Seriously, what is
with you people?

I'm not so much claiming it's unreasonable as dismissing your argument
why it is. I have to re-iterate: It's *not* markup. It's imperative
code full of explicit state management that you write in a way that
*llooks* like markup, which is a good call on your part because theres
a reason almost everyone uses declarative languages for UI layout
these days.
...and is almost done with:
"I know people who can read x86 assembly directly from hex dumps"

I rather enjoyed coding in x86, and once created a SWF file (compiled
Flash binary), by hand, entirely at the *bit* (not byte) level. It
took hours to get only several hundred bytes, but it worked! This, I
realize, is not a good argument in my favor.

...and FINALLY finishes:
"without really addressing the merits of a particular case."

But I have, over and over. It's very readable. It's a hierarchy of
layouts and controls, expressed in a hierarchy of indented blocks that
match up 1:1 with each other.

This is where the Ruby and Lisp people will come in and gloat about
DSLs, because that's what you've been doing - you've invented a very
simple sort of DSL and embedded in your host language, which happens
to syntatically support the DSL you've chosen. You can do the same
thing in Python, but you have different syntax constraints to conform
to.
What I've noticed is that no one in here as yet has backed themselves
up. Let me pick one, without creating an exhaustive list:

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.
 
R

Ross Ridge

Sam said:
cmds.window(t='gwfUI Builder')
cmds.paneLayout(configuration='vertical3', ps=((1, 25, 100), (3, 20,
100)))
cmds.paneLayout(configuration='horizontal2')
cmds.frameLayout(l='Layouts')
cmds.scrollLayout(cr=True)
cmds.columnLayout(adj=True, cat=('both', 2))
for i in layouts:
cmds.button(l=i)
cmds.setParent('..')
cmds.setParent('..')
cmds.setParent('..')
cmds.setParent('..')
cmds.setParent('..')
cmds.showWindow()

An alternative would be to do something like the following:

cmds.window(t='gwfUI Builder')
cmds.paneLayout(configuration='vertical3', ps=((1, 25, 100),
(3, 20, 100)))
cmds. paneLayout(configuration='horizontal2')
cmds. frameLayout(l='Layouts')
cmds. scrollLayout(cr=True)
cmds. columnLayout(adj=True, cat=('both', 2))
for i in layouts:
cmds. button(l=i)
cmds. setParent('..')
cmds. setParent('..')
cmds. setParent('..')
cmds. setParent('..')
cmds.setParent('..')
cmds.showWindow()

Stylistically it's not much better, but you don't need to change Python
interpreter for it work.

Ross Ridge
 
T

Terry Reedy

| Hi! I'd like to join the fray, as the person who posted that original
| LJ rant. First, some full disclosure, and stampings out of what seem
| to me to be misconceptions...

Hi, Gary. Welcome to Python. I hope you will take some of the reaction
you got as initiatory ribbing.

| 1) I am not a CS major.

Neither am I.

Anyone who loves Python obvious likes the idea of meaningful indentation.
The problem with your suggestion and example is with mixing two meanings in
the same hierarchy. Hence the suggestion that you separate program text
and declarative text.

| Grant Edwards also said:
| "Changing the language in order to allow authors to mislead readers is
| a bad thing."
|
| I'm not sure exactly what you mean by this, but I'm not really asking
| for the language to be changed.

You fooled me as well as others. OK, perhaps you were merely pointing out
that Python could be changed without 'really' asking that the change be
made. However, the subject line, the specifics in the post, and the
example constitute a more basic change in Python than you perhaps realize.
Hence the reaction.

| I think mostly I'm simply pointing out
| that it was very easy in MEL to express what I wanted in a simple,
| straightforward, very readable way, but in Python, this seems not to
| exist. I was looking for the Pythonic way to do it, but every example
| so far takes this very simple concept, and makes it a rather
| complicated affair, IMHO.

The sort of change you mentioned would take at least a couple of years even
if the developers loved it, which I am 99.9% sure they would not.
So in any case, you will have to make do with Python as is for the near
term.

A reasonable question would be something like this. "I currently do gui
layout with MEL [what is that?] and like this but not that. I am looking
at Python because of X. How do people express gui layout within or in
conjuction with Python code?"

Terry Jan Reedy
 
G

Gary

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.
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.
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
 
G

Gary

An alternative would be to do something like the following:

cmds.window(t='gwfUI Builder')
cmds.paneLayout(configuration='vertical3', ps=((1, 25, 100),
(3, 20, 100)))
cmds. paneLayout(configuration='horizontal2')
cmds. frameLayout(l='Layouts')
cmds. scrollLayout(cr=True)
cmds. columnLayout(adj=True, cat=('both', 2))
for i in layouts:
cmds. button(l=i)
cmds. setParent('..')
cmds. setParent('..')
cmds. setParent('..')
cmds. setParent('..')
cmds.setParent('..')
cmds.showWindow()

Stylistically it's not much better, but you don't need to change Python
interpreter for it work.

I'm adding this to my list of crazy things not to do :) I'm also
adding it to my list of code snippets I can use to injure Python
programmers, if the need arises. Thanks!

-g
 
G

Gary

An alternative would be to do something like the following:

cmds.window(t='gwfUI Builder')
cmds.paneLayout(configuration='vertical3', ps=((1, 25, 100),
(3, 20, 100)))
cmds. paneLayout(configuration='horizontal2')
cmds. frameLayout(l='Layouts')
cmds. scrollLayout(cr=True)
cmds. columnLayout(adj=True, cat=('both', 2))
for i in layouts:
cmds. button(l=i)
cmds. setParent('..')
cmds. setParent('..')
cmds. setParent('..')
cmds. setParent('..')
cmds.setParent('..')
cmds.showWindow()

Stylistically it's not much better, but you don't need to change Python
interpreter for it work.

I'm adding this to my list of crazy things not to do :) I'm also
adding it to my list of code snippets I can use to injure Python
programmers, if the need arises. Thanks!

-g
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,743
Messages
2,569,478
Members
44,899
Latest member
RodneyMcAu

Latest Threads

Top