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
3631
Features / Re: Bye Bye Recycle Bin?
« on February 15th, 2013, 06:36 AM »
Go for it! :)
3632
Bug reports / Re : Mini-menu implementation
« on February 14th, 2013, 10:59 PM »
Quote from Arantor on February 14th, 2013, 07:30 PM
Hmm, lots to think about.

I'd argue that minimenus would be nice to have as generic code available everywhere, not just in topics, and I can see places where mod authors might want to include them.
Sure they'd be great as generic things... And I certainly managed to turn them into a template_mini_menu() function in the index template.
However, I'm not satisfied with the difficult balance between byte-saving and complexity.

If you'll look at the source code for thought button creation, it's perfectly geared towards making it short and relatively clean.
Adapting this to a mini-menu required more bytes. It 'works', but I'm not exactly happy with all the extra luggage...

Additionally, you need to create three different arrays, which will then be used to generate the .mime() caller.
These arrays need to be done separately from the templates... Ideally, a mini-menu should 'behave' according to whatever data the *template* feeds it, I'd say.
So, we could move all the data to the DOM. For instance, instead of <div data-id="1234" class="acme">, do something like <div class="acme" data-id="1234" data-special="12345" data-re data-me>, where id=1234 and special=12345 obviously, and we declare a 're' menu entry and another 'me' menu entry. Or <... data-re="12345" data-me="12345">, but it forces repetition.
I don't fucking know what's best.
Plus, the awful Function eval stuff. I hate that.
All in all, maybe I should actually ditch the current mini-menu code and rewrite it entirely (not the looks but the internals), to explicitly set all entries explicitly instead of packing them into some barely understandable system with two-letter entries associated with a larger set of features.

Oh my, why do I always have to go for the complicated rewrites...?!
Or maybe I could just, hmm... I don't know... Separate the 'mini-menu generation' code from the 'mini-menu use' code, i.e. hovering it and showing it, should be in their own function (in script.js), while the generation could be pushed to topic.js for topic menus, and the HTML for thought menus or whatever.
I just don't know...
Quote
Seems to me that it would be worth it because it would usually be cached, it's the file most likely to be cached and available after jQuery.
If only it were that simple...
While most pages viewed will be topic pages, any homepage change is still going to have a huge impact.
Posted: February 14th, 2013, 10:27 PM

I saved another 30 bytes and sighed. Another bug has come up...
Damn.

