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
3601
Archived fixes / Re: Uninitialized string offset in Subs-BBC.php, line 1133
« on February 21st, 2013, 06:08 PM »
Fixed user menu thingy.
3602
Archived fixes / Re: Uninitialized string offset in Subs-BBC.php, line 1133
« on February 21st, 2013, 05:58 PM »
It's not that 'the errors disappear', it's that they disappeared, period...
I was simply emptying the cache. Which needed emptying after I'd just updated the website to rev 1942 (so, it has 10 days worth of new features, including the new language caching feature, which will hopefully help Pete test it on a wider scale.)
You just happened to refresh the page in the 2 minutes between finishing the upload and me finishing emptying all caches. ;)
:edit: Please report if you find the error shows up again, though.
PS: so, it takes a bug report to get you to post eh? :lol:
Okay, found a bug that I couldn't have seen in my test site because of me having just a single account to test with...
(It's with the user mini-menu.)
I was simply emptying the cache. Which needed emptying after I'd just updated the website to rev 1942 (so, it has 10 days worth of new features, including the new language caching feature, which will hopefully help Pete test it on a wider scale.)
You just happened to refresh the page in the 2 minutes between finishing the upload and me finishing emptying all caches. ;)
:edit: Please report if you find the error shows up again, though.
Posted: February 21st, 2013, 05:55 PM
PS: so, it takes a bug report to get you to post eh? :lol:
Posted: February 21st, 2013, 05:57 PM
Okay, found a bug that I couldn't have seen in my test site because of me having just a single account to test with...
(It's with the user mini-menu.)
3603
Features / Re: New revs
« on February 21st, 2013, 05:35 PM »
rev 1942 -- just one file, but it allows us to close a few bug reports... And hopefully not create any new one ;)
(1 file, 4kb)
! Committing my select box fix for .sb() not correctly updating the scrollbar. To tell you the truth, I left it to rot for a while because I couldn't figure out an efficient way to allow the user to click outside of a select box *after* **another** select box was redrawn with .sb()... Then I sat down, thought again about it, and I only have one thing to say. Why the hell would some code redraw a select box *while* you're in another? I mean, if you didn't even click one of the options, there's no reason for Wedge to redraw another select box anyway, right...? It just goes to show how silly I am sometimes. Well, the good news is that I'm not paid for all of that, so my hypothetical boss couldn't complain about the waste of time. (sbox.js)
@ Please note that not only the code is cool (it won't close the select box if it's being updated as of now...), but it's also shorter by 22 bytes than before. And I don't think I'd save more bytes by getting rid of the ability to keep the box open when updating it.
(1 file, 4kb)
! Committing my select box fix for .sb() not correctly updating the scrollbar. To tell you the truth, I left it to rot for a while because I couldn't figure out an efficient way to allow the user to click outside of a select box *after* **another** select box was redrawn with .sb()... Then I sat down, thought again about it, and I only have one thing to say. Why the hell would some code redraw a select box *while* you're in another? I mean, if you didn't even click one of the options, there's no reason for Wedge to redraw another select box anyway, right...? It just goes to show how silly I am sometimes. Well, the good news is that I'm not paid for all of that, so my hypothetical boss couldn't complain about the waste of time. (sbox.js)
@ Please note that not only the code is cool (it won't close the select box if it's being updated as of now...), but it's also shorter by 22 bytes than before. And I don't think I'd save more bytes by getting rid of the ability to keep the box open when updating it.
3604
Features / Re: New revs
« on February 21st, 2013, 05:15 PM »
rev 1941 -- I wanted to make a joke about the importance of being earnest, but it only works for in French. Damn translations. And I couldn't think of a Spielberg joke, either.
(27 files, 5kb)
* Replaced we::$is_ajax with AJAX constant... It's shorter, easier to type, and performance tests suggest that reading a constant is faster than accessing a static object. Also moved the declaration back to QueryString, because it no longer needs the system object and I'd rather define that one ASAP. (SOURCES: Class-Editor, Class-Skeleton, Class-System, JSModify, Like, Load, Aeva-Embed, Aeva-Gallery, Aeva-Gallery2, Aeva-ModCP, Aeva-Subs-Vital, Subs-Media, Packages, PersonalMessage, Post, Post2, Profile-View, QueryString, Search, Search2, Security, Split, Stats, Subs-Menu, Subs-Template, TEMPLATE: GenericPopup.template.php)
* CSS/JS filenames will now only retain the last 6 digits of the latest date. I'm even tempted to keep only 4 or 5... This gives a greater chance of cache collision, but seriously: one in a million, literally. And even if a file collides with an earlier version, what are the odds that the file, being at least 11.5 days old, will still be in some user's cache? And finally, you can always reupload a JS/CSS file to regenerate its date ID if someone complains about a collision. (Subs-Cache.php)
- Removed ?> footer from regular cache files. I tried hard, but couldn't find any evidence that this impacts performance, so we might as well save these two bytes, shouldn't we..? (Subs-Cache.php)
(27 files, 5kb)
* Replaced we::$is_ajax with AJAX constant... It's shorter, easier to type, and performance tests suggest that reading a constant is faster than accessing a static object. Also moved the declaration back to QueryString, because it no longer needs the system object and I'd rather define that one ASAP. (SOURCES: Class-Editor, Class-Skeleton, Class-System, JSModify, Like, Load, Aeva-Embed, Aeva-Gallery, Aeva-Gallery2, Aeva-ModCP, Aeva-Subs-Vital, Subs-Media, Packages, PersonalMessage, Post, Post2, Profile-View, QueryString, Search, Search2, Security, Split, Stats, Subs-Menu, Subs-Template, TEMPLATE: GenericPopup.template.php)
* CSS/JS filenames will now only retain the last 6 digits of the latest date. I'm even tempted to keep only 4 or 5... This gives a greater chance of cache collision, but seriously: one in a million, literally. And even if a file collides with an earlier version, what are the odds that the file, being at least 11.5 days old, will still be in some user's cache? And finally, you can always reupload a JS/CSS file to regenerate its date ID if someone complains about a collision. (Subs-Cache.php)
- Removed ?> footer from regular cache files. I tried hard, but couldn't find any evidence that this impacts performance, so we might as well save these two bytes, shouldn't we..? (Subs-Cache.php)
3605
Features / Re: New revs
« on February 21st, 2013, 04:52 PM »
rev 1940 -- more love for JSON, yay!
(5 files +2, 22kb)
+ Added support for JSON and XML strings to returnAjax() helper function... The JSON bit is interesting, because you really, really just need to supply an array or object to the function and it'll deal with it for you. Gotta like that. (Subs.php)
* More shameless script.js optimizations... Using .click() instead of .on(), while using a really odd structure, saves about 6 bytes. Changing is_opera init position and removing an unneeded 'false' init saves a byte or two (I'm unsure, gzip magic and all). Moving a semi-colon around ajaxUrl saves another byte. Removed a test for .thought_actions which I forgot to (saves 10 bytes!), and removed the strange .toLowerCase in the thought object -- while I suppose I did have a good reason to add this one, I'd rather save 5 bytes now and revert it later if I remember what it was for. Overall, saved close to 25 bytes while keeping the exact same functionality. (script.js)
* Rewrote JumpTo object to optimize it for performance and size. First, converted it to use a JSON object. This saves 26 bytes in JS, and a variable but noticeable number of bytes in the response. Then, err... Removed the name sanitizer, which was a leftover from SMF days, and saved an extra 25 bytes. The JSON thing took me an hour. This one took a second. Whatever. (script.js, Ajax.php, Xml.template.php)
+ Added a json_encode() fallback, called we_json_encode(). Just call it instead of the other. The original class was about 33KB, I reduced it to 6KB by stripping the decoder (which would only be used in the Google Closure codepath -- and I'm never going to recommend this one by default, so we're safe for now), all comments, cleaning up the code, and turning the class static. (Class-JSON.php, Subs.php)
+ Added an alternative json_encode() fallback to the attic. It's much shorter, much faster, and gave me similar results on test arrays, but I chose to go with the 'safe', PEAR-approved solution. (attic/Unused-json_decode.php)
! JSON_UNESCAPED_UNICODE is only for json_encode, so it was silly of me to use it in a json_decode call... Even if that call isn't actually in the Wedge codebase, ah ah. I scare myself. (attic/Unused-convertU.php)
@ Overall, saved 85 bytes in the gzipped script file since yesterday... And gave Wedge more power to boot ;)
(5 files +2, 22kb)
+ Added support for JSON and XML strings to returnAjax() helper function... The JSON bit is interesting, because you really, really just need to supply an array or object to the function and it'll deal with it for you. Gotta like that. (Subs.php)
* More shameless script.js optimizations... Using .click() instead of .on(), while using a really odd structure, saves about 6 bytes. Changing is_opera init position and removing an unneeded 'false' init saves a byte or two (I'm unsure, gzip magic and all). Moving a semi-colon around ajaxUrl saves another byte. Removed a test for .thought_actions which I forgot to (saves 10 bytes!), and removed the strange .toLowerCase in the thought object -- while I suppose I did have a good reason to add this one, I'd rather save 5 bytes now and revert it later if I remember what it was for. Overall, saved close to 25 bytes while keeping the exact same functionality. (script.js)
* Rewrote JumpTo object to optimize it for performance and size. First, converted it to use a JSON object. This saves 26 bytes in JS, and a variable but noticeable number of bytes in the response. Then, err... Removed the name sanitizer, which was a leftover from SMF days, and saved an extra 25 bytes. The JSON thing took me an hour. This one took a second. Whatever. (script.js, Ajax.php, Xml.template.php)
+ Added a json_encode() fallback, called we_json_encode(). Just call it instead of the other. The original class was about 33KB, I reduced it to 6KB by stripping the decoder (which would only be used in the Google Closure codepath -- and I'm never going to recommend this one by default, so we're safe for now), all comments, cleaning up the code, and turning the class static. (Class-JSON.php, Subs.php)
+ Added an alternative json_encode() fallback to the attic. It's much shorter, much faster, and gave me similar results on test arrays, but I chose to go with the 'safe', PEAR-approved solution. (attic/Unused-json_decode.php)
! JSON_UNESCAPED_UNICODE is only for json_encode, so it was silly of me to use it in a json_decode call... Even if that call isn't actually in the Wedge codebase, ah ah. I scare myself. (attic/Unused-convertU.php)
@ Overall, saved 85 bytes in the gzipped script file since yesterday... And gave Wedge more power to boot ;)
3606
Features / Re: New revs
« on February 21st, 2013, 04:51 PM »
rev 1939 -- tough job. C'est la vie.
(2 files, 14kb)
+ Added French agreement... I suppose that's how it's done..? I just took the text from the original SMF file. (Agreement.french.php)
* Partial French translation for e-mail templates. Seriously, this is one of the worse translation sessions I've ever had to go through... I've always hated this file, and I always will! (EmailTemplates.french.php)
(2 files, 14kb)
+ Added French agreement... I suppose that's how it's done..? I just took the text from the original SMF file. (Agreement.french.php)
* Partial French translation for e-mail templates. Seriously, this is one of the worse translation sessions I've ever had to go through... I've always hated this file, and I always will! (EmailTemplates.french.php)
3607
Bug reports / Re: Mini-menu implementation
« on February 20th, 2013, 08:09 PM »
Too many posts... :^^;:
And I really tend to overlook them all when there are too many.
I don't know how you can keep up, AND do long speeches at Elk and SM boards...!Quote from Arantor on February 18th, 2013, 10:49 PM Yes, which is why reuploading the file will fix the problem, but not emptying the cache... Because the original CSS/JS files will keep their original date ID.Quote (Done.)Quote I usually do that... And end up forgetting what I was doing the day before.
Creating my changelog and checking diffs in Tortoise is the only way I manage to keep up with my own changes and whatever I need to fix before the proper commit.Quote In this case, it wasn't about choosing, it was just about removing a duplicate file... ;)
Although I think we should consider changing some of our reply/quote/whatever icons.Quote In the end I pushed it to the left after the date, to be consistent with the mobile version where both date and action menu are in the first line, followed by a newline and the thought.
What do you think about the mini-menu as it is, anyway..?Quote I'd rather avoid it, but it's the obsessive-compulsive me talking at that point. See, I'm perfectly okay with adding 500 bytes for a cool new feature. I just don't think it's okay to add 500 bytes when it could be 300 with just some more effort... :^^;:Quote I don't understand what you're trying to say about the ternary fix...
Anyway, that one is just me trying to push short code into a single line when it's spread over 4 lines... That's just me.
Also, regarding the reason I changed the mini-menu code to always create all entries at load time, rather than hover time. Yes, 70ms (for a full page) isn't something to be ignored. If performance becomes an issue, I'll gladly rewrite my code to use pure JS instead of jQuery (it's all about manipulating document fragments...)
However, the reason, as I said, is that with this, I can do something pretty smart.
- Move ALL action entries to the mini-menu code. (Saves at least 200 gzipped bytes per page...)
- Calculate the current div width. Add entry to div. See if entry goes to a new line. If not, continue. If yes, cancel that one, move it to the action menu, and keep adding to the action menu for the remaining entries.
This would basically allow us to show the action menu on any screen width, and then ensure that smaller screens get an action menu when it's too much for them.
I don't know if I'm going to implement this immediately, but what do you think of it..?
I think the main (only?) drawback to this method is that if JS is disabled on your browser -- you don't get to see any option at all... This is why Wedge currently shows the two most important settings (quote and modify) as regular links, not part of the menu.
BTW, I'm working on allowing other thought pages to use the mini-menus.
Currently, I have the 'All thoughts' page showing it, as well as Likes. It doesn't show the Like/Unlike button in the menu though (just the likes count outside the menu.) Also, it's still buggy, so I can't actually edit or post answers.
I was a bit torn between copying the Homepage code to the other functions, but then I decided to instead try to merge both into one... So the homepage now includes the Thought source, but it's kinda annoying, the homepage code has some really custom stuff that the other pages don't, and vice-versa... Though job. Is taking longer than I'd like...
Will eventually complete it, though.
Oh, and the script.js file is now 22 bytes shorter than yesterday... :lol:
And I really tend to overlook them all when there are too many.
I don't know how you can keep up, AND do long speeches at Elk and SM boards...!
Most FTP clients seem to use current system date when uploading...
Hmm.Quote Hmm yeah then I probably did that by myself...
It was complicated. And I'm thinking I should get rid of .top_likes as it is right now. Dunno.
Then break it down and deal with it in stages. Especially with optimisation. Do that last.
Creating my changelog and checking diffs in Tortoise is the only way I manage to keep up with my own changes and whatever I need to fix before the proper commit.
Use what looks best. Something that's a few bytes more but looks better would be better appreciated by the users.
Although I think we should consider changing some of our reply/quote/whatever icons.
The very right would be better. I don't know that it would be 'much' shorter. But it's where it should go, IMO.
What do you think about the mini-menu as it is, anyway..?
Yeah, that sort of thing sucks :( This is why I don't do optimisation until late in the day, if at all.
I tend to hammer it out, iterate it, fix the bugs in it and then (and only then) worry about making it smaller. Like the change in r1930 about fixing the ternary, IIRC there wasn't even that if to start with, it only came about as a bugfix, and even though there's currently a missing space by the :, I would personally have been happy with it how it was - ternaries make it smaller, yes, but they do make it harder to follow again later :/ It's all good, though.
Anyway, that one is just me trying to push short code into a single line when it's spread over 4 lines... That's just me.
Also, regarding the reason I changed the mini-menu code to always create all entries at load time, rather than hover time. Yes, 70ms (for a full page) isn't something to be ignored. If performance becomes an issue, I'll gladly rewrite my code to use pure JS instead of jQuery (it's all about manipulating document fragments...)
However, the reason, as I said, is that with this, I can do something pretty smart.
- Move ALL action entries to the mini-menu code. (Saves at least 200 gzipped bytes per page...)
- Calculate the current div width. Add entry to div. See if entry goes to a new line. If not, continue. If yes, cancel that one, move it to the action menu, and keep adding to the action menu for the remaining entries.
This would basically allow us to show the action menu on any screen width, and then ensure that smaller screens get an action menu when it's too much for them.
I don't know if I'm going to implement this immediately, but what do you think of it..?
Posted: February 20th, 2013, 04:39 PM
I think the main (only?) drawback to this method is that if JS is disabled on your browser -- you don't get to see any option at all... This is why Wedge currently shows the two most important settings (quote and modify) as regular links, not part of the menu.
Posted: February 20th, 2013, 06:30 PM
BTW, I'm working on allowing other thought pages to use the mini-menus.
Currently, I have the 'All thoughts' page showing it, as well as Likes. It doesn't show the Like/Unlike button in the menu though (just the likes count outside the menu.) Also, it's still buggy, so I can't actually edit or post answers.
I was a bit torn between copying the Homepage code to the other functions, but then I decided to instead try to merge both into one... So the homepage now includes the Thought source, but it's kinda annoying, the homepage code has some really custom stuff that the other pages don't, and vice-versa... Though job. Is taking longer than I'd like...
Will eventually complete it, though.
Oh, and the script.js file is now 22 bytes shorter than yesterday... :lol:
3608
Features / Re: New revs
« on February 19th, 2013, 10:58 PM »
rev 1933 -- icon maintenance code. Gotta do whatcha gotta do...
(18 files + moves & deletions, 19kb)
* Renamed modify_button class to edit_button, because... Err... It's one byte shorter. Also removed modify_inline.gif from index CSS, because... Guess what? It was a duplicate... This saves about 200 bytes from the main CSS file. I almost choked on my food, but unfortunately I had no food under the hand. (Display.php, Home.php, Msg.template.php, extra.rtl.css, index.member.css, sections.css)
* Replaced login_sm.gif icon with online.gif -- it just looks better and means the same ("registered member"). (Login.template.php)
* Replaced assist.gif icon with field_invalid.gif... Why, oh why? Because. The assist icon is perfectly unreadable (and has been since the SMF 2.0 beta days), and it's only used once (legend block), and a relatively subtle warning icon is just as good -- and four times smaller in bytesize. Until we replace it with something else -- or nothing -- this is at least better. (MessageIndex.template.php)
- Removing a few remaining calendar-related lines/icons. Should be in the calendar plugin, I guess..? (upgrade.sql, QuickMod.php)
- Removed a language string that really didn't bring anything to the table... Even this commit line is more meaningful than it. And that's saying a lot. (Themes.template.php, Theme.language.php)
- Removed reply_all_button class... Seriously. It's only used once (in PMs), and was already a copy of reply_button, so I just renamed it to that... (PersonalMessage.template.php, extra.rtl.css, sections.css)
- Moved create_button function from Subs to moderation page, and removed the last (mostly wrongful) uses in the other pages. Basically, I tend to favor adding _button classes instead of using img tags. Only the merge.gif button remains as a 'real' linked button, dunno what to do with it. Also, most of these replacements are block-type classes set on an inline-type anchor, meaning the icon could get partially hidden from view, so this really warrants further inspection. See Profile template for an example... (Subs.php, Merge.template.php, ModerationCenter.template.php, PersonalMessage.template.php, Profile.template.php)
! Fixed edit_draft button, it should have been an edit button, not a reply button... (PersonalMessage.template.php)
* Moved plenty of unused icons to /other/images/buttons. Feels good... (12 files, removed another 4 entirely. I think.)
(18 files + moves & deletions, 19kb)
* Renamed modify_button class to edit_button, because... Err... It's one byte shorter. Also removed modify_inline.gif from index CSS, because... Guess what? It was a duplicate... This saves about 200 bytes from the main CSS file. I almost choked on my food, but unfortunately I had no food under the hand. (Display.php, Home.php, Msg.template.php, extra.rtl.css, index.member.css, sections.css)
* Replaced login_sm.gif icon with online.gif -- it just looks better and means the same ("registered member"). (Login.template.php)
* Replaced assist.gif icon with field_invalid.gif... Why, oh why? Because. The assist icon is perfectly unreadable (and has been since the SMF 2.0 beta days), and it's only used once (legend block), and a relatively subtle warning icon is just as good -- and four times smaller in bytesize. Until we replace it with something else -- or nothing -- this is at least better. (MessageIndex.template.php)
- Removing a few remaining calendar-related lines/icons. Should be in the calendar plugin, I guess..? (upgrade.sql, QuickMod.php)
- Removed a language string that really didn't bring anything to the table... Even this commit line is more meaningful than it. And that's saying a lot. (Themes.template.php, Theme.language.php)
- Removed reply_all_button class... Seriously. It's only used once (in PMs), and was already a copy of reply_button, so I just renamed it to that... (PersonalMessage.template.php, extra.rtl.css, sections.css)
- Moved create_button function from Subs to moderation page, and removed the last (mostly wrongful) uses in the other pages. Basically, I tend to favor adding _button classes instead of using img tags. Only the merge.gif button remains as a 'real' linked button, dunno what to do with it. Also, most of these replacements are block-type classes set on an inline-type anchor, meaning the icon could get partially hidden from view, so this really warrants further inspection. See Profile template for an example... (Subs.php, Merge.template.php, ModerationCenter.template.php, PersonalMessage.template.php, Profile.template.php)
! Fixed edit_draft button, it should have been an edit button, not a reply button... (PersonalMessage.template.php)
* Moved plenty of unused icons to /other/images/buttons. Feels good... (12 files, removed another 4 entirely. I think.)
3609
Features / Re: Guess the Feature
« on February 19th, 2013, 09:41 PM »
It's one of the most frightening language files there are.......
Okay, it's THE most frightening one... ;)
I actually always refused to touch it when I took over the task of overviewing the translation. It's the only file I didn't touch (along with the Manual, because it was to be gone soon after anyway...)
Oh my, I just noticed there are several more unread topics for me here from last night...... Oops :^^;:
Busy with stuff.
Oh, can't bother to find the proper topic for this quick one: I'm currently reviewing the various icon files for Wedge, and noticed there's still msntalk.gif in there... Shouldn't we move it to a skype.gif icon..? Also update ManageMemberOptions.php for that, I guess..? I don't know much about MSN, but I heard they'd switched over completely to Skype...
Okay, it's THE most frightening one... ;)
I actually always refused to touch it when I took over the task of overviewing the translation. It's the only file I didn't touch (along with the Manual, because it was to be gone soon after anyway...)
Oh my, I just noticed there are several more unread topics for me here from last night...... Oops :^^;:
Busy with stuff.
Oh, can't bother to find the proper topic for this quick one: I'm currently reviewing the various icon files for Wedge, and noticed there's still msntalk.gif in there... Shouldn't we move it to a skype.gif icon..? Also update ManageMemberOptions.php for that, I guess..? I don't know much about MSN, but I heard they'd switched over completely to Skype...
3610
Features / Re: New revs
« on February 19th, 2013, 06:46 PM »
rev 1932 -- at last, mini-menus for thoughts! Anxious to get feedback on this...
(23 files, 30kb)
* A major rewrite of the mini-menu system. It is now more 'generic', i.e. it's included in the main script and it does its best to accomodate more styles.
- The code is much tighter than before (as if it wasn't already before..!) Also, made a last-minute rewrite to create all mini-menus together at load time rather than invidually hover time. This only takes about 70ms on full topic pages in modern browsers, which is better than I thought. The reason is that I'm planning for something more... That might end up being interesting. Or not.
- The arrow position on right-aligned elements should now be consistent with the left-aligned ones.
- Related classes are now simplified in the CSS files.
- New virtual class .vbtn allows you to use these buttons anywhere, not just in action bars. (sections.css)
(Display.php, Home.php, Display.template.php, Home.template.php, images/theme/menurow.gif, index.template.php, Msg.template.php, Xml.template.php, index.language.php, script.js, topic.js, extra.ie6.css, extra.ie7.css, extra.ie8.css, extra.ios.css, extra.rtl.css, index.css, sections.css)
* Replaced thought action buttons with mini-menu. See above for file list...
+ Added Android compatibility to user mini-menus. Damn their hover system...! I hate iOS these days, but at least it got that one right, unlike Android and Windows 8... (script.js)
* Post textarea frame is now a bit less in-your-face. (index.css)
* In order to save more bytes (moving mini-menus to the script file originally cost over 400 bytes, now reduced to about 160), did a few things that I'm sometimes proud of, sometimes not at all... Renamed .dragslide() to .ds(), removed closer tags when jQuery can very quickly fix them by itself (e.g. $('<div></div>')), simplified jQuery plugin structure (not sure why jQuery insists on enclosing them in closures or whatever -- it works perfectly fine outside of these), dropped the chainable aspect of .ds (this is actually more consistent with what my other pseudo-plugins do... If we ever need to have these inserted inside a chain rather than at the end, I'll update all of the plugins to do it as well), the main menu is now a plugin again, renamed weToggle's hooks to onBefore and onCollapse and onExpand (this is all that was needed, really...), left in a pair of {}'s when they weren't needed (it added an extra gzipped byte if I removed them, the joys of gzip magic...). I think that's all... (script.js, stats.js, zoomedia.js)
- Removed .top_likes button code, as it saves over 40 gzipped bytes in the CSS, while adding a bit less to the stats page. Considering it's likely to be requested less often than a CSS file, it's a bargain! (Stats.template.php, sections.css)
@ New thought system on homepage causes posted replies to have improper HTML, and they don't get their own mini-menu. This is fixed with a simple page refresh, but will still need proper fixing... Probably won't be able to add the mini-menu, though. Would be too expensive. This is a big issue for me. Also, the Welcome template is probably broken, too...
(23 files, 30kb)
* A major rewrite of the mini-menu system. It is now more 'generic', i.e. it's included in the main script and it does its best to accomodate more styles.
- The code is much tighter than before (as if it wasn't already before..!) Also, made a last-minute rewrite to create all mini-menus together at load time rather than invidually hover time. This only takes about 70ms on full topic pages in modern browsers, which is better than I thought. The reason is that I'm planning for something more... That might end up being interesting. Or not.
- The arrow position on right-aligned elements should now be consistent with the left-aligned ones.
- Related classes are now simplified in the CSS files.
- New virtual class .vbtn allows you to use these buttons anywhere, not just in action bars. (sections.css)
(Display.php, Home.php, Display.template.php, Home.template.php, images/theme/menurow.gif, index.template.php, Msg.template.php, Xml.template.php, index.language.php, script.js, topic.js, extra.ie6.css, extra.ie7.css, extra.ie8.css, extra.ios.css, extra.rtl.css, index.css, sections.css)
* Replaced thought action buttons with mini-menu. See above for file list...
+ Added Android compatibility to user mini-menus. Damn their hover system...! I hate iOS these days, but at least it got that one right, unlike Android and Windows 8... (script.js)
* Post textarea frame is now a bit less in-your-face. (index.css)
* In order to save more bytes (moving mini-menus to the script file originally cost over 400 bytes, now reduced to about 160), did a few things that I'm sometimes proud of, sometimes not at all... Renamed .dragslide() to .ds(), removed closer tags when jQuery can very quickly fix them by itself (e.g. $('<div></div>')), simplified jQuery plugin structure (not sure why jQuery insists on enclosing them in closures or whatever -- it works perfectly fine outside of these), dropped the chainable aspect of .ds (this is actually more consistent with what my other pseudo-plugins do... If we ever need to have these inserted inside a chain rather than at the end, I'll update all of the plugins to do it as well), the main menu is now a plugin again, renamed weToggle's hooks to onBefore and onCollapse and onExpand (this is all that was needed, really...), left in a pair of {}'s when they weren't needed (it added an extra gzipped byte if I removed them, the joys of gzip magic...). I think that's all... (script.js, stats.js, zoomedia.js)
- Removed .top_likes button code, as it saves over 40 gzipped bytes in the CSS, while adding a bit less to the stats page. Considering it's likely to be requested less often than a CSS file, it's a bargain! (Stats.template.php, sections.css)
@ New thought system on homepage causes posted replies to have improper HTML, and they don't get their own mini-menu. This is fixed with a simple page refresh, but will still need proper fixing... Probably won't be able to add the mini-menu, though. Would be too expensive. This is a big issue for me. Also, the Welcome template is probably broken, too...
3611
Bug reports / Re: Mini-menu implementation
« on February 18th, 2013, 10:39 PM »Yup, reuploading the files will fix it, just as getting the admin to clear the file cache would too.
As I said -- either reupload the file, or just hope that the conflict is old enough that no one has a cached copy on their computer any more.
Did we? I had nothing to do with that stats block (other than a query bug fix after thought likes were implemented), but it seems to me that using a separate like image would be a simpler solution to that.
It was complicated. And I'm thinking I should get rid of .top_likes as it is right now. Dunno.
Heck I'm drowning in complexity... For instance, one of my most trivial issues is that I noticed that the mini-menu's .remove_button uses delete.gif, while the thought system's remove button uses delete.png, which is a different (and better looking!) icon... I'm considering dropping delete.gif and replacing it either with delete.png, or a smaller version of it. Again: dunno... :-/
And one of my most annoying ones is that I don't know where to place the Actions button in the thought list... To the very left? Looks strange. Right after the date? Not aligned. Right before the thought author? Looks strange, again... At the end, aligned in a new column? This makes the thought much shorter... Not cool.
I also had tons of bugs with my mini-menu rewrite. Ended up having to revert a few lines I was quite proud of... And losing another 20 bytes. I *knew* this stupid extra code was there for a reason... Yet, I attempted to remove it. My loss.
3612
The Pub / Re: Language editing inside Wedge
« on February 18th, 2013, 10:33 PM »
Okay... I don't really understand what you've been doing with language caching exactly... Not sure what it means for arrays like number_context things, etc...
What I know is that I'm getting tons of errors (hundreds per page load, which isn't handy to fix anything!) after installing the new table. And tons of language strings (not all?!) are missing on screen...
Can you tell me what to do to make it behave..?
Did you do any benchmarking? What are the performance gains exactly...?
Last time I checked, caching language files only saved a few milliseconds per page load...
Okay, fixed by emptying my /cache folder manually... (Phew.)
Quote from Arantor on February 18th, 2013, 06:05 AM It all seems very complicated to me... Still wondering if it was worth all that work..?Quote Even JS/CSS caching is far from being a full implementation. I mean, I don't plan to "leave it this way" forever. I'd like to cache the list of files (skins, skeletons and JS) into the database somewhere, and only check whether there are any changes from time to time... But it's always the same thing: what happens when the admin uploads a new file? Do they have to manually go to the admin and empty some cache? That sucks...Quote It never was in there because I never was translated it. It was translated, though... But I don't know its quality. Attaching the file. I'll read through it another day... There was a discussion about it 2 years ago about updating its translation so it was probably bad to begin with (like easily 10% of the SMF French translation), but I'd already stepped down from my French translation manager position, so didn't care about it at all.Quote Speaking of primary keys... I remember you added an entry recently to another table, custom fields I think, and noticed you didn't add a key for it although you did some extra ORDER BY queries on it... Was it voluntary, or something you forgot?
What I know is that I'm getting tons of errors (hundreds per page load, which isn't handy to fix anything!) after installing the new table. And tons of language strings (not all?!) are missing on screen...
Can you tell me what to do to make it behave..?
Did you do any benchmarking? What are the performance gains exactly...?
Last time I checked, caching language files only saved a few milliseconds per page load...
Posted: February 18th, 2013, 10:19 PM
Okay, fixed by emptying my /cache folder manually... (Phew.)
Posted: February 18th, 2013, 10:24 PM
This does mean that, currently, it *is* stored per theme. Whether that will change, I don't know. I can always assign 0 to force it for all themes and juggle the code. I don't know yet, I just implemented the base functionality and I'm not entirely sure where this is going yet.
I don't know also how this will affect JS caching, or whether editing a file means just flushing all the JS cached files of the same language, that would be the easiest, if not the cleanest.
Also... how come we never had agreement_french.txt anywhere in SVN that I can find? SMF supported multiple languages for the agreement for ages, not that most people really understood that it worked :/
Also, the table's PK should be PRIMARY KEY (id_theme, id_lang, lang_file, lang_var, lang_key) not what's currently in SVN. I'll commit when I submit everything else related to changing the registration form code.
3613
Features / Re: Rewriting the skin file parser...
« on February 18th, 2013, 10:21 PM »
Bumping this...... If anyone feels inspired by the moment or something ;)
Or, rewording... Does it feel more natural to use a skin.xml override to make a skin forget its parents, or to use a filename keyword..?
Posted: February 17th, 2013, 08:01 PM
Or, rewording... Does it feel more natural to use a skin.xml override to make a skin forget its parents, or to use a filename keyword..?
3614
Features / Re: New revs
« on February 18th, 2013, 10:08 PM »
rev 1930 -- minor bug fixes. I'm doing what I can to avoid a HUGE commit coming up where I've rewritten so many things... Also, +1 for screenshots ;)
(7 files, forgot to look for the size... probably a couple of KBs.)
! In profile pages, password length error message always said '4 chars' even when set to 8 chars minimum, because of a missing global. (Profile-Modify.php)
! Typo broke gallery pages. Dunno why no one noticed... (Aeva-Gallery2.php)
* Pretty please, use my refactored comment structure for commented out code please, or remove code altogether ;) (Admin.template.php)
* Also use ternary operators where it's painfully obvious... Again please ;) (ManageNews.php)
* Translation. Also, some of the outdated French strings weren't removed in a recent rewrite... (Admin.french.php, ManageSettings.french.php)
* Made post textarea frame a bit less in-your-face... (editor.css)
(7 files, forgot to look for the size... probably a couple of KBs.)
! In profile pages, password length error message always said '4 chars' even when set to 8 chars minimum, because of a missing global. (Profile-Modify.php)
! Typo broke gallery pages. Dunno why no one noticed... (Aeva-Gallery2.php)
* Pretty please, use my refactored comment structure for commented out code please, or remove code altogether ;) (Admin.template.php)
* Also use ternary operators where it's painfully obvious... Again please ;) (ManageNews.php)
* Translation. Also, some of the outdated French strings weren't removed in a recent rewrite... (Admin.french.php, ManageSettings.french.php)
* Made post textarea frame a bit less in-your-face... (editor.css)
3615
Off-topic / Re: Opera goes WebKit, RIP Presto
« on February 17th, 2013, 03:28 PM »Where is Opera "Ice"?
It was demoed last month, there's a video of it online. I don't really like the looks of it... Hopefully, it'll remain an iOS exclusive or something. Not that I'm particularly happy with Opera's app for Android (I never use it willingly), but at least it has a UI, not some marketing bullshit of a non-interface.
From what we know, they'll demo a new version of Opera for Android in 8 to 12 days at the MWC.
I've read hundreds, thousands of comments on this move to WebKit, and basically the community as a whole is against the move. They're not ready to trust Opera's ability to keep their browser 'as it is', with no changes to their UI/UX, most people expect it to be a Chromium clone. I don't think it'll be. Bruce Lawson has said in an interview that they're "free" from Google/Apple and are only forking Chromium, i.e. they're going to do what we did with SMF2... And that can't be a bad thing, can it? Basically, their development process will be public, they'll add stuff to Opera and maybe submit them to Chromium-dev, but rejection won't stop them from adding their own changes to their browser. They're also free to remove anything they consider as bloat...
The thing I'm more concerned with is that with this, Opera has effectively confirmed that they laid off a good number of their development team. Some of the more 'vocal' ones like Anne van Kasteren for instance (he officially started work at Mozilla recently), who was instrumental in pushing several of Opera's features to W3C standards. I'm afraid that their absence will be felt.
Some also say that ex-CEO Jon left Opera because of growing concerns over its impending lack of independence. It's been said that he sold half his remaining Opera shares the day before they announced the WebKit switch. To me, it definitely means that he doesn't trust Opera to be going in the right direction... :-/
Anyway -- those left at Opera will, I'm sure, be working very hard to produce the best Chromium clone out there. Which is why I'll be delighted to try it. But I don't think it's gonna bring down the house or whatever.
As for Dragonfly, given that it was developed in JavaScript, and Chrome Dev Tools aren't AFAIK, it's not going to be trivial to port it, and as an Opera employee said they'd already pulled the plug on it, we can only count on individuals wanting to port some features of DF into CDT as it is now. Fingers crossed...