SKX: Purpose and Philosophy

Moderator: Jim

SKX: Purpose and Philosophy

Postby Dan Rathbun » Tue Mar 29, 2011 10:31 pm

Is the SKX namespace and it's subnamespaces are for extending and patching the Google Sketchup namespace objects only (ie: modules Sketchup, Geom and UI, and the classes they encapsulate.) ?

I kind of envision the SKX system working this way:

We have an skx folder in one of the $LOAD_PATH dirs.
In that folder, are plugin scripts for a Sketchup API Extension Manager and a Sketchup API Patch Manager.

An API Extension is something that adds functionality (missing methods, etc.) to one of the Google modules or classes. (We write them in a way that still allows Google to add these functionalities to later API versions without conflict.)
In my mind, there is a big difference between such an extension, and a Plugin (which is an Application Extension, not an API Extension.)
Anyway.. I would put extension scripts in a skx/ext subfolder.

An API Patch is a temporary fix (usually written in Pure Ruby, but possibly also in compiled C or C++,) that fixes a bug in the API until it can be fixed by Google in a later release. These patches, thru the Patch Manager, would only be loaded if needed, dependant upon the Sketchup version and build, and Platform the user is running.
I would put patch scripts in a skx/fix subfolder.

A perfect Patch example that I thought of when John posted the list of command constants (using that little lister script I wrote*,) would be a patch script that redefines as many of the CMD_... constants as possible, on the Mac platform only, to send_action() strings. (Which is the way they should have been implemented by Google.) Later, when the Mac edition is updated, assuming it could happen, the patch can test to see if these constants have already been defined as strings, or perhaps test the Sketchup.send_action() method to see if it will accept Integer arguments on the Mac. If the test determines, that the patch is no longer needed, it is not loaded, and the reason why is logged in a "patch log".
The user should be able to open a "patch log viwer" and see which patches have been loaded, and which have not.. along with the reason(s) why.
We might even give the user a manual override.. that allows them to turn on|off individual patches based upon their own knowledge of whether they are needed, or perhaps they are a developer doing testing, and need to turn off a patch, during development.
0
    I'm not here much anymore. But a PM will fire email notifications.
    User avatar
    Dan Rathbun 
    PluginStore Author
    PluginStore Author
     

    Re: SKX: Purpose and Philosophy

    Postby Dan Rathbun » Tue Mar 29, 2011 10:39 pm


    Jim's, original intention for SKX is spelled out in the first post of this topic: SketchUp Ruby API Extension Library


    @Jim: Have your conceptions about SKX, it's potential, and it's implementation, changed since you first proposed it ?

    How do my ideas mesh with yours ?
    0
      I'm not here much anymore. But a PM will fire email notifications.
      User avatar
      Dan Rathbun 
      PluginStore Author
      PluginStore Author
       

      Re: SKX: Purpose and Philosophy

      Postby Jim » Sun Apr 03, 2011 3:36 pm

      Dan Rathbun wrote:s the SKX namespace and it's subnamespaces are for extending and patching the Google Sketchup namespace objects only (ie: modules Sketchup, Geom and UI, and the classes they encapsulate.) ?


      Yes, that was part of the initial idea. The general understanding is that it's a bad thing to modify SketchUp's built-in classes because they can cause problems with other scripts. But adding and modifying the built-ins can really make things easier for script writers, not to mention it's such a natural way to code when using Ruby.

      It wasn't long before plugins began appearing which were adding and modifying built-in methods anyway. Solutions to common problems were being duplicated and beginning to cause problems due to slight variations in the method behaviors.

      I thought if the modifications to SketchUp's built-in methods are going to happen anyway, maybe we can all agree on using a single library to implement them. That way, eveyone is on the same page - both users and developers.

      Initially, my intentions was to fix annoying, incorrect, and possibly non-intuitive behaviors through modifying the core classes, adding helper methods/features, and optimizing performance.
      0
      Hi

      Jim 
      Global Moderator
       

      Re: SKX: Purpose and Philosophy

      Postby Jim » Fri Dec 21, 2012 3:36 am

      Dan Rathbun wrote:How do my ideas mesh with yours ?


      You've expressed them better than I. I'm not as concerned about details like file locations, load paths, etc; but rather with creating libraries that enable script writers to more easily create plugins/tools by writing less code.

      The most prolific authors have already created their own libraries (some quite extensive.) At this late stage, it doesn't seem realistic to expect cooperation by authors in updating existing plugins to use an Skx-type library - what incentive is there?

      Yet, I still believe Skx would enable the creation of plugins by people who are not programmers and may lack the time to learn all the idiosyncrasies of SketchUp's Ruby API.

      Scott Lininger posted his thoughts about the scope of Skx, which I think also meshes quite closely to what you have expressed.
      0


      Last bumped by Dan Rathbun on Fri Dec 21, 2012 3:36 am.
      Hi

      Jim 
      Global Moderator
       

      SketchUcation One-Liner Adverts

      by Ad Machine » 5 minutes ago



      Ad Machine 
      Robot
       



       

      Return to Skx Extension Library

      Who is online

      Users browsing this forum: No registered users and 1 guest

      Visit our sponsors: