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
91
The Pub / Wedge private alpha is OUT!
« on November 1st, 2012, 09:37 AM »
Guys, you probably missed it, but I released Wedge ten minutes ago.... :lol:
It's in the Media area... :whistle:
It's in the Media area... :whistle:
92
The Pub / Looking for volunteers to test the Wedge private alpha!
« on October 22nd, 2012, 05:27 PM »
I think it's worthy of a public topic...
We're looking for hot young ladies to test our software, and possibly our hardware later on.
If you're a fat old man, you're welcome too, but you won't get a chance to sample the hardware though. At least not mine :ph34r:
So, here's what you have to do if you're interested...
Prerequisites
- You MUST be well versed into the SMF software itself. If you're new to SMF, or have relatively little experience with it, you're probably better off testing SMF some more, at least until we get the software ready for prime time.
- You MUST be well versed into forum administration, that goes without saying. You must have a good understanding of the SMF admin area, and be prepared to see the many changes it holds, and determine whether they feel more logical to you -- or not.
- You SHOULD have good MySQL experience in general.
- You MUST have good MySQL and diff patch experience if you're planning to install the alpha on a 'live' website. The reason is that, let me be clear on this, we will NOT release any SQL patches for further updates. We will do so when Wedge is gold, but not before, because it's a pain in the ass. So, if we're releasing an update to the alpha that changes the database structure, you should be able to:
(a) make a diff between of the install.sql script you used when you installed, and the updated install.sql file,
(b) spot the differences between the two,
(c) launch phpMyAdmin or whatever, and apply these changes MANUALLY.
- You MUST be ready to install all new updates as they come out (or at least in a timely manner). There's no point in testing software if the bugs you find were already fixed... Basically, if you find a bug, make sure you're using the latest version before you report it.
- You SHOULD be participating in the forums already. If you only have a couple of posts, you're less likely to be granted private alpha access. Not that you shouldn't try to get access, but I'm just saying -- it's a private alpha, so we're not interested in spreading the Wedge codebase immediately.
How to apply
Post a reply to this topic, with this information:
1 - How long have you been a SMF user? (Approximately...)
2 - If you're planning to use Wedge on a live forum, post its URL.
3 - How much daily time you think you can devote to testing Wedge. (If you're planning to use it on a live forum, you can also rely on your users to help test it.) Please keep in mind that we'd like to keep the private alpha period relatively short (no more than a couple of weeks would be ideal), so I'm really asking about the next couple of weeks mainly. (Well, at least the first couple of weeks after the initial release.)
4 - Is there a feature in Wedge that you're most interested in? Something you'll focus your testing on, etc... Or just something you're just excited to use!
5 - If you're a hot young lady, post a picture of you, preferably on a boat (in front of a boat is also acceptable), or in an administration building's waiting line. Extra points if you're wearing a Fez on your left hand. Fezzes are cool.
That should be all...
(Oh, and don't bother with (5)... My girlfriend would hate to see a picture of a waiting line. Bad memories.)
We're looking for hot young ladies to test our software, and possibly our hardware later on.
If you're a fat old man, you're welcome too, but you won't get a chance to sample the hardware though. At least not mine :ph34r:
So, here's what you have to do if you're interested...
Prerequisites
- You MUST be well versed into the SMF software itself. If you're new to SMF, or have relatively little experience with it, you're probably better off testing SMF some more, at least until we get the software ready for prime time.
- You MUST be well versed into forum administration, that goes without saying. You must have a good understanding of the SMF admin area, and be prepared to see the many changes it holds, and determine whether they feel more logical to you -- or not.
- You SHOULD have good MySQL experience in general.
- You MUST have good MySQL and diff patch experience if you're planning to install the alpha on a 'live' website. The reason is that, let me be clear on this, we will NOT release any SQL patches for further updates. We will do so when Wedge is gold, but not before, because it's a pain in the ass. So, if we're releasing an update to the alpha that changes the database structure, you should be able to:
(a) make a diff between of the install.sql script you used when you installed, and the updated install.sql file,
(b) spot the differences between the two,
(c) launch phpMyAdmin or whatever, and apply these changes MANUALLY.
- You MUST be ready to install all new updates as they come out (or at least in a timely manner). There's no point in testing software if the bugs you find were already fixed... Basically, if you find a bug, make sure you're using the latest version before you report it.
- You SHOULD be participating in the forums already. If you only have a couple of posts, you're less likely to be granted private alpha access. Not that you shouldn't try to get access, but I'm just saying -- it's a private alpha, so we're not interested in spreading the Wedge codebase immediately.
How to apply
Post a reply to this topic, with this information:
1 - How long have you been a SMF user? (Approximately...)
2 - If you're planning to use Wedge on a live forum, post its URL.
3 - How much daily time you think you can devote to testing Wedge. (If you're planning to use it on a live forum, you can also rely on your users to help test it.) Please keep in mind that we'd like to keep the private alpha period relatively short (no more than a couple of weeks would be ideal), so I'm really asking about the next couple of weeks mainly. (Well, at least the first couple of weeks after the initial release.)
4 - Is there a feature in Wedge that you're most interested in? Something you'll focus your testing on, etc... Or just something you're just excited to use!
5 - If you're a hot young lady, post a picture of you, preferably on a boat (in front of a boat is also acceptable), or in an administration building's waiting line. Extra points if you're wearing a Fez on your left hand. Fezzes are cool.
That should be all...
(Oh, and don't bother with (5)... My girlfriend would hate to see a picture of a waiting line. Bad memories.)
93
Features / Sidebar emulation method in IE6/7
« on September 19th, 2012, 02:48 PM »
These days I've been going through the skin files and trying to simplify some stuff. To little avail, though... It's still kind of messy.
Still, I've been thinking about the sidebar system (cf. my talk with Emanuele), and was reminded of two things:
- the macro system is really powerful and great,
- it's totally going to confuse themers.
Well, to be honest with my greatness, it's not that hard to understand: <we:sidebar> holds the sidebar code, <we:offside> has the main content, etc... And 'sidebar' is defined in the index template, as well as in <skeleton> tags in sub-skins. So far, so good.
Now, I've always considered Weaving to be a skin that really, really should require as little 'hacking' as possible.
In Wedge, by default, the sidebar has two different codebases:
- IE6/IE7 use a table-based layout (<table> tags)
- Other browsers use table emulation (<div> tags with display:table on them)
It's okay because it explains how flexible the system is.
Now, if we delve into sub-skins, the skeleton is modified. When it comes to Warm, it's okay that it's modified because the sidebar position really is quite removed from the original layout. It's a great example of what you can do with careful planning.
But in Wine, the skeleton is modified so that the sidebar can be shown on the LEFT of the screen instead of the right. It's just an example, of course -- but it's still completely silly to change the HTML for what can be done in CSS.
Well, in my defense, back then I didn't know that table cells could be swapped with CSS. I learned about that some time ago, that you just need to apply 'direction: rtl' to the parent display: table, and 'direction: ltr' to its children. And it works perfectly. Despite it being a 'dirty hack', it's still extremely simple to apply and even to understand -- and it has the added benefit of leaving the sidebar contents where it belongs, i.e. at the end of the HTML source. (Heck, I'm even considering pushing the menu into a display:table of its own, and using display:table-header-group to move it to the top regardless of its position in the source...)
Okay, so far so good. I'm definitely doing that. I only need to redefine the skeleton once (in Warm), and Wine is left alone. Consider it an 'announcement' of a change I'll commit soon. What matters right now is IE 6/7.
Now, when it comes to them, doing table-based layout is cooler in my opinion, but a more realistic way of handling them would be to instead use the negative margin hack to show the sidebar correctly. i.e., by putting a negative right margin on the main contents and a positive right margin that compensates for it right in the first nested div, I can easily put a right-floated sidebar on the right. It's a proven method, and has no drawbacks -- except that it's not a proper 'column' that shows up, instead just a floated sidebar, meaning that if you set a background color on the sidebar, it only extends as far as the sidebar contents will extends, rather than filling the entire sidebar.
It's a well known problem.
It can also be fixed by using faux columns or other alternative tweaks for IE that are also well documented. But it just adds to the bloat and limits extensibility.
So... Here's my question, basically (and as TL:DR).
When it comes to IE6/IE7 compatibility, what would you prefer to have by default in the skins provided in Wedge?
1/ What exists right now, i.e. the <div>s are replaced on-the-fly to simple <table> tags for IE6/7 only?
2/ A simple CSS float hack that positions the sidebar <div> correctly but doesn't extend the sidebar to the full height?
3/ A complicated CSS hack that positions the sidebar <div> correctly and extends the sidebar just like (1) would do?
4/ Like (3), but applied to all browsers, instead of using the more logical 'display: table' setting? (<-- don't bother, that one's just troll bait :P)
As a reminder - none of these change anything for non-IE browsers. They will *always* use <div> tags. Also, I'm still considering the possibility of allowing for the sidebar to be removed (possibly to be replaced by a single-line fallback for mini-links like the time of day and Unread posts/replies.)
So... Please start discussing :)
Still, I've been thinking about the sidebar system (cf. my talk with Emanuele), and was reminded of two things:
- the macro system is really powerful and great,
- it's totally going to confuse themers.
Well, to be honest with my greatness, it's not that hard to understand: <we:sidebar> holds the sidebar code, <we:offside> has the main content, etc... And 'sidebar' is defined in the index template, as well as in <skeleton> tags in sub-skins. So far, so good.
Now, I've always considered Weaving to be a skin that really, really should require as little 'hacking' as possible.
In Wedge, by default, the sidebar has two different codebases:
- IE6/IE7 use a table-based layout (<table> tags)
- Other browsers use table emulation (<div> tags with display:table on them)
It's okay because it explains how flexible the system is.
Now, if we delve into sub-skins, the skeleton is modified. When it comes to Warm, it's okay that it's modified because the sidebar position really is quite removed from the original layout. It's a great example of what you can do with careful planning.
But in Wine, the skeleton is modified so that the sidebar can be shown on the LEFT of the screen instead of the right. It's just an example, of course -- but it's still completely silly to change the HTML for what can be done in CSS.
Well, in my defense, back then I didn't know that table cells could be swapped with CSS. I learned about that some time ago, that you just need to apply 'direction: rtl' to the parent display: table, and 'direction: ltr' to its children. And it works perfectly. Despite it being a 'dirty hack', it's still extremely simple to apply and even to understand -- and it has the added benefit of leaving the sidebar contents where it belongs, i.e. at the end of the HTML source. (Heck, I'm even considering pushing the menu into a display:table of its own, and using display:table-header-group to move it to the top regardless of its position in the source...)
Okay, so far so good. I'm definitely doing that. I only need to redefine the skeleton once (in Warm), and Wine is left alone. Consider it an 'announcement' of a change I'll commit soon. What matters right now is IE 6/7.
Now, when it comes to them, doing table-based layout is cooler in my opinion, but a more realistic way of handling them would be to instead use the negative margin hack to show the sidebar correctly. i.e., by putting a negative right margin on the main contents and a positive right margin that compensates for it right in the first nested div, I can easily put a right-floated sidebar on the right. It's a proven method, and has no drawbacks -- except that it's not a proper 'column' that shows up, instead just a floated sidebar, meaning that if you set a background color on the sidebar, it only extends as far as the sidebar contents will extends, rather than filling the entire sidebar.
It's a well known problem.
It can also be fixed by using faux columns or other alternative tweaks for IE that are also well documented. But it just adds to the bloat and limits extensibility.
So... Here's my question, basically (and as TL:DR).
When it comes to IE6/IE7 compatibility, what would you prefer to have by default in the skins provided in Wedge?
1/ What exists right now, i.e. the <div>s are replaced on-the-fly to simple <table> tags for IE6/7 only?
2/ A simple CSS float hack that positions the sidebar <div> correctly but doesn't extend the sidebar to the full height?
3/ A complicated CSS hack that positions the sidebar <div> correctly and extends the sidebar just like (1) would do?
4/ Like (3), but applied to all browsers, instead of using the more logical 'display: table' setting? (<-- don't bother, that one's just troll bait :P)
As a reminder - none of these change anything for non-IE browsers. They will *always* use <div> tags. Also, I'm still considering the possibility of allowing for the sidebar to be removed (possibly to be replaced by a single-line fallback for mini-links like the time of day and Unread posts/replies.)
So... Please start discussing :)
94
Off-topic / Wedge fan sites? (Was: symfony vs zend)
« on September 12th, 2012, 11:03 AM »
Do tell us if we're bothering you... :whistle:
Inter, what's that site in your signature, wedge.su?! If anything, why didn't I hear about it until now? Why didn't you ask for authorization? What are your plans for this? Why use a TLD with a bad reputation?
Inter, what's that site in your signature, wedge.su?! If anything, why didn't I hear about it until now? Why didn't you ask for authorization? What are your plans for this? Why use a TLD with a bad reputation?
95
The Pub / Getting ready for an alpha release: WeCSS/Wess improvements
« on September 8th, 2012, 11:33 AM »
So... I slept on it, and it's even worse now :)
I think WeCSS is getting a bit 'old' by my standards, and I should remove some of the dust. And maybe rename it to 'Wess', which I've been considering for a while...
- First of all, because I support 'base:' and added the 'extends' keyword to make it more objecty, I think it's only fair that I add a 'mixes' keyword that would do the exact same thing as 'mixin:'.
- Additionally, maybe mixins should be defined the same way as bases, that is, as regular selectors... (Or, at least, to enable virtuals to be used as mixins). To get the regular mixin behavior, we'd just need to define them as virtuals. The good thing is that it would mean .inline-block can be used both as a base and a mixin. Can you hear "solves the media query problem" already? Yes I'm sure you can...
- I went to check out LESS and SASS (my main 'competition' if I may say), and LESS has done a lot of progress in a year (I should have kept up with their new stuff really...). They now both support mixin parameters, and it's indeed something that could happen to be useful in WeCSS as well. I'm just trying to figure out the proper way of writing it if I'm going to use selectors for mixin declarations... Something like:
Code: [Select]
- As seen just above, there's already an undocumented feature in WeCSS which I like a lot:
background-color: ifnull($custom_color, #fff)
Meaning, "if $custom_color is set, then set background-color to it, otherwise set it to #fff".
Okay, so should this remain like this? Or would it feel more natural to use @ifnull instead of ifnull?
- Same for conditionals...
Code: [Select]
Should these keywords use @? Should whatever follows if be between brackets? if(ie) or if (ie), like in JavaScript or PHP... But maybe skin authors aren't too versed into these languages, I don't know.
Should we use @endif, too, or would indenting be enough to say "it's the end of the argument list"...? (I haven't tested for now whether or not it can allow for nested selectors in such a situation...)
Should we allow for single-line if statements?
Code: [Select]
Code: [Select]
(In which case, an @endif would mean end of statement, while a missing @endif would mean the statement ends at the end of the line.... But again, maybe it's too complicated?)
Or maybe, similarly to ifnull/@ifnull...
Code: [Select]
Just a few ideas like that. May add some in the future... Would like opinions from everyone interested in CSS in general, thank you :)
I think WeCSS is getting a bit 'old' by my standards, and I should remove some of the dust. And maybe rename it to 'Wess', which I've been considering for a while...
- First of all, because I support 'base:' and added the 'extends' keyword to make it more objecty, I think it's only fair that I add a 'mixes' keyword that would do the exact same thing as 'mixin:'.
- Additionally, maybe mixins should be defined the same way as bases, that is, as regular selectors... (Or, at least, to enable virtuals to be used as mixins). To get the regular mixin behavior, we'd just need to define them as virtuals. The good thing is that it would mean .inline-block can be used both as a base and a mixin. Can you hear "solves the media query problem" already? Yes I'm sure you can...
- I went to check out LESS and SASS (my main 'competition' if I may say), and LESS has done a lot of progress in a year (I should have kept up with their new stuff really...). They now both support mixin parameters, and it's indeed something that could happen to be useful in WeCSS as well. I'm just trying to figure out the proper way of writing it if I'm going to use selectors for mixin declarations... Something like:
.my_mixin virtual params $col = #fff, $param2...
color: $col
box-shadow: ifnull($param2, none)- As seen just above, there's already an undocumented feature in WeCSS which I like a lot:
background-color: ifnull($custom_color, #fff)
Meaning, "if $custom_color is set, then set background-color to it, otherwise set it to #fff".
Okay, so should this remain like this? Or would it feel more natural to use @ifnull instead of ifnull?
- Same for conditionals...
.class
color: #fff
@if ie6, ie7, firefox[-3.7]
background: url(border)
@else
border-radius: 5px
font-size: 1emShould these keywords use @? Should whatever follows if be between brackets? if(ie) or if (ie), like in JavaScript or PHP... But maybe skin authors aren't too versed into these languages, I don't know.
Should we use @endif, too, or would indenting be enough to say "it's the end of the argument list"...? (I haven't tested for now whether or not it can allow for nested selectors in such a situation...)
Should we allow for single-line if statements?
.class
@if (ie[-8]) background-color: #fff @else background-color: rgba(255,255,255,.8).class
background-color: @if (ie[-8]) #fff @else rgba(255,255,255,.8)(In which case, an @endif would mean end of statement, while a missing @endif would mean the statement ends at the end of the line.... But again, maybe it's too complicated?)
Or maybe, similarly to ifnull/@ifnull...
.class
background-color: @if (ie[-8], #fff, rgba(255,255,255,.8))Just a few ideas like that. May add some in the future... Would like opinions from everyone interested in CSS in general, thank you :)
96
The Pub / Getting ready for an alpha release: CSS fixes
« on August 31st, 2012, 11:13 AM »
Been busy IRL blah blah blah, worked on a few things that I wanted to fix in my CSS. Not happy with the things I've had to give up for that... So I want your opinion, because all of this has been accumulating over the last couple of days, and last time I checked, I really wanted to commit everything I have before I'm ready for an alpha.
1/
Gradients in headers (Wine and children): for a long time, what I used was a very small PNG image, which allowed it to work in IE6+. Recently, I decided to replace gradient images with proper gradients, as IE6 doesn't deserve any non-essential goodies anyway. So I did that.
Then I realized that an issue with linear-gradient, is that to get the same effect as an image, you have to specify color stops in pixels, and then set an explicit background-size... It's a bit complicated, but I did it. (Unfortunately, it also meant that the resulting CSS was probably on par with the earlier one in terms of size :P)
Okay, so this morning, I was thinking... "What the hell?! I could simply be using an inset box-shadow to act as the inner gradient! And I get to set my pixel dimensions!"
And it works fantastic. Really. It's just a single line of code. It works in IE9+, and it's cleaner.
However... There's a catch.
The performance is excruciatingly slow when there are lots of these, e.g. alternating backgrounds in the error log or display page. Really. Under Opera 12.5, it runs fine, just a bit less responsive, but when you show a confirm box, you can see how long it takes to show up... Under Firefox 16, it's like night and day. Super fast with a gradient, HORRIBLY slow with a box-shadow.
That's really, really annoying because the results are much better in box-shadow mode!
So... What do you reckon I should do? Is there a way to fix performance? I'm talking about a test done on a Core i7 computer... :-/
2/
Another thing that always bothered me... Wedge using JavaScript to reposition the sidebar, instead of media queries. This was originally because I would 'switch' positions between two different elements, so that I could set a specific target for the sidebar inside the DOM, instead of using CSS tricks to reposition it. As time went by, I decided to save bandwidth in all HTML pages by applying a 'responsive' ID to the DOM's top instead, and I hacked into the CSS in a relatively clean way that I was satisfied with. Okay, so far so good...
Now, this morning I was looking at my code, and the first thing that came to mind was, "WTF?! I use #responsive to set specific media queries... Why not just use @media $responsive?". And this is exactly what I did...
So, $responsive is set to a max-width of 1000px for now, it's working okay. The main benefit here is that because it's done on the CSS level, there's absolutely zero FOUC effect when reloading a page. (There used to be a very, very short one when doing a F5 refresh.)
Plus, I think themers will be comfortable with that... As long as they know about responsive design, of course.
Now for the drawbacks...
- @media doesn't have a set precedence factor, so it doesn't change priorities in the code, unlike #responsive. This means that if you set a #responsive #sidebar to 'display: block' in index.css (or even in an hypothetical extra.css file in Weaving), and then set #sidebar to 'display: table' in a sub-skin's extra.css file, the resulting responsive page will have #sidebar set to display:block because #responsive has higher priority. But if you start replacing all of these with @media $responsive, the resulting responsive page has #sidebar set to display:table because it was filled in after the original media query. The (clean!) solution I'm using, is to take the original media query, copy it at the end of my extra.css file, and add a reset suffix to it. Yes, "@media $responsive reset" is all that's needed. This way, the original media query is removed, and the new one is set at the one, and it includes the original media query's rewrites. Yes, it isn't as bulletproof as direct inheritance because if Weaving is heavily modified you'll have to modify your sub-skin as well. But it's probably something that could also happen with #responsive, albeit with different issues.
- Perhaps an even worse one... Unfortunately, @media being a special construct, you can have a selector like ".myclass, #myid, @media all .anotherclass", ah ah. Well, Wedge doesn't even bother checking... It actually does build such a selector if you add an 'extends' keywords to .anotherclass in the media query. Which pretty much makes the css declaration fail. So, yes, it does mean that whenever you start declaring a media query, *you can't use any extends in it.* Bummer!
So, I'm seriously considering going back to the 'original', as flawed as it is.
3/
And finally... The menu arrows.
Currently, they're using a lightweight (150-byte) image with horizontal and vertical positions, as well as a hover version.
I decided that I wanted to associate the arrows with the text next to them -- so that you can set the text to any color and they'll follow the color. So I replaced the arrows with CSS right-floated 'content' set to '\a0\25bc' (IIRC), in a pseudo-class of course. It seems to work really fine. This also allowed me to remove a couple of CSS hacks I had for the arrows. Unfortunately, this technique also has its limitations... Apart from the fact that pseudo classes don't work in IE6 (fuck you IE), there's the fact that Firefox shows arrows using a largely different size compared to Opera (?!), and float issues in the different places where it's all used, e.g. menu arrows aren't floated the same way when they're in the top-level menu or inside the menu itself. Same with linktrees...
This one is more of a technical issue to me, as philosophically I think I'm really good with using CSS content rather than images.
Anyone got any experience with that...?
1/
Gradients in headers (Wine and children): for a long time, what I used was a very small PNG image, which allowed it to work in IE6+. Recently, I decided to replace gradient images with proper gradients, as IE6 doesn't deserve any non-essential goodies anyway. So I did that.
Then I realized that an issue with linear-gradient, is that to get the same effect as an image, you have to specify color stops in pixels, and then set an explicit background-size... It's a bit complicated, but I did it. (Unfortunately, it also meant that the resulting CSS was probably on par with the earlier one in terms of size :P)
Okay, so this morning, I was thinking... "What the hell?! I could simply be using an inset box-shadow to act as the inner gradient! And I get to set my pixel dimensions!"
And it works fantastic. Really. It's just a single line of code. It works in IE9+, and it's cleaner.
However... There's a catch.
The performance is excruciatingly slow when there are lots of these, e.g. alternating backgrounds in the error log or display page. Really. Under Opera 12.5, it runs fine, just a bit less responsive, but when you show a confirm box, you can see how long it takes to show up... Under Firefox 16, it's like night and day. Super fast with a gradient, HORRIBLY slow with a box-shadow.
That's really, really annoying because the results are much better in box-shadow mode!
So... What do you reckon I should do? Is there a way to fix performance? I'm talking about a test done on a Core i7 computer... :-/
2/
Another thing that always bothered me... Wedge using JavaScript to reposition the sidebar, instead of media queries. This was originally because I would 'switch' positions between two different elements, so that I could set a specific target for the sidebar inside the DOM, instead of using CSS tricks to reposition it. As time went by, I decided to save bandwidth in all HTML pages by applying a 'responsive' ID to the DOM's top instead, and I hacked into the CSS in a relatively clean way that I was satisfied with. Okay, so far so good...
Now, this morning I was looking at my code, and the first thing that came to mind was, "WTF?! I use #responsive to set specific media queries... Why not just use @media $responsive?". And this is exactly what I did...
So, $responsive is set to a max-width of 1000px for now, it's working okay. The main benefit here is that because it's done on the CSS level, there's absolutely zero FOUC effect when reloading a page. (There used to be a very, very short one when doing a F5 refresh.)
Plus, I think themers will be comfortable with that... As long as they know about responsive design, of course.
Now for the drawbacks...
- @media doesn't have a set precedence factor, so it doesn't change priorities in the code, unlike #responsive. This means that if you set a #responsive #sidebar to 'display: block' in index.css (or even in an hypothetical extra.css file in Weaving), and then set #sidebar to 'display: table' in a sub-skin's extra.css file, the resulting responsive page will have #sidebar set to display:block because #responsive has higher priority. But if you start replacing all of these with @media $responsive, the resulting responsive page has #sidebar set to display:table because it was filled in after the original media query. The (clean!) solution I'm using, is to take the original media query, copy it at the end of my extra.css file, and add a reset suffix to it. Yes, "@media $responsive reset" is all that's needed. This way, the original media query is removed, and the new one is set at the one, and it includes the original media query's rewrites. Yes, it isn't as bulletproof as direct inheritance because if Weaving is heavily modified you'll have to modify your sub-skin as well. But it's probably something that could also happen with #responsive, albeit with different issues.
- Perhaps an even worse one... Unfortunately, @media being a special construct, you can have a selector like ".myclass, #myid, @media all .anotherclass", ah ah. Well, Wedge doesn't even bother checking... It actually does build such a selector if you add an 'extends' keywords to .anotherclass in the media query. Which pretty much makes the css declaration fail. So, yes, it does mean that whenever you start declaring a media query, *you can't use any extends in it.* Bummer!
So, I'm seriously considering going back to the 'original', as flawed as it is.
3/
And finally... The menu arrows.
Currently, they're using a lightweight (150-byte) image with horizontal and vertical positions, as well as a hover version.
I decided that I wanted to associate the arrows with the text next to them -- so that you can set the text to any color and they'll follow the color. So I replaced the arrows with CSS right-floated 'content' set to '\a0\25bc' (IIRC), in a pseudo-class of course. It seems to work really fine. This also allowed me to remove a couple of CSS hacks I had for the arrows. Unfortunately, this technique also has its limitations... Apart from the fact that pseudo classes don't work in IE6 (fuck you IE), there's the fact that Firefox shows arrows using a largely different size compared to Opera (?!), and float issues in the different places where it's all used, e.g. menu arrows aren't floated the same way when they're in the top-level menu or inside the menu itself. Same with linktrees...
This one is more of a technical issue to me, as philosophically I think I'm really good with using CSS content rather than images.
Anyone got any experience with that...?
97
The Pub / Skin showdown
« on August 24th, 2012, 06:31 PM »
(Hey Pete, I think I've found a bug in the poll system... The voter viewing options are all off by default... Shouldn't it be set to the first one by default?)
So, I was wondering... After all this time (at least six months eh?), maybe you'd like to share your opinion about the Wedge skins that are currently available?
I'll give my opinion right now -- I think they all suck. Weaving is at least a bit more 'neutral' and thus works well as the default IMHO. Warm has some good ideas in it, but it's plagued by wrong color adjustments. Wuthering simply sucks from start to finish -- I only kept it for historical reasons because it was directly derived from Curve unlike the rest, and thus is what Wedge looked like in its infancy. And Wine is okay, I like it about as much as Weaving, pretty much when I want more color in my skin I'll choose Wine, and then I'll switch back to Weaving because I tend to lose my focus otherwise.
Still, I noticed while working on Wedge yesterday that some of you guys had chosen a different default skin, maybe because you liked it better, or maybe because you just wanted some change for a bit.
Do you like change? i.e. are you the kind of person who will switch skins from time to time for fun? Are there any issues you have with any of the skins?
I'd like to start work on a 6th skin (I'm not adding Wireless to the list because it's basically a stripped down Weaving), possibly the future default skin, at the very least I'd like to try for something a bit more daring, more designer-oriented. Hmm...
So, I was wondering... After all this time (at least six months eh?), maybe you'd like to share your opinion about the Wedge skins that are currently available?
I'll give my opinion right now -- I think they all suck. Weaving is at least a bit more 'neutral' and thus works well as the default IMHO. Warm has some good ideas in it, but it's plagued by wrong color adjustments. Wuthering simply sucks from start to finish -- I only kept it for historical reasons because it was directly derived from Curve unlike the rest, and thus is what Wedge looked like in its infancy. And Wine is okay, I like it about as much as Weaving, pretty much when I want more color in my skin I'll choose Wine, and then I'll switch back to Weaving because I tend to lose my focus otherwise.
Still, I noticed while working on Wedge yesterday that some of you guys had chosen a different default skin, maybe because you liked it better, or maybe because you just wanted some change for a bit.
Do you like change? i.e. are you the kind of person who will switch skins from time to time for fun? Are there any issues you have with any of the skins?
I'd like to start work on a 6th skin (I'm not adding Wireless to the list because it's basically a stripped down Weaving), possibly the future default skin, at the very least I'd like to try for something a bit more daring, more designer-oriented. Hmm...
98
The Pub / Getting ready for an alpha release...
« on August 18th, 2012, 12:24 PM »
So... I'm looking into making this August 25 date a reality, right...? :edit: Obviously at a later date, now...
In order to achieve such a close release date, I needed to decide that some of the features I want for 1.0 will have to go through an upgrade script of my own. I hate the idea, but I'd rather postpone 20% of my features (and a stable release), than have Wedge remain vaporware forever... Plus, the interest we might generate could help get more developers onboard.
So, there are places in the code where "I'm not too sure" about what I've been doing, and here's what I'll do: I'll simply post patches and ask for feedback... This is better than withholding commits until I'm sure of what I'm actually doing.
Could you guys review the first patch? It's a simple one really -- it's something we discussed before, the default lengths for various database columns. I tend to forget what we talked about, especially when it comes to MySQL, so I don't know what is "right" and what isn't. And because we're going to have an upgrade script eventually, it also means we can safely change these field lengths later in the process, so I'm not even sure this patch needs applying at all.
Yet, there might be a few fields that warrant shortening or lengthening. You tell me. Thanks.
:edit: Removed attachment to make it possible to have the topic in public...
In order to achieve such a close release date, I needed to decide that some of the features I want for 1.0 will have to go through an upgrade script of my own. I hate the idea, but I'd rather postpone 20% of my features (and a stable release), than have Wedge remain vaporware forever... Plus, the interest we might generate could help get more developers onboard.
So, there are places in the code where "I'm not too sure" about what I've been doing, and here's what I'll do: I'll simply post patches and ask for feedback... This is better than withholding commits until I'm sure of what I'm actually doing.
Could you guys review the first patch? It's a simple one really -- it's something we discussed before, the default lengths for various database columns. I tend to forget what we talked about, especially when it comes to MySQL, so I don't know what is "right" and what isn't. And because we're going to have an upgrade script eventually, it also means we can safely change these field lengths later in the process, so I'm not even sure this patch needs applying at all.
Yet, there might be a few fields that warrant shortening or lengthening. You tell me. Thanks.
:edit: Removed attachment to make it possible to have the topic in public...
99
Development blog / Development, full speed ahead!
« on August 6th, 2012, 06:38 PM »
Hey everyone! Long time no blog. Nope, none of us are dead... We just had 'things' happen in real life, which slowed everything down, sometimes to a halt. I made sure to have at least a couple of commits out every week, just so I never lose focus on what I'm planning to do, but it's true that I've had a tendency to focus on smaller details rather than the big picture.
The main point is that we've often gone through the same story: deciding to implement a minor feature that would be cool, and then realizing, weeks later, that we didn't realize that 'minor' doesn't mean 'quick to implement'... And it went on, and on. As a result, I myself became wary of starting the heavy-duty work on a number of 'heavy' features that I'd like to have in Wedge from day one[1], and I think if we keep it that way, we'll always have a good excuse not to release Wedge. Not that we're in a hurry to do it -- but we've got to keep it real, and part of it means we have to keep it real for users.
So, the reason why I'm so reluctant to go public is mainly the fact that it's hard to update the database once it's installed somewhere. If you don't tell people to use the upgrade script etc, then you're likely to get annoying support questions...
So here's what I'm suggesting: storing a $settings['db_version'] variable (or a variation if there's already an equivalent), and set it to the SVN revision number corresponding to the lastest database structure change. So, at runtime we can simply, as soon as we load $settings, check for the variable, and if it's lower than the current required database version, load an extra file that will automatically adjust the database structure. e.g. if the db_version is 1652, and user installs version 1815, Wedge will execute all database (and file structure) modifier functions located between those rev numbers -- db_update_1664, db_update_1727, etc... It should be easy to calculate, really, and we can safely call them, and then update db_version to the latest database version available. Then it wouldn't be (so) hard to change the database, whether for us or for users.
What do you think...?
PS: bugger, another issue I just discovered... The selection is off by a few bytes when I click the Bold button in the bbc box, perhaps related to the Opera hack that I wrote for editor.js in both SMF and Wedge... Maybe they FINALLY, after years, fixed that bug...? :edit: Yes, they did, but they didn't fix all of it, so I'll have to keep an eye open...
The main point is that we've often gone through the same story: deciding to implement a minor feature that would be cool, and then realizing, weeks later, that we didn't realize that 'minor' doesn't mean 'quick to implement'... And it went on, and on. As a result, I myself became wary of starting the heavy-duty work on a number of 'heavy' features that I'd like to have in Wedge from day one[1], and I think if we keep it that way, we'll always have a good excuse not to release Wedge. Not that we're in a hurry to do it -- but we've got to keep it real, and part of it means we have to keep it real for users.
So, the reason why I'm so reluctant to go public is mainly the fact that it's hard to update the database once it's installed somewhere. If you don't tell people to use the upgrade script etc, then you're likely to get annoying support questions...
So here's what I'm suggesting: storing a $settings['db_version'] variable (or a variation if there's already an equivalent), and set it to the SVN revision number corresponding to the lastest database structure change. So, at runtime we can simply, as soon as we load $settings, check for the variable, and if it's lower than the current required database version, load an extra file that will automatically adjust the database structure. e.g. if the db_version is 1652, and user installs version 1815, Wedge will execute all database (and file structure) modifier functions located between those rev numbers -- db_update_1664, db_update_1727, etc... It should be easy to calculate, really, and we can safely call them, and then update db_version to the latest database version available. Then it wouldn't be (so) hard to change the database, whether for us or for users.
What do you think...?
PS: bugger, another issue I just discovered... The selection is off by a few bytes when I click the Bold button in the bbc box, perhaps related to the Opera hack that I wrote for editor.js in both SMF and Wedge... Maybe they FINALLY, after years, fixed that bug...? :edit: Yes, they did, but they didn't fix all of it, so I'll have to keep an eye open...
| 1. | Custom boards, board types, custom groups, general privacy system, general tag system, attachments as media items, and so on... |
100
Archived fixes / SMF (not Wedge) bugs
« on July 26th, 2012, 04:19 PM »
I'll just have this topic around in case I find a bug that's in SMF but not in Wedge...
Well, in the case of this particular bug, which is not really a bug per se, I'm currently trying to rewrite the template so it's unlikely I'll even remember about the bug by the time I commit, so here it is, for SMF developers to fix...
Code: [Select]
That's in Search.template.php ;)
Well, in the case of this particular bug, which is not really a bug per se, I'm currently trying to rewrite the template so it's unlikely I'll even remember about the bug by the time I commit, so here it is, for SMF developers to fix...
<div class="verification>That's in Search.template.php ;)
101
Features / Virtual selectors in WeCSS
« on July 25th, 2012, 05:22 PM »
So, I was considering a new feature that I'll add to WeCSS, and need to get some thoughts on it first...
Let's consider this new keyword, 'virtual' (always in line with the C++/Delphi naming scheme.)
.inline-block virtual
display: inline-block
blablabla...
Now, the idea is that if a selector is found that has the virtual keyword, at the end of the pre-processing stage, Wedge will run a check for the selector, and delete it from all selector combinations (i.e. .inline-block, .windowbg, .windowbg2 will just become .windowbg, .windowbg2).
Additionally, if it's found to be alone (i.e. no other selectors extend it), it will simply delete it. Thus allowing me to create a 'virtual.css' or 'common.css' file with all of the nice little helpers like this one, and add it silently at the beginning of all files, which in turns allows us to use "extends .inline-block" everywhere, including external CSS files not related to the main file.
I think it's a pretty good idea, but this is where it gets tricky: there are a few rare situations where "inline-block" is used as a proper class in the HTML -- notably in the admin homepage, where it's also associated with admin_menu (making it easy to remove it... Just extend it!), the profile template (can add a custom class to that one), and the plugin manager (same here, will need an extra class.)
So, I'm wondering what's best?
1/ just forget about that keyword, and keep allowing the HTML to use virtual selectors.
2/ use it, but don't delete the selector afterwards... (which makes it pretty much useless, ah ah :))
3/ use it, and always delete the selector, and force the HTML to inherit from the selectors instead of using them.
Let's consider this new keyword, 'virtual' (always in line with the C++/Delphi naming scheme.)
.inline-block virtual
display: inline-block
blablabla...
Now, the idea is that if a selector is found that has the virtual keyword, at the end of the pre-processing stage, Wedge will run a check for the selector, and delete it from all selector combinations (i.e. .inline-block, .windowbg, .windowbg2 will just become .windowbg, .windowbg2).
Additionally, if it's found to be alone (i.e. no other selectors extend it), it will simply delete it. Thus allowing me to create a 'virtual.css' or 'common.css' file with all of the nice little helpers like this one, and add it silently at the beginning of all files, which in turns allows us to use "extends .inline-block" everywhere, including external CSS files not related to the main file.
I think it's a pretty good idea, but this is where it gets tricky: there are a few rare situations where "inline-block" is used as a proper class in the HTML -- notably in the admin homepage, where it's also associated with admin_menu (making it easy to remove it... Just extend it!), the profile template (can add a custom class to that one), and the plugin manager (same here, will need an extra class.)
So, I'm wondering what's best?
1/ just forget about that keyword, and keep allowing the HTML to use virtual selectors.
2/ use it, but don't delete the selector afterwards... (which makes it pretty much useless, ah ah :))
3/ use it, and always delete the selector, and force the HTML to inherit from the selectors instead of using them.
102
Features / Auto_increment madness...
« on July 10th, 2012, 11:27 AM »
You all know I'm a bit odd from time to time... This is one of those days.
I was wondering if we shouldn't (couldn't) do something specific on each table row deletion.
Let's say we have a draft that we don't want to keep (or that doesn't need to remain on the server because we just saved the original post), so Wedge will delete it internally... So we go through Post2.php:904, and the draft is deleted. Along with the auto-incremented (likely) latest id_draft.
If we could simply call ALTER TABLE {db_prefix}drafts AUTO_INCREMENT=1, where the auto_increment value would be set to the earliest 'available' id, that means it would be much slower for the table to reach its maximum size. Granted, it's int in this case, but you get my point: by being too lazy about some tables, and not resetting the auto_increment when we could do it, we're basically wasting IDs.
So maybe we could have an optional feature in db_query that would check whether a table row is being deleted, and if it is, just set its auto_increment to 1, either by checking against a whitelist of tables with auto_increment fields, or just doing it automatically (I doubt MySQL would do anything else than ignore the request if it has no such field.)
Is it too crazy..? Too smart for its own good?
(Oh, did you notice how I changed the layout for the top of the post page? The icons are now inside the select box itself, and the select box was moved to the left of the title input... I like that. Hopefully you all do.)
I was wondering if we shouldn't (couldn't) do something specific on each table row deletion.
Let's say we have a draft that we don't want to keep (or that doesn't need to remain on the server because we just saved the original post), so Wedge will delete it internally... So we go through Post2.php:904, and the draft is deleted. Along with the auto-incremented (likely) latest id_draft.
If we could simply call ALTER TABLE {db_prefix}drafts AUTO_INCREMENT=1, where the auto_increment value would be set to the earliest 'available' id, that means it would be much slower for the table to reach its maximum size. Granted, it's int in this case, but you get my point: by being too lazy about some tables, and not resetting the auto_increment when we could do it, we're basically wasting IDs.
So maybe we could have an optional feature in db_query that would check whether a table row is being deleted, and if it is, just set its auto_increment to 1, either by checking against a whitelist of tables with auto_increment fields, or just doing it automatically (I doubt MySQL would do anything else than ignore the request if it has no such field.)
Is it too crazy..? Too smart for its own good?
(Oh, did you notice how I changed the layout for the top of the post page? The icons are now inside the select box itself, and the select box was moved to the left of the title input... I like that. Hopefully you all do.)
103
Features / Like types?
« on July 5th, 2012, 11:22 AM »
Can we, should we, have Like types..?
I was on a French website yesterday, and noticed that it had an awful lot of Like buttons. Basically they all started with "This made me...", and then a list of verbs matching your emotion: "smile", "cry", "upset", "uncomfortable", "angry", things like that... Similarly, the latest .Net issue has a feature about someone writing a Chrome plugin to be able to say that you 'cried' at a YouTube video.
The whole point of this is to give you the ability to then search for the things that made people laugh, or cry, or react in any way different from just 'liking' it, basically just as if the users were adding 'personal tags'.
One of these things can be achieved through the playlist system in Wedge. For instance we could add playlist types and then let people create their playlists from a list of templates like "Favorites", "Pictures of places I should visit", "Videos that made me cry", etc, and then one could navigate through all similarly-named playlists and write plugins to sort items by most times seen in a specific playlist etc. Whatever.
Of course, playlists are only on a topic-level, while likes are on a message-level, so it's not the exact same thing. So I figured, it's hard to do that with playlists (although doable), so maybe with likes...
Maybe it should only be a plugin of course, like, adding emotion types through a plugin, but in the end maybe we should 'simply' accomodate for like types in the database already (i.e. a 'type' enum field), making it easier to add types later on.
What do you think...?
I was on a French website yesterday, and noticed that it had an awful lot of Like buttons. Basically they all started with "This made me...", and then a list of verbs matching your emotion: "smile", "cry", "upset", "uncomfortable", "angry", things like that... Similarly, the latest .Net issue has a feature about someone writing a Chrome plugin to be able to say that you 'cried' at a YouTube video.
The whole point of this is to give you the ability to then search for the things that made people laugh, or cry, or react in any way different from just 'liking' it, basically just as if the users were adding 'personal tags'.
One of these things can be achieved through the playlist system in Wedge. For instance we could add playlist types and then let people create their playlists from a list of templates like "Favorites", "Pictures of places I should visit", "Videos that made me cry", etc, and then one could navigate through all similarly-named playlists and write plugins to sort items by most times seen in a specific playlist etc. Whatever.
Of course, playlists are only on a topic-level, while likes are on a message-level, so it's not the exact same thing. So I figured, it's hard to do that with playlists (although doable), so maybe with likes...
Maybe it should only be a plugin of course, like, adding emotion types through a plugin, but in the end maybe we should 'simply' accomodate for like types in the database already (i.e. a 'type' enum field), making it easier to add types later on.
What do you think...?
104
Features / Database field formats
« on July 2nd, 2012, 02:56 PM »
As discussed earlier, I'm spending some time with the database and trying to harmonize field sizes.
id_album is currenty an int(10), while id_board is smallint(5).
In the future, albums will internally be treated as boards, so I could either reduce the id_album to a smallint (maximum value: unsigned 64K), or increase the size of id_board to medium(8), i.e. in the millions, and reduce the size of id_album accordingly.
While technically it's true that having millions of boards will probably crash Wedge before long, I'm not sure that the 64K limit is good enough. If you have a popular website where thousands of users create media galleries every day, you could easily break the limit in a few months time. More realistically, any image-oriented forum with a decent community could potentially break the limit in a few years. After that, we can either release a patch to increase the id_board size for them -- or simply account for it now.
Only problem is, mediumint(8) is stored on 3 bytes so I'm not sure it's as good in terms of performance as smallint. What do you think...? (The worst possible offender is the messages table, which has an id_board field.)
And finally -- id_group should be increased as well. Currently it's set to mediumint(5) which doesn't make sense (the 5-char limit will likely be ignored anyway if there are millions of groups...?), so I started by setting it to mediumint(8) for clarity, and then changed it to int(10) mainly for one reason: ideally, ANY user can create ANY number of groups to put ANY number of members into it. We should (?) probably put a limit to those, but for now I'm upgrading to int. Anyone knows whether this will have an influence over perfs...?
id_album is currenty an int(10), while id_board is smallint(5).
In the future, albums will internally be treated as boards, so I could either reduce the id_album to a smallint (maximum value: unsigned 64K), or increase the size of id_board to medium(8), i.e. in the millions, and reduce the size of id_album accordingly.
While technically it's true that having millions of boards will probably crash Wedge before long, I'm not sure that the 64K limit is good enough. If you have a popular website where thousands of users create media galleries every day, you could easily break the limit in a few months time. More realistically, any image-oriented forum with a decent community could potentially break the limit in a few years. After that, we can either release a patch to increase the id_board size for them -- or simply account for it now.
Only problem is, mediumint(8) is stored on 3 bytes so I'm not sure it's as good in terms of performance as smallint. What do you think...? (The worst possible offender is the messages table, which has an id_board field.)
And finally -- id_group should be increased as well. Currently it's set to mediumint(5) which doesn't make sense (the 5-char limit will likely be ignored anyway if there are millions of groups...?), so I started by setting it to mediumint(8) for clarity, and then changed it to int(10) mainly for one reason: ideally, ANY user can create ANY number of groups to put ANY number of members into it. We should (?) probably put a limit to those, but for now I'm upgrading to int. Anyone knows whether this will have an influence over perfs...?
105
Features / Media boards: fishing for opinions
« on July 1st, 2012, 01:53 AM »
So... For the last few weeks I've been considering multiple ways of integrating media items smoothly into Wedge. (Via the upcoming floating board feature.)
After all this time, there's one technique that sticks, and I'll explain it to you. The reason is that I'm not sure whether it's for the best, because it has a few disadvantages.
Simply said, a topic (wedge_topics table) would now have an associated id_media field. This field would represent a single entry in the media table.
With that said:
- an album is a custom board
- an album comment thread is a topic in this board where id_media = 0 (no associated image)
- an album item is actually a topic, which has a custom id_media that tells Wedge what thumbnail it should show. The item description could very simply be the first post in the topic.
- an album item comment thread is, obviously, the list of messages in that topic.
One of the advantages of this system is that it allows you to associate a media item with a topic even when the board isn't an album board.
For instance, we could have a blog where the posts are listed along with a thumbnail of their associated media item. Meaning, for each blog post the first media item you upload for it will become the default id_media for the topic. I could also ensure that you can select another item for use as main item. (Really, you could even use a single id_media for multiple blog posts -- e.g. like a category image.)
Now for the drawbacks...
- when you're writing a post, even a reply to some other post, if you upload a media item to attach in it, it creates a new topic internally. Which makes a lot of sense -- but then you get to the point where creating topics as 'supporting players' of a simple message sounds weird, even uncomfortable. (Then again, it's only internal stuff. I mean, users of Facebook don't really mind URLs with long series of digits... Also, we could always show ?topic=base64encoded_id in the URL, ahah...)
- it's not gonna be fun writing a converter for all of that... (Plus, TE is kinda MIA these days, so I fear it will be up to me to do it :P)
- the 'view unseen' permission is nulled by this, because it's all about new topics by then. Maybe I could add a filter for board types in the 'view unread posts' page. i.e. 'Mark (select box) as read' where the select box has Forums, Media, Blogs...
- I had another drawback in mind, which actually brought me to write this post, but I forgot about it for now. I'll make sure to bump this topic if I remember it.
Also, I've noticed that in AeMe, id_media is set to a size of int(11), while topics are set to mediumint(8). If a topic is now automatically attached to a media item, then it makes sense to set topics to int(11) as well, or set media size to mediumint(8) instead... No?
Which also reminds me that the SQL file has a lot of entries that don't use UNSIGNED where they could. But I don't know what's best -- fixing them as I find them, or leaving them as is, in the event that some would actually want to force a negative value...? (see privacy levels for instance, where a value of -3 means 'everyone' so that positive values can be assigned to membergroups.)
Please discuss all of this :)
(And Pete -- I understand you're on your way to KY, so you're dismissed, I was myself totally unable to participate in complex discussions this week with all the jetlag :P But if there aren't any solutions found by the time you come back, please feel free to share your opinion!)
After all this time, there's one technique that sticks, and I'll explain it to you. The reason is that I'm not sure whether it's for the best, because it has a few disadvantages.
Simply said, a topic (wedge_topics table) would now have an associated id_media field. This field would represent a single entry in the media table.
With that said:
- an album is a custom board
- an album comment thread is a topic in this board where id_media = 0 (no associated image)
- an album item is actually a topic, which has a custom id_media that tells Wedge what thumbnail it should show. The item description could very simply be the first post in the topic.
- an album item comment thread is, obviously, the list of messages in that topic.
One of the advantages of this system is that it allows you to associate a media item with a topic even when the board isn't an album board.
For instance, we could have a blog where the posts are listed along with a thumbnail of their associated media item. Meaning, for each blog post the first media item you upload for it will become the default id_media for the topic. I could also ensure that you can select another item for use as main item. (Really, you could even use a single id_media for multiple blog posts -- e.g. like a category image.)
Now for the drawbacks...
- when you're writing a post, even a reply to some other post, if you upload a media item to attach in it, it creates a new topic internally. Which makes a lot of sense -- but then you get to the point where creating topics as 'supporting players' of a simple message sounds weird, even uncomfortable. (Then again, it's only internal stuff. I mean, users of Facebook don't really mind URLs with long series of digits... Also, we could always show ?topic=base64encoded_id in the URL, ahah...)
- it's not gonna be fun writing a converter for all of that... (Plus, TE is kinda MIA these days, so I fear it will be up to me to do it :P)
- the 'view unseen' permission is nulled by this, because it's all about new topics by then. Maybe I could add a filter for board types in the 'view unread posts' page. i.e. 'Mark (select box) as read' where the select box has Forums, Media, Blogs...
- I had another drawback in mind, which actually brought me to write this post, but I forgot about it for now. I'll make sure to bump this topic if I remember it.
Also, I've noticed that in AeMe, id_media is set to a size of int(11), while topics are set to mediumint(8). If a topic is now automatically attached to a media item, then it makes sense to set topics to int(11) as well, or set media size to mediumint(8) instead... No?
Which also reminds me that the SQL file has a lot of entries that don't use UNSIGNED where they could. But I don't know what's best -- fixing them as I find them, or leaving them as is, in the event that some would actually want to force a negative value...? (see privacy levels for instance, where a value of -3 means 'everyone' so that positive values can be assigned to membergroups.)
Please discuss all of this :)
(And Pete -- I understand you're on your way to KY, so you're dismissed, I was myself totally unable to participate in complex discussions this week with all the jetlag :P But if there aren't any solutions found by the time you come back, please feel free to share your opinion!)