@chris fullmer said:
Well, quit trying to write code in the console. Move over to Jim's webconsole, as was suggested previously. I've found it to be quite useful! It allows multi-line editing, which is very usfeul.
Thanks, but i tried before with no results. Does it have an issue on Winders/Vista?
@chris fullmer said:
Good to see you back on the forum JesseJames!
Thanks, great to be back, i been out trail ridin' far too long, Whew! you know any good remedies for saddle rash? 
I must say as much as i love SU i really hate the Ruby console. I know SU dev has tons of stuff to do but i feel Ruby scripting is just as important as modeling (if you are a serious hardcore modeler that is...)
So here is a comparison of my favorite language's IDE (Python) that i think would be a good model for the SU Ruby console. Of course i am not suggesting that the Ruby console have syntax highlighting, command line help, path browser, configuration options, etc, etc.
I am simply referring to the look and feel of the thing. Also i really hate this idiom of the console always printing values even when nil is returned. This just jumbles up the console output something horrible!
Here are side by side interactive session with IDLE and Ruby console. Judge for yourself...
NOTE: i keep the code simple so everyone can follow along 
Python IDLE -> elegant beauty
>>> l = ['a', 1, 3.75, "SketchUp"]
>>> #must request an array!
>>> l
['a', 1, 3.75, 'SketchUp']
>>> def add(x, y);
return x+y
>>> print add(1,2)
3
>>> add(1,2)
3
>>> for x in range(1, 5);
print x
1
2
3
4
5
>>> [x.upper() for x in 'abcd']
['A', 'B', 'C', 'D']
The first thing you notice is how neat and clean everything is. IDLE uses the ">>>" to denote a command and "..." as a continuation. Also it follows the normal policy of using a single text widget and not a one line entry box and a textbox for output. I know why SU dev created their console this way, because it it easier to code up, but, the usabilty is sacrificed in the meantime. 
Ruby Console -> information overload! 
l = ['a', 1, 3.75, "SketchUp"]
["a", 1, 3.75, "SketchUp"]
#this is a comment
nil
def add(x, y) ;x+y ;end
nil
puts add(1,2)
3
nil
add(1,2)
3
for x in 0..5;puts x;end
0
1
2
3
4
5
0..5
'abcd'.split('').collect{|x| x.upcase}
["A", "B", "C", "D"]
Why is the console printing nil's all the time. If i need to know a boolean value i will ask for it. And what is the need to print arrays after printing the contents in a loop. This "excess" screen clogging cruft is on par with OCD tendencies! Makes me feel like old number 5 running around shouting, input! more input!
Happy Day!
SketchUp has now moved into the 21st century not only with it's elegant and ground breaking user interface, but now with the COLLADA file I/O.
This is the beginning of the end for the DXF prison and the blossuming of a bright future for SketchUp! DXF is the illegitimate child of an antiquated software(ACAD) and it's utter destruction is a god send! Thanks Google for having the conhones to stand up to these greed mongers and giving ACAD a swift kick in the huevos! 
If you are using SU+ACAD you are a professsional and should pay the 500 for SU. SketchUp is worth every penny and more. I do understand the backlash when losing functionality, but you need to look at this from Google perspective.
We are lucky to have what we have now. No software company has ever been so gracious as Google. And with the Chrome OS around the corner... We have some bright days ahead of us people! These are glorious days! 
psst: Next we should go after M$'s greed machine...
Viva Google!
I must also agree with previous posts here. Although i believe SU7 is a great improvement overall, this is one area where i still get very frustrated, and i am no SU n00b.
I really miss that back button, and find the new component browser very unintuitive. The SU6 and previous design was flawless, and i quite liked it. Mainly because you could remove any menu item you wanted (except for the in model which makes complete sense).
All these categories get in my way. I wish there were a way to remove some of the menu items in the drop down list. if someone wants to add a library to the menu, they can organize there models in a folder hierarchy within the top-level folder they are adding, thereby reducing the number of menu entries. The (MyModels, MyComponents, RecentList, and ComponentSampler) i will never use, and get in my way.
Having a favorites section just dirtys up the whole menu, and as far as i am concerned, they are all my favorites. I like as few menu items as possible with a structured folder scheme that makes everything much easier(just like the previous Browser).
And a better idea would be to let the user move a menu item up or down the list, this would be a far more powerful way to structure the menu items and replace a favorites section. In my previous setup, all i had was (InModel, GoogleComponents, MyComponents) that was it, everything else was structured below that (and there where thousands of them).
So if you guys can't change the browser now, at least give me the option to remove EVERY menu item i do not want or need. And please bring back that "Back" button 
.
Thanks
@gaieus said:
If you find out the way, plkease, start with a back button in the Component browser instead!
@thomthom said:
@gaieus said:
If you find out the way, plkease, start with a back button in the Component browser instead!
Aye!
If you are serious about this we really should get a thread going and the subject can be "Please bring the Back button, Umm, well, Back!". I have seen many others comment about this. I really miss the old componet browser and most of all that back-back-back button .
What do you guy's think?
Hello CPhillips,
I have said time and time again that Ruby and Python are equals in Power. Where Python has an edge is free well written tutorials aimed at non-programmers, and a built-in GUI. I don't think there has been any flaming of languages here. Everybody has stated their opinion and i accept it. If you like Ruby over Python, i respect that, and i do not want to take it away from you. If you would like more resources on your quest to SU scripting, i give you Python.
I am not here to say "Down with Ruby or Up with Python". I want the users to have a choice between the two best high-level-languages in the world today. That's all. I could show you one site that contains 300 plus Python tutorials in 50 different categories, if there is such a site for Ruby please let me know and i will include it in my post.
I know about the long standing "bad blood" between Ruby and Python. I think this is due to two tools that achieve the same results but in very different ways. Some people find Ruby fits their brain-type and some find Python.
Ruby and Python defiantly stand out among all programming languages because of their ease of use, and are by far the best choices for scripting. My argument is that with Python, the learning resources are almost limitless, and it is easier to get started. Thats all.
Thanks
hello Didier,
From your words you seem to be a very accomplished programmer, and i will agree. You have given greatly to the SU community with your scripts, and i thank you for you contributions.
But your professional experience is actually a handicap in this discussion. It is easy for "US" to forget the struggle of a new programmer. The knowledge you and i take for granted, is a complete mystery to others.
SU is a tool aimed at modelers, not professional programmers. They need a scripting language that is well documented, widely known, and most of all easy for non-programmers to learn.
I intend to prove that Python meets and exceeds all these qualities and then some -- making it the perfect scripting language for any application.
And i want to keep Ruby. Choices are good for the users of SU. When everybody can easily write scripts for SU, they will be able to use this software(tool) to it's full potential.
Thanks
Hello Chris,
@chris fullmer said:
I fully agree with #1 and 2. I'm not familiar with what #3 is in Ruby or any language, so I don't know what I'm missing. I'm sure it would be welcome though. Isn't there a plugin for this already?
Python has beautiful multi line interactive console and editor in one neat builtin package called IDLE. Ruby has IRC. But what i am referring to is a replacement of the single line Ruby Console in SU. The current Ruby console only allows for one-line-at-a-time entry. Which renders it completly usless as an effective learning tool. Multi line(good). Single line(Bad).
The console can be a noobs best friend, or worst nightmare. The current implementation resides on elm st.
@chris fullmer said:
#4 is something that seems like a no brainer to include from the start, but what do I know? So I agree, it would be nice - no, more than that. Is there a way to incorporate SciTE or something into SU?
Your SciTE idea is a good but SU DEV may not want to deal with an outside editor due to version confilcts and what-not. I am proposing a very simple custom built-in editor for beginners. Pro's have various ideas as to the best text editor . Remember, pro's don't need any help, they know where to find the advanced tools they need, besides most of them will never use a built-in text editor because it does not have "this" or "that" feature. My concern are those that are both new to programming, and SU-API scripting. They need a way to get started learning quickly without adding this thing or that thing... and "HEY New Guy" don't forget this other thing too!
@chris fullmer said:
It seems like there should be better real time feed back (well not realtime, but better testing and execution) inside of SU. (How are #3 and #4 different? I don't quite get what the difference is) #5 I haven't seen how poorly the built in ruby options are.
A multiline interactive console and a text editor with syntax highlight are two very different tools but together make for easy writing/debugging of code. Small pieces of code, algorithms, etc... can be debugged/improved immediantly in the multi-line console, and then pasted into the text editor. This work-flow is paramount to a new programmers learning of a language, not to mention the SU API.
@chris fullmer said:
Those are some great points and they would be a good starting point for helping get more of us into ruby.
Chris
This is the kind of well thought out post i am looking for from you and everybody. The ultimate goal here is to make SU scripting less painfull, and available to all who wish to learn.
Thank you Chris!
Hello Azuby,
@azuby said:
- What is wrong with WebDialogs?
Nothing that i know of, I just prefer a real GUI toolkit. The great thing about Pythons built-in GUI Tkinter is it's simplicity. Pro's and noobs will find it equally useful.
@azuby said:
- What is wrong with the multi line consoles I mentioned? (Have you tried them?)
No i haven't. What i want is a built-in Multi-Line Interactive Console in SU. The first experiance a new scripter will have is "playing around" in the console. Using a one-line-at-a-time Console will surely defeat them before they have a chance.
@azuby said:
- Why not writing an own Python lib with the help of the Sketchup SDK instead of using a bridge and getting angry about Ruby?
Good Idea!, i will look into this.
Thanks
Remus,
I am referring to the short-comings i see about Ruby scripting. I am sure many great advancements have been made before i came along, and I see many dedicated people writing scripts, and answering questions.
Here are the reasons I believe, learning Ruby is more painful than it needs to be...
1.) Lack of free, clearly written tutorials for the Ruby language aimed at non-programmers.
2.) Lack of good examples in the Ruby SU API(#1 would cancel this out though)
3.) The need for an improved Multi-Line Interactive Console in SU.
4.) The need for a simple integrated text editor w/syntax highlighting
5.) The need for a simple to use real GUI toolkit built-in to the scripting language(script and go)
These would greatly improve the SU scripting experience for all. This is the main reason for my recommendation of the Python Programming language. Python has the docs, and built-in GUI(TK) already. The text editor and multi-line console would need to be created either way.
Ruby and Python are the only two languages that stick out in the very high level programming world(IMO). Ruby and Python share some similarity's, but they also differ greatly in approach and style. The bonus here is that people could choose the language that best fits there mind-set. This would truly be beneficial to SU and all who use SU.
Hello sepo,
@sepo said:
All this sounds interesting (apart from "bickering"
The tut is in very beginning stages at this point, since i am the only author working on it. I had to stop and pursue this effort because of the current limitations of..
1.) Ruby documentation in general
2.) No built-in GUI toolkit in Ruby
3.) The single line Ruby Console in SU is detrimental to a new Rubyists learning experience.
A multi-line Console must replace the current single-line console. That way a Ruby Nuby can write code in a natural way, using indention. Interactive seesions are the key to learning a new language fast and painlessly. The "get results right away" aspect of interactive consoles makes learning more fun.
But the current Console sets up users for failure before they get a chance to even start. I also think a simple built-in text editor (or plug-in) would be a great idea to simplify work flow. Most software with an API, includes some sort of text editor built in and usually it has syntax highlighting.
So my current crusade is for SU to grow a Python API. Python has the first two already, and the last would be no problem. This would also give people choices -- i like to have choices.
So far my Ruby tut only covers strings, floats, integers, and functions -- all of which still need polishing. Plus i want to include leaning the API along with Ruby at the same time by building on a simple script throughout the tutorial. This sort of "see results right away" is what will keep people interested and motivate them to learn.
Right now a huge brick wall is between you and SU scripting. I will smash this wall to pieces, and lead you into the promised land!
@sepo said:
Are you saying that you intend to make a bridge which would than enable people to use Python instead of Ruby?
I am saying i want SU to grow a Python API so people can choose which language they want. But bridging may be the only step available at this point. Then i could develop a group of advocates who could convince the SU team to include a real Python API -- since most of the work would be already complete, and the need would be proven, the incorporation would be minimal.
Hence the reason for this thread, to find out what interest there may be in "SU land" for Python scripting. All that would be needed is good API docs, Python already has thousands of great tuts out there free of charge, and Python has a great easy-to-use built-in GUI toolkit.
Most of all, i believe Python is much easier to learn, making it perfect choice for any API -- and i intend to prove that by personally tutoring anybody interested in Python scripting. That's how committed i am!
Has anybody seen such commitment for teaching/improving the SU Ruby API in SU's 9 years??
EDIT:
Has anybody seen such commitment for teaching/improving the SU Ruby API in the almost 5 years since Ruby has been here??
Look, SU is the best piece of software i have ever seen, truly revolutionary 21st century software. The UI is flawless, the design is flawless. The only short-coming is the scripting API.
Scripting must be accessible for all, not just a few professionals at the top. Every hard-core user of SU will need the power scripting provides. Python like SU, is revolutionary in the programming world. The marriage of these two great powers will guarantee the upward evolution of SU for years to come!
PS: i am not upset with Chris, i just wish he would get on board with improving Ruby or including Python thats all. The only way any of this will get better is if we make it better.
@unknownuser said:
The SU Ruby API was introduced as being available for the first time in June 2004 with SU V4.
Thanks Todd and Remus for correcting me. Here is my newly edited version.
Has anybody seen such commitment for teaching/improving the SU Ruby API in the almost 5 years since it's introduction?
?
@tomot said:
...I could not sit down with a text editor and bang out a new Ruby without at the same time having open on my Desktop at least 2 or 3 existing Ruby's whose content may help form the basis of a new ruby idea I'm trying to bring into being. Then through lots of cutting and pasting of code and many trials and errors of loading and reloading the same script into the console, over and over again, I eventually arrive at the solution.
I agree tomot,
The work flow for writing scripts in SU is frustrating. This must be improved. Nobody(pro or not) has the ability to write bug free scripts in one go.
1.) A built-in text editor(very simple) with syntax highlight so a new scripter can get started easily
2.) a multi-line Console(for testing snippets with proper indentation) to replace the single line Ruby Console
3.) a real GUI toolkit(Python has TK built-in to the language)
4.) a good SU specific scripting tutorial.( most important )
These are the key to happy SU scripting.
The current work flow is painful and a real determent to all who wish to learn, or write scripts for SU. Something must be done. Scripting must be made available to all, not just a few professionals at the top.
SU design is flawless everywhere but this area. Once we can fix this, the full power of SU will be available to all.
I think if i where to ask a stranger for a favor, I would do it in a very humble way, and I would probably want to include a "please" or "thank you" somewhere in the conversation. What do you think Christopher?
As we speak I am creating a Group dedicated to a SU Ruby tutorial aimed at non-programmers. This tut will teach basic programming principals while writing scripts for the Ruby SU API. I am writing the tut all by myself at this time. You see i could just teach myself Ruby, and then look down on the others who don't know it, but i want to give back, and empower my fellow SU brothers and sisters.
I want people to learn and give back them selfs by adding to this tutorial as a community project. You see if everybody volunteered a piece of their time (instead of just gimme, gimme, gimme all the time) maybe the SU world would be a better place(9 years ago)? Eh Christopher?
I understand, why fight a losing battle?!
FYI: C and Python interact very well, you can optimize with C where needed.
Now you have the best of both worlds. The readability, maintainability, and clear syntax of Python, coupled the speed and low-level access of C.
WOW!, If you have as much experience as you say, then you would know that.
Christopher,
I see a lot of rage in your posts. Maybe you are angry because you are having trouble learning Ruby, and taking that frustration out on me. It's OK, i can understand that . Ruby is not nice to a nuby.
But there is light at the end of the tunnel Chris, one way or another i am going to improve SU for everybody. Maybe you should get involved and contribute some of your ideas instead of pitching temper-tantrums to those who are trying to improve this great software. Which will, in effect, make your learning process much easier, and your potential for success much greater.
BTW, I love your quote
I think what tomot wants is a GUI toolkit built-in for SU scripting. Web dialogs are quite lacking. Scriptwriters need widgets!
Text, Listbox, Entry, Button, Frame, Toplevel, Spinbox, Label, Scrollbar, Dialogs, RadioButton, CheckButton, Menu, Scale, LabelFrame, Canvas, OptionMenu, PanedWindow, Image Support
Python has all this built-in to the language as Tkinter(Tk widgets) An easy to use GUI builder with every thing a script writer/SUupper needs, amoung others.
I will also volunteer to do most of the dirty work to grow a Python API(and i could get others to help also -- SU DEV would not have to do much).
One of the best things about Python as compared to Ruby is the tons and tons of great documentation. This would be very appealing to those who wish to script but cannot find good docs for Ruby. And the built-in GUI is just icing on the cake!
Azuby,
If you (or anybody for that matter) know of a highlevel language besides Python that has more quality documentation, stable built-in GUI, clear syntax, is easy to learn, widely known and accepted, has a future, and open source -- Please let me know because i will dump Python and crusade for that language religiously.
My religion is not Python, my religion is any language that will give me the most production with the least effort and expenditures. Which is the definition of a good language. this is the 21st century, it's time to send some archaic, redundant languages off to their destiny of extinction. Let today's high-levels rule until the next generation of languages renders them obsolete!
@azuby said:
...
Ruby has GUI support for:
TK
wxWidgets
Qt
GTK
Fox
WebDialogs for Sketchup
Are any of these built-in?
@unknownuser said:
Multi line consoles:
WebConsole - http://sketchuptips.blogspot.com/2007/08/plugin-webconsolerb.html
d/Code - http://www.errorinitus.de/ => Software
I am talking about the Ruby Console in SU. Ruby has many good editors but not embedded directly into SU.
@unknownuser said:
Your first steps could be using a bridge between Ruby and Python (or use the Sketchup SDK to write your own lib):
Ruby/Python - http://www.goto.info.waseda.ac.jp/~fukusima/ruby/python/doc/index.html
Ruby-Python-Bridge - http://www.vyperlogix.com/ruby-python-bridge/
pyRuby-Python-Bridge - http://pypi.python.org/pypi/pyRuby-Python-Bridge/1.7
This is exactly how i want to start. The reason for this thread was to test the waters for SUuppers who would be interested in a Python API. From here i plan to get Python talking to Ruby, build support and see where it goes from there. Are you interseted in having more choices azuby?
@chris fullmer said:
I thought the thread was about using <blank>, not a decoy to try to convert from Ruby to python.
This Thread is about giving SU users the common sense tools they need to use SU to it's fullest capabilities. I want to hear everyones opinion on this subject. SU noob to pro! If you are with me, or against me, does not matter.
@chris fullmer said:
As for the tutorials, I am doing a nice ruby tutorial. Its pretty good for the syntax. But like others have stated, it would be easier if there were tutorials based entirely on a SU workflow. Its hard for my brain to understand how to implement some of the stuff I'm doing in the tutorial into SU. So more SU based ruby tuts would be grand. So quit jabbering and get making
btw, I've only taken 1 programming class and it was pascal. I don't really care what SU uses, but if it switched off of ruby right after I take the time to learn ruby, I'll be pretty upset.
Chris - not a programmer, just a dreamer.
I am working towards a solution as we speak.
One solution would be to fix Ruby. This is a grand undertaking because this is a Ruby problem ,and the SU community has little control over Ruby direction. A lot must be done here -- A good introductory tutorial aimed at SU Ruby scripters with no programming experience, and dive-in tut for experienced programmers new to Ruby SU scripting, a multi-line Ruby console, real GUI support, and improvement of the current API docs. So far SU has been around for 9 years and none of this has happened yet. WHEN IS THIS GOING TO HAPPEN? WHERE IS THE CALLING FOR IT? WHERE IS THE COMMUNITY ON THIS SUBJECT?
The other solution would be to INCLUDE a Python API in SU. Python has the docs, and the built-in GUI already. It would be disastrous to wake up tomorrow with Ruby gone and Python in it's place. Many people have invested hours, days, months and years building awesome scrips and plug-ins for SU. That's why I want to ADD Python, NOT replace Ruby. I want to give SU user the choice here because i believe Python has much more to offer. Some people will stay with Ruby, most(i think) will join the Python bandwagon. All of this will be for the betterment of SU. That is my point here.