<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">Il giorno gio 3 ott 2019 alle ore 19:33 Stephen Waterbury <<a href="mailto:waterbug@pangalactic.us">waterbug@pangalactic.us</a>> ha scritto:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF">
<blockquote type="cite">Designer does not generate Python (nor C++) code. That's what
the uic programs are for. You can even load .ui files into PyQt
without there ever even being Python source code (in a file or
otherwise). Regardless, it's generated stuff just like any
other. Do you also get upset at coders when their .pyc files
are illegible? What about their .o files? or .exe?
<br>
<br>
Doing more work is not the same as being a better coder.
<br>
<br>
</blockquote>
Designer doesn't necessarily enable one to "do less work", e.g.
for an experienced<br>
programmer who has lots of reusable code.<br></div></blockquote><div><br></div><div>That's exactly my point. Designer is not meant to be that wonderful magic wand that does whatever the [wannabe or even pro] developer wants it to.<br>No tool does that.</div><div>Ever. In any field, not just programming.</div><div><br></div><div>And luckily, I might add.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF"><blockquote type="cite">
Nobody is arguing Designer should always be used or that the
resulting .py files should be read. I in part used it because
it allows non-Python-developers to drop in my custom widgets and
add values to them as to what data feeds they should be hooked
to and layout the entire dashboard with drag'n'drop. My actual
code is all but unaware of any specific thing about the gui.
Just searches and finds the various sorts of generic widgets it
knows about and hooks them up to the data signals.
<br>
</blockquote>
<p></p>
You don't need Designer to make your application work that way -- I
don't use Designer and<br>
my app works similarly with drag/droppable widgets, dashboards,
etc. That technique<br>
is actually completely orthogonal to the issue of whether to use
Designer.<br></div></blockquote><div></div></div><div><br>I'm with Kyle about the whole "who cares about the contents of .ui files or pyuic generated ones".<br>After years of experience with Qt I learnt that there's [almost] really no need to care about their contents (as most web developers rightfully and wisely don't care about what their js frameworks dinamically create, just to say). I even stopped using pyuic at all, because all the fuss we should take care about is about ensuring that <font face="monospace">loadUi()</font> actually uses the right paths, so we don't even have to care about "rebuilding" ui>py files each time a property has been changed.</div><div><br>On the other side, I find myself to strongly agree with Dennis, because (as Florian already pointed out) to a beginner, the pyuic generated files *are* confusing.</div><div>What should I do with that?<br>Do I start programming with that file? Can I edit it?</div><div>What do all those [mostly-useless-for-general-use] functions do? Are they necessary? Should I keep them?</div><div><div>What does it mean that "all changes will be lost"? I can copy the file, I won't loose anything!</div><div>...oh wait.</div><div></div></div><div><br></div><div>I believe that there are 2 issues about that, both of them strongly linked one each other, and, still, really far apart.</div><div>1. Social evolution and perception of computer science (as in "programming"): in the last 5-10 years a *lot* of people got in touch with "coding", most of them without any kind of background. They have a "grasp" of the concepts, but they miss most of the logics. 10-20 years ago, those people were a very small percentage of the overall "community", and big-project developers could just "ignore" them: programming is ("was") not easy, if you're not eager to patiently understand the concepts, just do something else. I'm a musician and a musical teacher, and I've never felt that huge gap I feel today between those who "respectfully" understand how music can be created (no matter what tools they have) and people thinking that buying 500$ worth of hardware or software would make them instantly platinum-artists.</div><div>2. Even the most skilled developers look for automation of boring (as in painfully and mostly repeating) tasks. That's not just about "I don't want to click and type more than I could", but "I have to focus on *this*, because I can focus on *that* in another moment", or even "I do this now, so that I don't think about it later". That's the reason for which most of us create static functions for common tasks, even if sometimes it can be some kind of an overkill. And that is exactly what tools like Designer (and pyuic) do. They create a "standardized" code, that can work with *anybody*. That's what we in Italy call "con tutti i fronzoli" ("frills").<br>They're mostly useless? Yes, of course. But what would the alternative be? An unnecessary dialog with dozens of options that is shown everytime a developer saves the dialog? Dozens of tar-like command line "default" options for pyuic, to avoid some milliseconds-run-taking lines of code that maybe some day the developer would need (and wouldn't realize that she/he could add when rebuilding the dozens of files of the project)? C'mon. I believe that we're past that painful 640k memory myth and CPU clock limits since two decades at least.</div><div><br>Is the pyuic output sometimes an overkill? Yes, it is.<br>Is pyuic output necessary? Usually, not.</div><div>Can something be done about those auto-generated files, without overcomplicating things for *everybody*? No.</div><div>Can something be done to let beginners better understand what they *should* do? Yes (but users are the worst, we know; we're users, we know that ;-) ).<br>Despite all of that, should we, as [skillful] programmers care about that content (ui or py) for our needs, as long as it *can* help use save time and mental energy? Absolutely not.</div><div>Should we use it everytime? Absolutely not!</div><div>Should we advise against it no matter what? Again, no. Not ever, if that's without consciousness.<br><br>As a teacher (and son of teachers), I can only say that there's no use in saying people something as "don't do that", even with the most rightful and wise suggestions. And explaining why "doing that won't work", well... wont' work.</div><div>For example, I could just tell Dennis to try and use more punctuation, but I know that it won't get anywhere, if not worst. Nonetheless, I could ask him if he would like to *try* to use a *better* punctuation, since I know that not everybody in this list is fluent in english (I'm not), and reading lines-long sentencies is not as easy as one could think. But, even then, I'd leave that opinion to his experience, and I won't be able (nor want) to do anything else... As long as punctuation is not considered a "black-box" ;-)</div><div>(Dennis, I'm just joking, don't take it too seriously)</div><div><br></div><div>Cheers,</div><div>Maurizio</div><div><br></div>-- <br><div dir="ltr" class="gmail_signature">È difficile avere una convinzione precisa quando si parla delle ragioni del cuore. - "Sostiene Pereira", Antonio Tabucchi<br><a href="http://www.jidesk.net" target="_blank">http://www.jidesk.net</a></div><div dir="ltr" class="gmail_signature"><br></div></div></div></div></div></div></div></div>