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
2311
Features / Re: New revs
« on November 11th, 2013, 04:29 PM »
rev 2315
4 files changed, 45 insertions(+), 5 deletions(-), 2.04 KiB
! Fixed a bug with no consequences, but nasty to figure out, because it implied the homepage was loaded on mobile in Ajax mode, which wasn't supposed to happen. (Yeah, whatever.) As a rule of thumb, really, please developers, avoid using redirectexit() in an Ajax page! It didn't strike me as 'obvious' that the page would be loaded this way, which is why it took me days to figure it out. It's tempting to add a failsafe in that function itself, but I don't think it's likely to happen often, and I'll probably remember it next time, eheh. (Notifications.php)
! Forgot to add the skeleton.xml file in the last commit. (skeleton.xml)
+ A tentative DCO file, for contributors to agree to when they sign-off their code. (DCO.txt)
- Unused class. (PersonalMessage.template.php)
4 files changed, 45 insertions(+), 5 deletions(-), 2.04 KiB
! Fixed a bug with no consequences, but nasty to figure out, because it implied the homepage was loaded on mobile in Ajax mode, which wasn't supposed to happen. (Yeah, whatever.) As a rule of thumb, really, please developers, avoid using redirectexit() in an Ajax page! It didn't strike me as 'obvious' that the page would be loaded this way, which is why it took me days to figure it out. It's tempting to add a failsafe in that function itself, but I don't think it's likely to happen often, and I'll probably remember it next time, eheh. (Notifications.php)
! Forgot to add the skeleton.xml file in the last commit. (skeleton.xml)
+ A tentative DCO file, for contributors to agree to when they sign-off their code. (DCO.txt)
- Unused class. (PersonalMessage.template.php)
2312
Other software / Re: Fuck the SMF project. Fuck it up its stupid ass.
« on November 11th, 2013, 01:06 PM »
Sometimes I'll open a random topic that I never actually had time to read at all. And it'll be fun.
This one had an appealing title, so I thought, why not. Get the pop-corn out.
And I wasn't disappointed, lol. Arantor giving the middle finger to SMF and then 6 months later joining them and publicly acting as if he'd never been an opponent of their politics... (And implying that I was the one who had problems with the SMF team. Yeah, sure! I never even read that topic before! :lol:)Quote from Arantor on March 15th, 2013, 05:00 PM Or as opposed to, say, moving an array to the database, and then never writing any kind of interface to allow editing it.
At least he tried, didn't he.
Better try and fail, than never to have tried.Quote from Arantor on March 15th, 2013, 05:00 PM Given your high respect for the SMF development team and its low level of entry, it's even more amusing that you didn't hesitate for a split second to join them.Quote from emanuele on March 17th, 2013, 12:02 PM It all depends on your age. :P
I'm 38, so I've had time to 'be young' or 'be old' for things...
I started Basic at 11, assembler at 15, Pascal and HTML at 21, first contact with PHP at 28 (like, 'get the hell out of here!'), first PHP hacks at 30, first real PHP code at 32, first SMF contribution at 33, first mod at 34, first fork at 35, first post on this topic at 38. There's always a time for everything! :PQuote from emanuele on March 17th, 2013, 12:02 PM In terms of reinventing the wheel, it pains me each time I see 'similar' features that are implemented between Elk and SMF and Wedge. That's the price to pay for freedom of structural changes in one's fork, I guess: you can't just take code 'as it is'. Sometimes you can't even port it (e.g. taking things from Wedge and adapting it to Elk or SMF). I for one would love to see all of the 'nice' SMF developers work together on the same stuff, but it's pretty much impossible. Even these last couple of days, I saw you get upset with another developer I like. It is disappointing that human relationships aren't always as easy as "we like this codebase, we both know it, let's work on it together!"... But, well... See how Arantor left Wedge and now has completely forgotten about everything he seemed to hold so dear. You think you 'get' someone, but you have no idea. The only person you can 'get' is the one inside you. As for the others, you can only hope to simply have good relationships with them, but don't expect anything of them.
Meh, I started this post with an uplift mood, and now it all sounds so gloomy... :geek: :ph34r:
This one had an appealing title, so I thought, why not. Get the pop-corn out.
And I wasn't disappointed, lol. Arantor giving the middle finger to SMF and then 6 months later joining them and publicly acting as if he'd never been an opponent of their politics... (And implying that I was the one who had problems with the SMF team. Yeah, sure! I never even read that topic before! :lol:)
He made 5,000 lines of mod to make a nice interface around editing that array. Including such gems as a 50 line easter egg loaded every page, and his own file caching system that insists on pretty-printing everything, including comments, to a file, as opposed to, say, using serialize.
At least he tried, didn't he.
Better try and fail, than never to have tried.
And remember, this is being written by a core SMF developer as a paid mod. You see now why it bothers me so much?
I'm 38, so I've had time to 'be young' or 'be old' for things...
I started Basic at 11, assembler at 15, Pascal and HTML at 21, first contact with PHP at 28 (like, 'get the hell out of here!'), first PHP hacks at 30, first real PHP code at 32, first SMF contribution at 33, first mod at 34, first fork at 35, first post on this topic at 38. There's always a time for everything! :P
@Kindred: not sure if your comment was serious or not, though, why re-invent the wheel again and again and again? There is Lab's free version of the mod (under MPL, so anyone could take it, improve the code (change the name) and re-distribute the mod), there is Kays's version that is BSD.
Use one of those and if you have improvements put them somewhere so that people can grab them. ;)
Meh, I started this post with an uplift mood, and now it all sounds so gloomy... :geek: :ph34r:
2313
Features / Re: One theme to rule them all?
« on November 11th, 2013, 07:43 AM »
Oh, Bloc, you know I have the uttermost respect for your experiments.
I would totally include any of them as core in Wedge. (default or even root would depend on neutrality for former and code shortness for latter.)
For instance I remember i really was in love with your Vienna BBS experiments. Protendo a bit less (at least on mobile) but I can assure you of one thing: anything you experimented so far is doable in Wedge.
If i can have you onboard for skins... telle what I need to do to reassure you it's doable and exciting ;)
I would totally include any of them as core in Wedge. (default or even root would depend on neutrality for former and code shortness for latter.)
For instance I remember i really was in love with your Vienna BBS experiments. Protendo a bit less (at least on mobile) but I can assure you of one thing: anything you experimented so far is doable in Wedge.
If i can have you onboard for skins... telle what I need to do to reassure you it's doable and exciting ;)
2314
Features / Re: One theme to rule them all?
« on November 10th, 2013, 11:32 PM »Got a question:
Let's say I want to edit the header and move items around. With skins, will the header be placed in a template function for me to override like a plugin?
// Start the header layer.
function template_header_before()
{
echo '
<div id="header"><div class="frame">';
}
function template_top_bar_before()
{
echo '
<div id="top_section"><div class="frame">';
}
function template_top_bar_after()
{
echo '
</div></div>';
}
// End the header layer.
function template_header_after()
{
global $context, $settings, $options;
echo '
<div id="upper_section"', empty($options['collapse_header']) ? '' : ' class="hide"', '><div class="frame"><we:banner title="',
$context['header_logo_url_html_safe'], '" url="', !empty($settings['home_url']) && !empty($settings['home_link']) ?
$settings['home_url'] : '<URL>', '">', $context['site_slogan'], '</we:banner>
</div></div>
</div></div>';
}It will eventually be tweaked, probably to add more layers inside upper_section so you can override more specific functions. Basically, to change the header, you can do either of these:
- override (through custom.xml or Custom.template.php, or a plugin) template_header_after, or add a function before or after it. (You can override/before/after any function, even something that already overrides/befores/afters an existing function.)
- override the "banner" macro. This is what's in <we:banner>. It's basically the same as overriding a template function (aka block), but it may be a bit less overkill. Other macros available are title headers. You can completely rewrite their HTML, it'll be repercuted to all cat/title/title2 instances.
Is that all good with you..?
2315
Features / One theme to rule them all?
« on November 10th, 2013, 11:09 PM »
So, these days, the skin system has become really, really powerful. Powerful enough to be able to replace themes altogether, but it's up to you to decide.
- Theme settings: the equivalent is in skin.xml, in a thoroughly documented XML format; you can provide your own settings in custom.xml.
- Templates: while right now you can't simply replace an existing template, you can:
(1) write replacement functions for any template in your own Custom.template.php
(2) write replacement functions for any template in skin.xml (or custom.xml, etc),
(3) add code before or after an existing template function (through methods 1 or 2)
(4) very easily add any custom JavaScript or CSS to any template.
--> Overall, I think I could also provide the ability to override entire templates, but I'd like to avoid it, as it may easily break compatibility in the future. But really, it's just a matter of checking the skin folder, and loading the template there, instead of the 'default' template folder.
- Plugins, and skins, can already override, or add to any template functions, manipulate the layout skeleton so that one element will be shown before another instead of after it, etc.
- The only thing that isn't possible for now is completely overriding image sets, or language files, or scripts. I may write code in the future to account for these.
I don't really see anything that can't be done in skins. Granted, it might be easier to do some things in SMF and the theme system, but it's also true that some other things are much easier in Wedge, so... All in all, I think the skin system is better, more modern, and better suited to designers.
Removing themes from Wedge would allow me to...
- Simplify the folder structure. All folders in /Themes/default/ would be moved to the forum root.
- Remove a lot of legacy code from Wedge that I don't even know if it still works at this point. (I think it does.)
Drawbacks:
- It will postpone the first beta release by at least another two weeks.
- Likely to create bugs in the first phase of implementation.
- Heck, personally, I certainly hope I can still 'blame' files and view the 'commit history' for any files that have been moved, without any disruption. I think it'll be all right, but really, it's one of the things I'm worried about. I like blame, it's one of the best tools for debugging in (D)CVS software. Certainly saves me a lot of time.
So, please vote if you have any opinion on this!
- Theme settings: the equivalent is in skin.xml, in a thoroughly documented XML format; you can provide your own settings in custom.xml.
- Templates: while right now you can't simply replace an existing template, you can:
(1) write replacement functions for any template in your own Custom.template.php
(2) write replacement functions for any template in skin.xml (or custom.xml, etc),
(3) add code before or after an existing template function (through methods 1 or 2)
(4) very easily add any custom JavaScript or CSS to any template.
--> Overall, I think I could also provide the ability to override entire templates, but I'd like to avoid it, as it may easily break compatibility in the future. But really, it's just a matter of checking the skin folder, and loading the template there, instead of the 'default' template folder.
- Plugins, and skins, can already override, or add to any template functions, manipulate the layout skeleton so that one element will be shown before another instead of after it, etc.
- The only thing that isn't possible for now is completely overriding image sets, or language files, or scripts. I may write code in the future to account for these.
I don't really see anything that can't be done in skins. Granted, it might be easier to do some things in SMF and the theme system, but it's also true that some other things are much easier in Wedge, so... All in all, I think the skin system is better, more modern, and better suited to designers.
Removing themes from Wedge would allow me to...
- Simplify the folder structure. All folders in /Themes/default/ would be moved to the forum root.
- Remove a lot of legacy code from Wedge that I don't even know if it still works at this point. (I think it does.)
Drawbacks:
- It will postpone the first beta release by at least another two weeks.
- Likely to create bugs in the first phase of implementation.
- Heck, personally, I certainly hope I can still 'blame' files and view the 'commit history' for any files that have been moved, without any disruption. I think it'll be all right, but really, it's one of the things I'm worried about. I like blame, it's one of the best tools for debugging in (D)CVS software. Certainly saves me a lot of time.
So, please vote if you have any opinion on this!
2316
Features / Re: New revs
« on November 10th, 2013, 08:50 PM »
rev 2314
8 files changed, 7 insertions(+), 39 deletions(-), 1.80 KiB
* Admin area is now much more mobile-friendly. Can you believe it..? Oh, and yes, I try to avoid using the !important keyword whenever possible, but sometimes, it's just not worth the hassle. (ManageBoards.template.php, sections.css)
- Wuthering (and thus, Wilde) still had leftovers from the pre-mobile sidebar system, and it conflicted with the sidebar toggle button, making it impossible to change the theme if you'd chosen any of these by default on a mobile device. Ouch! (Wilde/skin.xml, Wuthering/skin.xml)
- Removing oldIE leftover CSS. (extra.ie6.css, extra.ie7.css, extra.ie8.css, extra.rtl.css)
- Removing a topic list hack for mobile, which doesn't seem to be very efficient to me. Hopefully, the original bug fixed itself by magic. Needs more testing. (sections.css)
! Attachments and custom fields shouldn't be removable by soft-merging. (skeleton.xml)
(And that commit deserves a few Likes, I say :niark:)
8 files changed, 7 insertions(+), 39 deletions(-), 1.80 KiB
* Admin area is now much more mobile-friendly. Can you believe it..? Oh, and yes, I try to avoid using the !important keyword whenever possible, but sometimes, it's just not worth the hassle. (ManageBoards.template.php, sections.css)
- Wuthering (and thus, Wilde) still had leftovers from the pre-mobile sidebar system, and it conflicted with the sidebar toggle button, making it impossible to change the theme if you'd chosen any of these by default on a mobile device. Ouch! (Wilde/skin.xml, Wuthering/skin.xml)
- Removing oldIE leftover CSS. (extra.ie6.css, extra.ie7.css, extra.ie8.css, extra.rtl.css)
- Removing a topic list hack for mobile, which doesn't seem to be very efficient to me. Hopefully, the original bug fixed itself by magic. Needs more testing. (sections.css)
! Attachments and custom fields shouldn't be removable by soft-merging. (skeleton.xml)
(And that commit deserves a few Likes, I say :niark:)
2317
Features / Re: On Mobile Theme...
« on November 10th, 2013, 07:41 PM »
Setting .mime to position: static, as I tried yesterday, makes it work on my iPod, but of course it screws up the menu. :-/
Seems to be the thing I dreaded. I'm not sure why it failed yesterday, though..??
Seems to be the thing I dreaded. I'm not sure why it failed yesterday, though..??
2318
Features / Re: On Mobile Theme...
« on November 10th, 2013, 07:33 PM »
Well, got my answer... There was a JavaScript error, which occurred on all mobile themes, if the user wasn't logged in, and thus had no rights. (It wouldn't happen on boards where guests are allowed to post, but it doesn't matter.)
And as I expected, fixing this bug suddenly makes the CSS fail in guest mode as well. Meaning, well... That it's all due to a JavaScript problem in the first place, and CSS hacks won't help at all, eh.
Was looking in the wrong place... Now I need to determine what JS function changes anything in that area. My bet is on mini-menus, of course.
:edit: Confirmed. Disabling mini-menu code will make it work. Uh. So, it's back to being a CSS problem, I guess... :^^;: (As: CSS added by the JS function.)
And as I expected, fixing this bug suddenly makes the CSS fail in guest mode as well. Meaning, well... That it's all due to a JavaScript problem in the first place, and CSS hacks won't help at all, eh.
Was looking in the wrong place... Now I need to determine what JS function changes anything in that area. My bet is on mini-menus, of course.
:edit: Confirmed. Disabling mini-menu code will make it work. Uh. So, it's back to being a CSS problem, I guess... :^^;: (As: CSS added by the JS function.)
2319
Features / Re: New revs
« on November 10th, 2013, 07:30 PM »
rev 2313
2 files changed, 6 insertions(+), 3 deletions(-), 762 bytes
! Fixed runtime CSS errors related to bad clean-ups after an unextends keyword. (Subs-Cache.php)
! Fixed an innocent bug that turned into a nasty JavaScript-show-stopper for guests on mobile devices. (Display.template.php)
2 files changed, 6 insertions(+), 3 deletions(-), 762 bytes
! Fixed runtime CSS errors related to bad clean-ups after an unextends keyword. (Subs-Cache.php)
! Fixed an innocent bug that turned into a nasty JavaScript-show-stopper for guests on mobile devices. (Display.template.php)
2320
Features / Re: On Mobile Theme...
« on November 10th, 2013, 06:54 PM »
iOS 5.1 + iPod Touch: works great in Wilderless, then as you imply, it fails once I log in. >_< Dunno why.
Yeah, still, that's a good direction to look into! At least I know that I can analyze both my ios CSS cached files, and see what the differences are.
Does this happen on your posts only? (i.e. posts where you probably have a checkbox next to the post title...)
Yeah, still, that's a good direction to look into! At least I know that I can analyze both my ios CSS cached files, and see what the differences are.
Posted: November 10th, 2013, 06:51 PM
Does this happen on your posts only? (i.e. posts where you probably have a checkbox next to the post title...)
2321
Features / Re: On Mobile Theme...
« on November 10th, 2013, 06:45 PM »
Hey, my iPod is still running 5.1.1... :P Never bothered to upgrade, since I stopped using it a year ago (was getting too slow, really.)
I've found my cable, I'll just restart it, for old time's sake, and see if I can reproduce there, eh...
I've found my cable, I'll just restart it, for old time's sake, and see if I can reproduce there, eh...
2322
Features / Re: On Mobile Theme...
« on November 10th, 2013, 06:17 PM »
Yeah that could be the reason lol. I actually got fooled when using browserstacks (iOS 6 only) to generate a screenshot of this page. I only saw your shot. And thought it was broken.
Please test in both wireless and wilderless. It's important. Then I may do one final test later and we'll call it quits. ;)
Please test in both wireless and wilderless. It's important. Then I may do one final test later and we'll call it quits. ;)
2323
Features / Re: Relative dates
« on November 10th, 2013, 03:14 PM »
I didn't remember Facebook did hours on older dates. Maybe it's a recent change. I never spend more than a few minutes a week on Facebook, these days. More time to work.
2324
Features / Re: On Mobile Theme...
« on November 10th, 2013, 01:29 PM »
Restored the float hack in Wireless; please test again. :^^;:
(Unfortunately it's not pixel-perfect, unlike the Wilderless hack...)
Can you remind me your version of iOS, already..?
Maybe it's a simulator-only bug, although I doubt it.
Still waiting for feedback on this. :whistle:
(Unfortunately it's not pixel-perfect, unlike the Wilderless hack...)
Can you remind me your version of iOS, already..?
Maybe it's a simulator-only bug, although I doubt it.
Posted: November 10th, 2013, 12:49 AM
Still waiting for feedback on this. :whistle:
2325
Features / Relative dates
« on November 10th, 2013, 12:42 PM »
Talking with Pandos reminded me that I needed to open a topic about this.
So, a few weeks ago, I wrote a quick, rough implementation of relative dates for Wedge. They behave like in Facebook or other 'modern' software, or, closer to us, ElkArte. I wanted pages to validate, and still use valid semantic tags, so I adopted the time tag, and used DATE_W3C as the datetime format, it's longer but more 'solid', and takes timezones into account.
At that point, I had: <time datetime="w3c valid date">Absolute date</time>
Okay.
I used JS to transform absolute dates to relative dates, and it's pretty neat and tidy. I'm happy with it.
But JS has this tiny little problem: it doesn't execute immediately (whatever you may think), and as such, the browser first shows the page with absolute dates, then executes the JS, and replaces dates with relative dates.
The problem is that I didn't realize this because I usually do page reloads, and Chrome is smart enough to execute the JS ASAP and thus I never see the absolute dates. However, if I simply move to a new page, I can see the absolute dates for a split second. I don't like that.
The solution would be to then use relative dates right in the HTML, but what if I want to know the exact date a message was posted at..? I'll have to keep it in a title tag (when right now, the title tag is generated on the fly from the contents of the time tag. Smart enough.) So, that makes this kind of line: <time datetime="w3c valid date" title="Absolute date">Relative date</time>
And, believe me, I think it's wayyyy overkill just for providing an accessible way of getting a relative date. I was already unsure about committing my HTML/JS work with the first version, but this one... Well, it's just not cool.
Not only that, but what if the user likes absolute dates better? Oh, well, I guess I can then simply change the HTML I'm printing out, I guess... I can wrap it up inside a small helper function, provide it a timestamp and then expect Wedge to do all the work for me. Okay, I'm okay with that. I can do that. The only thing I'm not looking forward to, is adding the UI for it, even if it's simple, because I'm rather remove user options than add them, but well, I think it's something that polarizes users more than "number of topics per page", I'd say.
But the extra length of time tags, I'm not sure it's worth it... :-/
So, two questions... Do you like absolute or relative dates better, and do you think it's all worth implementing (considering if I do, I'll add a setting to let you choose your preference)?
Also, when it comes to relative dates, how far away (ago?) do you think it's worth reverting back to absolute dates? I'm not exactly the kind of guy who enjoys seeing a "6 years ago" date. I prefer to see "May 2007", but maybe that's just me. I also don't like seeing "3 months ago" either, but I'm fine with "5 days ago", so... I guess it's a fair question.
PS: oh, another one... I also think it'd be really cool to see "5 days ago at 8:54" rather than just "5 days ago". Oddly, I've never seen this kind of implementation, anywhere...
So, a few weeks ago, I wrote a quick, rough implementation of relative dates for Wedge. They behave like in Facebook or other 'modern' software, or, closer to us, ElkArte. I wanted pages to validate, and still use valid semantic tags, so I adopted the time tag, and used DATE_W3C as the datetime format, it's longer but more 'solid', and takes timezones into account.
At that point, I had: <time datetime="w3c valid date">Absolute date</time>
Okay.
I used JS to transform absolute dates to relative dates, and it's pretty neat and tidy. I'm happy with it.
But JS has this tiny little problem: it doesn't execute immediately (whatever you may think), and as such, the browser first shows the page with absolute dates, then executes the JS, and replaces dates with relative dates.
The problem is that I didn't realize this because I usually do page reloads, and Chrome is smart enough to execute the JS ASAP and thus I never see the absolute dates. However, if I simply move to a new page, I can see the absolute dates for a split second. I don't like that.
The solution would be to then use relative dates right in the HTML, but what if I want to know the exact date a message was posted at..? I'll have to keep it in a title tag (when right now, the title tag is generated on the fly from the contents of the time tag. Smart enough.) So, that makes this kind of line: <time datetime="w3c valid date" title="Absolute date">Relative date</time>
And, believe me, I think it's wayyyy overkill just for providing an accessible way of getting a relative date. I was already unsure about committing my HTML/JS work with the first version, but this one... Well, it's just not cool.
Not only that, but what if the user likes absolute dates better? Oh, well, I guess I can then simply change the HTML I'm printing out, I guess... I can wrap it up inside a small helper function, provide it a timestamp and then expect Wedge to do all the work for me. Okay, I'm okay with that. I can do that. The only thing I'm not looking forward to, is adding the UI for it, even if it's simple, because I'm rather remove user options than add them, but well, I think it's something that polarizes users more than "number of topics per page", I'd say.
But the extra length of time tags, I'm not sure it's worth it... :-/
So, two questions... Do you like absolute or relative dates better, and do you think it's all worth implementing (considering if I do, I'll add a setting to let you choose your preference)?
Also, when it comes to relative dates, how far away (ago?) do you think it's worth reverting back to absolute dates? I'm not exactly the kind of guy who enjoys seeing a "6 years ago" date. I prefer to see "May 2007", but maybe that's just me. I also don't like seeing "3 months ago" either, but I'm fine with "5 days ago", so... I guess it's a fair question.
PS: oh, another one... I also think it'd be really cool to see "5 days ago at 8:54" rather than just "5 days ago". Oddly, I've never seen this kind of implementation, anywhere...