Licensing Tutorial - link broken - 404

In the API Documentation at:

The link to the ‘Licensing Tutorial’ is broken:
http://ruby.sketchup.com/tutorial_licensing

Where could one learn more about the licensing process?

The documentation was revamped to use YARD and a new (ruby.) subdomain created for simplified links.
The YARD template must have assumed the tutorial would also be moved (or be in it’s root folder.)

But the tutorial is part of the extension warehouse project, and the correct URL is:


Also be aware the Developer Center entry portal is here:
http://developer.sketchup.com/en

… and the Extension Warehouse Guidelines are here:


:pushpin: Documentation Issue logged:

Hi Dan,
When using the following link:
https://extensions.sketchup.com/en/developer_center/tutorial_licensing

…I’m only shown a Developer Center overview page. Is there another link that’s working properly for the licensing tutorial?

Thanks,
Andrew

1 Like

Andrew the issue is still open because I actually changed the link in the documentation, but about the same time someone at Trimble redirected the link to the Developer landing page (with no explanation why.)

@tt_su has pinged @ChrisFullmer for an explanation in the latest post in the issue thread:
https://github.com/SketchUp/ruby-api-stubs/issues/5#issuecomment-286100424

1 Like

HELP !! I need a tutorial on licensing.
I can’t believe it is gone for so long without being replaced !
Must I understand that we are asked to use other means than SU API ?
To license SU extensions ?

1 Like

Hmm, I’m looking into this. I’m not sure why it went away. It probably got lost in the shuffle. I’ll try to find the previous version and get it published asap.

Except the previous version recommended a method which was easily hackable from the ruby console.

pls, use the same url, or we’ll have to edit the documentation (again.)

1 Like

Any news on this?

Still nothing !! ??

I made my own licensing test code public so others can use it as inspiration: https://github.com/Eneroth3/Sketchup-Api-Licensing-Test/tree/master/src

A similar implementation is used in my two commercial plugins and seem to work because people are buying them and one user even reported an error that couldn’t have occurred unless ExtensionLicense#licensed? returns true.

2 Likes

How nice of you. :smiley:
Many thanks.
I will have a look at it.

UNBUMP (EDIT unping ChrisFullmer, see below.)

Suddenly I’ve become interested in this tutorial too :grinning:
I recently copied implementation of a license check from one of a previously submitted extension (it successfully passed the review process and was published back then). This implementation in turn was copied from that disappeared tutorial. The surprising fact is that new extension was rejected recently after the review for the reason that it has inapropriate license check implementation.

Apparently, the online tutorials were removed as being problematic to keep updated (ie, fixing errors, etc.)

The licensing tutorial was replaced with a specific example within the API Tutorials repository:
https://github.com/SketchUp/sketchup-ruby-api-tutorials/tree/master/examples/99_license

Thanks for the link! It is clear that logic implemented in this example became different or at least new to me:

      ...
      # Menus and toolbars are always visible, regardless of the extension's
      # license state. This is to avoid confusing for the user. This require
      # the commands themselves to have a license check. As seen in the example
      # above, it's recommended to provide a message back to the user.
      menu = UI.menu('Plugins')
      ...

So seems like logic, described in a comment “Menus and toolbars are always visible, regardless of the extension's license state” appeared at some point and became mandatory (according to my observations). I have to admit that new logic makes sense especially in case if an extension has no free trial period. If there is a trial period, then in my opinion it’s fine simply to skip extension’s loading too. Because it feels like the fact of disappearing of extension’s UI elements (menu entries and toolbars) after its trial expiration is something self explanatory. But maybe I’m wrong.

Anyway I think it would be nice to inform extension developers somehow, when some new mandatory rules (not just recommendations, but something that may become a reason to reject a submission) appear.
Also I double-checked publishing guide-lines: https://help.sketchup.com/en/extension-warehouse/extension-development-best-practices
…and haven’t found a direct requirement to maintain extension’s menus and toolbars visibility regardless of an extension’s license state.
I wonder what other extension developers and users think: is it necessary to keep extension’s menus and toolbars visible or it is also possible just to skip its loading after trial period expiration?

The user can always unload the extension via the Extension Manager if they decide not to license the extension.

If I had a licensed extension module, I’d freeze it so no changes could be made.

You are free to add a validation proc for menu items and UI::Commands (for both menus and toolbars.) So you can disable and grayout commands that are no longer valid. SketchUp itself has several extension like this that are Pro only and do a Pro check in validation procs attached to commands.

However (especially toolbar) validation proc run a lot. Doing a license check over the net is likely to slow SketchUp way down. So, I’d suggest simply changing the whole validation proc at startup based upon an initial license check.
If the user licenses during the session, they’d need to restart. A message box can explain this to them.

Yes a validation proc is another possible way to handle license state I suppose. In some cases developers may decide to limit functionality only partially and leave some certain functions of an extension accessible even after free trial expiration. Another example of a limitation (conventional for rendering extensions) is a watermark over rendered images or a limitation of an output image resolution. In short there could be various ways to limit a functionality after a free trial expiration depending on an extension’s functionality and developer’s intentions.
So the main question in other words was: “what aspects of a license expiration handling are mandatory, and what are improper to such an extent that it may lead to extension submisson rejection?”

Yes, the Solar North Toolbar extension is like this. The visibility toggle is always available, but the setter tools and inputbox commands are Pro only. I never really understood why it is like this. (Why allow visibility toggle but not setting?)

This is something @ChrisFullmer, @tt_su or @ene_su would need to answer.
Hopefully it gets published in the developer help articles.

I hope that open discussion of this topic is appropriate. I even think it may become useful. For example as for me personally I have some doubts (perhaps groundless) about new mandatory aspect of implementation, when extension’s menu entries and toolbars must remain visible after trial expiration, but each tool button click or menu entry selection would pop-up a message about expired trial instead of expected outcome. Maybe it is not exactly a dark UX pattern (bait and switch), but it makes a strong resemblance with it and would certainly lead to some disappointment.
Disabled buttons, which borrow working space, bloat visual field, decrease discoverability of other UI elements may also be perceived by some users as something annoying. So I’m afraid there is no such thing like “ideal” trial expiration handling.
So the main reason to maintain extension’s UI elements visible regardless of a license state is based on an assumption that disappearance of an extension’s toolbar and menus after trial expiration is something confusing. I don’t know maybe this assumption in turn is based on some solid evidence (numerous questions from various confused users collected by EW support team). In case if assumption is purely theoretical, I would suggest to downgrade the status of a new implementation from “requirement” to “recommendation” maybe.