@unknownuser said:

Never bring a toothbrush to a gun fight.

@unknownuser said:

My reason is that I have never bothered to look do closely at this whole open source concept. I know I use lots of software that are open source, but there are so many licenses out there to choose from - each with a long chuck of text with many clauses that it's hard to get an overview. And I also have no idea of what each license does - some let people use it commercial purposes etc. So I find it easier to just let people ask me and state their purpose.

I agree the amount of licenses available and understanding the clauses are a task better suited for tax code lawyers. However really all you need to concentrate on is a few small words...

1. use
2. copy
3. modify
4. distribute
5. commercial

Thats really all you need for open sourcing a script...

# Copyright YEARHERE, NAMEHERE.
#
# Permission to use, copy, modify, and distribute this software for 
# any purpose and without fee is hereby granted, provided that the above
# copyright notice appear in all copies.
#
# THIS SOFTWARE IS PROVIDED "AS IS" AND WITHOUT ANY EXPRESS OR
# IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED
# WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.

However! There really needs to be some templates for licensing posted at an official SketchUp site. Because most people (as you have admitted yourself) do not complelely understand the legality of all these licenses and when to apply them.

Choosing the wrong license spec can be damaging to the entire community. We desperately need some templates so everybody can copy paste the same license (of which they can choose from three) in the following categories...

1. Completely open source license.
2. Completely free to use for personal use only!
3. Free to use only!...and hopefully we will place these in the same place as the official script repository!

Of course Google and @Last should be pushing for ALL scripts to be completely open source or at least open source for personal usage. Of course --as i stated before-- i am not against people close sourcing "certain" scripts if they have done a substantial amount of groundbreaking work on them. But Google's official statement should promote the fee exchange of ideas, technology, and collaboration. That's IMO! Push the completely open source and frown on the closed.

@thomthom said:

@jessejames said:

Look we need to declare all out holy war against bad coding styles. We need to go through all the scripts at Ruby Library Depot, SketchUp scripts, and anywhere else we can get our grubby paws to, and re-write these abominations before too much damage is done

This just ain't going to happen.

In all due respect i highly disagree with that statement and the attitude of laziness you display. ThomThom, you have always been and continue to be one of my favorite people around here but please don't make damning statements like that. That very attitude is why we have found ourselves in such a pitiful state today. And with you being a moderator statements like that have greater potential to destroy the will of the new scripter's to do the right thing and follow a prescribed style of code writing.

@thomthom said:

All these scripts are written by people on their own time. Most are written by non-professional like me. And many are written for a small specific purpose just to get the job done. I doubt there are many enthusiastic about re-working everything just for the sake of making the code pretty while not providing any advantage for end user. I certainly have no interest, and most importantly time, for such a huge task.

Thats great that people give their time to do this however they need to realize the damage that is done from use a bad style. Bad styles are like a hereditary disease, they get passed down from generation to generation. Some one has to put a stop to that infestation at some point. And i hope we can all agree to apply the cure before it's too late!

@thomthom said:

Whenever I pick up an old plugin of mine to add some new features I do usually refactor - but I never bother to refactor just for the sake of refactoring.

I seriously hope that i can make you realize how important proper style is and change your bad habits ThomThom. Because it's always much harder to unlearn a bad habit than to learn a new "good habit"! Hopefully we caught the problem before it becomes terminal.

@thomthom said:

I do appreciate the thought of a wast repository of cleanly coded plugins - but it just isn't realistic.

But it is realistic ThomThom, we can go back and change the scripts if we can get the larger community speaking with the same voice. I would love to contribute myself at re-working these scripts -- and i will. However for the "non modifiable" licenses we will need the authors permission. Thats why we need peer pressure to make this work. It WILL work if you believe that it will. And we should use that peer pressure to encourage full open sourcing where applicable!

@thomthom said:

What is realistic is advocating good style for new plugins. And help out new scripters with best practices. There are loads of information on this forum - but unfortunately it's not properly organised.

I highly agree. At the very least we cannot. And we should not allow future scripts to be so sloppy. If we do the endless cycle repeats...

while lazy
    code_sloppy()
end

@thomthom said:

What I like about SketchUp is that it has a low entry level - for its modelling and for it's scripting system.

