sketchucation logo sketchucation
    • Login
    ℹ️ Licensed Extensions | FredoBatch, ElevationProfile, FredoSketch, LayOps, MatSim and Pic2Shape will require license from Sept 1st More Info

    Collaborative Effort - Ruby Template, RDoc, and Localization

    Scheduled Pinned Locked Moved Developers' Forum
    36 Posts 13 Posters 10.0k Views 13 Watching
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • T Offline
      todd burch
      last edited by

      Maybe something like this:

      
      <?xml version="1.0" encoding="UTF-8"?> 
      <menufile>
      	<mainmenu name="Tools">
      		<item>My Ruby Script V1.0</item> 
      		<submenu text="First Submenu">
      			<item>Function 1</item>
      			<item>Function 2</item>
      			<sep/> 
      			<item>Function 3</item>
      		</submenu>
      		<submenu text="Help">
      			<item>Contact Author</item>
      			<item>User's Guide</item>
      			<item>YouTube Video</item>
      		</submenu>
      	</mainmenu>
      </menufile>
      
      1 Reply Last reply Reply Quote 0
      • R Offline
        RickW
        last edited by

        @thomthom said:

        So use user completely replaces the menu language file?

        Just wondering about packaging. What if you want to include multiple language packs? (Or maybe this isn't the scope for this? This is purely a bare minimum way of allowing localization?)

        Someone replaces the contents of that file, yes. As far as Smustard goes, my goal is to have all our menu items converted over, and users could download "language packs" of the whole library of .menu files for their language (we'll see how quickly that gets done). 😄

        My goals in leaving it plain text is that it is most accessible (IMO) that way and it requires the least amount of processing in the ruby script, but there might be drawbacks. Input is definitely welcome.

        Obviously, for other authors, the issue is slightly more complicated, but only slightly. Each menu file could be appended with the proper country extension (for example, "myrubyscript-de.menu", "myrubyscript-mx.menu", "myrubyscript-enUS.menu" etc) and then the user removes the extension for the one they want to use ("myrubyscript.menu"). For Windowizer4, I tried making it automatic based on the SU-reported locale, but that was not reliable and so most users ended up renaming the .html file anyway.

        RickW
        [www.smustard.com](http://www.smustard.com)

        1 Reply Last reply Reply Quote 0
        • thomthomT Offline
          thomthom
          last edited by

          I see. Very interesting that integration with your site.

          While I'm positive to the XML format, my vote still goes to plain text as it'll be more understandable for more people.

          However, I'm wondering if the menu folder would have a set of subfolder for each language, so the users could switch between. I'm thinking in regards to the cases where there might be multiple people using a computer with different language preferences.

          
          menus
            + en
            + no
            + fr
          
          

          Thomas Thomassen — SketchUp Monkey & Coding addict
          List of my plugins and link to the CookieWare fund

          1 Reply Last reply Reply Quote 0
          • A Offline
            Aidus
            last edited by

            I wonder why people need such things 😲

            CPU: Intel Core i7 Extreme Edition 965
            RAM: OCZ Gold DDR3 1600MHz 12Gb
            Video: Asus Radeon HD4870 X2 2Gb
            Mobo: Asus P6T Deluxe 1366 Intel X58

            1 Reply Last reply Reply Quote 0
            • thomthomT Offline
              thomthom
              last edited by

              @aidus said:

              I wonder why people need such things 😲

              Why people need/want the UI in their own native/preferred language?

              Thomas Thomassen — SketchUp Monkey & Coding addict
              List of my plugins and link to the CookieWare fund

              1 Reply Last reply Reply Quote 0
              • T Offline
                tomot
                last edited by

                @rickw said:

                I'm considering adding this to the ruby template, but wanted to get input. After a rather infamous incident recently, I thought about easing the localization effort for menus, and came up with this:

                I have certainly benefited from looking at your coded Rubies, which have allowed me to mimic procedures for developing a bases upon which I was able to develop my own Rubies for distribution freely to his SU forum.
                That being said, I feel since Google bought SU. We have been more or less a rudderless ship. With each Ruby developer taking his or her own approach towards developing more advanced GUI solutions, under the Ruby umbrella.
                I applaud your efforts towards bringing some order to the Ruby script writing chaos. I also see you have taken it upon yourself to direct a task which I think should be directed by SU Google staff.

                But it appears they are again missing in action. Unless perhaps via private email you have their blessing in this endeavor.

                We also had a few weeks ago a new young gun 😄 who was offering to implement a new GUI within SU using the Python as a second scripting language. I looked at that thread through different eyes then those that responded, by dismissing it outright. As a result of a few negative comments his alternative solution was shot down by a few SU forum members.

                Again not a comment for or against was posted by SU Google staff.

                I don't know where Google wants to take SU. It would certainly be refreshing to get some direction from them.

                BTW: don't shoot the messenger, please!

                [my plugins](http://thingsvirtual.blogspot.ca/)
                tomot

                1 Reply Last reply Reply Quote 0
                • R Offline
                  RickW
                  last edited by

                  @tomot said:

                  I applaud your efforts towards bringing some order to the Ruby script writing chaos. I also see you have taken it upon yourself to direct a task which I think should be directed by SU Google staff.

                  But it appears they are again missing in action. Unless perhaps via private email you have their blessing in this endeavor.

                  Actually, Scott Lininger did provide input on the template file. I do know from private correspondence that they are very busy on some things and may not be responding as much as they would like, and hope Scott will have some time for input on this as well.

                  But yes, it is a rather self-appointed task 😄

                  I've thought about the xml vs. plain text issue. I suppose a standalone menu-generating script could be required and then called to create the menus by parsing the xml (which would need a <code> section added to Todd's example, I think). The drawback to me is that it becomes one more thing to write, distribute, support, and incorporate in the script, in addition to the extra menu file/s (which bothers me as well, but what do you do?). The benefit is that it clearly delimits each field's function.

                  RickW
                  [www.smustard.com](http://www.smustard.com)

                  1 Reply Last reply Reply Quote 0
                  • J Offline
                    Jim
                    last edited by

                    FYI, I merged the thread about menu localization into this thread.

                    Hi

                    1 Reply Last reply Reply Quote 0
                    • thomthomT Offline
                      thomthom
                      last edited by

                      I was thinking, if the plugins where made using the RDoc format, with HTML formatting. Then it should be possible to generate a documentation resource for then if they're collected into a joint repository. From what I understand, the Ruby docs http://www.ruby-doc.org/, are generated directly from the source.

                      With a joint repository, using this header, we can get a plugin manager working, as well as a central help system. I think that at the moment that I'm in favour of HTML formatting.

                      Thomas Thomassen — SketchUp Monkey & Coding addict
                      List of my plugins and link to the CookieWare fund

                      1 Reply Last reply Reply Quote 0
                      • A Offline
                        August
                        last edited by

                        Hi Todd,

                        @unknownuser said:

                        Get your requests in now, during the early design stages.

                        I've done lots and lots of API doc, sometimes writing SED scripts to extract info from header files etc., but I'm not really at the SOTA when it comes to RDoc, JavaDoc, Doxygen, etc.

                        I'd like to help in this project, if I can, but it looks from the discussion like I'm way down on the curve compared to other folks.

                        Could you put together an outline of what it might take to catch up?

                        One thing I'm going to throw out here that might make a difference if it's still early stages.

                        I've been seeing over and over in other doc projects that the idea of going from the code comments to a Wiki seems to be catching on. From a Wiki, you have immediate collaboration on updating the doc and there are lots of ways of going from Wiki to PDF and/or print.

                        And if it's just about any Wiki besides SharePoint, you have some kind of standard markup format for the Wiki text that can be a very simple rework of the code comments format. Then the Wiki manages the cross-references and the formatting and display and you don't have to reinvent all of that in your HTML output from the code comments.

                        The piece I've been looking for and have not been seeing anywhere is going backwards from the collaborative Wiki edits to merge those changes back into the source so that the "master" does live in the code and can be updated when the code is changed.

                        Any interest in pursuing that idea? Building systems that do the code>Wiki>PDF and Wiki>Code round trip is something I've been brainstorming about doing professionally, so getting into that with this project might just add to my portfolio.

                        Let me know what you think,
                        August

                        “An idea, like a ghost, must be spoken to a little before it will explain itself.”
                        [floatr:v1mcbde2]-- Charles Dickens[/floatr:v1mcbde2]

                        1 Reply Last reply Reply Quote 0
                        • R Offline
                          RickW
                          last edited by

                          Andrew,

                          It's an interesting idea, but I for one would be reluctant to let third parties edit my scripts (via a Wiki), which is essentially what you're proposing. A moderately clever person could introduce new code through the Wiki unless there was a parser that would filter out any ruby code, and then you would likely impede legitimate use of code snippets in commented sections.

                          It's not an impossible situation, but it would need some very serious attention to security.

                          As for SketchUp-oriented scripts, I'm not sure the collaborative comment editing is as important, but I'm certainly open to hearing from others about it.

                          RickW
                          [www.smustard.com](http://www.smustard.com)

                          1 Reply Last reply Reply Quote 0
                          • T Offline
                            todd burch
                            last edited by

                            Just as a community-wide FYI - ref. me on this project. I got interrupted with another project which I hope to finish this week, then I'll be back on this.

                            It's never too late.

                            Todd

                            1 Reply Last reply Reply Quote 0
                            • J Offline
                              Jim
                              last edited by

                              What about creating an abstract base class named Plugin which provides inspectors for the information? Not only could inspectors be created for name, author, copyright, license, etc; but also inspectors for menus, Commands and toolbar images?

                              This way, external applications (menu organizers, etc) can simply ask the plugin about itself.

                              Hi

                              1 Reply Last reply Reply Quote 0
                              • Chris FullmerC Offline
                                Chris Fullmer
                                last edited by

                                Ooh, I like the sounds of that.

                                Lately you've been tan, suspicious for the winter.
                                All my Plugins I've written

                                1 Reply Last reply Reply Quote 0
                                • R Offline
                                  RickW
                                  last edited by

                                  Ditto!

                                  RickW
                                  [www.smustard.com](http://www.smustard.com)

                                  1 Reply Last reply Reply Quote 0
                                  • thomthomT Offline
                                    thomthom
                                    last edited by

                                    @jim said:

                                    What about creating an abstract base class named Plugin which provides inspectors for the information? Not only could inspectors be created for name, author, copyright, license, etc; but also inspectors for menus, Commands and toolbar images?

                                    This way, external applications (menu organizers, etc) can simply ask the plugin about itself.

                                    Did anything happen to this?

                                    Thomas Thomassen — SketchUp Monkey & Coding addict
                                    List of my plugins and link to the CookieWare fund

                                    1 Reply Last reply Reply Quote 0
                                    • Dan RathbunD Offline
                                      Dan Rathbun
                                      last edited by

                                      @jim said:

                                      What about creating an abstract base class named Plugin which provides inspectors for the information? Not only could inspectors be created for name, author, copyright, license, etc; but also inspectors for menus, Commands and toolbar images?

                                      This way, external applications (menu organizers, etc) can simply ask the plugin about itself.

                                      I've actually done some playing around & testing this past week along these lines, before I saw this post.

                                      I had seen, in many standard (extra Sketchup) ruby scripts, that coders were just declaring a string constant "VERSION" at the top of their outer code blocks. This could be easily accessed ie:, Module::VERSION.

                                      But then the spark for me was seeing somewhere (perhaps within the RubyGems files,) someone took it a baby step forward by making the constant VERSION a Hash with 4 elements, the first 3 Integer components of the version number, and the 4th a string concatonation of the first 3. ie:

                                       VERSION=[MAJOR => 0, MINOR => 0, TEENY => 0, STRING => (MAJOR,MINOR,TEENY).join(".") ]
                                      

                                      This was a bit better, as you could get any one of the version components for comparison, without having to convert to numeric, by calling as an example:

                                       if Module;;VERSION[MAJOR] < 7 {..do a block..}
                                      

                                      Or if you wanted the whole version string, you'd call, like so:

                                      messagebox( "The plugin version is; #{Module;;VERSION[STRING]}" )
                                      

                                      But the spark had not yet ignited into flame until I stumbled across the standard ruby class OpenStruct. When I read the filenotes in 'ostruct.rb', I immediately thought this is perfect for versioning !!

                                      OpenStruct is similar to the built-in class Struct, but really makes it act like a true data object should act in an object oriented language like Ruby. Struct on the other hand is so much like a hash, there doesn't seem to be much benefit in it; as you still set and access values as you would in a hash object.

                                      OpenStruct is SO MUCH better! You simply state a new object name = followed by OpenStruct.new(keylist), where the keylist is just that; a list of data keys to create. The class creates all the keys as attributes, and automatically sets up getter and setter accessors for each one!

                                      (Pssst! [whispering off topic this would also be great for ruby-side JSON as OpenStructs will look and act just like Javascript Objects..)]

                                      So my thoughts are to set up a custom subclass of OpenStruct called VersionStruct, or just a custom class called VersionStruct that uses an OpenStruct. Still playing and testing which way is better. Any way the goal is to have something that is all setup correctly that can be either 'included' or mixed-in into a top code block, so the module or class inherits the data structure; OR instanstiated into a code block if it's set up as a class. (I cannot see making coders cut and paste a codeblock into everyscript, errors may creep in.) Anyway.. after instantiating a VersionStruct, a coder would set the fields, then freeze the VERSION object (so the data cannot be changed after the script is loaded.)

                                      Example: ['RubyTools' is a fictional Namespace.]

                                      
                                      module DandyCode
                                      
                                        VERSION = RubyTools;;VersionStruct.new(2,1,4)
                                        # first 3 parameters are integers; major, minor, teeny
                                          # note VERSION.string is created automatically
                                        VERSION.author="Ruby A. Coder"
                                        VERSION.copyright="(c) 2010 by author"
                                        VERSION.disclaimer="No Waranty...no particular purpose...author to be held harmless ...etc"  # can be preset
                                        VERSION.termsOfUse="Free for Public Use...etc." # can be preset
                                        VERSION.title="Title of this plugin code"
                                        VERSION.description="A short explanation of it's features."
                                        VERSION.minSUverMajor=7
                                        VERSION.minSUverMinor=1
                                        VERSION.dependancies=self.DependancyList
                                        VERSION.exclusions=self.ExclusionList
                                        VERSION.freeze
                                      
                                        DependancyList = Array.new
                                        DependancyList[0] = DependancyItemStruct.new(module='JRF;;Inputbox', minverMajor=2)
                                      
                                        ExclusionList = Array.new
                                        ExclusionList[0] = ExclusionItemStruct.new(module='SluggishKeyTrapper', allVers=true)
                                      
                                        VERSION.freeze
                                      
                                       .. more code ...
                                      end # module
                                      

                                      Anyway.. ideas to chew on...

                                      Currently.. I'm only playing with a VERSION structure that has Major, Minor, Teeny and String attributes.

                                      The other attributes in the above example, or discussed in the prior posts, could be in a separate struct as Jim suggested called 'Plugin' or whatever. (We've seen a similar thing done with the Sketchup Extension Class, except that it's put in a separate file.)

                                      For those interested, who don't have a full ruby install, I attach the ostruct.rb file that ships with Ruby 1.9.1 (put it in a folder that's in the search path, perhaps the Tools folder. I personally have it in a folder named 'Library' which I put in my search path.)


                                      ostruct.rb

                                      I'm not here much anymore.

                                      1 Reply Last reply Reply Quote 0
                                      • 1
                                      • 2
                                      • 2 / 2
                                      • First post
                                        Last post
                                      Buy SketchPlus
                                      Buy SUbD
                                      Buy WrapR
                                      Buy eBook
                                      Buy Modelur
                                      Buy Vertex Tools
                                      Buy SketchCuisine
                                      Buy FormFonts

                                      Advertisement