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
3931
Other software / Re: Discussing Wedge on simplemachines.org
« on January 11th, 2013, 01:42 PM »
If only we'd discussed that, like, yesterday... :lol:
When you say Apache route, you mean including a very large header file on every file..?
When you say Apache route, you mean including a very large header file on every file..?
3932
Archived fixes / Re: Why does Wedge look different for me?
« on January 11th, 2013, 01:40 PM »
Well, yeah, there's still a lot to fix and everything, it's just that it's the kind of thing that can be done anytime, like, "okay enough people are complaining, I'll do that now...", right now I'm... not exactly the kind of guy who enjoys working on the UI and UX aspects really. I did that for Aeva Media and it was already taxing, but with Wedge it's such a bigger codebase... My priority if I started working on 'annoying things' would probably be writing the documentation for Wess and stuff like that...
3933
Archived fixes / Re: Why does Wedge look different for me?
« on January 11th, 2013, 12:23 PM »
It's a hidden admin setting. Go to phpmyadmin, edit the settings table, replace default_index (I think that's the variable name) to Home. Then voilà, you get your Wedge.org-style homepage. IIRC :P
3934
Other software / Re: Discussing Wedge on simplemachines.org
« on January 11th, 2013, 11:32 AM »The discussion about the Forks discussion board really was about the open source issue.
As in -- "We went through a lot of trouble to switch to an open-source license, and we should promote open source", with a dash of "I'm a bit angry at those Wedge fellows at the moment, but I don't think that really influences my opinion on the license issue".
So, if Wedge uses the SMF 1.0 license it's bound to fail, isn't it...?
Or maybe they should have listened to Pete and I back in the day...
Maybe they should have rethought of the 'reward' system for developers. Maybe they should have been cooler with talented developers who could add a lot to SMF, instead of rejecting multiple times their requested to be made developers.
Maybe they should reconsider why they're rejecting talents, and embracing mediocrity (Labradoodle, AFAIK.)
Heck, I wouldn't want to be on the same team as he is... Not because I hate him (I don't know him). It's just that a developer should know what they're doing. If you're in the same position as a wannabe developer, there's a problem somewhere.
It is lovely to see people turn over a positive new leaf isn't it? A lovely way to start the new year!
It's as I say everywhere. I don't think SMF is 'dead', but I don't think it's going to be back in the limelight either. It had its momentum back in the 1.1 era, and that's all... Too many team changes after that. SMF is really lacking a vision and motivation, rather than talent, you see.
That is, I agree with Pete on most on this conversation. I think the non-dev team should quiet down and be very, VERY happy that some talented developers are spending many hours adding new features, when they could be charging $100+ per hour for that work.
If there's one thing that free software needs the most, it's the drive to build something that's worth millions, without being paid a dime.
It's very hard to accomplish, and it's even harder to find people who are willing to do it.
For that reason, I understand that Norv would be bothered that her copyright terms change was rejected that way. But I don't think that Norv added a lot to the SMF community these last few years, so I also understand that the rest of the team took action against her (mostly because she was AWOL and never explained it.)
So, it's not really a situation where I'd like to take sides. I'm more interested in what Pete has to say about Apache. Maybe we should all modify our headers to make them super short, like:
* @package wedge (or SMF)
* @copyright and license information http://wedge.org/license/
Or a text file, or something. And then indicate something similar to Apache.
See, copyright info isn't even needed in a file. It's best to have it, but not having it doesn't deprive you of your rights.
3935
Features / Re: New revs
« on January 11th, 2013, 09:15 AM »
rev 1837
(10 files, 20kb)
* French translation. Hopefully didn't forget anything or screw up the translation work itself. There was a lot to do... (Admin, EmailTemplates, Help, Login, ManageBans, ManageMembers, ManagePermissions)
! Typo in English version. Also reworked e-mail templates for breathing space. (Help.english.php, EmailTemplates.english.php)
* Commenazi. I believe that when a comment is a sentence (e.g. has a comma in it), it should end with a period. Anyway, not very important and I'm sure I missed hundreds before... I just felt like it. (Security.php)
(10 files, 20kb)
* French translation. Hopefully didn't forget anything or screw up the translation work itself. There was a lot to do... (Admin, EmailTemplates, Help, Login, ManageBans, ManageMembers, ManagePermissions)
! Typo in English version. Also reworked e-mail templates for breathing space. (Help.english.php, EmailTemplates.english.php)
* Commenazi. I believe that when a comment is a sentence (e.g. has a comma in it), it should end with a period. Anyway, not very important and I'm sure I missed hundreds before... I just felt like it. (Security.php)
3936
Features / Re: New revs
« on January 10th, 2013, 06:11 PM »
rev 1836
(412 files, 20kb)
* Removed closing ?> from all files, this should calm down everyone who fears for their headers. Or whatever... (Hundreds of files.)
* Changed last copyright year to 2013. Do we even need to provide a 'latest' year..? (Hundreds of files.)
* Also fixed a few minor things, like a broken link, yeah, nothing fascinating... Oh, and a minor license change, to make it shorter. Have to finish discussing it with Pete though, but it's closer to the original SMF license. (A few files. Damn I don't even want to remember which ones.)
(412 files, 20kb)
* Removed closing ?> from all files, this should calm down everyone who fears for their headers. Or whatever... (Hundreds of files.)
* Changed last copyright year to 2013. Do we even need to provide a 'latest' year..? (Hundreds of files.)
* Also fixed a few minor things, like a broken link, yeah, nothing fascinating... Oh, and a minor license change, to make it shorter. Have to finish discussing it with Pete though, but it's closer to the original SMF license. (A few files. Damn I don't even want to remember which ones.)
3937
Archived fixes / Re: Jumpy layout.
« on January 9th, 2013, 04:34 PM »
Oh and Wikipedia does that on Chrome. Dunno if it's related.
3938
Features / Re: New revs - Public comments
« on January 9th, 2013, 10:02 AM »
Well, I'll always be here to fix bugs in case they arise... I'm pretty much responsible for the frontend and all of the visual tricks.
That's what I did yesterday... Fixed a bug introduced by IE+Safari misbehaving with jQuery and conflicting with my ask() function. (Oh, and in case you don't follow the jQuery bug report I linked to, which is likely, I posted a request to fix it... Which they won't do. Nice. I've posted more arguments but I'm sure they'll be ignored as well... Maybe it's time to fork jQuery :lol:)
That's what I did yesterday... Fixed a bug introduced by IE+Safari misbehaving with jQuery and conflicting with my ask() function. (Oh, and in case you don't follow the jQuery bug report I linked to, which is likely, I posted a request to fix it... Which they won't do. Nice. I've posted more arguments but I'm sure they'll be ignored as well... Maybe it's time to fork jQuery :lol:)
3939
Archived fixes / Re: Jumpy layout.
« on January 9th, 2013, 09:57 AM »
Yes, it's a known issue, and no it's not deliberate.
The reason it wasn't reported before is that people don't use the Skin selector (for some reason), and thus never 'tried' Wuthering before.
Wuthering happens to have a media query that removes its stylish borders when the browser window gets too narrow, and does it with a minor animation.
All browsers check the media query when refreshing the page, and use the media query states to show the page. Animations are discarded.
However, for some reason (thank you Microsoft as always), IE10 decides that when it loads a new page (e.g. you click a link Inside the forum), it should start with the default state and then execute media queries and their associated animations. Other browsers don't do that.
You know how it's called... It's a browser bug.
I'm hopefuly that they will eventually fix it, though. It's only a 'preview' on Windows 7... I don't know about Windows 8.
An alternative, of course, would be to add a custom rule for IE10 to drop the animation. I don't like the idea, but maybe I should implement it ASAP. IE users aren't really worth my time. I want IE to die, even if IE10 is rather usable.
(Fixed. Also fixed here for your comfort, even though wedge.org is not using the latest revs.)
The reason it wasn't reported before is that people don't use the Skin selector (for some reason), and thus never 'tried' Wuthering before.
Wuthering happens to have a media query that removes its stylish borders when the browser window gets too narrow, and does it with a minor animation.
All browsers check the media query when refreshing the page, and use the media query states to show the page. Animations are discarded.
However, for some reason (thank you Microsoft as always), IE10 decides that when it loads a new page (e.g. you click a link Inside the forum), it should start with the default state and then execute media queries and their associated animations. Other browsers don't do that.
You know how it's called... It's a browser bug.
I'm hopefuly that they will eventually fix it, though. It's only a 'preview' on Windows 7... I don't know about Windows 8.
An alternative, of course, would be to add a custom rule for IE10 to drop the animation. I don't like the idea, but maybe I should implement it ASAP. IE users aren't really worth my time. I want IE to die, even if IE10 is rather usable.
Posted: January 9th, 2013, 09:52 AM
(Fixed. Also fixed here for your comfort, even though wedge.org is not using the latest revs.)
3940
Archived fixes / Re: No 'reply' button in 'thoughts' (all) page
« on January 8th, 2013, 07:02 PM »
I don't know, I only wrote this page to be able to browse thoughts by date. And there's also the profile page where you can filter them by author.
Fact is, the JS for thoughts is a bit complicated and I fear it would add to the JS filesize, which I don't really want.
Plus, I don't want to encourage digging out old thoughts for reply. Although I reckon that we post way more thoughts per day than what the homepage can hold...
Fact is, the JS for thoughts is a bit complicated and I fear it would add to the JS filesize, which I don't really want.
Plus, I don't want to encourage digging out old thoughts for reply. Although I reckon that we post way more thoughts per day than what the homepage can hold...
3941
Archived fixes / Re: No 'reply' button in 'thoughts' (all) page
« on January 8th, 2013, 06:32 PM »
None.
Just laziness ;)
Just laziness ;)
3942
Archived fixes / Re: Remove drafts
« on January 8th, 2013, 06:21 PM »
Yeah, it's nasty... Especially for someone like me who enjoys saving bytes one by one.
Okay, so I saved 4 bytes off these by ensuring that Wedge doesn't call <a onsomethingelsethanclick="return ask();">... Which it didn't, in the first place, so good. Now I don't have to test for the event type, just for an href to be there -- and it's only available on anchor tags anyway (at least as far as ask() is concerned.)
I was more bothered by the fact that my DCL function was inside the menu builder, so I tested how it'd fare outside of it... Turns out it only added two bytes to the file, so I went along with it. I also managed to save 2 extra bytes by moving the bindEvents part to the end of the DCL function (it was originally at the beginning, which was a flawed idea anyway), so that evened it out.
All in all, 6658 gzipped bytes. I think a couple of days ago, I was at around 6680, so even with these little extra hacks for ask() and $.browser, I'm still winning... :)
Okay, so I saved 4 bytes off these by ensuring that Wedge doesn't call <a onsomethingelsethanclick="return ask();">... Which it didn't, in the first place, so good. Now I don't have to test for the event type, just for an href to be there -- and it's only available on anchor tags anyway (at least as far as ask() is concerned.)
I was more bothered by the fact that my DCL function was inside the menu builder, so I tested how it'd fare outside of it... Turns out it only added two bytes to the file, so I went along with it. I also managed to save 2 extra bytes by moving the bindEvents part to the end of the DCL function (it was originally at the beginning, which was a flawed idea anyway), so that evened it out.
All in all, 6658 gzipped bytes. I think a couple of days ago, I was at around 6680, so even with these little extra hacks for ask() and $.browser, I'm still winning... :)
3943
Features / Re: New revs
« on January 8th, 2013, 06:15 PM »
rev 1832
(7 files, 5kb)
* Saved more precious gzipped bytes off both HTML pages and included script files, by: (script.js, sbox.js, index.template.php, GenericMenu.template.php, ManageModeration.template.php)
- Moving $('select').sb() to a DOMContentLoaded event instead of having it both in sbox.js and the HTML.
- Moving bindEvents() to that same event, instead of having a separate function, and fixing index and ManageModeration templates not to use it.
- Turning $.fn.wmenu() into a _b function, and calling it along with the rest. It's all cleaner this way...
! Fixed anchor links not properly working if associated with an ask() function. Unfortunately, this fix, however short it is, negates many of the bytes saved above. Well, not all, thankfully... (script.js)
! Draft removal 'delete all' form was using an onclick, instead of onsubmit, effectively making the entire horizontal area clickable... (Profile.template.php)
* Modified minimum menu ID value to 0 instead of 1... Only saves one addition at one moment. But I really didn't like it. (Subs-Menu.php, GenericMenu.template.php)
(7 files, 5kb)
* Saved more precious gzipped bytes off both HTML pages and included script files, by: (script.js, sbox.js, index.template.php, GenericMenu.template.php, ManageModeration.template.php)
- Moving $('select').sb() to a DOMContentLoaded event instead of having it both in sbox.js and the HTML.
- Moving bindEvents() to that same event, instead of having a separate function, and fixing index and ManageModeration templates not to use it.
- Turning $.fn.wmenu() into a _b function, and calling it along with the rest. It's all cleaner this way...
! Fixed anchor links not properly working if associated with an ask() function. Unfortunately, this fix, however short it is, negates many of the bytes saved above. Well, not all, thankfully... (script.js)
! Draft removal 'delete all' form was using an onclick, instead of onsubmit, effectively making the entire horizontal area clickable... (Profile.template.php)
* Modified minimum menu ID value to 0 instead of 1... Only saves one addition at one moment. But I really didn't like it. (Subs-Menu.php, GenericMenu.template.php)
3944
Archived fixes / Re: Remove drafts
« on January 8th, 2013, 10:22 AM »
Pardon my French, but that's one of the sickest sons of a bitch I've ever seen in a jQuery feature.
http://bugs.jquery.com/ticket/12652
Apparently, they *DO* have that bug, and they won't fix it because they don't think it's a jQuery bug (I beg to differ!)
To be more specific: DOMElement.click() only worked on INPUT tags until HTML5 told implementors to support it everywhere. jQuery, for some reason, actually checks, when triggering a $(elem).click() event, whether 'elem' is an anchor. And if it is... Be prepared... It just DROPS the entire process. I should have been more careful when tracing through the code... In jQuery 1.5.2, the test is made at line 2487, with the 'isClick' variable. It just drops it. No warning whatsoever. Unbelievable! And the bug is still in jQuery 1.9 beta, line 2989.
So, I've implemented the shortest possible 'valid' workaround for it. And this now uses 22 gzipped bytes. i.e., the exact amount of data I saved yesterday. (Original code in script.js only has the last line of this snippet, if you want to locate it and test it.)
Code: [Select]
And a final 'fuck you' to everyone involved in this bug for wasting emanuele's, Pete's and my valuable time.
http://bugs.jquery.com/ticket/12652
Apparently, they *DO* have that bug, and they won't fix it because they don't think it's a jQuery bug (I beg to differ!)
To be more specific: DOMElement.click() only worked on INPUT tags until HTML5 told implementors to support it everywhere. jQuery, for some reason, actually checks, when triggering a $(elem).click() event, whether 'elem' is an anchor. And if it is... Be prepared... It just DROPS the entire process. I should have been more careful when tracing through the code... In jQuery 1.5.2, the test is made at line 2487, with the 'isClick' variable. It just drops it. No warning whatsoever. Unbelievable! And the bug is still in jQuery 1.9 beta, line 2989.
So, I've implemented the shortest possible 'valid' workaround for it. And this now uses 22 gzipped bytes. i.e., the exact amount of data I saved yesterday. (Original code in script.js only has the last line of this snippet, if you want to locate it and test it.)
if (e.type == 'click' && e.target.href)
location = e.target.href;
else
$(e.target).trigger(e.type);And a final 'fuck you' to everyone involved in this bug for wasting emanuele's, Pete's and my valuable time.
3945
Archived fixes / Re: Remove drafts
« on January 8th, 2013, 09:11 AM »
It just makes me smile that you seem to be sleeping in the morning rather than in the night ;)
$('.remove_button').click() doesn't work with _modalDone set to true...
$('.remove_button').unbind('click').click() doesn't work either, but then doing a second manual click on the link works.
So far, all I could find to 'make it work', is do a silly location = e.target.href... Not exactly 'good looking', and it will definitely add a lot of code to reqWin(), even to cancel out the 20 bytes I just saved by rewriting stuff yesterday...
Maybe it's a jQuery bug. I'll try with v1.9.
Posted: January 8th, 2013, 08:48 AM
$('.remove_button').click() doesn't work with _modalDone set to true...
$('.remove_button').unbind('click').click() doesn't work either, but then doing a second manual click on the link works.
So far, all I could find to 'make it work', is do a silly location = e.target.href... Not exactly 'good looking', and it will definitely add a lot of code to reqWin(), even to cancel out the 20 bytes I just saved by rewriting stuff yesterday...
Maybe it's a jQuery bug. I'll try with v1.9.