Oh, it should be said that the generation code represents about 150 bytes, and the animation code is about 200 bytes (at the current time). It's really tempting to get rid of the generation code... :^^;:
Anyway... Time for bed. I'm useless right now.
3633
Archived fixes / Re: Plugin execution
« on February 14th, 2013, 07:24 PM »
You have to help with thought menus first, you cheat :P
3634
Archived fixes / Re: Plugin execution
« on February 14th, 2013, 07:11 PM »
Quote from Arantor on January 28th, 2013, 10:58 PM
Well, effectively we have per-post titles. And it's possible for people to change them mid-flow if they want to. (And there are times it's advantageous, e.g. if you merge threads but don't change the post titles)
Yup, as I probably said before, it's done that way in Noisen... Titles are hidden, unless someone manually changed it in their post. It's really what's best. But it just doesn't "work" when the browser doesn't show the page title anywhere, e.g. Chrome or mobile ones.
And I'm not ready to do it like some software that, ahem, adds a position:fixed div with the title whenever the actual title scrolls out of view... It's fun for a minute. Not for daily use.
Quote
Quote
We might as well want to check all topic queries, and ensure they all comply to {query_see_topic}, at least when needed...
True enough - but for now at least, it occurs to me that this measure would essentially encourage us to re-review all the queries.
Yes.
(I've always hated privacy stuff... Well, even more since I implemented per-topic privacy in Noisen... Took me days, probably weeks :P)
Quote
We *could* do that, but I'd rather not, personally. I'd simply avoid the effort of it by just outputting it in the template when necessary. Saves the space in the DB, the extra 'performance hit' is negligible at worst.
'kay.
3635
Bug reports / Mini-menu implementation
« on February 14th, 2013, 07:05 PM »
Quote from Nao on February 14th, 2013, 06:20 PM
To answer the question you're thinking of -- yes, it's actually up and running, has been for about 5 minutes, seems to work, but I'm not extremely happy with the extra overhead... It adds like 1.1KB of code in the script footer area, and about 300 gzipped bytes to the script file. Really not happy with that...
Of course, it also 'removes' 300 bytes from the topic.js file (but what do I care.....), and it implements likes. (Not Ajaxively yet, obviously.) So that's about 110 bytes saved per thought, and as there are 10 thoughts on the homepage, it saves, ahem... 1.1KB of code. Whatever... But the repeated likes compress obviously much better than my mini-menu code.
Currently...
1.0KB of code per page, and adds 275 bytes to script. (I was wrong earlier, it wasn't 300 originally, but 400.)
I can't do much better really... mini-menus simply take a lot of code.
I had to do something I really don't enjoy -- storing the events as strings, and then running them with .click(new Function('e', string))... OMG, my eyes!! eval()!!! If I tried to do it like in eves, i.e. by declaring anonymous functions, I'd have to somehow transmit the current ID to the event function in a way that's not very cool either... (global?!)

I'm just stuck for now.
Sure, it looks nice to have a mini-menu for thoughts. And if you load a topic page, you actually load less JS overall, because the overhead is only in the homepage, and in topic pages you're not forced to download the (internal to script.js) HTML for new thoughts, which represents about 150 bytes of gzipped code.

But I don't know whether it's worth it. It's fucked up.
3636
Bug reports / Re: Quick editing own posts marks topics unread..?
« on February 14th, 2013, 06:20 PM »
Quote from Arantor on February 14th, 2013, 06:06 PM
Therein lies the thing. I'm fairly sure the edit was after I'd read it.
Hmm... So, it said '1' but you'd actually already read my last post?
I suppose you don't remember whether it had a 'New' icon next to it, in the topic page...? Or whether it directed you to my edited post or my last one?
Quote
But what I want to know is not what the current behaviour is - that we can determine from the code. What I want to know is what it *should* do, not what it currently *does*. Whatever the current behaviour, it is not correct.
Sure.
As for looking into the code -- not my 'area of expertise' today... I'm already suffering hell for trying to implement mini-menus as a generic template.

To answer the question you're thinking of -- yes, it's actually up and running, has been for about 5 minutes, seems to work, but I'm not extremely happy with the extra overhead... It adds like 1.1KB of code in the script footer area, and about 300 gzipped bytes to the script file. Really not happy with that...
Of course, it also 'removes' 300 bytes from the topic.js file (but what do I care.....), and it implements likes. (Not Ajaxively yet, obviously.) So that's about 110 bytes saved per thought, and as there are 10 thoughts on the homepage, it saves, ahem... 1.1KB of code. Whatever... But the repeated likes compress obviously much better than my mini-menu code.

Well, it's still a mini-menu... Mini-menus are cool.
Quote
Quote
And, more importantly, it shouldn't mark the topic as unread if I edited my own post (whatever its position.)
Unread for you or unread for everyone?
For me, of course.
Quote
It shouldn't touch its unread position for you, agreed. But others?
It should.
Quote
Sounds like a plan to me.
Good...
Hopefully for this weekend, then...
3637
Off-topic / Re: Opera goes WebKit, RIP Presto
« on February 14th, 2013, 05:14 PM »
Quoting myself............ ::)
Quote from Nao on February 13th, 2013, 03:27 PM
Actually, after trying it out in Chrome (and Firefox's Tree Tabs add-on), I discovered that Opera allowed me to do the same (it has a side tab, and there's a Window feature in it that must be added manually, but then you get a tree-style list that works really well.)
3638
Features / Re: New revs
« on February 14th, 2013, 02:10 PM »
rev 1926 -- we::$is_ajax harmonization, and fixing a Wysiwyg bug. (My fault for this one.)
(37 files, 14kb)

* Renamed $context['is_ajax'] to we::$is_ajax, as it's more of a system variable than context one. It doesn't seem to be tested against before the system class is loaded, but I may be wrong. Also harmonized all $_REQUEST['xml'] requests to replace them with we::$is_ajax and remove 'xml' from Ajax URLs. Just plain and simple... Mass-upload was a special case, because it uses YUI, so I'll be forcing we::$is_ajax on this one. (unittest.js, Class-Editor.php, Class-Skeleton.php, Class-System.php, JSModify.php, Like.php, Load.php, Aeva-Embed.php, Aeva-Gallery.php, Aeva-Gallery2.php, Aeva-ModCP.php, Aeva-Subs-Vital.php, Subs-Media.php, Packages.php (when do we remove that one?), PersonalMessage.php, Post.php, Post2.php, Profile-View.php, QueryString.php, Search.php, Search2.php, Security.php, Split.php, Stats.php, Subs-Menu.php, Subs-Post.php, Subs-Template.php, GenericPopup.template.php, ManageMedia.template.php, Packages.template.php, editor.js, script.js)

* Rewrote some Ajax calls in the editor code to save about, hmm... 30 bytes? Even years after I started my quest to reduce the size of all our JS files to a couple of bytes, I'm still amazed at how much I can save just by being a bit smart about something. (editor.js)

! Which hopefully compensates the silly bug I introduced a month ago, that actually broke switching from Wysiwyg to non-Wysiwyg. Interestingly, a jQuery bug is also associated with it, but because my 'fix' actually compresses better than what I'd written, I'm not even going to bother submitting a report for that one. (editor.js)

* Simplified draft ajax response. Just enough to be able to optimize the matching editor-func JS file... Surprised uh? No? Okay, no. It saves 10 bytes, so sue me. (Subs-Post.php, editor-func.js)

* Moved .xml->feed action compatibility code to the QueryString file, which seems more appropriate for that to me. Also ensured that the corresponding $_GET/$_REQUEST action is updated as well. (index.php, QueryString.php)

! Fixed Pretty URLs in media feeds. (Aeva-Foxy.php)

* Now using XML template codepath for Atom feeds... This seems to work. Needs some double checking. Also fixed some Aeva Media files that still requested the older feed format (.xml in the URL) -- boo. (Load.php, Aeva-Embed.php, Aeva-Subs-Vital.php, Subs-Media.php)

- Replaced a few remaining ISO header declarations to UTF. (upgrade.php, Aeva-ModCP.php)

* Forgot a newline at the end of a file. (ManagePlugins.french.php)

@ I'm (very) worried about start_output() now always returning a XML header for all Ajax responses. Because not all of them are XML-formatted... Do you think this will be okay? (Subs-Template.php)
3639
Bug reports / Re: Quick editing own posts marks topics unread..?
« on February 14th, 2013, 11:31 AM »
Quote from Arantor on February 13th, 2013, 11:43 PM
When I looked at it just now, it said 1 unread. But I had read it up until earlier anyway.
I thought it'd say 3, i.e. my new quick edit, then your (earlier) answer to my post, then my (unedited) answer.
In a way, this should say 3, but only if the edit is EARLIER than the last post you saw. It probably takes a lot of computation to determine this... I don't know. I haven't looked at that code for a while.
Quote
So that's really the big question... should it mark as unread if the topic has since been updated (to let us know there's been a change)?
As I said above.
And, more importantly, it shouldn't mark the topic as unread if I edited my own post (whatever its position.)
Quote
Also, yes, the plugin code still has a lot to go but honestly, the worst of it is done.
Must feel good... Now... How about we consider releasing a new alpha, then..?
3640
Bug reports / Re: Quick editing own posts marks topics unread..?
« on February 13th, 2013, 11:21 PM »
Looks like that plugin code is going to be updated for a long time... ;)

