How To Optimize Your Plugins
-
How To Optimize Your Plugins... I got you there didn't I? you were really excited to see this weren't you? Well, I don't know how to optimize my plugins... I'm hoping there is a plugin that checks all the plugins to see if there is a conflict or an updated script. Or maybe a script that just reads all of your plugins and makes a list of what you have and what version it is... I think that is probably a wish and not a reality.
so perhaps we could have a discussion on a method that would work until that tool comes along. here are just a few of the questions that come to mind.
what are the symptoms of plugin conflict?
do all of the plugin writers use version numbers?
what is the system of numbering the version?
where is the version number located?
what is the optimum number of plugins?
what is the maximum number of plugins SU can handle?
are some plugins "heavier" than others?
do toolbar plugins "weigh" on the system more than drop down menu plugins?
what is the load on demand process? and how can you remember all those plugin names?
what would be the process of removing plugins, knowing what went with what?I look forward to answers and opinions...
(I know a lot of the answers could be found individually in the forum but I think it would be good to have them all in one post. towards one end... optimization.)
-
Well, other thing that could help users to decide about plugins would be a poll on each plugin page on SCF, where users to vote if they use it. Or some other way to see which plugins are most used. I noticed that are several plugins which make similar things, but It's a little hard to choose which is best.
The only way I can think now, would be "by popularity". I can see this is not the best idea, maybe someone else will have a better one. -
How about a list of redundant plugins also, ones that have been superceded or even have newer plugings that include what they did?
lot's of folks just copy and paste all their plugins version to version.
-
@unknownuser said:
lot's of folks just copy and paste all their plugins version to version.
Guilty as Charged.
-
I've always thought that Sketchucation should develop a co-op of it's highly talented posters and create a compendium of these programs. If you think about it, this would be a moneymaker for some of these skilled script writers in a consolidated effort and categorized based on professions. You've attempted this with your forum sub-categories and ruby listings; maybe a refinement of this effort, i.e. script written by the combined efforts of Tig,Didier and Chris Fullmer. Rewards could be offered efforts recognized and as mentioned financial gains.
-
Well, I'll explain my system and logic as best I can. I know other script writers have different ideas about how it should be done. At this point, there are just so many of us, it is hard to come to any concensus. But I do feel script writers should do something to organize their work.
I preface all my script names with "clf_". clf_shape_bender.rb for example. That way, as you look through your folder, all my scripts are all next to eachother in line. Many scripts are single files, just the .rb file. But some get more complex and involve icon files. Anytime I have more than one file, I put it into its own sub folder, also labeled clf_shape_bender. Though to be more complete, once there is a subfolder, the ruby file in the plugins folder is actually just a small "loader file", so the complete naming structure would be:
file in plugins folder =
clf_shape_bender_loader.rb
sub fodler name =clf_shape_bender
main ruby file name inside of subfolder =clf_shape_bender.rbAnd that is my file naming convention system. Then within my files, I put everything into its own class or module, also prefaced with "clf_". So if I make my own "offset" class, I would name it something like "Clf_offset_sb" so it has my initials, its name, and sometimes another marker to differentiate it even more. Because if class names conflict with another script, the scripts can break eachother. So if two people decide to make their own "Offset" class, then their scripts will probably mess eachothers up. There are some ideas out there about how to handle internal naming better. So far we are getting by with just trying to be creative and not use simple names, though some people could do better.
when I started writing scripts, I was seeing that my scripts were going to quickly cause people's plugins menu to be too long for the screen. That is why I put all of my plugins in the Chris Fullmer Tool submenu. So I only take up one line in the plugins menu. Then I don't feel so bad about making lots of small plugins. As for toolbars, I find I don't use them that much so I tend to not make them. But for some of the more complex scripts, I like to make them if it makes the csript feel more complete. I also rarely use the right click menu, and I hate my right click menu being cluttered, so for that reason I almost never load anything into the right click menu.
There also is a ruby tool called RDoc for script documentation. Theoretically, we couold all use their markup system and document our scripts internally. Then you, the user, could run rdoc on their plugins folder and it would read all the scripts and puttogether an html document with all the scripts information. It could easily include plugin version, basic usage, in-depth usage, copyright info, author name, website, on and on.
I use this system in my scripts a little bit. I think if you run rdoc on my scripts, it will output lots of basic info because I have my template set up to use rdoc formatting. Not all script authors care for rdoc. But seriously this is slightly more advanced than the average user would need to do. BUT, it is possible to setup a plugin library here on SCF where scripts would be uploaded. Then SCF server could run rdoc on its scripts every night and update a new set of HTML files that would be current. Online documentation of all scripts at SCF.
That would be a massive undertaking though that would require that plugin authors all get on-board. But something like that would help make it so that SCF coulld have a plugin that helps you keep your scripts up to date. You would install a script on your machine that would check in to SCF and compare the scripts you have installed to the current version numbers and it would let you know if you have outdated scripts. Would it be a cool service? Yes! Who has the time to develop it? No one. Who has the money to pay someone to do it? At this point, probably no one. That would cost a lot of time ($$$) to develop.
Smustard has something similar though. So you can download the smustard toolbar and check for smustard script updates.
Hope that gives some insight into my process.
Chris
-
Chris, one other thing about your system that I appreciate is your conformance to Rick Wilson's Organizer.rb. It is so nice to be able to move scripts into subfolders rather than trying to sort through a huge list in the plugins menu.
-
@unknownuser said:
There also is a ruby tool called RDoc for script documentation. Theoretically, we couold all use their markup system and document our scripts internally. Then you, the user, could run rdoc on their plugins folder and it would read all the scripts and puttogether an html document with all the scripts information. It could easily include plugin version, basic usage, in-depth usage, copyright info, author name, website, on and on.
I use this system in my scripts a little bit. I think if you run rdoc on my scripts, it will output lots of basic info because I have my template set up to use rdoc formatting. Not all script authors care for rdoc. But seriously this is slightly more advanced than the average user would need to do. BUT, it is possible to setup a plugin library here on SCF where scripts would be uploaded. Then SCF server could run rdoc on its scripts every night and update a new set of HTML files that would be current. Online documentation of all scripts at SCF.
that would be awesome...
-
looks like RDoc is inactive on SourceForge... no file to download.
-
Oh sorry, I just put the first link I found that looked official. I forgot that rdoc is now included in the regular ruby installation. So to get it, you would need to do download ruby and install that (it will have no affect on your SketchUp ruby). Then if you tell it to add all ruby executables to your system path, then all you would need to do is open a command window, navigate to your plugins folder and type "rdoc" and it would make a subfolde called "doc" with an index.html file that you would open in a web brwoser. Though the pluigins folder is often write protected on Vista, so I needed to copy my plugins folder to a temp folder in my
drive. Then it worked.So I went ahead and it just to show what it looks like. This whole thing, the html pages, the structure of it all, everything was made automatically from rdoc:
http://chrisfullmer.com/forums/doc/index.html
On the far left you can navigate from file to file (plugin to plugin approximately) to see more info on the plugin. Its semi useful, but not pefrect for what we would need.
Chris
-
@unknownuser said:
Chris, one other thing about your system that I appreciate is your conformance to Rick Wilson's Organizer.rb. It is so nice to be able to move scripts into subfolders rather than trying to sort through a huge list in the plugins menu.
Thanks Wyatt. I try to conform to what he set up. I'm not sure how many people use his system, but hopefully my scripts work well with his system.
-
I've found RDoc to be awkward to use. Instead I now use YARD: http://yardoc.org/
So far I've only used it with TT_Lib2: http://www.thomthom.net/software/sketchup/tt_lib2/doc/TT.html
Advertisement