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
7681
Plugins / Re: Hooking up data loading
« on September 25th, 2011, 11:30 PM »
An oversight.
Just like Recent Posts... No?
7682
Features / Re: Template skeleton!
« on September 25th, 2011, 11:17 PM »
Alright...
7683
Features / Re: Template skeleton!
« on September 25th, 2011, 09:28 PM »
Can you print_r($context['skeleton_array']) and print_r($context['layers']) for me before you run the function...? Thanks.
7684
Off-topic / Re: Lol
« on September 25th, 2011, 08:17 AM »
Akyhne has delusions and anger management issues. I think he's living in his own world.
Vbgamer45 lives in his own world, too, where his spaghetti code is beautiful, and he's the Lehman Brothers of everyone, ie he gets your money and he doesn't have to give it back one day.
7685
Features / Re: New revs
« on September 25th, 2011, 02:09 AM »
rev 1031
(7 files, 12kb)

* Split the header contents into several blocks[1] (logo_toggler, search_box, language_selector and random_news), allowing to move individual components into other places like the sidebar, as demonstrated in Warm. (And yes, it will break indentation if you check the HTML code. I'm not going to fix it, it's too resource-intensive.) Also, removing logo_toggler will now cancel the oMainHeaderToggler object setup. (index.template.php, Warm/skin.xml)

! Fixed various glitches in Warm and Wuthering, and harmonized their main font: Warm is a PT Sans beast with Segoe UI and Trebuchet MS fallbacks, and Wuthering is a Segoe UI with an Arial fallback. (Warm/index.css, Wuthering/index.css)

- Don't bother setting we_iso_case_folding if it's never going to be used (i.e. set to false, or simply sha1.js is not loaded.) (ssi_examples.php, index.template.php, sha1.js)

* Forgot to remove an 'add' from a loadBlock. (Admin.php)
 1. One question... Is it TOO much? I'm assuming it's okay because these are important components, but I'll refrain from doing it everywhere...
7686
The Pub / [Archive] Re: Logo Madness
« on September 24th, 2011, 05:49 PM »
Quote from Arantor on September 24th, 2011, 11:56 AM
That said, I do want to add my $0.02 here.
Thanks, and I agree with 100% of what you said :)
Quote
There have to be boundaries on creativity on both sides (between add-ons and themes) so that the two can co-exist nicely, and from the point we had that discussion, it seemed pretty clear to me that we were never going to work together too well, because we're at polar opposites and neither of us is prepared to give too much ground.
Still doesn't mean we can't bring anything to each other. It's important to keep one's options open.
Quote
Whether you realise it or not, or care or not, you have shaped Wedge in your own way, with the template skeleton stuff.
IIRC, I built the skeleton code because I wanted to have one of my skins put the sidebar on the very left of the screen, because I was looking at one of my old sites that was built this way and had a feeling of nostalgia... eh eh :P
I thought hard, and first imagined I could make a 'string' that would tell Wedge where to put the sidebar. I just needed to give these 'blocks' a name and substance... Should I make a small HTML page that would call the template_functions by itself? Would it override the obExit code? And I think I quickly realized I could simply put together layers and blocks into that skeleton and call them normally from obExit & co.

Heck, the most surprising to me, is how natural this all is now. I mean, when it comes to templating, SMF is in the stone age for me. It took me only a day to implement a working prototype, and about a couple of weeks (among other projects) to make it work perfectly. Now I'm so happy with it, I'm actually working on splitting the index template into more items so that for instance a skin can push the language flags to the footer, things like that, without a single line of code... :)

Hmm, here's wondering if a plugin could do it by code easily... Hmmmmm... Either remove the block (removeBlock()) and then add it back where they want... Or just add it somewhere, and have Wedge automatically remove other instances... Although it could be possible that themers/modders would want to have a same block in two different places on the page.
Hmm... And what if I wanted to have a page index block... Problem is it takes params to work... Maybe I could improve the skeleton code to support something like <page_index:"base_url",0,100,10,false,true />

Or even conditional blocks...?

if (!empty($context['bottom_linktree']))
   template_linktree(false, true);

Could become...

<if:bottom_linktree:linktree:false, true />

Or just have the $context['bottom_linktree'] setter code go through something like this instead...

loadBlock('linktree:false,true', 'footer', 'before');

