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.
Topics - Nao
136
Development blog / This. Is. Crazy.
« on February 3rd, 2012, 04:20 PM »
One year and a half... In a couple of weeks, it will be one year and a half since Pete and I decided to work on our own SMF fork. Talk about commitment!
About a year later, thanks to the SMF license change, over half a dozen new forks went into production. Somehow, I felt a bit relieved that we weren't going to be 'the new SMF' and that maybe we could simply focus on being the smarter one, instead of the one everyone wants to use (including morons. We hate morons. But don't tell them, or they'll come.)
Some of them were officially stopped after a few days or weeks. Others lasted a bit longer, but are clearly never going to happen. Nightwish's fork is clearly, and definitely, the only 'serious' competition we ever had, and given that I was the one that revealed its existence, I feel somehow responsible for pushing him into working hard on it. After several months of daily commits, however, it went off the radar and it would seem that none of the other forks made it into 2012.
Well, I'm sad about it. Once again, everyone's looking at Wedge again and expecting a release. I was kind of enjoying being able to simply work on it without any pressure. Hmm, still no pressure, but I'm starting to feel uncomfortable that nearly a year after SMF 2 went gold, no single fork has been made available to the public. So, it's time for me to look into what's ready and what's not.
If you'll remember, back when I published the first screenshots, I said I'd start using Wedge on Wedge.org itself once we'd reach 200 Likes on Facebook. While it was more of a joke than anything, it just so happens that we're getting close to that decent number of friends, and that in the same time, I'm working hard on making the transition as smooth as possible. So it's very likely that Wedge.org will actually be running Wedge by the time we reach 200 Likes. I'm currently running a 'beta-test' of the Wedge.org website on our friends group. The feedback is very positive, thankfully, so it appears I won't have too much to implement or fix before I make the final switch.
What else? Well, it's become customary to give a quick review of what we did since the last blog post... Pete worked on removing the calendar to turn it into a plugin, but as it turned out, it was harder than expected, and it pretty much hurt his motivation, and he has yet to dive back into the game. Still, 11 commits is better than all of the other forks together, so I guess I can still hope. I really don't want to keep working on Wedge alone, that's enough to drive a man crazy. Plus, well, I love working with Pete. He's such a great guy. I could say the same of the rest of our non-dev team. It's always been such a pleasure to share ideas with you!
And now for the customary changelog summary...
As for myself, I made 125 commits, which is pretty much on par with my regular output. I'm not going to keep up with this in 2012, well I'm hoping I'll take some time off because I never stopped to take a moment, and maybe I should go see a doctor or something. Or at least get paid for working on Wedge. I spent most of November working on improving the template skeleton system (it's now pretty much flawless), and finishing the thought system. In December I rewrote the BBCode implementation to be smarter about fixing mismatched tags and even giving proper error messages to the user.
Then the big chunk -- I had in mind that I wanted to replace our basic select boxes with a JavaScript implementation that would look cool. Well, it took me weeks to get it right, but it's possibly the best JS select box every written when it comes to usability, features and compacity (it's only about 2 kilobytes when other JS plugins are usually double the size.) Learned a LOT about JS code size optimization in the process, which means Wedge loads faster. I also changed my mind on that cool feature of mine, the automatic quote splitter. While technically interesting and everything, I felt that in the long run, it might seem unnatural to those used to non-Wysiwyg editors. So I decided to only run the splitter if you hold the Shift or Ctrl keys when pressing Enter. Plus I've documented it in the post editor.
Which brings us to January, where I kept working on the improved select box. I most notably added a custom scrollbar. After I was done, needless to say I was pretty burnt out, so I decided to focus on a small and easy task instead -- getting rid of the Wysiwyg editor's iframe. Well, that's what I thought... It turned into an absolute nightmare. Oddly, the only browser that liked doing without the iframe was Internet Explorer. Of all browsers. Including IE6. Well. Eventually, I had to admit defeat and went back to the original code. Which, I hate to say, was just as broken. I just don't use Wysiwyg that much, you know. So I spent another couple of weeks working on fixing it. It was pretty much an extensive rewrite, and I can now safely say that our Wysiwyg editor is more solid than SMF's. And shorter. And smarter. As I pointed out in the changelog (you know where to find it), the most annoying bug was due to Wedge using sprited images (inside a div) instead of regular img tags to show buttons and smileys. It turned out that IE loses focus when you click a div outside the iframe, but it doesn't when you click an img. Don't shoot the messenger. No, fear not, I didn't come back to a series of image files, it would be ridiculous. I simply added a dummy transparent image in front of the buttons if using IE. Sometimes, the simple solution is what is best.
After I was done with "small tasks that end up taking weeks to complete", I went the safe route and implemented some additions I'd already written for Noisen.com and Wedge.org -- such as indicating the number of new posts next to a New icon. Or adding support for transparent avatars. (Well, this one's from Aeva Media 2.x, technically.) Then I fixed a few broken areas of WeCSS (which live627 declared his love for, oh I sooo needed that!), and I renamed the 'sticky' feature to 'pinned', which took longer than I'd hoped, but will definitely be an improvement for everyone -- pinning a topic makes more sense than 'setting it sticky'. What does that mean anyway?
Now, what's in store for February? Well, as I said at the beginning, my plans are to finally use Wedge on Wedge.org once and for all, as soon as possible, and that does mean this month. So I've quickly cooked up a new skin for Wedge, which I'll hopefully be using here. My current keyword for Wedge is 'simplicity', so I'm trying to remove as much crap from the templates as possible. The current feedback is very positive, so I think I'm on the right track here.
And if I happen to fall asleep and not post for another month -- go, go, The Artist! The French touch is alive and kicking!
About a year later, thanks to the SMF license change, over half a dozen new forks went into production. Somehow, I felt a bit relieved that we weren't going to be 'the new SMF' and that maybe we could simply focus on being the smarter one, instead of the one everyone wants to use (including morons. We hate morons. But don't tell them, or they'll come.)
Some of them were officially stopped after a few days or weeks. Others lasted a bit longer, but are clearly never going to happen. Nightwish's fork is clearly, and definitely, the only 'serious' competition we ever had, and given that I was the one that revealed its existence, I feel somehow responsible for pushing him into working hard on it. After several months of daily commits, however, it went off the radar and it would seem that none of the other forks made it into 2012.
Well, I'm sad about it. Once again, everyone's looking at Wedge again and expecting a release. I was kind of enjoying being able to simply work on it without any pressure. Hmm, still no pressure, but I'm starting to feel uncomfortable that nearly a year after SMF 2 went gold, no single fork has been made available to the public. So, it's time for me to look into what's ready and what's not.
If you'll remember, back when I published the first screenshots, I said I'd start using Wedge on Wedge.org itself once we'd reach 200 Likes on Facebook. While it was more of a joke than anything, it just so happens that we're getting close to that decent number of friends, and that in the same time, I'm working hard on making the transition as smooth as possible. So it's very likely that Wedge.org will actually be running Wedge by the time we reach 200 Likes. I'm currently running a 'beta-test' of the Wedge.org website on our friends group. The feedback is very positive, thankfully, so it appears I won't have too much to implement or fix before I make the final switch.
What else? Well, it's become customary to give a quick review of what we did since the last blog post... Pete worked on removing the calendar to turn it into a plugin, but as it turned out, it was harder than expected, and it pretty much hurt his motivation, and he has yet to dive back into the game. Still, 11 commits is better than all of the other forks together, so I guess I can still hope. I really don't want to keep working on Wedge alone, that's enough to drive a man crazy. Plus, well, I love working with Pete. He's such a great guy. I could say the same of the rest of our non-dev team. It's always been such a pleasure to share ideas with you!
And now for the customary changelog summary...
As for myself, I made 125 commits, which is pretty much on par with my regular output. I'm not going to keep up with this in 2012, well I'm hoping I'll take some time off because I never stopped to take a moment, and maybe I should go see a doctor or something. Or at least get paid for working on Wedge. I spent most of November working on improving the template skeleton system (it's now pretty much flawless), and finishing the thought system. In December I rewrote the BBCode implementation to be smarter about fixing mismatched tags and even giving proper error messages to the user.
 |