What happens if I edit a post not being the last one..? Hmm... Well, it works as I'd expect -- it doesn't tell me the topic was updated. I don't know if the same would happen for you though. Did the "Someone Nao might enjoy" topic say '3 new posts' or '1 new post' to you...?
3641
Off-topic / Re: Something Nao might enjoy (and others, but Nao especially)
« on February 13th, 2013, 11:19 PM »
I didn't even try ;)
3642
Features / Re: New revs
« on February 13th, 2013, 11:18 PM »
rev 1925 -- just pushing a smaller one before bed time. All in all, a day filled with crappy cleanup commits :P
(12 files, 42kb) (because of reindenting. I suppose.)

* Translation. (ManagePlugins.french.php)

* Some cleanup of remaining ?> closers or missing file newlines. (Class-UnitTest*.php, latest-themes.php, mirrors.xml, Announce.php, module.audio-video.matroska.php, Profile-Modify.php, ManagePlugins.english.php)
3643
Features / Re: New revs
« on February 13th, 2013, 10:59 PM »
rev 1924
(40 files, 10kb)

* Rewrote ajax rating of media items. In case there's an error, it will now show in the rating box instead of silently crashing. Also, it now returns plain text instead of XML. I'm trying to stay away from XML if not needed, not because I hate XML or anything, but because there really isn't any reason to use XML in Ajax transitions, except to look smug and use more bandwidth for nothing. Plus, this slight rewrite saves me 10 bytes or so in the script file. Oh, and I removed show_ajax calls from thought removal as well... Never bother to call that when you're not actually waiting for any Ajax feedback... That doesn't make sense. (Aeva-Gallery.php, Media.template.php, script.js)