Oh, well... :)
Quote
Specifically on the logo, I have to say I wasn't that impressed with the comment about the logo. You might find it a waste of time, but I don't, on different levels. Firstly, it's a relatively harmless way to blow off a bit of creative steam for Nao.
You know, I'm still not sure about either the logo shape and the logo font... :lol:
Quote
Wedge has seen both Nao and myself with the freedom to do things that we've never done before, never been able to do before. It's a power, and it's sadly a little intoxicating. But with that power comes a responsibility.
Yes, true enough, when we started, we mainly saw Wedge as 'SMF for real men' (that was the original joke slogan), that is to say, a SMF for veteran admins who knew it well, and wanted to avoid its issues. I don't know when exactly we realized we'd started making Wedge targeted to just everyone. Our goal was never to be a 'real' SMF competitor, but I think that after spending a year of your life on something, you somehow want it to matter...
Quote
Therein lies the problem: you could design the single most innovative default theme ever, and we'd end up rejecting it or removing parts of it, not because it's you, not because it's not awesome: but simply because it's not what people expect, and it would reflect badly on all of us in that situation.
There are two things in Wedge: themes and skins. I'm encouraging Bloc to both improve on the theme to make it more *universal* (i.e. more likely to help create stunning and original skins), and create skins for it. Given how small our skin files are, we can largely afford to provide several very different skins by default. As you can see, Warm and Wuthering don't require much attention from me. When I make a change to Wine, it's reflected automatically in the others, so it's like I only have one skin to maintain. I'm always considering making a barebones skin (which was my original goal with Warm, but honestly it was a failure, I just didn't go far enough and will something else about that in the near future.) There IS room for more skins, whether full skins or inherited skins. Really. The final choice over the 'default' skin will come later, and it can always change. Because people change, too. Ideas and tastes are not carved in stone, they evolve over time.
Quote
As for being an innovator, I'd argue that by being prepared to buck the trend and go down roads that are less well travelled, or even untravelled, that does make you an innovator, Nao. I mean, what other system implements block management with the facility and ease of use that Wedge has?
I reckon I had plenty of ideas that the competition didn't have. I'm even a bit overprotective of them by now... I always let a sound out when I see John's fork (or another) is implementing a Wedge feature... (Well, that's mostly because he has access to the Wedge codebase and I don't have access to his own, so... I can't help but be a bit paranoid :P)
But I probably need to let these things behind me and focus on new things. There isn't any value in being 'attached' to your earlier achievements. Moving on is necessary at least when working on such a project.
Quote
The only reason I even came back to this topic today was that I was wondering if there was a bigger version of the current logo that I could pimp out my Twitter with. (Bigger version of the triangles, with the word underneath)
Here's a version that I hope you'll find visually appealing ;) Attached filesize and picture size variations in the RAR file. The second logo is for use on DARK backgrounds, of course.
Posted: September 24th, 2011, 05:45 PM

Oh, and a last minute addition: a 50x50 version... Not in the RAR file though. It's not very good, I attempted to keep the font readable but I should have made the triangles a bit smaller.
7687
Development blog / Re: The saga of the Add-on Manager
« on September 24th, 2011, 10:37 AM »
I already suggested wedget as a joke some time ago. Someone was enthusiastic about it -- but I wasn't ;)

My main issue with add-on is that one is supposed to use the hyphen but in theory it's not always used.
7688
Features / Re: New revs - Public comments
« on September 24th, 2011, 02:26 AM »
Welcome to the AeMe 2.10 nightmare :lol:
7689
Development blog / Re: The saga of the Add-on Manager
« on September 24th, 2011, 01:09 AM »
I wouldn't remind it. The name was popular amongst English speakers. Meaning it should be used in the English version. I use extension in French and that's nice enough. Other languages might use plugin...
7690
Features / Re: New revs - Public comments
« on September 24th, 2011, 12:28 AM »
I thought so ;)
Glad to know!
7691
Development blog / Re: The saga of the Add-on Manager
« on September 24th, 2011, 12:27 AM »
Dont worry Pete. Your system is perfection and worth the commitment. Well, it would be if it were called a plugin system :lol: just kidding.
7692
Off-topic / Re: Something kind of crazy
« on September 23rd, 2011, 07:36 PM »
I think Doom made me wanna buy my first PC...
Second Reality closed the deal, though.
7693
Features / Re: New revs
« on September 23rd, 2011, 07:31 PM »
rev 1027
(23 files -1 -1 folder, 31kb)

