Home of the Squeezebox™ & Transporter® network music players.
Page 3 of 23 FirstFirst 1234513 ... LastLast
Results 21 to 30 of 222
  1. #21
    Senior Member
    Join Date
    Apr 2005
    Posts
    8,410

    Plugin installer - demo now available in 7.3fortest

    > peterw;357790 Wrote:
    >> It'd be nice if the web UI would let me see the description and link to
    >> more info for plugins that are already installed. Currently it seems to
    >> only make that info available for upgrades and plugins not yet
    >> installed.

    >


    Yes this would be possible. I was relying on the information available from
    the installed plugin rather than the repo file for the list of installed
    stuff so I didn't have two cases - one where the plugin is installed but it
    is no longer in the repo and one where the one in the repo is installed.
    Perhaps I need two cases for this.

    > There are descriptions and links(homepageURL) available in the standard
    > install.xml file provided with a plugin. Description is already shown in
    > the standard Plugins tab in the settings interface, wouldn't it be
    > enough if it also provided a link to the "homepageURL" element ?


    Will look at this - we could probably link to this if the installed plugin
    is not in the current repos (there are two sources of data need to pick one
    and I had been using the plugin itself first - any views which should be
    used in this case?)


  2. #22
    Senior Member erland's Avatar
    Join Date
    Dec 2005
    Location
    Sweden
    Posts
    11,046
    Quote Originally Posted by Triode View Post

    > There are descriptions and links(homepageURL) available in the standard
    > install.xml file provided with a plugin. Description is already shown in
    > the standard Plugins tab in the settings interface, wouldn't it be
    > enough if it also provided a link to the "homepageURL" element ?


    Will look at this - we could probably link to this if the installed plugin
    is not in the current repos (there are two sources of data need to pick one
    and I had been using the plugin itself first - any views which should be
    used in this case?)
    Is it really worth doing any changes related to this before we merge the plugin installer with the standard "Plugins" tab ?

    Until we are ready to merge "Plugins" and "Extension Downloader" tabs in 7.4 or 8.0, I would suggest:
    - "Plugins" tab: Shows installed plugins, take information from install.xml file
    - "Extension Downloader" tab: Shows plugins in configured repositories that haven't been installed yet or plugins where a another version than the currently installed one exists in the repositories. Take information from the repository xml files.

    I plan to use the descriptions like:
    - Description in install.xml file shown in "Plugins" tab: Will contain a short description of the plugin
    - Description in repository xml fille shown in "Extension Downloader" tab: Will contain a short description of the plugin and a list of changes in this version compared to the previous version.
    - The link information will probably both link to an information page of the plugin, for example: http://wiki.slimdevices.com/index.php/TrackStat_plugin

    If the Extension Downloader interface is changed in the future so it doesn't allow <br> in the repository xml description element I'll probably have the same description in both cases. However, IMHO it really useful to make it possible to have a change log in the "Extension Downloader" tab.

    An alternative to all this would be if "Extension Downloader" provided a merged tab already in 7.3, so users could either user the standard "Plugins" tab with no download functionality or use the "Extension Downloader" tab which included all functionallity in "Plugins" plus the downloading functionality. However, this might be confusing to end users.
    Erland Isaksson (My homepage)
    Developer of many plugins/applets

  3. #23
    Senior Member
    Join Date
    Apr 2005
    Posts
    8,410

    Plugin installer - demo now available in 7.3fortest

    > Is it really worth doing any changes related to this before we merge
    > the plugin installer with the standard "Plugins" tab ?


    We can only realy do bug fixes/minor changes now - such as adding an extra
    link to the web page. Which I think this is.

    > Until we are ready to merge "Plugins" and "Extension Downloader" tabs
    > in 7.4 or 8.0, I would suggest:
    > - "Plugins" tab: Shows installed plugins, take information from
    > install.xml file
    > - "Extension Downloader" tab: Shows plugins in configured repositories
    > that haven't been installed yet or plugins where a another version than
    > the currently installed one exists in the repositories. Take information
    > from the repository xml files.


    Yes - the only other case that needs to be covered is plugins that have been
    installed by extension downloader, but are no longer in the repos - that was
    the case I was referring to. Without this its not possible to remove them
    (I don't want the user to go searching for where the plugin is....)

    > I plan to use the descriptions like:
    > - Description in install.xml file shown in "Plugins" tab: Will contain
    > a short description of the plugin
    > - Description in repository xml fille shown in "Extension Downloader"
    > tab: Will contain a short description of the plugin and a list of
    > changes in this version compared to the previous version.
    > - The link information will probably both link to an information page
    > of the plugin, for example:
    > http://wiki.slimdevices.com/index.php/TrackStat_plugin
    >
    > If the Extension Downloader interface is changed in the future so it
    > doesn't allow <br> in the repository xml description element I'll
    > probably have the same description in both cases. However, IMHO it
    > really useful to make it possible to have a change log in the
    > "Extension Downloader" tab.
    >
    > An alternative to all this would be if "Extension Downloader" provided
    > a merged tab already in 7.3, so users could either user the standard
    > "Plugins" tab with no download functionality or use the "Extension
    > Downloader" tab which included all functionallity in "Plugins" plus the
    > downloading functionality. However, this might be confusing to end
    > users.


    This won't be possible in the timescales - merging with the main plugin page
    will be later, once we get feedback that it works ok. [It was written to be
    standalone give the late stage of 7.3 that it was introduced] I absolutely
    want it to become the default mechanism for installing plugins in future
    though - so please support by providing a repo....

    I also want to lobby Slim to provide a default repo which we can all
    contribute to during the lifetime of 7.3. My aim is to get the url into
    7.3, but then look at the mechanism for building the centralised repo during
    the lifetime of 7.3.


  4. #24
    Senior Member erland's Avatar
    Join Date
    Dec 2005
    Location
    Sweden
    Posts
    11,046
    Quote Originally Posted by Triode View Post
    Yes - the only other case that needs to be covered is plugins that have been
    installed by extension downloader, but are no longer in the repos - that was
    the case I was referring to. Without this its not possible to remove them
    (I don't want the user to go searching for where the plugin is....)
    How is SqueezeCenter upgrades handled ?
    In this case you are probably going to have a lot of plugins in the Cache/InstalledPlugins directory which can't be loaded by SqueezeCenter because their install.xml <maxVersion> is below the new version of SqueezeCenter.

    A similar situation could also happen if you install a plugin which contains a bug so it can't be loaded during SqueezeCenter startup.

    Will plugins which can't be loaded also be available in the list of plugins possible to remove ?
    Or will they be deleted automatically when you try to install a new version after the upgrade ?
    Erland Isaksson (My homepage)
    Developer of many plugins/applets

  5. #25
    Senior Member
    Join Date
    Apr 2005
    Posts
    8,410

    Plugin installer - demo now available in 7.3fortest

    > How is SqueezeCenter upgrades handled ?
    > In this case you are probably going to have a lot of plugins in the
    > Cache/InstalledPlugins directory which can't be loaded by SqueezeCenter
    > because their install.xml <maxVersion> is below the new version of
    > SqueezeCenter.


    Something which needs fixing in time for 8.0...

    Actually at present any upgrade will remove the whole of the previous plugin
    by wiping the directory. I'm assuming there is no persitent data stored in
    the plugin directory as this is all stored in Cache and can be wiped.
    Plugins which were downloaded but disabled or failed to load should also be
    on the list for removal.

    Please try and report bugs if you find this is not the case....


  6. #26

    unpacking too soon?

    If I agree to upgrade a plugin, I see log messages like this:

    Code:
    [08-11-08 21:35:26.3544] Slim::Plugin::Extensions::PluginDownloader::_downloadDone (108) downloaded AutoDisplay to .../cache/DownloadedPlugins/AutoDisplay.zip
    [08-11-08 21:35:26.3559] Slim::Plugin::Extensions::PluginDownloader::_downloadDone (132) digest matches - extracting AutoDisplay
    [08-11-08 21:35:26.3862] Slim::Plugin::Extensions::PluginDownloader::_downloadDone (168) extracted AutoDisplay (AutoDisplay/) to .../cache/InstalledPlugins/Plugins/AutoDisplay
    And, indeed, that's what it seems to do. I thought the plan was to download the zips to DownloadedPlugins and check the sha1 checksums. If the checksum is OK, leave the zip in place; otherwise, delete it. Only clear out the old InstalledPlugins dir and unzip the new zip file when SqueezeCenter starts up.

    The current behavior seems likely to introduce consistency problems. For instance, HTML templates are re-read for new web requests if the template has been updated, but strings.txt files are only loaded at startup. So unpacking the zip before the SC restart could break the HTML templates for something as simple as a reference to a new string token.
    owner of the stuff at https://tuxreborn.netlify.com/
    (which used to reside at www.tux.org/~peterw/)
    Note: The best way to reach me is email or PM, as I don't spend much time on the forums.
    Free plugins: AllQuiet Auto Dim/AutoDisplay BlankSaver ContextMenu DenonSerial
    FuzzyTime KidsPlay KitchenTimer PlayLog PowerCenter/BottleRocket SaverSwitcher
    SettingsManager SleepFade StatusFirst SyncOptions VolumeLock

  7. #27
    Senior Member
    Join Date
    Apr 2005
    Posts
    8,410
    See coments in the code.. Unfortunately it is not possible to unzip at startup when the installer is implemented in a plugin. This will change as soon as we merge into the mail server (post 7.3). For the moment we ask users to restart the server as soon as something is installed. The only serious issue I see is if plugins include binaries which can't be deleted whilst they are in use.

  8. #28
    Senior Member erland's Avatar
    Join Date
    Dec 2005
    Location
    Sweden
    Posts
    11,046
    At the moment no error is shown if you enter an incorrect repository url or if the repository url can't be retrieved.
    Maybe it would be a good idea to show some kind of warning if the repository xml can't be retrieved ?
    Erland Isaksson (My homepage)
    Developer of many plugins/applets

  9. #29
    Quote Originally Posted by erland View Post
    I plan to use the descriptions like:
    - Description in install.xml file shown in "Plugins" tab: Will contain a short description of the plugin
    - Description in repository xml fille shown in "Extension Downloader" tab: Will contain a short description of the plugin and a list of changes in this version compared to the previous version.
    - The link information will probably both link to an information page of the plugin, for example: http://wiki.slimdevices.com/index.php/TrackStat_plugin

    If the Extension Downloader interface is changed in the future so it doesn't allow <br> in the repository xml description element I'll probably have the same description in both cases. However, IMHO it really useful to make it possible to have a change log in the "Extension Downloader" tab.
    I like your thinking. I think it'd be great if ther could be two strings, <desc> and <changelog>. The downloader page would show <desc> for everything, and also show <changelog> for extensions with updates available. Javascript could be used to expand/collapse this info so it's not overwhelming. Would there be any point in a third string, <notes>, for special installation notes (e.g., some of your plugins have significant impacts when first loaded due to DB work), or maybe it's enough to add a note to <desc> suggesting they visit the <link> page?

    I'm following your lead on this. My web page now has my PLUGIN_FOO_DESC text, but my repo XML has PLUGIN_FOO_DESC + PLUGIN_FOO_REPO_DESC. See the SyncOptions XML entry for a good example (though the published zip doesn't have the updated strings.txt yet). I've updated my mkrepo.pl script to handle this, and to make both HTML for including on another page (see link in my .sig) and the repo XML. And I added more comments so it should be easier for others to use & adapt.

    Adrian, this stuff is awesome. I fully expect to use this rather than my old SCP + bash script method pn my production system even for my own plugins.

    -Peter
    owner of the stuff at https://tuxreborn.netlify.com/
    (which used to reside at www.tux.org/~peterw/)
    Note: The best way to reach me is email or PM, as I don't spend much time on the forums.
    Free plugins: AllQuiet Auto Dim/AutoDisplay BlankSaver ContextMenu DenonSerial
    FuzzyTime KidsPlay KitchenTimer PlayLog PowerCenter/BottleRocket SaverSwitcher
    SettingsManager SleepFade StatusFirst SyncOptions VolumeLock

  10. #30
    Senior Member mudlark's Avatar
    Join Date
    Aug 2006
    Location
    Cumbria, England
    Posts
    736
    As a punter I would suggest that the plugin installer should be put out as simple as possible.

    Can there not be a central rep for those plugin designers who want to be included? Would this not mean a direct connection to it from the installer page in settings rather than the present cut and paste system?
    Transporter or Cyrus streamX>CyrusDACXP>ESPAudio P09B Active filter>Cyrus X x 2>Rhapsody, Avondale and Naim cable, Kubuntu 16.10 server, various boxes for storage.
    SB3 Flycatcher 3A linear power supply. Touch also.
    Using SqueezeBoxServer (LMS) 7.9
    Also piCorePlayer>Rega DAC>B4>Avondale 260>Royd Eden Kubuntu 14.10
    also naim 32.5>hicap>140>Akroyd Coniston

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •