-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 09/06/2010 09:37 PM, Lorenzo Marcantonio wrote: > On Mon, 6 Sep 2010, Alex G wrote: > >> I don't use kicad comercially, at least not yet. Eye candy or not, the >> truth of the matter is that the 3D view is a unique feature to kicad, >> and is not worth neglecting. > > Never said to neglect it. I was explaining why I didn't even mess with > the 3d models. I *have* used boxes for interference checking, though. > The 3d models are a pain in the gluteus maximus to make, I agree, and I don't blame anyone for not wanting to get their hands dirty with them. The question is on striking a balance between this and not having them left out.
>> My instinct would be to find gluPerspective and combine it in a switch >> with glOrtho, but I haven't fully digested the way kicad does it. One > > That's exactly the way it should be done. > Great! The next time I open the kicad source, I'll look for where to put that. I think I've already figured out how to add buttons to the GUI :p . >> thing I generally hate about C++, is people not using this-> when >> accessing members of the current object. It would make things so much >> more clear, and it's the reason I'm slow at digesting kicad. > > It's not idiomatic in C++ where encapsulation is somewhat strong. > I think you could be the only one proposing said syntax :D (also, there is > one exception: this isn't available/reliable in constructors and > destructors). > Constructors and destructors are a different story, and the reason we have (well, C++ has) initialization lists, which make things explicit. Either way, I am not trying to propose this syntax. I'm simply describing the current one as a minor grudge. > Maybe you're coming from an OO model where the this/self pointer is > explicit (like perl, lua and many others). Remember it's from a family > of languages where terseness is valued. CLOS on the other hand has > method completely external to classes (it does inheritance with > polymorphism... sort of:) > > OTOH there are many conventions, more or less useful or followed, for > example the m_ for members and g_ for global, it's pretty used in kicad. > I find more difficult to find from what parent a member comes... > And that is yet another awful convention. Efficient, I admit, but ugly, awful, and intolerable. It's a C-style convention. Prefixing variables/members is frowned upon in many C++ books. This reminds me of a discussion on the list of people "programming on their hands and knees" by "feeding C code to the C++ compiler". Disclaimer: this is entirely my opinion, and it does not constitute a request, a proposal, a suggestion, or any other attempt at code reform in kicad, or any other source code. > Another rationale is: since there should be no global variables (or at > least few of them), you can see the function parameters so everything > that's not a parameter is a member. Too bad there are soooo many > non-static globals in kicad :( > Yes, I compile a list of the parameters in my head, and whenever I see a variable, I compare it against the list to determine whether or not it is a member. Why does programming have to be so complicated? If I can tell myself that this-> variable is a member, but that other one isn't, and without having to alter the variable names to do that, why shouldn't I? (Well, I shouldn't, because if I ever end up writing a patch, it will be rejected by Dick). :P The above disclaimer still applies. > And anyway there is one style for each programmer:D > Indeed. I am not proposing any of the above; however, kicad _does_ need a _documented_, agreed upon coding style. At least we don't end up getting one-line C-style comments mixed with a C++ style comment on the next line. Alex -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJMhfWhAAoJEL0kPHNPXJJKfksP/0pXYO8r71n/yKBsUpcHmMRd TJWMT6Ma1GhsVuAIyHjGIb5qkx7aRE3gFAdJKiOrmzPzsQF/VKX1gahptuwMILah lPvOtbJFJAhQN1TZym8NRYD6Zr9etZiAsE5hAmKZoxkmyenCB5CpdmidYucI1vuX 0aP5sVEZex8Z+gvAVV7DtdvoIAHCI39h952VKhAwqgEbuPuo1lt0K/GF1IhiJHX0 0uwMNerzMVSkyquJBx/+4J6PfQmKXK4UuFpeXsmhlw2imO8oYPZ21qAvlOCObaAP Q8u1o41sW1Y8ov4SQ+s5q/SOtYFYdznS4+GkHRBO5Hcs3pP6hd0OIIpIq/fS0/xR 8AfanNWmMRV+OjVektzP/xH+yyKmifVteGF3vT/Sl0ozt/9OMvpY8b29mje8++Xy kMbbUhWYGz7POnDblhRFIh1XUXckBJppm3cEmPOoSkG6otkjyBojxf4crFnKDDcm wrsGp+VUGEgiWSvLXhTmxuLlsW0bfd1GXJxjcTCgzFzvdL5jM/wPQ1wdvr1zE9YQ QGhVCkwrpaVZooDXF45oXdVg2e5ZS4QSfEsFc1Q95LpLCGPrbd5v6oKxhE7SbUCl c0LLducQAhtKl14+zf4hiaHEHNT/Gi4airA5LnylGax7IT0kvP5JopYT+4WzWh24 rKJ9czoldIXt651wsx79 =Yhj4 -----END PGP SIGNATURE----- _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
