JohnSwenson;487987 Wrote: > The previous products could be customized by writing plugins to the > server, the information on the display was sent over the network and put > on the display.
Correct. JohnSwenson;487987 Wrote: > In the new devices the screens are primarily controlled by the local > processors but I think data can still be displayed from the server. Incorrect. For instance, see the response to my query about taking over the screen of a new player (as is very easy with the old gear): http://forums.slimdevices.com/showthread.php?t=42596 -- in short, it seems that there MUST be Lua code on the player; the server cannot "push" info as with the older players. > This gives the option of writing third party applications the same as > before (as a server plugin) or as an "applet" that runs on the local > processor. Misleading. Plugins and applets have very different capabilities. JohnSwenson;487987 Wrote: > Even if you retain a "plugin" and tried to use it directly without > modification on the Touch it would be barely visible. The screen is much > higher resolution with a very different aspect ratio, thus if you > directly used existing plugins they would display as a little rectangle, > probably not what you had in mind. What are you talking about??? The majority of "old" plugins don't do bitmapped graphics, they deal with textual displays. Typically a plugin specifies what should go on each of the two normal text lines on, say, a Boom. One line is guaranteed to be there; the other will be there in all but one of the common text sizes for Boom/Classic/etc. True, there are some plugins that use custom bitmap fonts (SuperDateTime for weather & sports icons, MusicInfoScr for the "alternative volume" display, the simple shuffle & repeat icons, etc). But the vast majority just specify text and let the Squeezebox handle layout. JohnSwenson;487987 Wrote: > What Logitech chose to do was give developers the option to either > modify existing plugins to display properly on the Touch screen or start > from scratch writing a program that runs on the local processor. No, they chose to change the platform for the player, and to make more of the typical operations (like volume control) primarily "local". The fact that code can run on player or server is merely a byproduct of that fundamental decision. And, as noted above, each platform (SBS/server, SqueezePlay/player) has its own set of advantages and drawbacks. Often what was possible with 100% server-side Perl code for Boom now *requires* server-side Perl AND player-side Lua. And the current mechanisms for installing player-side code are terribly primitive -- especially that there's no way for SBS to "push" install to players, and player-side code is wiped out with any firmware update (which, as Controller owners know, happen more often than official SBS/MySqueezebox updates). JohnSwenson;487987 Wrote: > If a program is primarily working with the music files, searching, > taging etc its probably best to run on the server as a plugin, if its > primarily a graphical interface such as a visualizer its probably best > as an applet where it can quickly draw to the screen. True. JohnSwenson;487987 Wrote: > A plugin that works with the database and just has a simple menu and or > button interface should be easy to convert over. Something that has a > complex graphical display may be a little tougher. Oh, yeah? How many have you converted, John? Do you have any tools you'd care to share for converting old-style INPUT.* code to xmlbrowse? JohnSwenson;487987 Wrote: > So I don't think its quite fair to say that all third party work has to > be redone from scratch, some developers may choose to do so, some may > quickly convert existing plugins. On what are you basing your statements, John? I know you've been doing some serious work on the new platform, hacking Linux/ALSA configs, etc., but what experience do you really have writing plugins, writing applets, converting plugins to applets, and making plugins and applets interoperate? I do think you mean well and generally do respoect you, but I haven't seen anything yet to suggest you're at all qualified to comment on these development issues, and your post is full of misinformation and apparent speculation. Please stick to what you know. -- peterw http://www.tux.org/~peterw/ Free plugins: 'AllQuiet' (http://www.tux.org/~peterw/slim/AllQuiet.html) 'Auto Dim/AutoDisplay' (http://www.tux.org/~peterw/slim/AutoDisplay.html) 'BlankSaver' (http://www.tux.org/~peterw/slim/BlankSaver.html) 'ContextMenu' (http://www.tux.org/~peterw/slim/ContextMenu.html) 'FuzzyTime' (http://www.tux.org/~peterw/slim/FuzzyTime.html) 'KidsPlay' (http://www.tux.org/~peterw/slim/KidsPlay.html) 'KitchenTimer' (http://www.tux.org/~peterw/slim/KitchenTimer.html) 'PlayLog' (http://www.tux.org/~peterw/slim/PlayLog.html) 'PowerCenter/BottleRocket' (http://www.tux.org/~peterw/slim/PowerCenter.html) 'SaverSwitcher' (http://www.tux.org/~peterw/slim/SaverSwitcher.html) 'SettingsManager' (http://www.tux.org/~peterw/slim/SettingsManager.html) 'SleepFade' (http://www.tux.org/~peterw/slim/SleepFade.html) 'StatusFirst' (http://www.tux.org/~peterw/slim/StatusFirst.html) 'SyncOptions' (http://www.tux.org/~peterw/slim/SyncOptions.html) 'VolumeLock' (http://www.tux.org/~peterw/slim/VolumeLock.html) ------------------------------------------------------------------------ peterw's Profile: http://forums.slimdevices.com/member.php?userid=2107 View this thread: http://forums.slimdevices.com/showthread.php?t=71637 _______________________________________________ Touch mailing list Touch@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/touch
