England
Joined: May 16, 2014
Post Count: 33
Status:
Offline
Re: Plug-in update
I don't know if there's an 'official' way to deal with this. However when your plugin loads, your Action class object is run. At that time, I add a menu items to the "Tools" menu.
public class Action extends PluginAction { public Action() { putPropertyValue(Property.NAME, "ToWebPlugin..."); putPropertyValue(Property.MENU, "Tools"); setEnabled(true); } ... stuff deleted ... }
You could inspect something over the internet (using http) and inform the user that a new version is available. And a brief explanation about how to install it.
France
Joined: Nov 7, 2005
Post Count: 9426
Status:
Offline
Re: Plug-in update
If a plug-in declares an id among the properties of ApplicationPlugin.properties (which is unfortunately not the case for the plug-in you wrote), Sweet Home 3D proposes to describe a new version of a plug-in (or a library) with an update XML element that respects the following DTD. To ensure the end users receive this information, the update XML element will have to be integrated to SweetHome3DUpdates.xml hosted on sweethome3d.com web server. It's the file that is read at program launch when a user has Internet access to sweethome3d.com and the Check updates at program launch option is selected in the preferences pane. At the moment, editing SweetHome3DUpdates.xml can only be made by the webmaster of sweethome3d.com, i.e. me. Hope you'll understand that I'll accept to edit that file only for very important udpates.
----------------------------------------
Emmanuel Puybaret, Sweet Home 3D creator
Joined: May 28, 2015
Post Count: 607
Status:
Offline
Re: Plug-in update
Trying to write a tutorial (I will submit you) for setting up the SunFlow rendering engine, I found a new revision of the PhotoRenderer.java and PhotoRenderer.properties files. The integration of these new settings in the plug-in is an important update?
----------------------------------------
EnkoNyito
Joined: Sep 15, 2010
Post Count: 40
Status:
Offline
Re: Plug-in update
Hi Emmanuel,
so you are saying even if we integrate the ID it wouldn't help, as you wouldn't integrate new versions of our plugins into SweetHome3DUpdates.xml?
By the way, I couldn't find something about the ID in the Plug-in developer's guide. Only the JavaDoc of Plugin.java states:
The id key gives an optional id to the plug-in, which can be useful to determine if an update for this plug-in is available during libraries updates checking.
For me it looks like that this option was intended for your own plugins.
Just an idea: What about an optional updateUrl in the ApplicationPlugin.properties, which points to an URL that uses the same or a similar DTD?
France
Joined: Nov 7, 2005
Post Count: 9426
Status:
Offline
Re: Plug-in update
I never stated that I'll refuse to update SweetHome3DUpdates.xml for contributed plug-ins, and I don't understand how you can conclude that I programmed this feature for me exclusively since I even didn't use it myself! It wasn't possible for enkonyito's plug-in when he made his comment, because he didn't set any ID in the previous version of his plug-in (I was also on vacation at the end of November and forgot to answer here when I got back).
There's no information about this ID in the Plug-in developer's guide because the update warning was added afterwards.
What about an optional updateUrl in the ApplicationPlugin.properties, which points to an URL that uses the same or a similar DTD?
That's a nice idea but not so easy to program because it would require to merge the update information to display only one dialog box to the user. I fear also that it could be a way to spam users with messages I couldn't control.
----------------------------------------
Emmanuel Puybaret, Sweet Home 3D creator
Joined: Sep 15, 2010
Post Count: 40
Status:
Offline
Re: Plug-in update
Hi Emmanuel,
I never stated that I'll refuse to update SweetHome3DUpdates.xml for contributed plug-ins
Oh, apologies, no offense, it seems that I've got the meaning of this statement wrong:
I'll accept to edit that file only for very important udpates.
I have to admit that the intention of your first post was not really clear to me and I might have interpreted it in a wrong direction.
So lets try to make it clear:
How should the ID look like - esp. to prevent name clashes (in other words - what's the difference to just use the plugin name or class)?
How does the workflow of a new update look like esp. on which channel does a plugin developer provide a new update-element to you?
When will that update get promoted to your XML file?
If that is the official way of providing easy updates for a plugin to the end user, could you integrate it into the Plug-in developer's guide?
A last word about "spamming" with the updateUrl: As soon as someone has installed a 3rd party plugin, you have already lost control .
Seriously, if every plugin developer uses his own update stratgegy, because there is no official way for updates, the user might be annoyed even more by the different configuration, messages, intervals...
. 