Absolutely! And offering these budding chaps clean code will only serve to quicken the pace of their learning. There is no downside to accepting a good style of coding. Everyone will benefit in the end

@tig said:

You don't learn a foreign language by reading a dictionary.

Of course not! Your missing the point.

You could not learn any language from a dictionary alone! A dictionary only gives meaning to words. However to communicate in any language you not only need to know what each word "means" but how to construct many "meaningful" words into coherent structures called sentences and paragraphs that have a grander meaning then the sum of all their individual parts. Even if you knew every word in the English dictionary (most well educated don't) you still could not communicate to anyone coherently (even a 5 year old) with out understanding basic grammar and some sort of universally accepted style guide for writing sentences and paragraphs.

There are many fundamental values good written communication must have to work properly...

Symbols
Starting from the bottom you need symbols or letters that map to grunts and groans. Symbols are the basic building block.

Words
Words that map to a mutually understood value or object. If my association of the word dog is that of a furry animal that barks and yours is to a tall plant with leaves then we are going to have a very hard time communicating. A dictionary is full of words that map to many other words which in turn provide meaning to the word in question -- but not much else can be learned from a dictionary alone! However lucky for us Ruby has defined the symbols and the words (largely taken from the English language) so we need not quarrel over these low level object. Symbols and words are provided by the gods so we need not question them. Therefore Symbols and words have nothing to do with style.

Grammar
Grammar is the rules that define how to combine simple words to construct meaningful sentence objects (or statements) and further how you construct sentence objects into paragraph objects (or blocks) and furthermore up the chain of building blocks of how to construct entire modules, classes, and programs. In Ruby we can effect the grammar by how we write code --I'm not talking about indention here that is in layout-- i talking about choosing bad statement constructs that Ruby allows use to use -- which we should not! These are forbidden fruits!

Layout
The "layout" (or visual aesthetics) of written language is concerned with how you organize the larger parts of the communication. You would not declare globals at the end of a script no more than you would start a lecture with the last paragraph. Just nonsense! There are rules and good reasons for having rules. This is where Indention comes into the argument. But indention is only part of the style issue!

These are the required rules and objects that make up meaningful communication at the basic level. The "fundamental four" you might say. All these "rules" are necessary if you want to trans mutate your ideas (or objects) into the brain of your reader (or listener) in an effective way. Without them, you might as well just talk to a sea shell or write with disappearing ink because you're wasting your time.

When two entities communicate there must be rules that both the "sender" and the "receiver" understand mutually or the entire communication process will shut down and all attempts to communicate will be inevitably lost in translation.

Remember, language (whether verbal or written) is nothing more than me trying to take the electrical energy that is currently "excited" in my brain and recreate those same signals and "excitement" in your brain. If you think about it, using fancy grunts and groans or some chicken scratch on a piece of thin dried out tree bark is a very inefficient and error prone process for transferring a very physical process between two entities. It's subject to all sorts of interference, mis-communications, mis-understandings, and mis-interpretations than one can shake a stick at. The LAST thing we want to do is induce more entropy into this moronic system of communication!

@thomthom said:

For collaboration projects it is good to have a set style - but very few such projects exists.

Oh i missed this juicy tidbit earlier...

What do you think SketchUp scripting is ThomThom? -- a one for all wild west show? Ruby scripting is NOT a mere "collaboration project", No, it is an ENORMOUS COLLABORATION PROJECT"! We are a team of SketchUp developers. From the free open source to the freeware to the payware. We are a giant team. And any team needs a few things to be succesfull

1. A strong leader (Goolge/@Last)
2. A battle plan (Style guide/Official Script Repository)

Without these two things Sparta will fall. All Greece will fall. Trust not in fools... honor the style gods. Honor the style guide!

"""We will stop our rotting code base by building the great SketchUp Code Repository! And from there, we will funnel this code into the filter we call a "style guide". Now, in that focused corridor of thought, it's numbers of current atrocious styles will count for nothing! And wave after wave of style abominations will smash against our logic shields. Bad Styles losses will be so great, it's atrocious influence so demoralized, it will have no choice but to abandon this destructive development cycle and yield to the very will of the SketchUp community!"""

What say ye...?

Talking more about bad styles...

There are lots of amateur programmers among us ( and i am happy for that!) and a few really talented professional guys hanging around. It is of up most importance that we set a proper example for the new and up and coming scripters by writing code not only in a good style, but in a mutually accepted style so we are all setting the same example. I guarantee if WE write in a bad style they will just follow along thinking of sunshine and rainbows on the slow decent to hell-in-handbasket. Heck i've even seem @Last code that looked like lipstick on a pig!! What kind of example does that set? Huh?

Look we need to declare all out holy war against bad coding styles. We need to go through all the scripts at Ruby Library Depot, SketchUp scripts, and anywhere else we can get our grubby paws to, and re-write these abominations before too much damage is done

FURTHERMORE! We need to be yelling and screaming daily to Google, @Last, and anybody who will listen that WE NEED AN OFFICIAL SCRIPTS REPOSITORY! One that demands a script must meet certain style, documentation, and bug-free-ness to be included. We can still have all the other sites out there. But this site must be an official site that SketchUp users can find easily and trust that the code they download will be professional quality! This responsibility belongs to everyone who ever writes a script and releases it to the public!

There must be some kind of logical system we can employ to reign in this madness of multiplicity, mediocrity, and utterly destructive style complicity!

@adamb said:

@jessejames said:

It's insane the amount of poor styles and inconsitancies i see from script to script and EVEN inconsitencies within the same script!

A self referential example?

HaHa!, you got me however that was the beta 1 release of my post so i had not gotten a chance to debug. I just relased a bug fix version via the edit button

@adamb said:

[
"Information-free" comments are a personal bugbear:

# loop over my_widgets for i in my_widgets

Utterly pointless.

I completely agree!

@adamb said:

Well written code should read/scan easily. If you have to stop and re-read then it needs teasing out. Classic one is use of negated meaning in the name of variables. eg:

` notWriting = true

unless notWriting
...`

Again i completely agree. This style saves only a very few key stokes but induces levels of ambiguity that only MSDN and the US tax code can rival!

@thomthom said:

Just to make clear - free doesn't mean it belongs to everyone. Still need permission from the author to redistribute free plugins, and source code if there are no explicit permission in the file itself.

Yes you are correct about this and there is a reason i used those words. The main reason is i cannot understand why someone would release free software and NOT open source it -- but make sure to read on so i can explain further because there are a few exceptions to this rule!

First of all if you create a script that uses real algorithms (i'm not talking about calling API methods ir iterating over some collection!) i talking about real algorithms that are creating an "above the normal" kind of script. Something new and wonderful, something not everyone here could write up in under a couple of hours. Then by all means release it under a license that protects the new ground you have conquered! But anyway i could go on for hours. Some folks here are here to suck up every dime they can and when the moneys gone they will move on to the next town to sell snake oil.

But lets get back on track here...
There are a lot of "open" and free scripts that need to be combined. There are lots of small tools that can be "grouped" into one script so these users don't have a Plugins menu 5 miles long.

The SketchUp Ruby community needs to come up with a style sheet for writing scripts. I am not suggesting we tell proprietary or private script writers what style to use, NO i am speaking of all the open source and free ware scripts out there. These scripts belong to the SketchUp community as whole and we have a responsibility to make sure there bug free, and written in a style that not only teaches good coding practices but also promotes them. It's insane the amount of poor styles and inconstancies i see from script to script and EVEN inconsistencies within the same script! This style sheet will lay out the expected style for scripts to follow. Of course with Ruby's tim toady-ness we cannot make it perfect however we can do a lot to clean this god awful mess up!

Parenthesis around method arguments
One thing that really grinds my gears is the laziness of folks who refuse to wrap method arguments in parenthesis. I know the ruby language allows one to do this but its ugly, harder to read, and just exposes the author's laziness. Koala bears have an excuse to be lazy from eating those eucalyptus leaves all day, Ruby coders have no excuse!

Indention Style
Another gear grinder (or jam'mer to exact) is the poor indention style, or lack there of. Yes Ruby does not force indention but you should use indention because it's more natural to read indented code. I personally perfer 4 space indention however ANY indention is better than NO indention. But whatever you do NEVER INDENT CODE IN THE WRONG PLACES AS THIS IS WORSE THAN NO INDENTION AT ALL! Indentions should only come at the start of a block body after one of these words (module, class, def, for, if, elsif, else... or after the "{")

## good indention style ##

module namehere
    def self.method
        for x in collection
            if x == blah
                # do something with x
            else
                # jump off the golden gate
            end
        end
    end
end

## Not so good indention style ##

module namehere
def self.method
    for x in collection
        if x == blah
            # do something with x
        else
            # jump off the golden gate
        end
    end
end
end

## Horrible indention style ##

module namehere
def self.method
 for x in collection
 if x == blah
 # do something with x
 else
 # jump off the golden gate
end
end
end
end

## You should be banned from coding style ##

module namehere
def self.method
    for x in collection
    if x == blah
     # do something with x
    else
# jump off the golden gate
     end
 end
end
end

And Never Ever mix indention widths within the same script. Picka a number of spaces and stick with it. Also never use tabs to indent because different editors use different distances for tab stops.

Loops (for verses each)
I personally prefer the for loop because i hate eyeball parsing "{" and "}". However if your loop is small enough to fit onto one line then by all means use the collection.each{...}. But again consistency is the key!

Modules and Classes ...to indent or not to indent. That is the question!
I have said it before and i'll say it again... the module syntax is clutter and it would be more elegant to use the file as the module (like Python does) however thats a Ruby issue and we need to accept that for now. As my first example showed indenting the module code makes for nice readability however it does start getting dense. I am not against (and have myself done this) NOT indenting the module code body. However for classes the body should ALWAYS be indented!! Let me repeat that...HOWEVER FOR CLASSES THE BODY SHOULD ALWAYS BE INDENTED!!

Documentation
People, you should always document your code at the very top. Start out with your license and then provide a detailed discription of what the code does and most importantly how the user will interface with the code. Please use complete sentences and proper punctuation and grammar. Code usage descriptions should take the same amount of effort as the code itself.

Comments, wheres waldo?
Always include ample comments -- but never ever over comment as you can do more harm than good! Also remember that a poorly written comment will only serve to confuse the reader, it's better not comment at all than to confuse! Also as always use complete sentences and proper grammar and punctuation. If you have a very long comment break into logical paragraphs.

I would like to hear input from all scripter's (new and old) about this subject. There is much much more to cover (i have not even mention naming conventions or repeated code, or multiple scripts that need to be combined) this only scratching the surface but we must start some where!

Thanks

@martinrinehart said:

Ruby Console Pro

Magnificent Martin! simply Magnificent!

This console is exactly what i have been lamenting about since i first used SketchUp! Had SketchUp included a GUI kit i would of created something like this myself! However i bow to you!

Any who, i had a few questions/suggestions for improvement...

1. Can you combine the input and output windows into one window. Preferably with the output window at the bottom. I have no idea if things like "sizable panes" are available for user customization of the sizes? However even with no customization it would be a nice alternative to have both in one window.

2. I noticed pressing tab does not insert a tab char into the text area, it just does the usual "tabbing" of focus though the widgets. Can this be overridden to insert a tab? I don't care about losing the "tabbing" ability!

PS: oh and i did also have a problem with the buttons being cut off at the top (like a previous poster had mentioned). However I played around with the padding values and was able to rectify it. I am using Vista+SU7+Chrome. So just an FYI.

Thanks again Martin!

@thomthom said:

What I found most interesting in those test was that Vertex is a valid argument where the manual claims only Point3d. And passing the Vertex is faster than Vertex.position.

Well i think you'll find this is a commonality of the API and the Docs is the fact that "those" who are creating the API and the Docs ARE NOT "those" who use it on a daily basis!

@dan rathbun said:

There is a plugin for this (that needs some language cleanup,) written by Sahi.
It's called AxizComp.rb

Thanks for the heads up Dan! Although i won't look at since my function works just fine. I try to never look at other scripts and learn my way around a problem using only the docs and my Ruby Console (God i wish we had a multi line console!!!). Copy and paste is detrimental to your future evolution as a programmer. Only in the most extreme circumstances when i feel i have exhausted every possibility of self reliance then and only then would i take a "peek" at some OS script to get an idea of how to do it.

@martinrinehart said:

I've created an alternate API for moving, rotating and scaling. Design goal: eliminate the transformation matrix; let the developer move, rotate and scale directly.

Martin,
i like this Alternate API approach. This is exactly what i proposed some 2 years ago but at the time i was just beginning the long and weary obstacle course of learning the Ruby language. Well now i have quite a good grasp on the language (about time right!) although strangely i have picked up other languages very quickly.

Anyhoo, i wanted to offer a suggestion for extending this API to correct some asinine inefficiencies in the BoundingBox class. Of course like you mentioned in the Movable and Transformable, these methods should belong to some derived class. But alas we can't hold our collective breaths forever lest we suffocate and die waiting for change.

I find the need to grab a group/comp by it's "bbox.center", "bbox.center_bottom", and "bbox.center_top" so important that i wrote a nice function to encapsulate all the calls required to retrieve these points. So maybe you would like to add this, maybe not. Let me know. It would be so nice to call obj.bounds.center('center'), obj.bounds.center('top'), or obj.bounds.center('bottom'), but that will have to wait.

@martin said:

I'm creating SketchUp learning materials. If you want to compete with me, please write your own code. Otherwise you can use this as if it were public domain.

And thanks for being an honest scripter who is willing to share knowledge with others free of attached binding licensing. We need many more folks who think as you do because such practices fosters innovation. Sure we could lock up some code and make a few quick buck, but then we would have sold our souls in the process. We have many honest scripters, but we always need more.

Thanks again Martin!

@jean lemire said:

What is the optimal resolution that you need (in pixels, for example)

Jean, as my wife has told me on numerous occasions...

@unknownuser said:

it ain't the size that matters, it's what ya do with it!

@martinrinehart said:

Yet Another WebDialog Gotcha

Seems to be annogolous with...

@unknownuser said:

Yet another Microsoft Windows Bug

...yes web dialogs are quite the cruel irony of SketchUp i would say. We sure could use a good ol built-in GUI about now.

@dan rathbun said:

@jessejames said:

...just don't blame me if you fall in love with the Python language and lament the shortcomings of all others
Well, there are some things I don't like off the bat with Python. Those hanging indents with no block closures.

Once you read code with no redundant end statements you'll wonder how you ever liked them in the first place. The forced indention of Python uses the visual aid of INDENT/DEDENT to mark blocks which the human eye notices much quicker than end or "}" or whatever. Let C hackers "eyeball-parse" brackets like a compiler until they go blind, let humans "read" code naturally!

@unknownuser said:

I had planned to learn Python for other things, even before I found Sketchup and Ruby.

Dan, i will personally give you (or anybody) a crash coarse in the Python language anytime you are ready send me a PM. I will show you everything i know, and i guarantee it won't be a waste of your time, you're going to like this language friend!

@unknownuser said:

@jessejames said:

PS: i remember a while back you wanting to get wxRuby into the API as a usable GUI kit.
Yes, but is it cross-platform, as WxRuby/WxWidgets claims to be? GTK+ or Fx or something else?

Absolutely, even more so than wx. I don't know if you have messed around with wx but it is not as cross platform as they claim it to be. Yes it is a good full featured GUI kit but totally cross platform, no way!

@chris fullmer said:

And another thread gets hijacked off into dreamy python land...

Oh Chris, stop being theatrical!

@driven said:

0.109
0.469
0.766
1.125
1.422

Python is still quite a bit quicker. Thanks for posting these specs.

@unknownuser said:

I posted about suPy.rb before, with very little response,
I've got hypocycloid.py and suPy.rb but I can't get them to run on the Mac, want to take a look?

I am very sorry i never saw the post. Only a few people have shown interest in SuPy from it's conception, probably due to the bulling from some higher ups in this group when Greg and I tried to announce it. But i will keep on despite the resistance because i know the language has much to offer for the noob programmer. And it would be a good motivator if people showed interest. I still have much docs to write and tutorials which never were completed.

From now on if anyone has questions about SuPy or Python feel free to contact me personally via PM. I will go out of my way to help you no matter what your level of programming skills are. I also help a lot with Ruby, it's just i am more versed in the Python language.

John, I don't have a Mac but i'll do everything in my power to get you up and running. Send me a PM immediately and let me see what i can do. The Good news is Greg is a mac fan so i know he built a solid mac version, or will update it if needed.

@martinrinehart said:

Got a lexer running, tho it's blocks are delimited, not indented. Begun a parser. I only pick on this a bit at a time. (In Python, of course.)

Can you show me some code, i like to look over specs only after i see the code in action, specifically the simplistic syntactic elegance of the language in particular. Python is a hard act to follow in this category.

My idea of the perfect language is Pythons core seasoned lightly with some Ruby, and maybe a very small pinch of Java. . But i am open to new ideas also.

@martinrinehart said:

Language design shouldn't dictate source code structure. When I wrote Java, for example, I had one special place for main(). It was important that it always resided in its special place as it was typically test code, commented out when the class was finished. Once commented out, the IDE couldn't see it.

You do know about using Python's...

If __name__ == '__main__';
    # block here

...construct to insert tests where ever you like? It's typically used at the end of a script for running tests. It will only run the test when the module is ran directly, not when it is imported, so no need to comment out!

@martinrinehart said:

When I wrote Java, for example, I had one special place for main().

Where is that exactly?

@martinrinehart said:

This is off topic. I'm posting this so that those who want to join the debate will have a place to do so. Hopefully, we'll not have the topic raised elsewhere.

Well Martin you had to know i could not resist a thread with Python in the title, no more than a dog can resist chasing his tail, it's just too damn interesting.

@martinrinehart said:

I have a pet Python named Monty. Monty promises to give Tim Toady a big hug if he ever meets him. (No, you do not want a big hug from Monty.) You can figure out where I stand.

Another example of Martin's comedic genius, pure gold!

@martinrinehart said:

Python's suites (four-space indented code blocks) are great. They enforce good code writing. Ruby's if/unless pairing, and especially suffixing, are great.

i love Ruby's one line statements "if condition then statement else statement end". Reminds me of Python list comprehensions. We have something similar now in 3.0

@martinrinehart said:

Python lacks the implicit "this" of C++ and Java.

i'm still out on this one. On one hand (like Guido argues) you see the path of self, but i could live without it.

@martinrinehart said:

And I find the processing of code in the order it appears in the file is utterly lame. Even JavaScript has sense enough to eat all the declarative code before it starts running imperative code. Matz? Guido? This is 2010!

I don't see how that matters but i won't disagree on such a small thing. So Martin, can i surmise your rant as...

@unknownuser said:

"The best language today would incorporate everything that is good in Python, Ruby, and Javascript into one beautiful 21st centry language".

If so i agree, when do we start building this thing? And what the heck are we going to call it? hmm, scratches head, how bout "Full Monty"?

@unknownuser said:

It's so cute and quirky, we've decided to keep it.

(I agree with you that it's attached to the wrong object, BTW. But once a method's in the wild it's really, really hard to change it.)

Cheers,

Well this is going to sound condescending no matter how i put it so i'll dispense with any niceties and just be blunt, hope you all can handle it...?

It seems the API was written by people who have no experience using it. This is what happens when you get a bunch of low level C hackers who hardly use high-level scripting languages to spec out an API. I think it would behoove the dev team to gather input from the soldiers in the trenches instead of just barking orders from the White House.

Dan (along with Jim and others) has documented time and again the atrocities of the API and i have noticed many more. The fact is that we need to look towards a major release where all these blasphemies can be rectified into a beautiful API we can all love. Look i know mistakes are unavoidable and i am in no way saying i am better than anyone here. So lets put our collective heads together and make this API all it can be!

Are you with me?

@dan rathbun said:

@jessejames said:

However, this is a Ruby module and not a REAL Python API. Basically Python calls Ruby code, then Ruby calls SketchUp, very inefficient!

That SUCKS! dang.. thot I was onto something.

Well don't give up so easy Dan. I know you to be quite versed in the Ruby language and i think you may also be an accomplished C programmer. Maybe you could offer you expertise to the project? Are you interested?

...just don't blame me if you fall in love with the Python language and lament the shortcomings of all others

PS: i remember a while back you wanting to get wxRuby into the API as a usable GUI kit. I also believe strongly in the power of GUI kits over those atrocious web dialogs. With Python's built in GUI you need look no further!