Wedge

Are you free starting Monday? :P

Seriously, who would use "drawers" to discuss mods ;)
No, I think we should just use "mods" everywhere, including where "packages" is being used. Nobody cares about the container.

This is really where the issue is: there's already a name for these. Mods. "Packages" is barely used, and confusing. If you choose "Drawers", or "Cogs", or anything silly or not, newbies are still not going to understand it, just like "packages" is hard to understand... While "Modifications" is a bit easier, and "plugins/extensions/add-ons" DEFINITELY is easy to understand. That's what matters. Remember one of our mottos: if it needs explaining, then it's not good ;) (Interestingly, the iPod Touch comes without a proper manual... I was quite surprised with that. But it's really efficient, most of the time.)

Maybe we could do this:
- We change the whole terminology to "Extensions" or "Addons".
- We then use two sub-genres.
- Some extensions will be called "modifications" or "mods". They're the addons that use a xml file to modify the Wedge code. No warranty is given as to what happens when you upgrade, and in case of conflicts. "It may work, but good luck".
- Other extensions, those without the xml modifications, will be called "plugins", will be showed as such in the admin, and will be properly supported by Wedge. We will encourage modders to release plugins.

Well, we'll probably be renaming other vars, so...
Like, $smcFunc. What does SMC mean? Most people don't know. (And I don't even remember, myself.)
$wedgeFunc is too long and $weFunc may sound like "we fuck", so... $wf?
Might as well use $cx and $wf. And then document the change somewhere.

I'm thinking we could be doing things even better...
For instance, create a global local array (if I may say), something like $local_array, which we'd global everytime we write a function that offers hooks.
Now, instead of adding a hook point and specifying the vars that can be shared with it, we'd just add a hook point -- period. Hooks would then automatically be able to access the local array where we put all of the code. ($local_array['this_variable'] for instance.)
At the beginning of the original function, we could add $this_variable = &$local_array['this_variable'] or something. Then we can change $this_variable, and the hook function would still be able to access $this_variable without needing to determine which local vars we'll pass through the hook.

Aaaaand, once again, I'm totally obscure and probably offering to do something that would complicate everything needlessly. :P

Still, most of the SMF calls to call_integration_hook provide only a variable or two, AND they often 'forget' to provide a reference to the variable, instead of a copy of the variable. It not only makes it a bit longer to process -- but it also prevents the mod from tampering with the variable at all. Which can be counter-productive.Yeah, $context could be a place to store most of these vars. We could also delete the vars after they become useless, but I don't know, maybe it'd be a waste of time.
Also, rename $context to $cx or something, to make it faster to type?And we should/would/will try to be open about hook addition requests. Like, "if you add a hook here, I could do this or that without modding the code". If it seems like something that would benefit more mods, then it'll definitely warrant a mod.

Seriously, I think there are many places that should never have been moddable in the first place -- like, adding menu entries. It should be done exclusively via hooks. We just need to educate modders about it.

PS: maybe this conversation should be split into the private area.

It's the rounded corners topic really ;)

Should have bought DeathSpank instead, man! :P
Best game I've played in months on the PC... (Probably best since Tales of Monkey Island... Ah ah.)

rev 251

! $modSettings['pretty_enable'] didn't actually exist, so it screwed up a lot of Pretty URLs code... (ManageBoards.php, QueryString.php, ManageBoards.template.php)
! Fixed some styling. (ManageServer.php, ManageSettings.php, index.css)
! Foolishly trying to make all browsers like each other when showing popups. Sob. (script.js)
+ Added placeholder about a "Wedge license"... Need to setup an URL and actually put something there. (script.js)

Was unrelated until now, but since this will probably all find its way into Wedge... Here's the Aeva Media latest rev changelog, eheh :)

rev 11

+ Added transparency flag to pictures, and functions to determine transparency. (db_aeva.php, Aeva-Gallery.php, Aeva-Gallery2.php, Aeva-Subs.php, Aeva.template.php)
* Changed album page layout to show only thumbnails and titles, and hide the rest, which will instead appear in a popup when you hover over the thumbnail or title. (Aeva-Subs.php, am.css)
* Instead of just kilobytes, show filesize in bytes, kilobytes or megabytes in item pages. (Aeva-Gallery.php, Aeva.template.php)
+ Added a function to hide/show popups in IE6. (Aeva-Subs.php, am.js)
! Fixed error when deleting a comment. (Aeva-Gallery.php)
! Fixed animated GIFs shown at incorrect sizes when using ImageMagick. (Aeva-Media.php)