+ Added a returnAjax helper function that simply outputs a raw string, passes it through ob_sessrewrite (in case it's some HTML) and returns. Thanks to Pete for unknowingly inspiring this to me. Hopefully this will become somehow my standard way of doing this. Otherwise I'll just add more params or something... (Subs.php, Aeva-Gallery.php, Media.template.php)

- Removed @ from ini_get/ini_set, an old SMF practice that never seemed to do anything special (these functions don't generate errors in the first place, just return false in case something went awry), and God knows I hate useless bytes. (40 files or so.)
3644
Off-topic / Re: Opera goes WebKit, RIP Presto
« on February 13th, 2013, 05:49 PM »
I started using it daily about a year before it removed any ads, I think. I remember I didn't pay for it, but got a legitimate copy through their marketing program -- I posted an ad-like link on my website for some time, and got enough clicks to get a proper ad-free copy. The irony... :)

Oh yes, one of the things I love so much in Opera is the 9.2x-era keyboard shortcuts. Thankfully, they left the option in after they overhauled the shortcuts... One of the things I always do when installing a clean copy of Opera is to switch the shortcut system. Pressing 1 and 2 on my keypad to switch between tabs is especially nice[1], but pressing 4 did what no other browser has ever done: it minimizes the current tab, and switches to the *last used* tab (before the one I just minimized.) Firefox can minimize a tab when clicking it, but it'll only switch to the last tab, and then register the tab I just minimized as the last tab, meaning that even with keyboard shortcuts, I can only switch between two tabs... Which pretty much sucks.
Well, that's just me of course... :^^;:

One of the things I'll regret in Opera is Dragonfly. The version in Opera 12 was finally mature: proper JS tracing, and it had a nice feature the other browsers didn't: it rewrote indentation on minified scripts, meaning I could easily trace through my minified stuff without the need to disable minification in the admin settings. It was very, VERY helpful... I hope Chromium implements that in the future...! Maybe Opera will offer a patch.
 1. Chrome has a similar option, but it involves pressing Ctrl+PageUp/PageDown, which in terms of UX is a big downer...
3645
Off-topic / Re: If Twitter can do it, should we?
« on February 13th, 2013, 03:41 PM »
....