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
8521
Features / Re: New revs
« on July 6th, 2011, 12:16 AM »
rev 837
(5 files, 7kb)

! Classic Permission headers looked odd. (ManagePermissions.template.php)

! Fixed bug in determineVersions(). (admin.js)

* Two lines become one. Very moving. (Subs-Admin.php)

* Current Wedge version is 0.1, not 1.0 Alpha. (Security.language.php)

(As always, most of my day's work isn't ready for a commit, being linked to changes in index.css and sections.css...)
8522
The Pub / [Archive] Re: Logo Madness
« on July 6th, 2011, 12:10 AM »
Quote from Arantor on July 6th, 2011, 12:07 AM
SP Studio doesn't make transparent PNGs as far as I know.[1]
 1. In fact, I just checked and it doesn't even support PNG, it outputs to JPG. http://sp-studio.de/ is the one I use.
I used this one as well, but I chose a more 'invisible' color as the background, allowing me to hide it more easily :P
Look at the version below... As you can see, the blue IS visible on you.
(I took the liberty to add a proper mouth... ::))
Quote
Quote
And you could have done it BEFORE I made the new logo for the FB group
What do you think inspired me to do it, haha!
Obviously you're not the one who always has the Credits page open as an incentive to work on making all Wedge pages as good loking as that one :P
Quote
I did play around with having a mouth on there, but the previous image didn't have a mouth IIRC,
Yeah but it had a beard so you could see what was what.
Quote
and the 'tache is still big enough you can't really see my mouth under it!
Go and shave!
8523
The Pub / [Archive] Re: Logo Madness
« on July 6th, 2011, 12:03 AM »
No transparent PNG uh? Would be best for my image manipulations...... :whistle:

And you could have done it BEFORE I made the new logo for the FB group..... :P

BTW, the mustache doesn't look like a mustache at first sight... Since there's no mouth, it actually looks like you're brooding. And the mustache is your mouth!
8524
Features: Theming / Re: JavaScript caching
« on July 6th, 2011, 12:01 AM »
Just Google it ;)

I suppose strtr() isn't that slow anyway...

Tss, another day of frustration in my code. Among many other things, I wanted to set the action buttons straight in the post list. I ended up settling for the 'easy' solution -- display:table. Unfortunately I don't have Safari installed right now. Since it's not very table-friendly I'm afraid it'll fail. I tested under Firefox 5 and it doesn't work very well already... Only Opera 11 loves it, meh. And, strangely, IE9... Although it doesn't set .quickbuttons to full height (it should fill the table... Like any NORMAL table cell...!)

I'm getting very annoyed by the constant changes in my CSS. I'd really like to call it quits and commit it, but I'm scared most people will think it doesn't look as good as a stock SMF2, ah ah...
Heck, I made many changes to the visuals this week really. Even the windowbg divs have finally lost their border... (I'm not kidding. I was adamant this border would be in the final design... Until I decided it wasn't needed.)
8525
Features: Theming / Re: JavaScript caching
« on July 5th, 2011, 11:35 PM »
It's actually documented but not in the json_encode help page... You have to go look into the JSON module and search for 'resources' or something like that. I found it originally via Google (duh)...

I posted *after* looking into these. At that point I already knew that none of the params (including the 5.4.0 params) could help in this situation.
8526
Features: Theming / Re: JavaScript caching
« on July 5th, 2011, 08:10 PM »
Ah... Yes indeed. That makes sense :lol:

