What Motivates You?
-
@pilou: Interesting phrases! It seems the coding community can get quite exclusive, only those who at least tried to code know, but maybe not those who don't. Once I got the hang of coding in Ruby for Sketchup, my motivation increased.
@Rich O Brian: A painful series of tasks does quite well in motivating someone into automating the task. Even in other applications do I find myself wishing there was a way to automate tasks or even just assigning a macro.
-
I'm actually becoming less and less and less motivated with each new release of SketchUp.
What once used to work, now no long does. Particularly since 2016and now 2017.
I really don't have the time, nor do I care care to upgrade my Ruby scripts to the latest and greatest [highlight=#ff8000:400kq15r]Trimble Tweeks[/highlight:400kq15r]! .........
-
@tomot Does the api work the same or has it changed from 2014 to 2016-2017?
-
@ArcTeo: webdialogs have changed in the latest release. Maybe seems like a minor change but if your plugin depends heavily on webdialogs you could be in trouble.
Personally what motivates me is to automate repetitive tasks. The inspiration comes from working with SketchUp on a daily basis. Learning ruby and coding tools saved me a lot of time and resulted in more joy @ work.
When I get stuck, it's google-time. A lot of questions have been asked before at SketchUcation. Most of them even answered so that really helps. The official API used to contain quite some errors. I haven't been coding anything new in v2017 so don't know if that's better now.
-
The new HTMLdialog will eventually replace the WEBdialog, but at you moment the warning is only that it's 'deprecated'.
That is, there will be no more WEBdialog development... and one day it might be no longer usable in a newer SketchUp version >=2018.Of course this swap was a massive shift, and if you have a plugin that needs WEBdialog you might be wise to be considering migrating it to the newer protocols...
However, at least for the next year or so there is no real problem.
Indeed, the brand new HTMLdialogs are already getting reports of some 'teething problems' so they are not the answer to everything !Personally I am not considering migrating yet.
The older version users still need WEBdialogs anyway - which therefore needs dual-coding solutions ! and v2017 already offers many challenges for recoding my existing plugins for full compatibility in any case... -
@Kass: I don't use Web dialogs, I have refused to learn 2 more languages to implement Web dialogs. From the day someone thought they were a bad idea, I decided not to go down that road. Web dialogs are dead... RIP!
I'm also still motivated to make my own Ruby scripts for my daily tasks. I have many of them. But I will NO longer share them with the SketchUp community for fear they wont meet some [highlight=#ff8000:1o0czok1]Trivial=Trimble[/highlight:1o0czok1] standard now or in the future.
The whole idea of sharing at this forum has been replaced by a few bad apples here, that thought they had a better idea of how to implement Ruby installation using Ruby, and in the process also thought it was a good idea to create 1st class and 2nd class Forum users..... shame on you!@ArcTeo: Today I checked D. Bur web site: http://rhin.crai.archi.fr/rld/author_details.php?id=27 It contains several of my free scripts:
- WindowTools script has been downloaded 24,518 times to date
- DoorTools has been downloaded 40,726 times to date
I also never ask for a donation... silly me
I suspect neither of them will work in 2016 & 1017, I still use 2015 on a daily basis
I have been told they wont work in 2016 & 1017 because they are not in .rbz format.
You may not be aware, but every .rbz file is simply a .zip or .rar file.
Placing the files in the required dirs. was really never a problem. I never had one complaint, from customers, not being able to read my instructions. The changes are in the Extra Ruby code required for the .rbz installation process that puts the script and icons in the correct dirs. Here is an example:http://sketchucation.com/forums/viewtopic.php?p=347912#p347912
Where TIG ended up fixing my non Extension Friendly script....(thanks TIG)Maybe its time to re-examine where Ruby is heading?
Does Ruby have a future going forward in SketchUpHere is my really check on whats been happening with scripting: The following are Programs that have moved on. Houdini, Rhino/Grasshooper, Blender to name a few, or game engines like Unity, CryEngine, Unreal. All use node based VB.net Python or C# components that make it easier for any user, not just programmers, to communicate with the main program. As far as I'm concerned, I see learning more about Ruby as relevant as learning more about AutoLisp, which I also wasted many years learning, except for one very important fact AutoLisp was simpler to learn. It had a compact set of subroutines, and it was by design a 3D Math based math language, the same cannot be said about the SketchUp Ruby API. Another even simpler scripting interface is GDL. GDL as a Basic like Language interface which communicates with ArchiCad.
I hope someone is listening otherwise all of this is a waste of time.
-
@kass: Thanks for the info on webdialogs in Sketchup 2015-2016! I was thinking of using webdialogs myself for a script, but I may go with the custom UI toolbox provided here on Sketchucation. And, of course, Sketchucation does wonders for finding answers to scripting problems
@TIG: Helpful as always! Good to know the change from WEBdialogs to HTMLdialogs.
@tomot: Don't worry, I was listening! It seems to me that you're worried that Ruby may not be so prevalent in the upcoming versions of sketchup. I would be worried too if I knew that the API had changed. But, perhaps, Trimble is planning to move to another language? In either case, I'd like to keep a scripting language in sketchup for the pure joy of automation and scripting. I hope when I do decide to migrate, there's still a scripting language in place.
-
how can I feel motivated if I cannot solve simple issues like this one described in this post:
http://sketchucation.com/forums/viewtopic.php?f=40%26amp;t=66906I'd appreciate your help, if you could.
-
@sketchucationkid said:
how can I feel motivated if I cannot solve simple issues like this one described in this post:
http://sketchucation.com/forums/viewtopic.php?f=40%26amp;t=66906I'd appreciate your help, if you could.
It's not you. Dynamic Component programming is basically undocumented. All you can do is look at other peoples examples. Not to mention there are a number of bugs that occur even if you are doing everything correctly. Overall, it's a frustrating experience.
-
@Jim. you are much right! Dynamic Componets are limited in terms of programming. We also have to deal with bugs. do you have any idea I can put in practice to overcome this issue?
thanks.
-
@jim said:
It's not you. Dynamic Component programming is basically undocumented. All you can do is look at other peoples examples. Not to mention there are a number of bugs that occur even if you are doing everything correctly. Overall, it's a frustrating experience.
Amen! But let's separate Ruby from Dynamic Components. Although the DC mechanism is implemented in (encrypted) Ruby, developing DC's does not involve Ruby per se. It is done via a set of GUI panels without any Ruby source file coding at all!
Someone with more insight than me could correct this, but I have the impression that the DC's were a pet project of a single person who left the development team some time ago and Trimble has not seen fit to devote anyone to maintenance of DCs since. Personally, I found the lack of documentation so severe and the myriad quirks and bugs so frustrating that I long ago gave up even attempting to develop DCs!
For a long time the documentation of the Ruby API has also been deficient, full of errors and sloppy or lazy examples. At least the Trimble team is giving attention to this aspect, including a new YARD-based technique for generating the API docs and a GitHub repository where people can propose corrections.
My own Ruby API coding efforts are motivated by two things:
Sometimes I find a seemingly simple operation that core SketchUp simply doesn't provide and that other existing plugins don't implement the way I would prefer (typically because they throw in extra stuff I didn't want. I prefer KISS). So I write my own.
I'm also fascinated by the defective models that people bring to this and the official SketchUp forum asking for help. I write Ruby analysis tools for my own use to probe into the model structure and understand what went wrong. Sometimes these tools help me to repair a broken model, and sometimes they help me to identify bugs in SketchUp itself. But they always help me to gain a deeper understanding of how SketchUp works.
-
What motivates me with programming plugins is that it allows me to be creative and create something that never existed before.
Advertisement