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
3106
Archived fixes / Re: menu height
« on April 30th, 2013, 05:58 PM »
This was probably due to an upload error. Two conflicting CSS files.
3107
Features / Re: return_raw buggy if enableCompressedOutput is on
« on April 30th, 2013, 03:24 PM »If you mean what's already committed, check what it is. It is not the warning system, it's the moderation centre which is sort of needed for the board index since that's what's happening, a new virtual category that contains virtual boards. I forget, I haven't committed half of this because of the ever sprawling changes.
Not too important, though...!
The only real difference as far as parent language goes is how much difference there really is. English UK vs English US has some major differences but it also has an awful lot of similarities, so it would make sense to have the parent language.
The parent language aspect does sort of require the other language to be installed.
If you want to set up a forum for local events in Portugal (emphasis: Portuguese/PT), that's fine because presumably it's the parent language. But if you want to install a forum for local events in Brazil (emphasis: Portuguese/BR), you then need to install *two* language packs. This is not intuitive even if it is documented somewhere.
I don't know how significant the differences are - though I did ask for some feedback on this - but the impression I've been given is that the variations are big enough to warrant two sets of language files being maintained.
However, that does make language loading more complex (in trying to report missing files etc.) and more importantly: is it logical or appropriate to ask those forum cases to install *both* French and the Québécois language files? (Ignore, for the moment, that French is already bundled)
And yes, it would make sense to ship FR with QC, because inevitably Québécois forums will receive visits from French visitors, and vice versa, so it's best to have both in there... (Well, French being crucial, Québécois being less important, but if I *had* access to such a package, I would definitely include it.)
If the situation were reversed, and French were the only bundled language, with English US being the primary and English UK being a secondary, if I were setting up a forum for *British* users (i.e. the minority speakers), I would not want to install both English US and English UK, even if I only made English UK selectable by users.
load language: English (US), e.g. mypage.english.php
then
load language: French (if file not found, error), e.g. mypage.french.php
then
load language: Québecois (if file not found, ignore if parent_lang is set, otherwise error), e.g. mypage.french-qc.php
I think that's pretty much what I suggested a few weeks or months ago... And I don't really see any fault in doing it that way, is there..?
As far as suffixes go, I've always seen where it could be practical but I've always had the feeling it's going to be a feature that no-one but you is going to use anyway :(
Then, do you mind if I rewrite them the way I mentioned in the other, also unrelated[1] topic..?
Back on topic, it seems that it is working as expected elsewhere with that code, so I don't know why it is in normal execution. (At least, attachments are working even when > 4MB)
| 1. | I'm the world champion for corrupting topic subjects. |
3108
Features: Posts & Topics / Re: Auto-embedding
« on April 30th, 2013, 02:45 PM »Please consider adding sports (Soccer) websites like Arsenal, Manchester United, Chelsea, Real Madrid, Barcelona. My country is a soccer mad country and members are always looking beyond youtube for interviews, match highlights etc.
Doesn't change the fact that I have no interest for football, and no intention of ever going to a sports-related website... :P
Aeva-related requests should be made after Wedge is out. Maybe I'll cook up some kind of plugin to easily allow adding new sites; right now, I think it's quite 'monolithic', as I probably removed most of the auto-update code. (Aeva for SMF also went through the same, as I decided long ago to stop updating it except for potential security fixes...)
3109
Off-topic / Re: WEDGEHAMMER 40,000
« on April 30th, 2013, 02:43 PM »
I'll give you an example, wanchope... Last night, I decided to try and optimize the CSS suffix system to allow for more flexibility.
Currently, if you want to include some custom CSS for IE6 and IE7 only, you can add this to your skin folder:
custom.ie[-7].css
But if you want to do that, except for yourself (admin), in case for instance you're testing something, you can't do this:
custom.ie[-7] && !admin.css
This syntax is valid inside the CSS file itself, through "@if ie[-7] && !admin / @endif", but not in the suffixes.
I was contemplating the possibility to give up on suffixes, and just force everyone to use @if, but it would be a bad decision, because these suffixes at least allow you to include additional files that you'd have a hard time including otherwise, i.e. if you don't want to put everything into "custom.css", which may quickly become a real mess...
So, I rewrote many things internally. Did many tests. Right now, I'm envisioning changing the current $user_info replacement, which is called "we::$user" (if you're unfamiliar with this syntax, it means "$user static array inside the 'we' system object", and allows you to bypass declaring a global everytime you want to use it, which is nice), and split it into more variables. Right now I have we::$user and we::$browser, but I'm probably going to go for we::$user (for regular user variables), we::$is (for anything related to the user that has 'is_' in it, such as admin or mod testing), we::$browser (no changes except removing the 'is_', tests what browser you're using), and we::$os, which currently is integrated into we::$browser, but really we don't need this to confuse us...
This is a 'convenience' change, which I'm going to do in order to make things simpler for both me and other developers in the future (unless Pete reads this before I commit later tonight, and thinks it's a bad idea.. ;)), and which isn't going to help in any other way than, as I said, clarity. This kind of change, Wedge were to be currently available, would mean that I'd think twice about it, because *plugins may need to be rewritten..!* And yes, this is one of the reasons SMF is always behind Wedge in that respect -- because they have to accomodate for all earlier mods and themes that people have written. When we started Wedge, one of the first liberating things to do was get rid of all the old code that was only there for compatibility reasons, and rewrite it in a more sensible way...
We are not gods, we are good developers and that's all, so we can't everything right on the first try. I know that my caching system, which has great complexity (but that doesn't matter because it's not to be modified by anything else than the ones who wrote it anyway), works perfectly with the current @if and suffix system, just 'differently', and I'd like to rewrite it in a way that'll be (slightly) more maintainable in the future, and account for the merging of both systems. I would really, really think twice before doing it if Wedge was public.
There are other areas that might warrant a similar rewrite, and keeping Wedge private for now entitles us to give it time to develop into a perfect system that we can really, really be proud about, and that won't require breaking rewrites in the near future.
Now, if all you want is to 'prepare' for your forum to be converted to Wedge in the future, just stick with SMF 2.1 for now, as they're doing some great work to catch up with Wedge, and have adopted many of our philosophies and thus your switch might be easier once Wedge is released, if you still want to switch of course...
Currently, if you want to include some custom CSS for IE6 and IE7 only, you can add this to your skin folder:
custom.ie[-7].css
But if you want to do that, except for yourself (admin), in case for instance you're testing something, you can't do this:
custom.ie[-7] && !admin.css
This syntax is valid inside the CSS file itself, through "@if ie[-7] && !admin / @endif", but not in the suffixes.
I was contemplating the possibility to give up on suffixes, and just force everyone to use @if, but it would be a bad decision, because these suffixes at least allow you to include additional files that you'd have a hard time including otherwise, i.e. if you don't want to put everything into "custom.css", which may quickly become a real mess...
So, I rewrote many things internally. Did many tests. Right now, I'm envisioning changing the current $user_info replacement, which is called "we::$user" (if you're unfamiliar with this syntax, it means "$user static array inside the 'we' system object", and allows you to bypass declaring a global everytime you want to use it, which is nice), and split it into more variables. Right now I have we::$user and we::$browser, but I'm probably going to go for we::$user (for regular user variables), we::$is (for anything related to the user that has 'is_' in it, such as admin or mod testing), we::$browser (no changes except removing the 'is_', tests what browser you're using), and we::$os, which currently is integrated into we::$browser, but really we don't need this to confuse us...
This is a 'convenience' change, which I'm going to do in order to make things simpler for both me and other developers in the future (unless Pete reads this before I commit later tonight, and thinks it's a bad idea.. ;)), and which isn't going to help in any other way than, as I said, clarity. This kind of change, Wedge were to be currently available, would mean that I'd think twice about it, because *plugins may need to be rewritten..!* And yes, this is one of the reasons SMF is always behind Wedge in that respect -- because they have to accomodate for all earlier mods and themes that people have written. When we started Wedge, one of the first liberating things to do was get rid of all the old code that was only there for compatibility reasons, and rewrite it in a more sensible way...
We are not gods, we are good developers and that's all, so we can't everything right on the first try. I know that my caching system, which has great complexity (but that doesn't matter because it's not to be modified by anything else than the ones who wrote it anyway), works perfectly with the current @if and suffix system, just 'differently', and I'd like to rewrite it in a way that'll be (slightly) more maintainable in the future, and account for the merging of both systems. I would really, really think twice before doing it if Wedge was public.
There are other areas that might warrant a similar rewrite, and keeping Wedge private for now entitles us to give it time to develop into a perfect system that we can really, really be proud about, and that won't require breaking rewrites in the near future.
Now, if all you want is to 'prepare' for your forum to be converted to Wedge in the future, just stick with SMF 2.1 for now, as they're doing some great work to catch up with Wedge, and have adopted many of our philosophies and thus your switch might be easier once Wedge is released, if you still want to switch of course...
3110
Features / Re: Separating lock and unlock permissions
« on April 30th, 2013, 12:48 PM »
I have nothing against the idea, it's just that I'm always losing myself in the sea of permissions in Wedge and SMF. Now, if there's a reason to implement this from a moderator's view, then of course it's potentially a good idea. ;)
3111
Off-topic / Re: WEDGEHAMMER 40,000
« on April 30th, 2013, 12:47 PM »
@live627, don't get me started on movies and TV... I'll kill you with my massive name-dropping!
@wanchope, it's not available because we have no reasons to go through the pains of supporting our software before it's ready -- when there's really no incentive to do so. Because supporting it also automatically means we have less leeway to work on new features, innovate and rewrite large portions of the software. It's probably the main reason why I myself haven't come to terms with that. I'm not sure about Pete. But the first 'public' release will definitely be in 2013, after the private alpha of late 2012... (Whose purpose was probably to demonstrate that it wasn't vaporware :lol:)
(Heck, we still haven't even settled on a public license and determined whether it'll be free software or commercial, things like that...)
@wanchope, it's not available because we have no reasons to go through the pains of supporting our software before it's ready -- when there's really no incentive to do so. Because supporting it also automatically means we have less leeway to work on new features, innovate and rewrite large portions of the software. It's probably the main reason why I myself haven't come to terms with that. I'm not sure about Pete. But the first 'public' release will definitely be in 2013, after the private alpha of late 2012... (Whose purpose was probably to demonstrate that it wasn't vaporware :lol:)
(Heck, we still haven't even settled on a public license and determined whether it'll be free software or commercial, things like that...)
3112
Features / Re: New revs
« on April 30th, 2013, 12:16 PM »
rev 2084
(3 files, 2kb)
! Fixed two woopsies in thought threads: likes not showing up (thanks to me not calling the template block for them), and mini-menus not working entirely, despite showing up (due to the Thought object not being initialized in that code path.) (Thoughts.php, Thoughts.template.php)
* Wedge doesn't need to go through obExit() to run ob_sessrewrite, as it's already added in the clean_output() process. So, no need to waste time running this, I'm sure the mail queue and track stats won't mind that Ajax calls don't trigger them... (Subs.php)
! Fixed return_raw() crashing, and thus failing to return thoughts and likes, due to an issue with ob_end_clean() and gzipping. Pete and I couldn't find the reason why it doesn't work there but works in other situations, such as file downloading, but it's all right, I can live with small Ajax returns being gzipped, I'm sure it has no influence over anything. (Subs.php)
(3 files, 2kb)
! Fixed two woopsies in thought threads: likes not showing up (thanks to me not calling the template block for them), and mini-menus not working entirely, despite showing up (due to the Thought object not being initialized in that code path.) (Thoughts.php, Thoughts.template.php)
* Wedge doesn't need to go through obExit() to run ob_sessrewrite, as it's already added in the clean_output() process. So, no need to waste time running this, I'm sure the mail queue and track stats won't mind that Ajax calls don't trigger them... (Subs.php)
! Fixed return_raw() crashing, and thus failing to return thoughts and likes, due to an issue with ob_end_clean() and gzipping. Pete and I couldn't find the reason why it doesn't work there but works in other situations, such as file downloading, but it's all right, I can live with small Ajax returns being gzipped, I'm sure it has no influence over anything. (Subs.php)
3113
Features / Re: Separating lock and unlock permissions
« on April 30th, 2013, 07:18 AM »
Hmmm... not feeling it. Too many perms already, maybe..?
3114
Features / Re: return_raw buggy if enableCompressedOutput is on
« on April 30th, 2013, 12:16 AM »Checking whether the old 'less optimised' code causes the same problem under the same conditions. I've been busy with RL stuff today but I'll check it tonight.Quote So...? What do you suggest?
That and I'm fed up of the infractions code but I can't commit it in its present state because I don't want to have something in SVN that actively limits what we can do on here in the meantime. And all the other things I've been thinking of doing are not small projects >_<
Oh, speaking about English, I really think we should add a $txt['parent_lang'] parameter. Because it's not only about English UK, or Brazilian Portuguese, or whatever... Every language has its own variations, and maybe the reason we're not seeing these variations around is precisely because it's so annoying to maintain a file for a minority..?
For instance, Québec people (around 10M, IIRC..?) speak French, but they have their own words for tons of things. I'm pretty sure that if they could do a Québecois language file, and set parent_lang to French, and just provide a few files with rewrites, and fall back to French for the rest, they'd be really happy to work on it.
I don't know what's best with suffixes.
The 'thing' is that up until I implemented @if/@is, the only way to define a CSS block for some browser, was to add a new file and use a suffix for it. Then I figured people would want multiple browsers in a single file, so I did index.ie6,ie7.css, then I decided I wanted to have @if and wrote more generic code, but I never really thought of using the same codebase in both @if and suffixes, while it was very easy...
See, the reason why I kept track of 'found' suffixes, was that I wanted to limit the number of suffixes in the final filename. However, it's NOT possible to do that when any CSS file can have a specific variable test inside it. You DO have to keep track of all of them, and thus you need to store all possible suffixes in the filename, instead of just those that are useful.
Fortunately, my system was already smart enough that it only records suffixes conservatively, so it's mainly been about browser-name-OS-name-logged-status-date.
I even found a solution to manage the 'local' keyword in the same way.
There are a few issues remaining, though... Namely, the member ID, board ID and category ID stuff. Thing is -- if I record these for everyone, then it means one single CSS file per user, per board... Which is crazy, really. It's not possible. So... I could do it like I did so far, i.e. check suffixes and if a member Id or board Id is found in them, store these as well if they return true. But then I realized... Hey, what about @is and @if..?! What if we use "@if m1" to show some CSS only for member #1..? Well, you can't know that until you load the file.[1] Which doesn't happen until you cache it. And the point of caching it, is that you want to save time... So, no loads.
There's always the possibility to cache these entries into the database, and associate them with a corresponding skin + member ID + board ID etc, but I don't think it's very realistic...
So, I guess we could restrict use of these IDs to file suffixes only. Which isn't cool, because I'm struggling to have suffixes be interoperable with @if.
Or, just drop m1/b2/c3 from the list of features in Wess... :-/
I think I've been getting too technical in this post. I can't complain that I don't understand your feature explanations if I'm no better at exposing mine, ah ah... :^^;:
Anyway, I guess I'll have to make a decision about this...
| 1. | I probably thought about it, then forgot. Because Wedge never uses this kind of test in its default skin files, obviously the problem doesn't jump immediately to mind. And my only use of the 'm1' keyword is in a file suffix, so... Back to square one. |
3115
Off-topic / Re: Doctor Who
« on April 29th, 2013, 08:59 PM »
Doesn't change the fact that it lacks logic to me...
I'm a sucker for time travel and stuff; I should have loved this episode, in fact I only liked it. Probably because, if I wanted to watch an 'episode about travelling inside the TARDIS', I'd rather re-watch The Doctor's Wife a hundred times...
I'm a sucker for time travel and stuff; I should have loved this episode, in fact I only liked it. Probably because, if I wanted to watch an 'episode about travelling inside the TARDIS', I'd rather re-watch The Doctor's Wife a hundred times...
3116
Features / Re: return_raw buggy if enableCompressedOutput is on
« on April 29th, 2013, 07:26 PM »
So...? What do you suggest?
Also, I'm having the toughest time rewriting the CSS filename suffix parser. It's one of my to-do's... My goal was to allow users to do "index.(ie[-7] && !m1) || mod && can_flex, replace.css" or whatever crap they want... The same freedom as in CSS files themselves, really.
Turns out it's a PITA. My original code is a bit complex, and right now I'm not even sure whether I really needed all these $suffixes_to_keep and things like that... :-/
I'm torn between trying to fix it all, or just telling people that suffixes are only for simple tests, and deal with it, I'm not paid, if you're not happy then don't use it.™
Do you think it's worth it..?
Heck, I could even get rid of suffixes entirely, if I listened to myself, ah ah...
Main problem is due to the fact that Wess optimizes final filenames not to have crappy suffixes in them if they're not used at all, but it gets complicated because of the contents of the files themselves, so I'll probably have to always include all keywords, and shouldn't bother about this at all, I guess...!
Also, I'm having the toughest time rewriting the CSS filename suffix parser. It's one of my to-do's... My goal was to allow users to do "index.(ie[-7] && !m1) || mod && can_flex, replace.css" or whatever crap they want... The same freedom as in CSS files themselves, really.
Turns out it's a PITA. My original code is a bit complex, and right now I'm not even sure whether I really needed all these $suffixes_to_keep and things like that... :-/
I'm torn between trying to fix it all, or just telling people that suffixes are only for simple tests, and deal with it, I'm not paid, if you're not happy then don't use it.™
Do you think it's worth it..?
Heck, I could even get rid of suffixes entirely, if I listened to myself, ah ah...
Main problem is due to the fact that Wess optimizes final filenames not to have crappy suffixes in them if they're not used at all, but it gets complicated because of the contents of the files themselves, so I'll probably have to always include all keywords, and shouldn't bother about this at all, I guess...!
3117
Off-topic / Re: WEDGEHAMMER 40,000
« on April 29th, 2013, 06:54 PM »That's because we're very talkative.
3118
Off-topic / Re: Doctor Who
« on April 29th, 2013, 06:54 PM »
Entertainment-wise, I found last weekend's episode to be much nicer than the crap before it. It was a bit closer to the Bells episode, which still remains the best in this half-season, which says a lot about the overall quality... :-/
However, once you leave entertainment aside and start considering the story, and the 'logic' behind it, it's an absolute mess... It tends to contradict itself, and indeed I think it's unfair that the Doctor keeps saying it's impossible to rewrite a timeline and/or meet his past self, and then do it very conveniently when he's trying to right his own wrongs... (What did these bros do to him, really..?!)
However, once you leave entertainment aside and start considering the story, and the 'logic' behind it, it's an absolute mess... It tends to contradict itself, and indeed I think it's unfair that the Doctor keeps saying it's impossible to rewrite a timeline and/or meet his past self, and then do it very conveniently when he's trying to right his own wrongs... (What did these bros do to him, really..?!)
3119
Features / Re: return_raw buggy if enableCompressedOutput is on
« on April 29th, 2013, 06:51 PM »
What a mess...
I still don't get why it's not working now, when it used to. It's very obviously due to the ob_gzip handler being removed from the handler list after being somewhat initialized internally, but I can't see where the issue is, really.
Would you suggest that we keep things as they are and only fix when finding errors (such as in return_raw...), or doing something more drastic..?
I still don't get why it's not working now, when it used to. It's very obviously due to the ob_gzip handler being removed from the handler list after being somewhat initialized internally, but I can't see where the issue is, really.
Would you suggest that we keep things as they are and only fix when finding errors (such as in return_raw...), or doing something more drastic..?
3120
Features / Re: return_raw buggy if enableCompressedOutput is on
« on April 29th, 2013, 04:15 PM »How often did the @while(ob_end_clean()); line actually run before?
Seems to me that the lines we had before have a very slightly different behaviour to them because this is closing even the default output handler when it shouldn't.