Wedge

rev 2173 -- don't fret, I don't have much committable material after that one...
(2 files, 2kb)

! Was still using the min-device-pixel-ratio media query, when I should have been using min-resolution instead, which is fully supported by Wedge... (As in, 'it provides a fallback for it.') Also, IE8 has never supported that particular query, so I'm updating the target browser list. (index.css)

* Mixing .hide classes compresses better than extending them. Should have noticed I wasn't doing the right thing, but... (index.css)

* Moved random_news block to the main content area, right before the linktree. I simply thought that the header was crowded enough as it was, and people would be less likely to notice the extra news block in these conditions. I was so very tempted to remove the feature entirely, but I respect Pete's work on overhauling it! (index.css, skeleton.xml)

rev 2171 -- finally got around to cherry-picking this N-th large overhaul of the notifications system...
(12 files, 21kb)

* Large overhaul of the notification system. Notifier is no longer an abstract class, and it provides default actions for all methods. It assumes that your notification is about a forum post, so if you want to notify about a topic, a thought, a media item or whatever else, you'll have to override some of the methods, but it's better than having to override it constantly. (Class-Notifier.php, Notifications.php, notifiers/*, ...)

* Notification::issue parameters were changed; notifier name now comes first (it makes more sense to me), and it expects a string, rather than a notifier object, so just remove weNotif::getNotifier() calls, it's much simpler this way. Also changed order in NotifSubscription::issue, although I have yet to see this function used, so it doesn't matter... (Class-Notification.php, Class-NotifSubscription.php, Like.php, MoveTopic.php, QuickMod.php)

* Notification previews are now prepared entirely within the getPreview method, making it easier for notifier objects to override the default behavior in case the notification isn't related to a topic, or something more complicated is needed. (Class-Notifier.php, Notifications.php, notifiers/Likes.php)

* Notification periodical e-mails should now be in plain text, as desired. (Notifications.template.php)

* Commenazi. (Class-Notification.php, Class-Notifier.php)

! Fixed missing header. (notifiers/Move.php)

Fun crap of the day...
Chrome: $(document).mousedown(e) -> e.which returns 1 for left button click, 2 for middle, 3 for right.
Firefox: e.which returns 1 for left button click, and isn't caught at all in middle and right clicks... To trigger 2, you have to first press the right mouse button, then the middle button, then release the right button.

This is totally stupid..!

Also, doing it on click() (which isn't in the jQuery docs), right button works, but middle button still doesn't... -_-

I'm starting to seriously consider doing two different sidebar animations...

- desktop: sidebar shows from the left; screen remains static.
- mobile: sidebar is stuck to the left of the screen; entire screen scrolls, or 'pans' to the right.

The reason why I need to do it that way in mobile, is that it's the only way to trigger hardware acceleration; as a counterpart (?), the sidebar position can only be 'absolute', instead of 'fixed' (this is a W3C-induced limitation related to stacking contexts). It doesn't matter much anyway, because scrolling a position: fixed element on mobile is an... absolute PITA. Believe me, I've tried HARD... Doing it in a native app is easy as hell, but in a web app, it's really hard to get it right.
Desktop browsers don't need the extra boost from hardware acceleration anyway, so we can do without it... Although the animation isn't as cool, but since it's done by jQuery, it's compatible with all browsers, including oldIE. Normally...

I don't know... Should I do the hardware accelerated animation on both..?

There are two different sidebars...

I take it you haven't followed this topic at all... Anyway...

While your features are mostly admin-only and thus were shown through screenshots, my features are mostly front-end, and when I ask members for their opinion, it's on what they can currently experience on the website... It's not so hard to press the middle mouse button and see for yourself what this animation is about, for instance... :-/(And I didn't bother too much about the lack of feedback on this, because the feedback I want is from developers, and currently, the only ones to have access to the codebase can be counted on one hand.)Yes, it's one of the cases where everyone was stumped, including me.
(Although later, I made a suggestion about moving everything to use hover dropdowns, which I still think is going to work great, but I'm always postponing my 'generic hover dropdown' thing, because I have other things to deal with... Currently, notifications, sidebar and infinite scroll, all three of which have taken their toll on me...)Yeah, just like everywhere -- when people are happy with something, they don't bother discussing it, they only post where they're concerned with something. But still, usually when I ask for feedback, I'll get some, and I'm not getting feedback on anything these days... Even from you, Pete, but well, you're on hiatus, right..?Yeah, happened to me, too...
I was actually considering dropping the hover act for this, and going for a Menu button in both mobile and desktop. Both will have an additional trigger technique, of course: middle click for desktop, and right swipe for mobile. (The version I'm working on currently is much more conservative when it comes to the swipe length, and I'm hoping to be able to make it work the same on all mobile devices, whatever their way of calculating said length, which can be annoying.)

PS: I still think that, maybe, just maybe, we should consider saying Wedge is a 'blog' platform, or at least remove references to 'forum', and use 'community' everywhere...

Okay, let's just say... You wrote a plugin that adds a bbcode. And that bbcode is related to a feature offered by an external service, and thus implements a script (add_js_file) that's located on another server. It's an example among plenty possible. It's very likely that it will break, in these conditions...

Unless I can get to do the iframe version, and then move the code, including events and scripts (and not re-running them), to the parent page, after it's finished loading. So far, I wasn't able to prevent alerts from being shown in the iframe, so...

I see it was worth the effort... :lol:

Single tap would be crazy, eh... ;)

Okay, so I read a bit about iOS 7, and from what I gathered, they simply copied Chrome's behavior for Safari, i.e. you have to swipe from a side, it won't trigger if you swipe from the middle, for instance. So, it should be okay... Just as I thought -- they wouldn't dare break thousands of websites that implemented code specifically to work on their OS...!

Also, I rewrote (again) my code tonight, and ended up getting a faster animation on Android, but it's extremely broken (apart from the sidebar font size finally being fine), and the animation doesn't work on iOS (at least older versions), will fix later.. Also, the opening/closing triggers stop working after the first time, so you'll have to reload your page. I'll fix all of these, tomorrow... For now, bed time is upon me. Ah, well... Maybe if I manage to steal a few extra minutes, eheh...

Okay, fixed the triggers to happen all the time, fixed font color, didn't fix the stuff in iOS though, I couldn't care less... :niark:
What do you think of this new animation..? It could be seen as bothersome if you're currently writing a post or something and then accidentally triggering the thing, but it's no biggie.