Home of the Squeezebox™ & Transporter® network music players.
Page 5 of 6 FirstFirst ... 3456 LastLast
Results 41 to 50 of 58
  1. #41
    Senior Member erland's Avatar
    Join Date
    Dec 2005
    Location
    Sweden
    Posts
    11,244
    Quote Originally Posted by Triode View Post
    Could you append a space to the name so it doesn't match? At present getString does uc on the token.
    Sure, adding a space is no problem if it solves the problem.
    Erland Isaksson (My homepage)
    Developer of many plugins/applets
    Starting with LMS 8.0 I no longer support my plugins/applets (see here for more information )

  2. #42
    Senior Member
    Join Date
    Apr 2005
    Posts
    8,410

    Re: Attention Plugin Developers: API Changing/Discussion

    OK I've thought some more about this and given the current addPageLinks API, I can see the merit of being able to dynamically change
    the string associated with a token, so I will include a setString function for this. This will be similar internally to the old
    addStringPointer, but hopefully more clearly named:

    Slim::Uils::String::setString ($token, $string)

    Limitations will be that it will only set the current language and the change will be lost if the language is changed. Given the
    use cases appear to be all related to the web page build, I believe this is acceptable.



  3. #43
    Senior Member erland's Avatar
    Join Date
    Dec 2005
    Location
    Sweden
    Posts
    11,244
    Quote Originally Posted by Triode View Post
    OK I've thought some more about this and given the current addPageLinks API, I can see the merit of being able to dynamically change
    the string associated with a token, so I will include a setString function for this. This will be similar internally to the old
    addStringPointer, but hopefully more clearly named:

    Slim::Uils::String::setString ($token, $string)

    Limitations will be that it will only set the current language and the change will be lost if the language is changed. Given the
    use cases appear to be all related to the web page build, I believe this is acceptable.
    Does this mean I have to predefine tokens in a strings.txt file and change them ?
    Or is there any way to add completely new strings from the plugin at runtime ?

    I guess I could add 20 predefined tokens that always is changed to something else if they are used, but it feels a bit stupid. Or will home.html also be changed to use |getstring instead of |string as it does today ?
    Erland Isaksson (My homepage)
    Developer of many plugins/applets
    Starting with LMS 8.0 I no longer support my plugins/applets (see here for more information )

  4. #44
    Senior Member
    Join Date
    Apr 2005
    Posts
    8,410

    Re: Attention Plugin Developers: API Changing/Discussion

    >> Slim::Uils::String::setString ($token, $string)
    >>
    >> Limitations will be that it will only set the current language and the
    >> change will be lost if the language is changed. Given the
    >> use cases appear to be all related to the web page build, I believe
    >> this is acceptable.Does this mean I have to predefine tokens in a strings.txt file and

    > change them ?
    > Or is there any way to add completely new strings from the plugin at
    > runtime ?
    >
    > I guess I could add 20 predefined tokens that always is changed to
    > something else if they are used, but it feels a bit stupid. Or will
    > home.html also be changed to use |getstring instead of |string as it
    > does today ?


    setString will allow addition of completely new strings at run time if you need it. At present I've not changed home.html to use
    getstring as I thought that setString would solve the problem. Does this not cover your use case?



  5. #45
    Senior Member erland's Avatar
    Join Date
    Dec 2005
    Location
    Sweden
    Posts
    11,244
    Quote Originally Posted by Triode View Post
    setString will allow addition of completely new strings at run time if you need it. At present I've not changed home.html to use
    getstring as I thought that setString would solve the problem. Does this not cover your use case?
    Yes, as long as it also is possible to add completely new strings using setString it should work.
    Erland Isaksson (My homepage)
    Developer of many plugins/applets
    Starting with LMS 8.0 I no longer support my plugins/applets (see here for more information )

  6. #46
    Senior Member
    Join Date
    Apr 2005
    Posts
    8,410

    Re: Attention Plugin Developers: API Changing/Discussion

    >Yes, as long as it also is possible to add completely new strings using
    > setString it should work.


    Trunk as now will allow this. The only limitation is that the new strings will be lost on a language change, but I view this as
    something users only do once, so don't see this as a significant problem?



  7. #47
    Senior Member erland's Avatar
    Join Date
    Dec 2005
    Location
    Sweden
    Posts
    11,244
    Quote Originally Posted by Triode View Post
    The only limitation is that the new strings will be lost on a language change, but I view this as
    something users only do once, so don't see this as a significant problem?
    No, that should be fine.
    Erland Isaksson (My homepage)
    Developer of many plugins/applets
    Starting with LMS 8.0 I no longer support my plugins/applets (see here for more information )

  8. #48
    Senior Member gerph's Avatar
    Join Date
    Oct 2005
    Location
    Reading
    Posts
    179
    I did an update to the trunk version earlier and noticed that all the plugins had stopped working. So I dug out this thread and read through the changes to see what needed to be done - primarily so that I could use LazySearch again :-)

    I didn't see any complete explanation of what had changed; just a few smatterings of comments. So whilst I've been making the changes here, I've made a quick note of what I did. If, as someone suggests, all the plugin authors follow every word of discussion and update regularly to keep their plugins working, then I'm sure these changes won't be hard anyhow. Instructions on how to update plugins to 7.0 would help greatly - and I noticed whilst doing this that the error log provides feedback to say what's wrong with the plugin which is lovely. Anyhow... for LazySearch2 I the following is necessary (as an example - other plugins may be similar in their changes - and some of this is restating things mentioned in the thread) :

    Plugins can no longer be bare perl .pm files. They must be in a sub-directory. Create a sub-directory with the correct name for the plugin - in this case 'LazySearch2'. Place the plugin source inside this directory as 'Plugin.pm'.

    Because of this move, the plugin's package will no longer be correct. This means that all references to 'Plugins::LazySearch2' will need to be replaced by 'Plugins::LazySearch2::Plugin'. A search and replace will do here. If the plugin tries to manipulate the contents of other plugins then they, too, will need to be updated. Obviously it's not a wonderful idea to mess with someone else's innards like that, but you knew that when you wrote the code.

    Strings have changed. They are no longer stored in the plugin source, but in a 'strings.txt' in the directory. Most plugins (LazySearch2 included) just return a big string. If the plugin does something more dynamic than this then it may be necessary to be more clever. However, for LazySearch2, locate the 'sub strings' and see it is returning a single string containing all the internationalised string translations. The contents of this string should be placed in 'strings.txt'. LazySearch2 has a few comments in the source attributing the translations to people. Obviously we don't want to lose this information, so these can be copied to the 'strings.txt' as well. Lines preceded by a '#' character are comments (same as perl) so this is easy to transfer. When this is done, remove the 'sub strings' function and all the comments relating to it.

    (at this point the plugin will function, but may not be completely usable)

    Settings have changed. Plugins are no longer organised so that all the settings are on a single 'Plugins' configuration. Each plugin has its own page. This means that the 'sub setupGroup' function which was previously used to return the details of how to construct the page is no longer used.

    (at this point I'm not entirely clear and haven't managed to make things work, so I'm going to explain what I can see and how I think it works)

    A new source file should be used to handle the settings - this is called 'Settings.pm', and should be based on the Slim::Web::Settings package ('use base qw(Slim::Web::Settings)'). This package provides most of the work necessary to configure the plugin. 3 functions must be provided in Settings file - name, page and prefs.

    The name is the name of the plugin and should be a string (eg 'sub name { return 'PLUGIN_LAZYSEARCH2'; ).

    The page should be the path in the SlimServer HTML hierarchy of the page to be used as the template (eg 'sub page { return plugins/LazySearch2/settings/basic.html'; }')

    The prefs returns a list of the preference variables which are required by this plugin (eg 'sub prefs { return qw(plugin-lazysearch2-minlength-artist plugin-lazysearch2-minlength-album ...); }' (many plugin preferences omitted!) ). It is recommended that these be prefixed by 'plugin-<name>' so ensure that there are no clashes.

    In the old API, the hash for the plugin variables allowed validation of the values specified and the specification of a message to display when the value was changed. My quick examination of the source doesn't tell me how to do this too clearly. It looks like there's a 'handler' function which takes a list of the values specifid and processes them; Someone else probably ought to provide some explanation of this, because I'm having trouble following what it must do and how it does it.

    The actual HTML files should be held within a directory within the plugin directory. This has the somewhat longwinded, but obvious form of 'HTML/<language>/plugins/<pluginname>/settings/<html file>', where <language> is the two character language which is in use, usually with 'EN' as a fallback, <pluginname> is the name of the plugin, and <html file> is the actual settings file to use. Other non-settings files would, presumably, live alongside the 'settings' directory. Compare this structure to the top level HTML resource directory and it should be observed that it follows the same pattern. The regular template operations can be used within the HTML.

    It might be useful for the Plugin manager to either log a warning if the plugin contains a 'setupGroup' function, as this no longer functions, OR to delegate its processing to another handler which can do the page generation in the old style.

    In investigating, the RadioTime plugin seems to have a very simple interface to allow it to be configured and would probably be a nice starting point for anyone trying to copy that behaviour.

    That's somewhat longer than I intended it to be, and it's not complete, but it's a partial documentation of what I understand the plugins changes are. I may have just wasted my time writing that lot out - there may be clearer documentation somewhere, but I didn't see anything in this thread or the wiki.

  9. #49
    Babelfish's Best Boy mherger's Avatar
    Join Date
    Apr 2005
    Location
    Switzerland
    Posts
    20,524

    Re: Attention Plugin Developers: API Changing /Discussion

    > Instructions on how to update plugins to 7.0 would help greatly

    I think it's just too early: the changes you've seen are not the planned
    changes to the plugin API but rather side effects of other changes. The
    plugin API overhaul is still to come.

    --

    Michael

    -----------------------------------------------------------------
    http://www.herger.net/SlimCD - your SlimServer on a CD
    http://www.herger.net/slim - AlbumReview, Biography, MusicInfoSCR

  10. #50
    Senior Member gerph's Avatar
    Join Date
    Oct 2005
    Location
    Reading
    Posts
    179
    Quote Originally Posted by Michael Herger View Post
    > Instructions on how to update plugins to 7.0 would help greatly

    I think it's just too early: the changes you've seen are not the planned
    changes to the plugin API but rather side effects of other changes. The
    plugin API overhaul is still to come.
    Fair enough; I just thought it would be useful to know what's changed. If my description helps someone then great. If it doesn't then the only person whose time I've wasted is mine.

Posting Permissions

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