This skin is a work in progress! And the select box looks even better in action! I like exclamation marks, sue me! |
Which brings us to January, where I kept working on the improved select box. I most notably added a custom scrollbar. After I was done, needless to say I was pretty burnt out, so I decided to focus on a small and easy task instead -- getting rid of the Wysiwyg editor's iframe. Well, that's what I thought... It turned into an absolute nightmare. Oddly, the only browser that liked doing without the iframe was Internet Explorer. Of all browsers. Including IE6. Well. Eventually, I had to admit defeat and went back to the original code. Which, I hate to say, was just as broken. I just don't use Wysiwyg that much, you know. So I spent another couple of weeks working on fixing it. It was pretty much an extensive rewrite, and I can now safely say that our Wysiwyg editor is more solid than SMF's. And shorter. And smarter. As I pointed out in the changelog (you know where to find it), the most annoying bug was due to Wedge using sprited images (inside a div) instead of regular img tags to show buttons and smileys. It turned out that IE loses focus when you click a div outside the iframe, but it doesn't when you click an img. Don't shoot the messenger. No, fear not, I didn't come back to a series of image files, it would be ridiculous. I simply added a dummy transparent image in front of the buttons if using IE. Sometimes, the simple solution is what is best.
After I was done with "small tasks that end up taking weeks to complete", I went the safe route and implemented some additions I'd already written for Noisen.com and Wedge.org -- such as indicating the number of new posts next to a New icon. Or adding support for transparent avatars. (Well, this one's from Aeva Media 2.x, technically.) Then I fixed a few broken areas of WeCSS (which live627 declared his love for, oh I sooo needed that!), and I renamed the 'sticky' feature to 'pinned', which took longer than I'd hoped, but will definitely be an improvement for everyone -- pinning a topic makes more sense than 'setting it sticky'. What does that mean anyway?
Now, what's in store for February? Well, as I said at the beginning, my plans are to finally use Wedge on Wedge.org once and for all, as soon as possible, and that does mean this month. So I've quickly cooked up a new skin for Wedge, which I'll hopefully be using here. My current keyword for Wedge is 'simplicity', so I'm trying to remove as much crap from the templates as possible. The current feedback is very positive, so I think I'm on the right track here.
And if I happen to fall asleep and not post for another month -- go, go, The Artist! The French touch is alive and kicking!
137
Features / Fixing mismatched BBCode
« on December 4th, 2011, 11:59 AM »
The code in Class-Editor that straightens out missing code tags is quite odd to look at... Some variables are initialized and never actually used, etc. I looked into it and decided to rewrite it. As a result, I did pretty much the same thing -- in only three lines of code instead of 10.
Now, the thing is that the I'm using a $num_tags variable instead, which is incremented or decremented based on whether it meets an opening or closing tag. Although technically it works (if you have two opened code tags, it will addd two closers), in reality it doesn't work as expected. Two examples:
- if you first use a closer, then an opener, $num_tags will be set to zero and nothing will be fixed. The code needs to be smarter than that.
- if you use two openers and a closer, Wedge will add an extra closer... Except that code tags within other code tags are treated as code (not tags), so they don't need a closer. It's always been a mess in SMF because if you add two closer tags here, the second one is shown as plain text, instead of the first one. Here, I'd tend to say this is a SMF bug that needs to be fixed in Wedge... What do you think?
Now, the thing is that the I'm using a $num_tags variable instead, which is incremented or decremented based on whether it meets an opening or closing tag. Although technically it works (if you have two opened code tags, it will addd two closers), in reality it doesn't work as expected. Two examples:
- if you first use a closer, then an opener, $num_tags will be set to zero and nothing will be fixed. The code needs to be smarter than that.
- if you use two openers and a closer, Wedge will add an extra closer... Except that code tags within other code tags are treated as code (not tags), so they don't need a closer. It's always been a mess in SMF because if you add two closer tags here, the second one is shown as plain text, instead of the first one. Here, I'd tend to say this is a SMF bug that needs to be fixed in Wedge... What do you think?
138
Features / Privacy options
« on November 28th, 2011, 09:09 PM »
Splitting this topic into its own from the original Selectbox topic...
Please read the bold characters below and tell us your opinion!
Please read the bold characters below and tell us your opinion!
139
A short note...
Yesterday I was looking into improving the privacy selectbox, notably to allow for friend groups to be specified, was planning to turn it into an object similar to the privacy button on Wedge.org (click the key icon next to a topic link (that you own, in a blog), and it opens up a popup, select Groups or something and it'll show you a checkbox list...), then I found out about selectbox replacement plugins for jQuery, looked into their code and demos, I particularly liked one (it basically creates an absolutely positioned div with scroll overflow like the key object in here, but does it while retaining compatibility with non-JS browsers so that'd be nice to use everywhere), anyway -- when packed and gzipped, the main script file is 5.89KB, and with the extra plugin (which I would clearly modify...), it's 8.52KB. So that's an increase of 50% in size, but OTOH it's still less than 3KB... And then on the other, other hand, 3KB is exactly the reason I'm not excited to upgrade jQuery to a newer version... :lol:
I'm not sure just yet.
The demo: http://labs.abeautifulsite.net/projects/js/jquery/selectBox/
Second time this week I'm on this website... I have no idea why I was there the first time, I just remember I liked their logo... And now I'm starting to realize my own logo for Wedge may have been unconsciously influenced by them :lol: No, no, it's just leaves... :^^;:
Yesterday I was looking into improving the privacy selectbox, notably to allow for friend groups to be specified, was planning to turn it into an object similar to the privacy button on Wedge.org (click the key icon next to a topic link (that you own, in a blog), and it opens up a popup, select Groups or something and it'll show you a checkbox list...), then I found out about selectbox replacement plugins for jQuery, looked into their code and demos, I particularly liked one (it basically creates an absolutely positioned div with scroll overflow like the key object in here, but does it while retaining compatibility with non-JS browsers so that'd be nice to use everywhere), anyway -- when packed and gzipped, the main script file is 5.89KB, and with the extra plugin (which I would clearly modify...), it's 8.52KB. So that's an increase of 50% in size, but OTOH it's still less than 3KB... And then on the other, other hand, 3KB is exactly the reason I'm not excited to upgrade jQuery to a newer version... :lol:
I'm not sure just yet.
The demo: http://labs.abeautifulsite.net/projects/js/jquery/selectBox/
Second time this week I'm on this website... I have no idea why I was there the first time, I just remember I liked their logo... And now I'm starting to realize my own logo for Wedge may have been unconsciously influenced by them :lol: No, no, it's just leaves... :^^;:
140
Features / Thought system
« on October 31st, 2011, 11:08 PM »
Okay, I'll be opening this topic to discuss the upcoming thought system...
For those of you who aren't in our Friends group, you can't access thoughts in here, so I'll redirect you to noisen.com where you can see a list of thoughts on the homepage.
Basically, it's a chatbox, only it doesn't have all that Ajax stuff that makes it look like it's real time and mostly puts a lot more load on your server.
I'm about halfway through my implementation for Wedge. I rewrote a lot of it, and added some features which may or may not work.
- Privacy: determine whether you want your thoughts to be visible to everyone, just members, just your friends, or just you (e.g. a to-do...)
- Edit ANY of your thoughts, including older 'latest thought' or your replies to others' thoughts.
- The latest thought is now in the sidebar. You can either edit it, or write a new one (there are links for that.)
- If you edit a current thought, if the new version has less than 10% differing from the old thought, the original publishing date will be kept. Otherwise, the thought's publishing date is set to now. (This is different from the current implementation where a 20% difference will generate a new timestamp, also it allows you to edit anything.)
- I've removed the 'Default Personal Text' option which means nothing to me... And to anyone else, I'd venture into saying. (Hey, Pete isn't the only one entitled to deleting SMF crap :P)
- Users can no longer set their Personal Text in their profile, if only because they can now set it from any page in the sidebar...
The privacy stuff only has the UI implemented. The 'edit everything' code is barely started, so it doesn't work.
The JavaScript adds an extra couple of kilobytes to script.js, which bothers me a bit (though it'll probably be more like 500 bytes once minified an gzipped), but OTOH it's a pretty neat feature so I think it's best to have it as default...
I'm a bit stumped with storing the latest thought though. Right now I'm storing something like "1500|My thought" in the members table where 1500 is the thought's ID, so that I can easily tell Wedge whether we're currently editing the latest thought (by putting its ID into an invisible part of the form) or simply writing a new thought that looks a lot like an earlier one (in which case the ID is set to 0 at this point.)
I don't want (too much) to get rid of personal_text because some people may not want to use the thought system and still have their old SMF-imported personal text below their avatar and stuff. But I think that storing the thought ID as a 'hack' inside the personal_text itself is not exactly pretty.
Open to any suggestions... I'm off to bed, this weekend was hectic.
For those of you who aren't in our Friends group, you can't access thoughts in here, so I'll redirect you to noisen.com where you can see a list of thoughts on the homepage.
Basically, it's a chatbox, only it doesn't have all that Ajax stuff that makes it look like it's real time and mostly puts a lot more load on your server.
I'm about halfway through my implementation for Wedge. I rewrote a lot of it, and added some features which may or may not work.
- Privacy: determine whether you want your thoughts to be visible to everyone, just members, just your friends, or just you (e.g. a to-do...)
- Edit ANY of your thoughts, including older 'latest thought' or your replies to others' thoughts.
- The latest thought is now in the sidebar. You can either edit it, or write a new one (there are links for that.)
- If you edit a current thought, if the new version has less than 10% differing from the old thought, the original publishing date will be kept. Otherwise, the thought's publishing date is set to now. (This is different from the current implementation where a 20% difference will generate a new timestamp, also it allows you to edit anything.)
- I've removed the 'Default Personal Text' option which means nothing to me... And to anyone else, I'd venture into saying. (Hey, Pete isn't the only one entitled to deleting SMF crap :P)
- Users can no longer set their Personal Text in their profile, if only because they can now set it from any page in the sidebar...
The privacy stuff only has the UI implemented. The 'edit everything' code is barely started, so it doesn't work.
The JavaScript adds an extra couple of kilobytes to script.js, which bothers me a bit (though it'll probably be more like 500 bytes once minified an gzipped), but OTOH it's a pretty neat feature so I think it's best to have it as default...
I'm a bit stumped with storing the latest thought though. Right now I'm storing something like "1500|My thought" in the members table where 1500 is the thought's ID, so that I can easily tell Wedge whether we're currently editing the latest thought (by putting its ID into an invisible part of the form) or simply writing a new thought that looks a lot like an earlier one (in which case the ID is set to 0 at this point.)
I don't want (too much) to get rid of personal_text because some people may not want to use the thought system and still have their old SMF-imported personal text below their avatar and stuff. But I think that storing the thought ID as a 'hack' inside the personal_text itself is not exactly pretty.
Open to any suggestions... I'm off to bed, this weekend was hectic.
141
Features / New revs - Noob questions?
« on October 20th, 2011, 07:58 AM »
The purpose of this topic is to give a safe haven for readers who:
- find interesting to read the 'New revs' topic,
- mostly don't get a word of it because it's too technical,
- would really like to know what this is all about.
Everytime you see a new revision that intrigues you, feel free to ask here for more details. Chances are, they're already available elsewhere so we'll just point you to them, and if they aren't, we'll take some time to explain -- we help you, we help ourselves.
So, go ahead, this is your topic!
- find interesting to read the 'New revs' topic,
- mostly don't get a word of it because it's too technical,
- would really like to know what this is all about.
Everytime you see a new revision that intrigues you, feel free to ask here for more details. Chances are, they're already available elsewhere so we'll just point you to them, and if they aren't, we'll take some time to explain -- we help you, we help ourselves.
So, go ahead, this is your topic!
142
Features / Moving options out of Current Theme
« on October 19th, 2011, 10:15 AM »
(split from New Rev comments)
Found the origin of the bug. Comment out the $current_action = 'moderate' line in Subs.php and it doesn't generate the error anymore... I think it's related to how I moved the moderation center to within the admin menu. Didn't look any further.
I'm seeing FOUS effects in the admin area when dealing with the error log... Hadn't seen these in a while. Dunno if it's due to some bug in the new Opera. Can you tell me if you've seen any of these in Chrome?Quote from Arantor on October 19th, 2011, 03:17 AM There are plenty of options that should be in general options...
Fading delay between items for the news fader: NEWS area
Number of recent posts to display on board index: possibly elsewhere. That's in the info center right..? See below.
Show statistics on board index: --> I don't believe themes would modify the info center so much that this would kill layout...
Show latest member on board index: ditto (might be removed entirely)
Show group key on board index: ditto (should be removed as an option, and always shown.)
"Show who is viewing" --> this is an important feature, it should be enabled by default at the very least... (And the English description is confusing, too.)
Show last modification date on modified posts: if themes don't provide a field for that, then it just won't be shown... Otherwise, they'll provide for it, and make sure it's usable. This is definitely an option for POST settings.
Show view profile button under post: POST settings.
Show user avatars in message view: POST settings or AVATAR settings.
Show personal text in message view: POST settings.
Show gender images in message view: POST settings.
Hide post group titles for grouped members: POST settings or MEMBERGROUP settings.
Enable collapsible additional post options: general, post settings or something...
My conclusion: theme settings should only *contain settings that related to the theme itself (e.g. something like, "show the info center in the sidebar/main area"), not settings related to features that are built into Wedge* (e.g. personal_text has a field in the members table, so all themes are expected to be able to deal with it.)
What do you think...? As an added bonus, we get to have the options made searchable... This is all because yesterday I wasted 5 minutes trying to enable 'show group key' and the admin search refused to point me to it...
We should also rename 'Current Theme' to 'Current theme settings & options' or something. Yeah, I know, it's a bit too long...Quote (It's interesting that Opera is telling me 'unobvious' is not a valid word... I always thought it was. A dictionary gives me these antonyms for obvious: ambiguous, indefinite, obscure, unclear, vague. Hmm, that's very close to what we'd use in French -- ambigu, indéfini, obscur, flou/pas clair, vague.)
If they're actual theme settings, I understand they need to be together in one place, but if they're not logically theme settings per se, they should be elsewhere. At worst, we could add 'aliases/shortcuts' to the correct setting pages in a main page if needed.Quote It's inside the info center... Especially now that InfoCenter is its own template, I don't see how/why themes should delete the option. Additionally -- it's up to the theme to decide what to do. For instance, if I had an admin setting to choose the default sidebar position (left/right), I'd expect the theme to either follow it, or just don't show a sidebar on the left or right (e.g. show it at the bottom). It's a bad example but I hope you get my point...Quote I don't know... :-/
I suppose you're right in that sense. Like, people might want to sort membergroups by color brightness... :lol:Quote I hope you used a walkthrough for that :P It's easier to get below 3 hours that way.
Don't have Steam though... I only have MI2 on my iPod and I don't think it has achievement lists :P Arrr... How appropriate anyway, I play like a cow!Quote Yeah, pretty much... Over 60 times. And the cache would be updated even if 'id_group/additional_groups' isn't updated, which isn't too great IMNSHO.Quote Sure. Do you want me to get started on it maybe...? Or would you rather do it? It's not exciting work :P
Heck, technically I thought you were planning to have a minified version of the file... (Maybe we could move Class-SFTP.php to the wip folder, and include the minified version in Sources. No one has to know about the problems it had :P)Quote Sure, but I'd rather know why SMF/Wedge is using \n when it could be using br in most places :PQuote I'd rather not have ';xml' on any URL that is likely to be reused by someone, reposted on a forum, etc. We can just add a special || action == 'feed' anyway ;)
Found the origin of the bug. Comment out the $current_action = 'moderate' line in Subs.php and it doesn't generate the error anymore... I think it's related to how I moved the moderation center to within the admin menu. Didn't look any further.
Posted: October 19th, 2011, 09:43 AM
I'm seeing FOUS effects in the admin area when dealing with the error log... Hadn't seen these in a while. Dunno if it's due to some bug in the new Opera. Can you tell me if you've seen any of these in Chrome?
It's to make it easier for themes to add options, that are under admin control. There's no way for themes to add user options AFAIK without replacing some/all of the profile template.
Fading delay between items for the news fader: NEWS area
Number of recent posts to display on board index: possibly elsewhere. That's in the info center right..? See below.
Show statistics on board index: --> I don't believe themes would modify the info center so much that this would kill layout...
Show latest member on board index: ditto (might be removed entirely)
Show group key on board index: ditto (should be removed as an option, and always shown.)
"Show who is viewing" --> this is an important feature, it should be enabled by default at the very least... (And the English description is confusing, too.)
Show last modification date on modified posts: if themes don't provide a field for that, then it just won't be shown... Otherwise, they'll provide for it, and make sure it's usable. This is definitely an option for POST settings.
Show view profile button under post: POST settings.
Show user avatars in message view: POST settings or AVATAR settings.
Show personal text in message view: POST settings.
Show gender images in message view: POST settings.
Hide post group titles for grouped members: POST settings or MEMBERGROUP settings.
Enable collapsible additional post options: general, post settings or something...
My conclusion: theme settings should only *contain settings that related to the theme itself (e.g. something like, "show the info center in the sidebar/main area"), not settings related to features that are built into Wedge* (e.g. personal_text has a field in the members table, so all themes are expected to be able to deal with it.)
What do you think...? As an added bonus, we get to have the options made searchable... This is all because yesterday I wasted 5 minutes trying to enable 'show group key' and the admin search refused to point me to it...
We should also rename 'Current Theme' to 'Current theme settings & options' or something. Yeah, I know, it's a bit too long...
Admin > Current Theme makes some modicum of sense, but not a lot - though it's a world better than how unobvious theme settings are to find normally.
If they're actual theme settings, I understand they need to be together in one place, but if they're not logically theme settings per se, they should be elsewhere. At worst, we could add 'aliases/shortcuts' to the correct setting pages in a main page if needed.
It's a theme option because not all themes provide it.
Seriously tempted to move that back out into being a plugin anyway because partly not all themes provide it and partly because so many people want it 'ordered how they want, not just alphabetic', and I think it would be a stretch too far to make core with that in mind. It's not like it's tough to expand any more or anything.
I suppose you're right in that sense. Like, people might want to sort membergroups by color brightness... :lol:
Nice. I spent the rest of my evening trying to score the one remaining achievement I had for Monkey Island II on Steam (complete the game in under 3 hours, just finished with 30 mins to spare), so I haven't looked at the commit yet.
Don't have Steam though... I only have MI2 on my iPod and I don't think it has achievement lists :P Arrr... How appropriate anyway, I play like a cow!
Is there really a lot of places that call updateMemberData?Quote Uncaching on updateMemberData() means doing it on many, many user actions... Might as well not cache anything
I'll update it if it becomes necessary but given how there haven't been updates for a while and it's one of those things that generally 'just works', it should be OK to fix up now.
Heck, technically I thought you were planning to have a minified version of the file... (Maybe we could move Class-SFTP.php to the wip folder, and include the minified version in Sources. No one has to know about the problems it had :P)
Hmm, we should probably test that. It's likely I'm worrying about nothing but I'd rather that and be proven wrong than to be bitten by it later.
Testing for $_GET['xml'] is good but it doesn't automagically do that for the feeds IIRC. But if we had the feeds set that too (if they don't already), then it's a no-brainer.Quote In that case, hmmm... How do we do that? Just a simple if (isset($_GET['xml'])) will do...?
143
Features / Bot logging
« on October 16th, 2011, 12:42 AM »
Hey guys.
Do you think it's all right to have smf take bots into account when calculating most online and similar stats?
I think it's unfair to take them into account. And misleading. But I fear that smf users switching to wedge would think that they lost all their visitors overnight and switch back :P
Do you think it's all right to have smf take bots into account when calculating most online and similar stats?
I think it's unfair to take them into account. And misleading. But I fear that smf users switching to wedge would think that they lost all their visitors overnight and switch back :P
144
Features / Template skeleton!
« on September 6th, 2011, 12:08 PM »
I'd like a few opinions on the sidebar thingy... I'm posting in the public topic willingly, BTW.
Here's a small screenshot of the Warm skin. I've modified it to put the sidebar on the left of the *page*, as opposed to the left of the *content area* (i.e. surrounded by footer, header and nav.)
I just figured that forcing a sidebar onto users wasn't too big a deal (as it helps separate the main content from the asides, really, that's what it's all about), but forcing a sidebar layout onto themers wasn't as cool. It's not too hard to force the sidebar to show on the *right*, but then I thought, what if the themer wants a layout where the sidebar is outside of the header area? I think it's doable but it's hard. And most likely will require creating a new theme just for that aspect. Themes are harder to maintain than skins, so I tried to figure out a solution and it struck me that the layer system is either too simple, or too complicated.
The current layer structure makes the order of calling templates functions as such:
- template_html_above
- template_body_above
- template_header
- template_menu
- template_linktree
- template_sidebar_above
- "sidebar" sub-templates
- template_sidebar_below
- template_main_above
- "top" sub-templates
- "main" sub-templates (i.e. main content)
- template_main_below
- template_footer
- template_body_below
- template_html_below
In order to have the sidebar shown next to the rest of the page, I'd have to move the sidebar layer out of this loop. Although I'm not too scared at the idea of 'hacking' into the system for the good cause, I'm just wondering if there isn't a smooth way to do it.
Could we consider doing something like a 'skeleton' for the template functions...?
For instance, a $context['skeleton'] array of arrays, that pretty much holds the template structure. We already have similar things with the $context['sub_template'] variable, but it only holds the main content area structure.
I added a skin variable called <sidebar> and a theme variable called $settings['sidebar_position'], they both do the same thing: tell Wedge whether the skin wants the sidebar to be outside the flow, or next to the content. By default it's next to the content. So, right now, in template_body_above(), I just have two occurrences of this:
Code: [Select]
(The other being 'left_content', of course, and positioned in the correct place. And template_sidebar is a function defined in Subs.php that basically calls sidebar_above, the sidebar sub-templates, and sidebar_below.)
Although it works, I can't help feeling this is 'wrong'. Plus, it will force the skin to redefine the 'sidebar' and 'content' blocks, because in the default skin, they're linked together. Not a big deal of course, but what I probably don't like here, is that a themer can't simply switch between two sidebar positions through a single variable being set -- they'll also need to redefine the actual HTML content to match it... Not only that, but I'm not even sure it's not going to break stuff. I have the sidebar + content stuck inside an 'edge' div that serves as display:table and is also used by the onresize sidebar toggler. If I remove it, the toggler will stop working, but the 'edge' div is closed at the end of the 'content' block... And there's no 'block' for the entire page that shows on the right of the sidebar when in left_page mode. Meaning, the 'edge' div never gets closed properly just by redefining the blocks.
I can't really think of a way to get out of this loop of complicated crap. And I definitely don't want to live another week like last week, where a simple remark ("allow embedding in sentences doesn't work") led into a nightmare with a complete overhaul of the auto-embedding code. In the end I'm happy with it (the feature finally works as expected and the actual logic of the embedding process is a bit better), but... I'm just not ready to jump straight back into another nightmare, see.
Update -- I thought it didn't validate, but it does. The magic of nesting sort of fixed itself actually: the edge div closer is still in the same place (after the main content block), but this time it's seen as a closer for the wedge id, not edge. It should be totally broken because the wedge div is not even behaving like a table cell, but... bah. I guess these can be fixed in Warm/index.css anyway.
Still, I don't like hacks... :^^;:
I could actually allow skin.xml files to hold PHP code -- such as a template_body_above_override() function allowing for new sidebar layouts -- but it also mean eval. And, uhh... Let's just say I'd rather do without evals.
Lol... A modified sidebar location will freeze IE9 (100% CPU). But not IE7 or IE8, mind you! :lol:
Nice bug. Sasuga Maikurosofuto da na...
Here's a small screenshot of the Warm skin. I've modified it to put the sidebar on the left of the *page*, as opposed to the left of the *content area* (i.e. surrounded by footer, header and nav.)
I just figured that forcing a sidebar onto users wasn't too big a deal (as it helps separate the main content from the asides, really, that's what it's all about), but forcing a sidebar layout onto themers wasn't as cool. It's not too hard to force the sidebar to show on the *right*, but then I thought, what if the themer wants a layout where the sidebar is outside of the header area? I think it's doable but it's hard. And most likely will require creating a new theme just for that aspect. Themes are harder to maintain than skins, so I tried to figure out a solution and it struck me that the layer system is either too simple, or too complicated.
The current layer structure makes the order of calling templates functions as such:
- template_html_above
- template_body_above
- template_header
- template_menu
- template_linktree
- template_sidebar_above
- "sidebar" sub-templates
- template_sidebar_below
- template_main_above
- "top" sub-templates
- "main" sub-templates (i.e. main content)
- template_main_below
- template_footer
- template_body_below
- template_html_below
In order to have the sidebar shown next to the rest of the page, I'd have to move the sidebar layer out of this loop. Although I'm not too scared at the idea of 'hacking' into the system for the good cause, I'm just wondering if there isn't a smooth way to do it.
Could we consider doing something like a 'skeleton' for the template functions...?
For instance, a $context['skeleton'] array of arrays, that pretty much holds the template structure. We already have similar things with the $context['sub_template'] variable, but it only holds the main content area structure.
I added a skin variable called <sidebar> and a theme variable called $settings['sidebar_position'], they both do the same thing: tell Wedge whether the skin wants the sidebar to be outside the flow, or next to the content. By default it's next to the content. So, right now, in template_body_above(), I just have two occurrences of this:
if ($settings['sidebar_position'] === 'left_page')
template_sidebar();(The other being 'left_content', of course, and positioned in the correct place. And template_sidebar is a function defined in Subs.php that basically calls sidebar_above, the sidebar sub-templates, and sidebar_below.)
Although it works, I can't help feeling this is 'wrong'. Plus, it will force the skin to redefine the 'sidebar' and 'content' blocks, because in the default skin, they're linked together. Not a big deal of course, but what I probably don't like here, is that a themer can't simply switch between two sidebar positions through a single variable being set -- they'll also need to redefine the actual HTML content to match it... Not only that, but I'm not even sure it's not going to break stuff. I have the sidebar + content stuck inside an 'edge' div that serves as display:table and is also used by the onresize sidebar toggler. If I remove it, the toggler will stop working, but the 'edge' div is closed at the end of the 'content' block... And there's no 'block' for the entire page that shows on the right of the sidebar when in left_page mode. Meaning, the 'edge' div never gets closed properly just by redefining the blocks.
I can't really think of a way to get out of this loop of complicated crap. And I definitely don't want to live another week like last week, where a simple remark ("allow embedding in sentences doesn't work") led into a nightmare with a complete overhaul of the auto-embedding code. In the end I'm happy with it (the feature finally works as expected and the actual logic of the embedding process is a bit better), but... I'm just not ready to jump straight back into another nightmare, see.
Posted: September 6th, 2011, 11:15 AM
Update -- I thought it didn't validate, but it does. The magic of nesting sort of fixed itself actually: the edge div closer is still in the same place (after the main content block), but this time it's seen as a closer for the wedge id, not edge. It should be totally broken because the wedge div is not even behaving like a table cell, but... bah. I guess these can be fixed in Warm/index.css anyway.
Still, I don't like hacks... :^^;:
I could actually allow skin.xml files to hold PHP code -- such as a template_body_above_override() function allowing for new sidebar layouts -- but it also mean eval. And, uhh... Let's just say I'd rather do without evals.
Posted: September 6th, 2011, 11:45 AM
Lol... A modified sidebar location will freeze IE9 (100% CPU). But not IE7 or IE8, mind you! :lol:
Nice bug. Sasuga Maikurosofuto da na...
145
Development blog / Anniwersary
« on August 25th, 2011, 08:48 AM »
A year ago, on August 25, 2010, the first commit to the Wedge SVN server was made. I was hoping to get to rev 1000 before the first anniversary, but I tend to commit small bug fixes in a large batch so we 'only' reached the 965 commit milestone.
Well, a year later, what can be said of the project...? It already had a name back then, it still has the same. It had goals and a vision, it still does. Some adjustments were made to our schedule (personally, I decided to give up on a lot of the Noisen.com improvements I was planning to integrate, and will rewrite them later), and other things were pushed into the codebase as we went -- the product of being mainly fueled by passion, instead of money. I know, I know, it's a classic, but it's just the plain truth -- you can't work full time on an unpaid project for a year without some kind of solid passion and commitment. Back when we started the project, I wasn't 100% sure Pete would remain interested in the project in the long run. I was totally wrong, so I'd like to take the opportunity to give a big thumb up to him for being one of the driving forces (the other being me, but I may not say :P) behind the Wedge project, a shining beacon of courage and determination, a herdsman for the nerds, a vanquisher of spaghetti code and... What, I fully expect him to give me the same treatment in return! :niark:
(Oh, and in other news, apparently I'm back in the 'Friends' group at SM.org. Can anyone tell me when this kind of thing happens? :P)
What better way to celebrate the first anniversary than to release a public alpha version! Yes!
Okay, I'm playing with your nerves... There is nothing (yet), but it won't be too long now. As the commit process is now a public one, you've all seen we're still as busy as ever to fix bugs and add new features. I can't honestly see myself release Wedge without having first integrated Aeva into the avatar and attachment system, and I can't work on that before I can fully focus on it. And this month has been doing a very good work at distracting me: Nightwish's fork (interesting ideas, it's definitely going to be the worthiest competitor to Wedge if Nightwish can keep up for another year :D), playing a little gem of a game played Xenoblade (okay, so I passed on other RPGs and JRPGs these last few months because they're time eaters, but the guy made one of my all-time top 3 games so I have to play his titles, even if unrelated to Xenogears), and more generally a personal burnout and declining health (I'm not one to complain, though. These things happen in cycles.)
In short: I don't remember my original schedule, but right now my personal target is for a demo in early September, and an alpha in late September or October. I'm still kind of wary about releasing my code to a general audience. It's our baby you know... We want Harvard for it. Hopefully it'll spawn into Facebook. Or something else.
Well, a year later, what can be said of the project...? It already had a name back then, it still has the same. It had goals and a vision, it still does. Some adjustments were made to our schedule (personally, I decided to give up on a lot of the Noisen.com improvements I was planning to integrate, and will rewrite them later), and other things were pushed into the codebase as we went -- the product of being mainly fueled by passion, instead of money. I know, I know, it's a classic, but it's just the plain truth -- you can't work full time on an unpaid project for a year without some kind of solid passion and commitment. Back when we started the project, I wasn't 100% sure Pete would remain interested in the project in the long run. I was totally wrong, so I'd like to take the opportunity to give a big thumb up to him for being one of the driving forces (the other being me, but I may not say :P) behind the Wedge project, a shining beacon of courage and determination, a herdsman for the nerds, a vanquisher of spaghetti code and... What, I fully expect him to give me the same treatment in return! :niark:
(Oh, and in other news, apparently I'm back in the 'Friends' group at SM.org. Can anyone tell me when this kind of thing happens? :P)
What better way to celebrate the first anniversary than to release a public alpha version! Yes!
Okay, I'm playing with your nerves... There is nothing (yet), but it won't be too long now. As the commit process is now a public one, you've all seen we're still as busy as ever to fix bugs and add new features. I can't honestly see myself release Wedge without having first integrated Aeva into the avatar and attachment system, and I can't work on that before I can fully focus on it. And this month has been doing a very good work at distracting me: Nightwish's fork (interesting ideas, it's definitely going to be the worthiest competitor to Wedge if Nightwish can keep up for another year :D), playing a little gem of a game played Xenoblade (okay, so I passed on other RPGs and JRPGs these last few months because they're time eaters, but the guy made one of my all-time top 3 games so I have to play his titles, even if unrelated to Xenogears), and more generally a personal burnout and declining health (I'm not one to complain, though. These things happen in cycles.)
In short: I don't remember my original schedule, but right now my personal target is for a demo in early September, and an alpha in late September or October. I'm still kind of wary about releasing my code to a general audience. It's our baby you know... We want Harvard for it. Hopefully it'll spawn into Facebook. Or something else.
146
Features / These two bytes may not matter to you...
« on August 5th, 2011, 12:31 PM »
(I decided I'd make this into a general purpose topic about my stupid micro-optimizations :P)
I had a look at addLoadEvent() in Wedge, and I can confirm that none of the calls use a string format at all. Heck -- it's actually used only 3 times in the entire codebase by now: to resize avatars on the fly, to resize images when clicking them, and to fix the code box sizes in FF, WebKit and IE. This last one I don't think even deserves being called through .load() but simply directly... Heck, I don't even know if the bug is still a valid one!
Thus, it even seems a bit odd to be using it when we could simply call $(window).load, although it's two bytes longer, but well, it also saves a function alias and declaring the function to begin with in script.js :P
Of course there's the possibility of modders calling addLoadEvent themselves, but... err... Since we're not compatible anymore... Maybe it'd be time for them to determine whether they want to use add_js() or DOMContentReady instead (i.e. anything that doesn't require images to finish loading...)
What do you think?
I had a look at addLoadEvent() in Wedge, and I can confirm that none of the calls use a string format at all. Heck -- it's actually used only 3 times in the entire codebase by now: to resize avatars on the fly, to resize images when clicking them, and to fix the code box sizes in FF, WebKit and IE. This last one I don't think even deserves being called through .load() but simply directly... Heck, I don't even know if the bug is still a valid one!
Thus, it even seems a bit odd to be using it when we could simply call $(window).load, although it's two bytes longer, but well, it also saves a function alias and declaring the function to begin with in script.js :P
Of course there's the possibility of modders calling addLoadEvent themselves, but... err... Since we're not compatible anymore... Maybe it'd be time for them to determine whether they want to use add_js() or DOMContentReady instead (i.e. anything that doesn't require images to finish loading...)
What do you think?
147
Features / Calendar dates
« on August 5th, 2011, 12:26 PM »
As I mentioned in another post (in the team boards), I think it'd be nice to be able to translate holidays into other languages.
Most of these holidays are English-centric though -- e.g. St Patrick's Day? I think 95% of the planet doesn't have a clue what it's about... I think it's Irish or something. It's all I know. I would tend to either delete this one (and maybe a few others like Halloween), or add more. Why does the database have the national days for the US and Mexico, but not other countries? It always seemed to me like it was an unfinished feature...
We could these dates out of the default package, and offer add-ons that will simply insert dates in the database. We could then have a US date database, a French one, a Zimbabwean one, etc...
Or maybe we could add a field to the dates, specifying which country/culture should be able to see a date.
Opinions welcome on these matters!
Most of these holidays are English-centric though -- e.g. St Patrick's Day? I think 95% of the planet doesn't have a clue what it's about... I think it's Irish or something. It's all I know. I would tend to either delete this one (and maybe a few others like Halloween), or add more. Why does the database have the national days for the US and Mexico, but not other countries? It always seemed to me like it was an unfinished feature...
We could these dates out of the default package, and offer add-ons that will simply insert dates in the database. We could then have a US date database, a French one, a Zimbabwean one, etc...
Or maybe we could add a field to the dates, specifying which country/culture should be able to see a date.
Opinions welcome on these matters!
148
Development blog / A nice kick in the CSS
« on August 3rd, 2011, 10:14 PM »
Tonight's a special night to me. I installed another copy of Wedge on the server, and I finally ran TE's import tool on Wedge.org. I just... wanted to see if it would work. And it does!
It's not perfect, has bugs here and there, doesn't import attachments and avatars yet, but you have absolutely no idea how wonderful it was for me to find myself face to face with a fully converted SMF forum running Wedge. The dream has finally come true!
And it looks gorgeous. There's no better way to test a design than to insert real data into it. I'm really happy with it now. I wasn't sure -- now I am. Party on! (Oh, and we're trying new Wedge logos, if you didn't notice. It's not final yet, but you can follow the process in the Logo Madness topic. Everything's public. Because that's how we do things at Wedge.)
It's not perfect, has bugs here and there, doesn't import attachments and avatars yet, but you have absolutely no idea how wonderful it was for me to find myself face to face with a fully converted SMF forum running Wedge. The dream has finally come true!
 |
 |
