Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Messages - Nao
10036
Features / Re: New revs
« on November 18th, 2010, 12:08 AM »
Yes you do...
It stayed in the Help template, yes (the one which we removed from Wedge), but it's only an example page, it's not the proper Display page.
Just compare RC3 to RC4's Display template. The top_subject went away ;)
They can remove it if they want... But then they should remove any code that manipulates it!
It stayed in the Help template, yes (the one which we removed from Wedge), but it's only an example page, it's not the proper Display page.
Just compare RC3 to RC4's Display template. The top_subject went away ;)
They can remove it if they want... But then they should remove any code that manipulates it!
10037
Features / Re: New revs
« on November 17th, 2010, 09:58 PM »
rev 262
! It would be a shame to break w3c validation just for this... Changed the lang trick to use comments instead. So, basically, move your onclick code, unmodified, to a comment immediately after the target element, and add a clickme class to that element. (Display.template.php, index.template.php, script.js)
- Removed a few nbsp's from Javascript confirm boxes. (index.french.php)
+ Finished French translation of the new Security language file. Hopefully... (Security.french.php)
Tested the comments trick successfully on Opera 9.62 (I figured it'd be more representative than v10.6x), Safari 5.0.2 (which BTW now seems to accept my CGZ files... Don't ask me), and IE8. It should be a tad slower than the lang version, but only because it retrieves firstChild and then possibly nextSibling.
! It would be a shame to break w3c validation just for this... Changed the lang trick to use comments instead. So, basically, move your onclick code, unmodified, to a comment immediately after the target element, and add a clickme class to that element. (Display.template.php, index.template.php, script.js)
- Removed a few nbsp's from Javascript confirm boxes. (index.french.php)
+ Finished French translation of the new Security language file. Hopefully... (Security.french.php)
Tested the comments trick successfully on Opera 9.62 (I figured it'd be more representative than v10.6x), Safari 5.0.2 (which BTW now seems to accept my CGZ files... Don't ask me), and IE8. It should be a tad slower than the lang version, but only because it retrieves firstChild and then possibly nextSibling.
10038
Features / Re: New revs
« on November 17th, 2010, 07:23 PM »
Okay, I'm committing, hopefully you can look into my code changes and my remarks in the changelog....
rev 261
! Trying to add support for .jgz and .cgz for Safari, but even if just using uncompressed .css, it doesn't seem to work on Safari 5.0.2... Needs some further research! (.htaccess, Subs.php)
* Moved the rest of the common Javascript to the bottom of the page. IE6 pawa. (index.template.php)
+ Started replacing onclick events with a neat trick I devised, to prevent UI clicks before the scripts are actually loaded. (Okay, I'm proud of myself, so what. Go away. I'm the only reading these changelogs anyway.) (Display.template.php, script.js)
! SMF bug: <span id="top_subject"> was missing, causing quick edit to fail on first topic posts. They don't want me as beta tester so I'll just let them find out by themselves. Ah ah. (Display.template.php)
* The user menu didn't return specific values, so return false anyway, so save a few bytes in the Display template. (topic.js, Display.template.php)
! User menu failed when clicking a guest account. (topic.js)
! Syntax error. (RemoveTopic.php)
! Whatever you put into onclick, it's *already* in Javascript... No need to specify it is! (Post.template.php, Display.template.php)
* Spacinazi on addPollOption. Why is that function duplicated anyway?! Should be changed... (Poll.template.php, Post.template.php)
rev 261
! Trying to add support for .jgz and .cgz for Safari, but even if just using uncompressed .css, it doesn't seem to work on Safari 5.0.2... Needs some further research! (.htaccess, Subs.php)
* Moved the rest of the common Javascript to the bottom of the page. IE6 pawa. (index.template.php)
+ Started replacing onclick events with a neat trick I devised, to prevent UI clicks before the scripts are actually loaded. (Okay, I'm proud of myself, so what. Go away. I'm the only reading these changelogs anyway.) (Display.template.php, script.js)
! SMF bug: <span id="top_subject"> was missing, causing quick edit to fail on first topic posts. They don't want me as beta tester so I'll just let them find out by themselves. Ah ah. (Display.template.php)
* The user menu didn't return specific values, so return false anyway, so save a few bytes in the Display template. (topic.js, Display.template.php)
! User menu failed when clicking a guest account. (topic.js)
! Syntax error. (RemoveTopic.php)
! Whatever you put into onclick, it's *already* in Javascript... No need to specify it is! (Post.template.php, Display.template.php)
* Spacinazi on addPollOption. Why is that function duplicated anyway?! Should be changed... (Poll.template.php, Post.template.php)
10039
Features / Re: New revs
« on November 17th, 2010, 11:48 AM »
Absolutely.
I'm tempted to add them everywhere (in prototype definitions) and then force users to use them as well, by failing to compile their JS if they don't.
I'm tempted to add them everywhere (in prototype definitions) and then force users to use them as well, by failing to compile their JS if they don't.
10040
Features / Re: New revs
« on November 16th, 2010, 11:30 PM »
rev 260
+ Added support for compressed JS files, just like CSS files but with different syntax. (.htaccess, Load.php, ManageServer.php, Help language, ManageSettings language)
* Moved all Display and Editor javascript to the footer, including some inline code that was in the header. (Class-Editor.php, Display.template.php)
+ Added wedge_add_css and wedge_add_js functions to make life easier. (Load.php, Subs.php)
+ Added a short copyright notice in the HTML source code, to have a signature left when people will remove the onscreen credits. (index.template.php)
! Fixed mixup between default theme and current theme when looking for CSS folders. (Subs.php)
! Started adding missing semicolons that would make the JS minifier fail. (editor.js, script.js)
@ JS minifier is a work in progress. Can't account for all lazy Javascript coders putting some strange code in... (Subs.php)
+ Added support for compressed JS files, just like CSS files but with different syntax. (.htaccess, Load.php, ManageServer.php, Help language, ManageSettings language)
* Moved all Display and Editor javascript to the footer, including some inline code that was in the header. (Class-Editor.php, Display.template.php)
+ Added wedge_add_css and wedge_add_js functions to make life easier. (Load.php, Subs.php)
+ Added a short copyright notice in the HTML source code, to have a signature left when people will remove the onscreen credits. (index.template.php)
! Fixed mixup between default theme and current theme when looking for CSS folders. (Subs.php)
! Started adding missing semicolons that would make the JS minifier fail. (editor.js, script.js)
@ JS minifier is a work in progress. Can't account for all lazy Javascript coders putting some strange code in... (Subs.php)
10041
Plugins / Re: Plugin hooks
« on November 15th, 2010, 11:51 PM »
I'm just having a hard time with the hyphen in "add-on"... :P
Seriously, I always like "mods". Just wanted to get rid of "packages"...
Seriously, I always like "mods". Just wanted to get rid of "packages"...
10042
Plugins / Re: Plugin hooks
« on November 15th, 2010, 07:12 PM »
I'm not 100% happy with the add-on structure, "add-on = mod(ification) or plugin". (mod = source code modification, plugin = something that uses hooks.)
I'd like to discuss changing this to "mod (modULE) = hack or plugin". I think the word "hack" really represents what this would be. Modifying the source code can cause issues, and thus isn't very solid, and is just a plain hack.
"Module" would be fine because people would then say "mods", like they do right now. "Mods" as "modifications" doesn't go well with the plugin system, so I think "mods" as "modules" would be better.
What do you think?
(Sorry, couldn't find where we discussed all of this originally...)
I'd like to discuss changing this to "mod (modULE) = hack or plugin". I think the word "hack" really represents what this would be. Modifying the source code can cause issues, and thus isn't very solid, and is just a plain hack.
"Module" would be fine because people would then say "mods", like they do right now. "Mods" as "modifications" doesn't go well with the plugin system, so I think "mods" as "modules" would be better.
What do you think?
(Sorry, couldn't find where we discussed all of this originally...)
10043
Features / Re: New revs
« on November 15th, 2010, 03:16 PM »
rev 259
+ Added hooks for copyright management ('place_credit'), and Pretty URL manipulation ('determine_location'). (Credits.php, QueryString.php)
- Removed the "orignal" txt strng, as it was emty in the fist plce. (Who.englsh.php, Who.frnch.pp)
+ Added hooks for copyright management ('place_credit'), and Pretty URL manipulation ('determine_location'). (Credits.php, QueryString.php)
- Removed the "orignal" txt strng, as it was emty in the fist plce. (Who.englsh.php, Who.frnch.pp)
10044
Features / Re: New revs
« on November 15th, 2010, 11:20 AM »
rev 258
* Moved CSS cache folder to the theme folder's root. (Subs.php)
* Replaced Wedge logo with a simpler one. (wedgelogo.png)
+ Added a help description for the styling selector. (ManageBoards language files)
* Spacinazi is adding a useless space, for once. It's just to make large hierarchies readable in Opera... (ManageBoards.template.php)
* Moved CSS cache folder to the theme folder's root. (Subs.php)
* Replaced Wedge logo with a simpler one. (wedgelogo.png)
+ Added a help description for the styling selector. (ManageBoards language files)
* Spacinazi is adding a useless space, for once. It's just to make large hierarchies readable in Opera... (ManageBoards.template.php)
10045
Features / Re: New revs
« on November 14th, 2010, 10:40 PM »
rev 255
* Renamed "package" to "add-on", "package-info" to "addon-info", "paquet" (French) to "extension", "modification" to "code add-on", etc. (tools/package/modifications/*, PackageGet.php, Packages.php, Subs-Package.php, language files in English and French: Admin, Errors, Help, index, Install, ManagePermissions, ManageSettings, Packages, Who)
Just to be clear... I only renamed these where the user has interaction with them. Internally, I didn't rename anything, because there are 2500+ occurrences of "package", and it's not ALWAYS related to actual add-ons...
If you want to do it, Pete, feel free, but our efforts should be focus on more important things.
Still, I'd like to see /Packages/ renamed to /Addons/. Would be nice.
BTW, I used "Extension" for French. It looks cool.
rev 256
* A few more renames I forgot. (Admin.*.php, Help.*.php, ManageSettings.english.php, Packages.*.php, Who.french.php)
(I just hope I didn't rename anything that shouldn't have been.)
rev 257
* Found better entities for representing theme hierarchy. I was dying to commit that. (ManageBoards.template.php)
* Renamed "package" to "add-on", "package-info" to "addon-info", "paquet" (French) to "extension", "modification" to "code add-on", etc. (tools/package/modifications/*, PackageGet.php, Packages.php, Subs-Package.php, language files in English and French: Admin, Errors, Help, index, Install, ManagePermissions, ManageSettings, Packages, Who)
Just to be clear... I only renamed these where the user has interaction with them. Internally, I didn't rename anything, because there are 2500+ occurrences of "package", and it's not ALWAYS related to actual add-ons...
If you want to do it, Pete, feel free, but our efforts should be focus on more important things.
Still, I'd like to see /Packages/ renamed to /Addons/. Would be nice.
BTW, I used "Extension" for French. It looks cool.
Posted: November 14th, 2010, 09:48 PM
rev 256
* A few more renames I forgot. (Admin.*.php, Help.*.php, ManageSettings.english.php, Packages.*.php, Who.french.php)
(I just hope I didn't rename anything that shouldn't have been.)
Posted: November 14th, 2010, 09:57 PM
rev 257
* Found better entities for representing theme hierarchy. I was dying to commit that. (ManageBoards.template.php)
10046
Features / Re: New revs
« on November 14th, 2010, 08:54 PM »
rev 254
* Renamed "Wedge Default theme" to just "Wedge"... If we call our main theme "Wedge", people will understand that it's the default theme, right? Right? (Install.english.php, Install.french.php)
! Fixed a XML bug reported by live627. Thanks! (Subs.php)
* Reworked the theme/styling selector to better emphasize the overall hierarchy. (ManageBoards.template.php, admin.css)
* Renamed "Wedge Default theme" to just "Wedge"... If we call our main theme "Wedge", people will understand that it's the default theme, right? Right? (Install.english.php, Install.french.php)
! Fixed a XML bug reported by live627. Thanks! (Subs.php)
* Reworked the theme/styling selector to better emphasize the overall hierarchy. (ManageBoards.template.php, admin.css)
10047
Off-topic / Re: Aeva Message - My Wierd Sense Of Humour
« on November 14th, 2010, 11:46 AM »
Message shows up when someone's browsing an area which isn't registered in the action list.
It's easier to determine WHICH areas when you're using noisen and wedge.org as an admin (ie just me), because I also log the complete URI in the database, and I show it as a popup next to the description. Sadly, I rarely if ever go to the Who's online page, and thus I don't get to see people with strange descriptions browsing the gallery.
I could do it as a guest with another browser at the same time, of course...
It's easier to determine WHICH areas when you're using noisen and wedge.org as an admin (ie just me), because I also log the complete URI in the database, and I show it as a popup next to the description. Sadly, I rarely if ever go to the Who's online page, and thus I don't get to see people with strange descriptions browsing the gallery.
I could do it as a guest with another browser at the same time, of course...
10048
Features / Re: New revs
« on November 13th, 2010, 04:42 PM »
rev 253
* Renaming Wedge 1.0 Alpha to SMF 2.0 RC4 (Wedge 0.1), for as long as the BSD licensing is not official. (index.php)
! Clearly separated temporary from permanent hooks. (Load.php, Subs.php)
* The reqWin function will now open an iframe instead of a popup window. It's less aggressive and it's cooler. Also, it now properly positions it. (Help.template.php, script.js)
PS: reqWin was tested under Opera, not other browsers though... It may not work elsewhere. I'm quite happy with the current results, although we may want to go Ajax on this, so that we can add cool animations and show/hide on hover...
* Renaming Wedge 1.0 Alpha to SMF 2.0 RC4 (Wedge 0.1), for as long as the BSD licensing is not official. (index.php)
! Clearly separated temporary from permanent hooks. (Load.php, Subs.php)
* The reqWin function will now open an iframe instead of a popup window. It's less aggressive and it's cooler. Also, it now properly positions it. (Help.template.php, script.js)
PS: reqWin was tested under Opera, not other browsers though... It may not work elsewhere. I'm quite happy with the current results, although we may want to go Ajax on this, so that we can add cool animations and show/hide on hover...
10049
Plugins / Re: Plugin hooks
« on November 12th, 2010, 10:57 PM »
Well, I'd taken that into account...
Because I honestly doubt a hook function would take up to 64 characters ;)
More likely around 10 characters...
I chose serialize because it has a reputation for being extremely fast. (It may even be faster than an implode(',')... Haven't tested, though.)
Because I honestly doubt a hook function would take up to 64 characters ;)
More likely around 10 characters...
I chose serialize because it has a reputation for being extremely fast. (It may even be faster than an implode(',')... Haven't tested, though.)
10050
Plugins / Re: Plugin hooks
« on November 12th, 2010, 05:57 PM »
Obviously I can simply store them again in $modSettings['hook_*'] or something, but it'd force me to go through the entire array to find these keys and unserialize them or something. Uh.
Anyway, to reach 64KB, you'd probably need to have about, hmm... a thousand hooks?
That would probably be a bad idea, eheh.
Anyway, to reach 64KB, you'd probably need to have about, hmm... a thousand hooks?
That would probably be a bad idea, eheh.