Aborting a .rbz install

driven

cheers,
I got it working by 'naming' the difficult ones
but I'll have a play with your version tomorrow...

I think it's worth not loading the binary into a PC, even if it won't hurt...

your up late

john

danielbowring

Deleting it seems like overkill, you could employ something like this instead


module AuthorModule
    def self.is_mac?()
        # ...
    end

    module PluginModule

    end if is_mac?

    mac_only_warning unless is_mac?
end

Or in the extension file


if is_mac?
    extension = # ...
else
    mac_only_warning
end

driven

having 'only works on mac' should be enough, but never is.

I'm just wanting to avoid the 'this isn't working' posts from 'PC' users.

Beside anything else, it would be trivial for SU to pre-screen for files marked as os dependant.

john

danielbowring

@driven said:

having 'only works on mac' should be enough, but never is.

I'm just wanting to avoid the 'this isn't working' posts from 'PC' users.

Beside anything else, it would be trivial for SU to pre-screen for files marked as os dependant.

john

Note the if is_mac? at the end of PluginModule. That will prevent the plugin from "loading" anything more. Same if you just don't register the SketchupExtension. You could also write a setting to prevent it re-showing the message using Sketchup.write_default / Sketchup.read_default

Edit: Demo


module MyModule
    puts "This section will never be executed!"
end if false # because of this!

puts "But this will!"

puts defined?(MyModule)

Gives


But this will!
nil

TIG

BUT we are trying to stop an RBZ install of a plugin onto an incompatible OS [a relatively rare occurrence?]...
So we need to check the OS early on, then tell the user what we are doing and delete the files/subfolders of files that ship in the RBZ [including itself!] ans stop loading anything at all.
It pointless having a plugin installed into an OS where it won't work...

driven

@aerilius said:

.. or maybe the plugin folder is synced with another system on which the plugin is supposed to be used).

Excellent point I hadn't considered.

I was already leaning towards adding the [ is_mac? ] to the menu/toolbar loader, which which will prevent unusable menu items when on the wrong platform...

As my plugin's 'logic' is dynamically loaded into SU by either of these items being 'clicked', then it will also remain inert without any additional screening.

This, in addition to setting the extension i.e.
Sketchup.register_extension( add_icon_to_mac_skp, false) unless is_mac?
should accommodate a shared Plugin folders.

further thoughts?

john

TIG

If you have mixed OSs on a network which share plugins you are making some issues for yourself...
Only a few plugins ship in PC and MAC 'version's anyway, and handle OS differences within their methods...
So just allow the plugin to install on any OS...
but as suggested... test in the main 'loader' for the appropriate OS and only set up its Extension if there's an OS match...
That way you could have it installed on a shared folder that resides on a PC, that can never actually load it, but it can successfully load from that shared folder if it's called by a MAC etc...

Aerilius

Are there no risks when messing around with file deletions?
[If such a method existed] I would prefer to use corresponding API methods for (un)installation, or more generally put:
The same method for uninstallation that was used for installation (by hand, API or EWH).

What is the problem of keeping the plugin and just telling the user about the issue. This gives the clearest explanation and the least surprise. Also the user could maybe have reasons to keep the plugin installed without using it actively (like only inspecting how it works, or maybe the plugin folder is synced with another system on which the plugin is supposed to be used). Suddenly disappearing files would rather make a user worried and would blur the line between good software and malware.

Edit: Another thing is: Using ruby to delete files circumvents the trash. If we let the user manage "his" files (that the user installed), there is the chance to restore them.

driven

one last idea
what happens on Windows if I add this to the top of each script

windows use = nil

If done correctly on a mac it returns nil and the ruby continues.

@unknownuser said:

you cantype non-breaking spaces directly on OS X with Option+Space.

I'm under the impression Windows will see it as a space and error out
Error: #<NoMethodError: undefined methodwindows' for #Object:0x56b89ec>`

If so, I can add it and even if the file/folders are there, nothing will run unless your on a mac...

pilfered from here:
http://www.rubyinside.com/the-split-is-not-enough-whitespace-shenigans-for-rubyists-5980.html

danielbowring

@driven said:

I'm under the impression Windows will see it as a space and error out
Error: #<NoMethodError: undefined methodwindows' for #Object:0x56b89ec>`

Depends what encoding you save it in.

Western (Windows 1252) gives this:


Error; #<SyntaxError; (eval);5231;in `load'; path/to/nbsp.rb;1; Invalid char `\240' in expression>

UTF-8, however, will load and work fine


windows use = "o.~"
puts "Success #{windows use.inspect}"

# ->

load 'path/to/nbsp.rb'
Success "o.~"
true

Note: Browsers will replace the character in question (160, "non-breaking space") with a regular space (32, "space"), but I did correct for this for this test.