And it looks gorgeous. There's no better way to test a design than to insert real data into it. I'm really happy with it now. I wasn't sure -- now I am. Party on! (Oh, and we're trying new Wedge logos, if you didn't notice. It's not final yet, but you can follow the process in the Logo Madness topic. Everything's public. Because that's how we do things at Wedge.)
149
Development blog / Would you rather have free speech or a free beer?
« on July 28th, 2011, 01:45 PM »
I don't know about you but I don't like beer, so I'd choose a free coke instead. Can't I?
Oh yeah, what's this post about already? I read something over here. At one point, one of the members says that he's not interested in Wedge because it's not free. When asked why he thought that, he mentioned the sidebar slogan:
Performance! Features! Reasonably priced coolness! And a hard-boiled egg!
I felt a bit stupid when reading that. I know that my sense of humor is mostly harmless™, but this is a case where it might be. See, when it comes to jokes I'm a big fan of British nonsense (something I share with Pete), and I tend to quote them a lot. And it just happened that I recently read a book by Sir Terry Pratchett, Night Watch, in which people were looking for a motto for their newly founded republic, and they chose that: "Truth! Justice! Reasonably priced love! And a hard-boiled egg!"
I simply re-used that in my slogan collection. The script will randomly pick one of ten silly quotes, and this was one of them. I found that 'reasonably priced' was a funny metaphor for Wedge -- you get it for free, so it's a reasonable deal. Of course, it only works if you already know that Wedge is free. Uh.
So, I just replaced that line with another British nonsense example free to any price indications. Anyway, the good news is: at least someone reads these slogans. <sigh of relief>
If my little story needs a conclusion, which is probably the case at this point, it is this: don't forget that Wedge is free, and will remain so. It's not that we don't like, or need, money. We just never built Wedge for money. We built Wedge to be what SMF should have been at this point. We didn't want money in the first place, and we still don't. We're doing it for ourselves. We pay the price for everyone else, so that you can spend the money on Pratchett books instead. Just enjoy the thing, you silly lawn ornaments™!
Oh yeah, what's this post about already? I read something over here. At one point, one of the members says that he's not interested in Wedge because it's not free. When asked why he thought that, he mentioned the sidebar slogan:
Performance! Features! Reasonably priced coolness! And a hard-boiled egg!
I felt a bit stupid when reading that. I know that my sense of humor is mostly harmless™, but this is a case where it might be. See, when it comes to jokes I'm a big fan of British nonsense (something I share with Pete), and I tend to quote them a lot. And it just happened that I recently read a book by Sir Terry Pratchett, Night Watch, in which people were looking for a motto for their newly founded republic, and they chose that: "Truth! Justice! Reasonably priced love! And a hard-boiled egg!"
I simply re-used that in my slogan collection. The script will randomly pick one of ten silly quotes, and this was one of them. I found that 'reasonably priced' was a funny metaphor for Wedge -- you get it for free, so it's a reasonable deal. Of course, it only works if you already know that Wedge is free. Uh.
So, I just replaced that line with another British nonsense example free to any price indications. Anyway, the good news is: at least someone reads these slogans. <sigh of relief>
If my little story needs a conclusion, which is probably the case at this point, it is this: don't forget that Wedge is free, and will remain so. It's not that we don't like, or need, money. We just never built Wedge for money. We built Wedge to be what SMF should have been at this point. We didn't want money in the first place, and we still don't. We're doing it for ourselves. We pay the price for everyone else, so that you can spend the money on Pratchett books instead. Just enjoy the thing, you silly lawn ornaments™!
150
Development blog / Changelog? You mean, like Odo in DS9?
« on July 28th, 2011, 12:48 PM »
A short but sweet one.
This was something I'd been eager to do. Now it's there. The changelog is public at last, and you can follow ournew bu progress in real time.
For more details, please read the first post in the topic!
http://wedge.org/pub/feats/6108/new-revs/
This was something I'd been eager to do. Now it's there. The changelog is public at last, and you can follow our
For more details, please read the first post in the topic!
http://wedge.org/pub/feats/6108/new-revs/