I just gave it a try. It's interesting, but I don't know if it's worth replacing JSE with it.
For instance it'll always escape "/", even when we don't need it. It'll also turn tabs and newlines into \t and \n with no way to disable these. And re-deescaping them could prove complicated (I don't remember if regexp in JS supports assertions... Because without an assertion, you can hardly turn \\t into a litteral \t, it'll just turn it into \ followed with a tab...)
8527
Features: Theming / Re: JavaScript caching
« on July 5th, 2011, 07:01 PM »
Quote from [Unknown
link=msg=263516 date=1309749092]
Hmm, this is not the same as my experience, odd.  I just combine with newlines between the files, which generally solves all the problems I can think of (some people don't add newlines, which means Windows-style files with a comment at the end or a missing semicolon can have issues.)
I think I accounted for that...
Quote
Sure, unless you're debugging/developing.
True dat. But OTOH, if you're debugging/developing, generally you won't be enabling the minifier at all.
If you're specifically testing the minification process, then you probably won't need very high performance -- if it works, no need to re-parse.
Quote
Well, with minification, yes.  Although, I see the JS has changed markedly since I last touched it.  I've mentioned before my dislike of hungarian type notation.
I know, but it's there, so... I just use it. It's a matter of being consistent with the existing codebase. There would be too much to change otherwise.
Also, sometimes it can be helpful to know what the *intended* purpose of a variable is. I know it has helped me... Don't forget that our code needs to be readable by future devs!
Quote
Ah, I've seen this too.  I think the best way (and the way I use) is to just use a common base url variable.
You mean like <base href>...?
Quote
I think it's better to json encode values (and not have to deal with the quotes and escaping and such) than this JavaScriptEscape business.
But it would mean having to decode after that, wouldn't it...?
I don't even remember seeing a ready-made function for that in ECMAScript...
Quote
Note that json_encode escapes / as \/ to avoid the </script> issue, which is cleaner and more obvious than '<' + '/'.
Indeed. But maybe Google automatically decodes these, as opposed to the + business..?
Quote
Also AFAIK Google appears to often aggressively detect URLs, so even escaping the href probably does no good (at least in my usages it didn't.)
Yeah, I don't think it does.
I can find a middle point by turning href into hr\ef... (Seems to work, at least.)
Quote
Last of all, \t can be cleanly represented in js
It seems to be the case for me... In which case, why did JSE ever begin to escape them...?
Quote
and \n can be escaped as in:

var x = '\
   <div>\
     Hi\
   </div>';
Yes, but it doesn't save a byte, and because of \t, the layout doesn't look good. Although at the time I didn't notice \t could be printed out directly as a tab in the code...
Quote
So if JavaScriptEscape is kept, it's probably better to just escape the newline rather than making it \n, if concerned about readability.  Probably gzips better.
Gzip doesn't really matter here, you'd be surprised with the strange results I've been getting. (There's a recent discussion somewhere about the effort I went into converting some variable names to be one char instead of long stuff, and in the end the resulting gzipped file was actually longer by a few bytes... I just couldn't believe it.)
Ah, would be swell if Apache added support for 7z or even RAR... :lol:
Quote
Of possible interest to this topic, I've been briefly experimenting with a plugin to TOX-G that adds minification to inline js/css (as long as it doesn't have any ifs/etc. in it) and minifies some parts of the HTML (all of this done in the cached template, so runtime speed is not affected.)  Initial impressions seem like it's mostly a waste of time (at least in my inline script tags, which are not common), but offers a small benefit.  I haven't been messing with it much since.
Sounds like fun to me, though. Then again I'm a sucker for minification... (Except for the odd bug like the one I hacked into fixed yesterday.)
8528
Features / Re: New revs
« on July 5th, 2011, 10:25 AM »
rev 836
(5 files, 7kb)

* French translation updates and fixes. Sorry, couldn't bring myself to delete the admin intro, only commented it out. Also deleted the support_resources string since it's no longer showing anything (for now at least.) (Admin.template.php, Admin.language.php, ManageSettings.french.php, PersonalMessage.french.php)

- Removed support resources text, since it was no longer in the language files... (Admin.template.php, Admin.language.php)
8529
Features: Forward thinking / Re: Objects
« on July 4th, 2011, 09:26 PM »
I agree. Better get started on big changes sooner with small things, than wait forever until everything is figured out. You can't make an omelette without breaking a few eggs.
8530
Features: Posts & Topics / Re: Like/dislike
« on July 4th, 2011, 01:11 PM »
We never planned to focus on the poster ;)
8531
Features / Re: New revs
« on July 4th, 2011, 12:20 AM »
rev 833
(11 files, 29kb)

! Using the same format as SMF for version numbers. (detailed-version.php)

* Devised a method to provide day and month names in the user's current language when showing the latest news. (Somehow, I think it's a bit overkill for such a small detail....) (latest-news.php, Admin.php, admin.js)

* Admin homepage needed some extra space. (Admin.template.php)

* wedgeAnnouncements instead of smfAnnouncements. (ModerationCenter.template.php, latest-news.php, admin.js)

* Translation. (Admin.french.php)

- I'm sure there's a good reason to have $txt['months_titles'] that are exactly the same as $txt['months'], and to only use them in the calendar, but OTOH just using $txt['months'] in the calendar will teach it a lesson. Bad calendar! (Calendar.template.php, index.language.php)

- Removing some temp SMF code. (ViewRemote.php)
Posted: July 4th, 2011, 12:15 AM

rev 834
(1 file +1, 7kb)

+ Forgot to add new file admin.rtl.css, which at it says, is the RTL version of admin.css. We really should move as much code as possible from index.rtl.css to whatever.rtl.css, especially in the admin/moderation area. Oh, and that index.rtl file really needs to be overhauled. From top to bottom... (admin.rtl.css, index.rtl.css)
8532
Features / Re: New revs
« on July 3rd, 2011, 10:59 PM »
rev 832
(4 files, 8kb)

! Is it me, or did the SMF team actually forget to fill the MySQL version number in the admin area...? (Admin.php)

! A forgotten semicolon would crash the admin homepage if Packer was enabled. (admin.js)

* Some improvements to the admin sidebar layout. (admin.css)

* Commenazi. (Admin.template.php)
8533
Features: Posts & Topics / Re: Like/dislike
« on July 3rd, 2011, 09:24 PM »
So basically, I think it'd be good to calculate the average score of an item based on its number of likes AND visits.
i.e., it doesn't matter if you have 500 likes for a post if you have 10 million views on that page. However, if you have 50 likes on a pages with 10 topic views, it means more. This should be taken into account and that page should appear above the other in Like scoreboards.
8534
Features: Posts & Topics / Re: Like/dislike
« on July 3rd, 2011, 09:22 PM »
Quote from spoogs on July 3rd, 2011, 09:01 PM
Completely agree there Nao,
My post was actually pro-dislike button, I'm afraid ;)

But this is the only point where I'm pro-dislike. Overall I'm not very enthusiastic about it. Why? Because I think a 'dislike' is not something encouraging, and if you really want to share your feelings about something, it should be constructive criticism -- i.e. you should post an actual comment about it.
8535
Features: Posts & Topics / Re: Like/dislike
« on July 3rd, 2011, 08:51 PM »
@DS> My only gripe with 'dislike' not being there, is that you don't know if people don't 'like' your items because they disliked them, or just because they didn't read it... ;)

For the French reading this -- think of L'école des fans. Everyone gets a 10/10, even if they suck.