* Updated loadBlock() to set the default 'where' param to 'add' for non-default layers (still defaults to 'replace' in default.) You may also just use an empty string instead of specifying 'default' in loadBlock() and loadLayer(). Whatever makes you feel more comfortable. (index.php, Boards.php, Calendar.php, Display.php, Homepage.php, Aeva-Gallery.php, MessageIndex.php, Profile.php, Subs-Menu.php, Subs-Template.php, Unread.php, UnreadReplies.php, Warm/skin.xml)

* Moved constructPageIndex() to the index template, to make it easier to style for themers. (Subs.php, index.template.php)

* Turned the stat center into a proper layer. (Boards.php, Homepage.php, InfoCenter.template.php)

! Fixed menus and menu notices in plenty of browsers. IE9, I hate you with a passion now. It's the only browser that doesn't play nicely with floats... IE10 works, and even IE6 works here. Eh. (GenericMenu.template.php, script.js, index.css, index.ie6.css, index.ie7.css)

- Forgot to remove layer hint and extra CSS definitions. Also removed the hs folder, as we're no longer using Highslide. (Load.php, Subs-Cache.php, aeva/hs, smf2.css)
7694
The Pub / Re: Copyrights
« on September 23rd, 2011, 01:25 PM »
Unrelated-but-not-worth-a-topic-search™: are you still of the opinion that you prefer domain.com/profile/User/ to domain.com/~User/...? I've reworked the code to use /profile/ instead (I mourned the idea long enough that it doesn't particularly bother me now), I can commit it if you want.
Quote from Arantor on September 23rd, 2011, 12:31 PM
Quote
Including files that are 100% ours, like the addon code or my CSS preparser?
No, any files that are 100% ours can forgo that line. (You know, we really should change that warning to something other than 'Hacking attempt', then we solve that problem too.)
"Hey guys, you used $modSettings in your code! You should add a copyright!"
Anyone remember the "shared memory space" thingy in GPL? :lol:

"Hacking attempt" -- agreed. any suggestion to replace this? "You can not run this PHP file directly"? "You must run this action through index.php"? "If I'm a chicken, then you're my egg"?
Quote
It's a matter of debate, but as far as I'm concerned, provided that we retain some semblance of mentioning their copyright per file,
Weren't you the one who removed it to begin with? :niark:
Quote
Any code that's not theirs or derived from theirs can safely exclude mentioning them, which does indeed cover pretty much all of Subs-Cache, all of ManageAddons, media/* from what I remember of it and probably more besides.
Yeah, a few more files.
We could even split some files in two just for the pleasure of not mentioning them in the new one... :lol:
Quote
It's only an issue if someone then actually proceeds to build off phpDoc doc files off it, though I guess we might do that in the future. The argument is that if they're contributing, they're validly part of the copyright normally anyway. I also think I'd rather have one long-ish line than two for the purposes of noting copyright.
@copyright based on portions © 2011 Simple Machines, rewritten by Wedgeward © 2010-2011, wedge.org
@copyright © 2010-2011 Wedgeward, wedge.org (uses portions © 2011 Simple Machines)

Oh, and where do we define what Wedgeward is...? Only in the license file?
Quote
We don't *have* to keep their names in the credits at all, there is absolutely no requirement to do so, given that as far as I'm concerned we would have complied with the licence by mentioning it via their copyright and the licence file.
Yes.
Quote
I just think it's kind of nice to leave it though.
Well, I guess it all depends on how it unfolds eventually.
One thing for sure though, I'm still bothered by the list of SMF developers. I mean, it may be confusing. If people want the list of SMF developers, they can just follow our link to sm.org and download SMF2 for themselves... And those who contributed to Wedge are already credited in our Consultant list. Dunno.
7695
Features / Re: New revs - Public comments
« on September 23rd, 2011, 12:59 PM »
Quote from Arantor on September 23rd, 2011, 12:57 AM
Quote
The fact that $where defaults to 'replace' when $target == 'default and defaults to 'add' everywhere else...
Seriously, it's fine. It might sound odd but it actually works fairly well in practice (now that WedgeDesk does it)
Uh... I suppose.
But there's much to be said. For instance:

loadBlock('my_block', array('sidebar', 'default'))

