Discussion of Standardization in RoadRunner skins, plugins, addons and whatever else
Let me introduce myself, my name is Marvin and I've been using RoadRunner since its inception. In my previous career, I was tasked to maintain interoperability of offensive and defensive weapons systems for leading edge U.S.Air Force aircraft systems. It has come to my attention recently that many agree that some standardization is now required for RoadRunner in order for skins, plugins, addons, and whatever else to play nice together (kinda like what I used to do for the warfighters).
There have been several attempts to discuss standardization for individual aspects of this wonderful front-end, but it seems only a few participated, even less paid attention, and the community as a whole is falling apart. One notable exception is the plugins bug which required all plugins be redone so all their indicators would work regardless of the load sequence, but there, too, some of the plugin developers are either no longer on the forum or don't have time to update their work. The RR.ini variable "BACKGROUNDPATH" was discussed and Guino agreed to create this variable in the source code for standardization, but I guess it was not widely publicized because skinners are still creating their own variable to perform the same task.
Another thing that has come up lately is skinners programming in a vacuum. I understand that your skin is your creation for you and you don't have to share it nor do you have to change it cause every RoadRunner enduser want some special tweak. But when one skin stops another from operating properly, some sort of interoperability standard needs to be developed and followed by all. A skinner that puts all the plugins he uses in his skinpath and registers them via installer, is a dangerous thing for anyone who uses more than one skin, i.e., I no longer know which copy of the plugin is running, and therefore, when an update must be installed I have no clue which one to uninstall.
Standardization could also cleanup the RR install as well as eliminate most duplication. Using "BACKGROUNDPATH" as an example: I have over 300 backgrounds on my development machine. If I didn't manually move backgrounds I'd have thousands (mostly duplicates) all over the RR skins. So every time I install a new skin, I search the new skinpath for backgrounds, copy them to my backgroundpath, and then begin learning the coding of the skin to fix the backgroundpath references. MAKE THE DAMN NEWBIES DO THIS! Just tell us old heads that additional backgrounds are included in the skinpath.
This brings up my last concern, documentation. I know this is a dirty work among programmers (I were one). Even when I had programmers working for me, I had to constantly remind them to document, document, document inside and out! Here, as in my last career, we could probably make this easier by developing boilerplate docs. By this I mean boilerplate instructions for the Newbies to be included in the readme.txt distributed with new skins, plugins, etc., that explains how to make everything work using the RR standards. I know we'll always have newbies posts like in the DFX thread where the response is: "Its in the Docs!" But hopefully, if we say it enough for every skin it'll sink. I noticed it doesn't come up nearly as much in DFX, but it took 2500 posts to get the message across.
Now, how do we accomplish this? That's what this thread is for, I hope. I don't see us convening a standards committee, nor Guino dictating to us what needs to be done, definitely not MitchJS, who doesn't understand every aspect of the source, let alone the plugins/skinning/etc. If not them then who? I'm not planning on going away, so I could volunteer to maintain the final boilerplates (especially since I no longer do computer language programming, a little RRCode, but that's it) Who wants to start coming up with examples? DFX docs are probably the most extensive and I would think JohnWPB wouldn't mind us borrowing from him to develop a list of topics for boilerplating, start with what he has already written and update it to be appropriate for any skin based upon the agreed standardization.
As the standards are set, we will also need another thread locked from new posts that will summarized all standards, list boilerplate for copy into skinners documentation, and address unresolved standardization issues. This too I am willing to maintain for the community. I realize this will become a lifetime project and am willing to take this on for the foreseeable future. Who else wants to help?
The first step is to close the holes in the RoadRunner Source documentation. A lot of changes/additions were made this year and the only "skin commands.txt" and "readme.txt" (RR.ini commands) that I can find are from 12/04/07 and Mitchjs' 092308. Who knows what was done in between during the source code wars? What got added, what didn't, what got changed, what got removed? HELP!
CURRENT PROPOSALS:
1.CHANGES TO THE ROADRUNNER.EXE SOURCE
a) How about having RR become a little more intelligent. As RR loads a skin let it check if the BACKGROUNDPATH is actually set in RR, and if it's not then have RR load a default BG colour to get the skin going. Add to this the ability to actually have the "FILEEXSITS" IND/CMD actually work so it checks inside the skin if the BG image is there and if not the skinner can take appropriate action to allow the user to set the BACKGROUNDPATH variable from inside his/her skin.
b) Put in a sub folder is the preset files (*.pst) called something like "Presets" that is one item that can have a lot of file with it
2. ..\ROAD RUNNER\Backgrounds\files
Skinners use backgroundspath for background.skin references to background directory.
Eliminate "Background=" from RR Config. "Background=" should be in skin.ini.
I still need words (boilerplate) to add in readme.txt for directions on moving sample backgrounds from skin directories to the common directory.
3. ..\ROAD RUNNER\PLUGINS\PLUGINNAME\files
A new RR.ini entry needs to be made, that is initially defaulted to: "PluginsPath=c:\Program Files\Road Runner\Plugins\" added to RR.ini. The soon to be released Plugin Browser can be used much like RRConfig to add remove and update plugins. Now is the time to set where the plugins will reside. Plugin developers need to use relative paths. All plugin labels, buttons, sliders and indicators should be prefixed with the plugin name (to avoid conflicting with other plugins). Developers need to distribute plugins in .zip format. A text file containing a list of button, labels, indicator a slider codes should be included in the zip file (call it skincommands.txt). Users will be able to specify where there plugins install via .ini. NO installers for plugins. Each developer should provide a set of skin files and graphics that contain an example of how there plugin can be used. Every plugin should have a set of BMV2 or Carwings skin files and graphics seeing as that is the default skin it comes with, the PSD's are easily available. Also, if there are dlls other than the main plugin .dll that need be registered you have 2 options:
a) Register them in your code(if you need help with this pm me)
b) Document which files need registering along with the method they need be registered (regsvr vs codebase etc)
These little requirements should make most all plugins past and present compatible with the plugin browser.
4. To enhance plugin management, skinners should now use "INC, PLUGINS.TXT" in their MENU.SKIN and a PLUGINS.TXT file to list applicable plugins.
5. All the standalone DLLs (other than GDI+ and MusicPlayers), scripts, add ons, etc. should be located in "..\Road Runner\Plugins\{Plugin Name}\files", not the root of the plugins folder, nothing should be in the root, except maybe documentation to help developers, skinners and users.
6. All plugins should have an indicator that has the same name as the plugin, so that other plugins can tell if they are running or not
7. Add a "requiredskins" list within the plugin itself, that could be both listed/displayed by the browser and could make RR aware of it, or maybe just inform the user that the plugin X requires skin files: Y, Z in the case those are not present on the loaded skin.
***** BACKGROUNDPATH ***** standard
O.K. after reviewing the forum, the consensus of those participating agreed that backgrounds should be in a folder under the RRPath. The backgroundpath variable does not have an "S" in it.
So for all future skinners and updates please utilize "C:\Program Files\Road Runner\Backgrounds" for the location of your backgrounds. This is in conjunction with all users setting backgroundpath=C:\Program Files\Road Runner\Backgrounds\ in their RR.ini files. Pay particular attention to the trailing slash in your programming, this has caused problems in the past.
I will be accepting any and all comments about how to word the documentation to explain the skinners' process for adding their own backgrounds to the folder.
This standardization will allow end-users to use the same set of backgrounds for all their transparent skins without duplication. Another issue brought up along these lines was adding a single background in the skinpath and distribute new skin with that initially set in the skin.ini as the background. This way they work right out of the box and support the standardization if other backgrounds are available. This should also probably be discussed in the documentation for the newbies.
MGBs welcome (Moans, Gripes, *****es). What say you?
***** Plugins Path ***** standard
Enforcer started a standardization thread for plugins and I don't want to step on any toes there, but from what I could glean from the discussion, the majority agreed to have all plugins located in a subdirectory off the RRPath. The overwhelming consensus was to use "C:\Program Files\Road Runner\Plugins\PLUGINNAME\FILES". I'd like to move that discussion here and moderate as necessary. The old thread. Further discussion in the Road Runner Plugin Browser thread.
Here are my thoughts: The biggest drawback to me in doing this is the manual labor required to uninstall, move, and reinstall the numerous plugins, but once that's done I would have reduced the number of sub directories under the RRPath by half. JohnWPB mentioned that they wold stop working if buried in sub/sub folders of the RRPath. Can anyone verify this? And If so does it require a change in the RR source or changes in the plugins to relative paths? I don't know. So I'm for it, but I don't look forward to it.
But this thread is about standardization. So how do we make this transition as smooth as humanly possible?