Will add my_block to the sidebar. If not found, however, it will be added to (and NOT replacing) the default layer... Looks logical to me. The other way around (array('default', 'sidebar')) doesn't make sense because default is always there.

Okay, done on my local install... (Hopefully will work fine.)

I'd be tempted, though, to split these into more functions, like 'replaceBlock' and 'addBlock'... Dunno which would be best, really (especially given the number of choices I offer. One function for each...?!)
Or perhaps just alias functions. I mean, it's not like they're called a lot anyway...

function replaceBlock($block, $target)
{
   loadBlock($block, $target, 'replace');
}

Also transformed the info center into the layer. 'info_center_begin' and 'info_center_end' bothered me too much... :lol:
Quote
Whether it being worth the hassle is a good question. But it would certainly prevent random tampering with the arrays directly, and it becomes more semantic because instead of having generic (but nicely named) functions, you have an object to which all the functions physically belong.
Yes, I suppose it's a nice way of doing it.
But loadBlock() is short and sweet. I don't know if wetem::loadBlock() would be better. Or wetem::load_block. Or wetem::load() with Wedge guessing by itself what the contents is (heck, I could do it... I'm just not sure it's as readable!)
Or having functions outside the object, and the object only manipulated through these functions like loadBlock()...?
Quote
This is one of the issues I have with SMF's error messages. In the event of a database error, it can quite easily say something to the effect of "There has been a database error, please refer to the administrator." Which is fine - until it displays that message, as is, to an administrator when they're logged (and after determination of permissions has occurred)
Yeah, true dat!
It would make sense to actually display the faulty query etc to them...
Quote
Quote
No, that's not what I was saying... If a board has a default language, different than the forum's, *and* the admin disabled the ability to change languages for users, i.e. $modSettings['userLanguages'] or whatever is false, then getLanguages() is not called... And my test code isn't, either.
Hmm, not sure how to proceed on that one.
I believe we should store somewhere the number of language files available. If it's > 1 we call getLanguages() either way. We'll only use $modSettings['userLanguage'] when in the index template, just before showing the flags themselves.
Quote
Also, in add-on related news, WedgeDesk is now capable of being installed (and running) cleanly from the add-on manager. The only thing it can't handle right now is attachments, and that's only because it's expecting to use the old attachment handling code which I haven't removed yet.
Ah, attachments and avatars...

It's probably my greatest failure of these last few months. Have you noticed how I keep postponing them...?
It's mainly because I'm afraid doing these changes will push me into a 3-month bug hunt that will prevent us from showing Wedge to the public, etc. I keep thinking of situations where the current attachment and avatar systems make more sense than Aeva's, *or* may require users to change the way they see things. I'm already considering ensuring the avatar and attachment albums won't be browsable by users (bit wary of the permission issues -- way too risky). Things like that, from which I'm backing off... (backing away?)

To be honest -- apart from the cool fact that Aeva would allow user to rotate through their favorite avatars (I do have a local folder of my favorite avatars but maintaining it is a hassle), the main reason why I released Aeva Media 2.10 (you know, the failed one :P) *AND* wanted to have v2.10 in Wedge (instead of 1.x), *AND* wanted to replace the avatar system with Aeva, is because.... Wait for it... I love having a drop shadow on my avatar, and want it on every forum I go to, but I just don't want a drop shadow when I'm using a transparent avatar!

Yeah... That's, basically, the only reason I did all of it.

I'm stupid.
Quote
On that note, actually... I was thinking about how to handle attachment access for things like WedgeDesk that have their own authentication needs and that have different needs to the norm. Galleries, by definition, are accessed at gallery level, but we need to change that to being determined at board level for attachment gallery items.
Yeah, and more than that... Topic level. See what I mean. (If we implement topic privacy. Another of my recent failures.)
Quote
I'm not sure how we'd do *that*, but the solution for handling attachments generally when it's an external source seems fairly clear: have a hook that attempts to make the query that Dlattach.php normally would (or MGalleryItem.php, whatever query would normally be run to identify a file and validate the user can access it), and the hooked functions should return the necessary information, or false - that way, systems can deal with it as necessary.
I'm not sure I understand.

Oh, and if we have board-level permissions, then I suppose we could (should?!) modify Aeva to use boards and topics instead of albums and items. Not sure about that yet, though... It basically means implementing the floating topic stuff.