Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Messages - Nao
8161
Features: Posts & Topics / Re: Merge Double Posts
« on August 11th, 2011, 07:40 PM »
Flat mode: Nothing. 1 and 2 are merged, followed by 3 and 4.
Threaded mode: 1 shows up, followed with 2 and 3 as indented posts. Then post 4 indented under 3. Nothing is shown as 'merged'.
Threaded mode: 1 shows up, followed with 2 and 3 as indented posts. Then post 4 indented under 3. Nothing is shown as 'merged'.
8162
Features: Posts & Topics / Re: Merge Double Posts
« on August 11th, 2011, 06:30 PM »
Looks like a conversation between deaf people :P
Sorry, I have no idea what you're trying to convey at this point..... :^^;:
Sorry, I have no idea what you're trying to convey at this point..... :^^;:
8163
Features / Re: These two bytes may not matter to you...
« on August 11th, 2011, 06:28 PM »
But it doesn't mean the same thing... It's COMPLICATEDER :^^;:
8164
Off-topic / Re: To fork or not to fork - in other words: Hi :)
« on August 11th, 2011, 06:26 PM »
Angelina, aren't you still a SMF teamie.......? Am I right in detecting some insinuation in your post...? :whistle:
No, Pete, I don't think you're sour about potential reuse of your ideas -- just about potential reuse by SMF itself. And I share your opinion on this. But Wedge (well at least me :P) is precisely very open to sharing code. Heck, I hope I won't have to spend my entire life guarding the Holy Source Code of Wedge. Its purpose is not to make us rich. It's to show what SMF should have been like by this point if they had developers with cojones. Why do you think Nightshade is here, and has a Friend badge? Because we're friendly to the SMF universe, including its forks -- just not to the team that has vblamer45 in its ranks. Not to the team that considers Akyhne a "friend". And not to those team members who respond to his requests to censor us, like Kindred... ::)
No, Pete, I don't think you're sour about potential reuse of your ideas -- just about potential reuse by SMF itself. And I share your opinion on this. But Wedge (well at least me :P) is precisely very open to sharing code. Heck, I hope I won't have to spend my entire life guarding the Holy Source Code of Wedge. Its purpose is not to make us rich. It's to show what SMF should have been like by this point if they had developers with cojones. Why do you think Nightshade is here, and has a Friend badge? Because we're friendly to the SMF universe, including its forks -- just not to the team that has vblamer45 in its ranks. Not to the team that considers Akyhne a "friend". And not to those team members who respond to his requests to censor us, like Kindred... ::)
8165
Off-topic / Re: To fork or not to fork - in other words: Hi :)
« on August 11th, 2011, 05:28 PM »I meant message icons, not just smileys; both are configurable.
8166
Features: Posts & Topics / Re: Merge Double Posts
« on August 11th, 2011, 05:18 PM »
Uhhh...
Posted April 1 by Nao
I saw a great movie called Deep Throat. Beautiful and very moving!
Posted June 12 by StupidSoccerMomWhoDoesntReadFullTopics
You pedophile! I'm gonna press charges!!!
Posted April 2 by Nao
(By the way... April's fool!)
Posted April 1 by Nao
I saw a great movie called Deep Throat. Beautiful and very moving!
Posted June 12 by StupidSoccerMomWhoDoesntReadFullTopics
You pedophile! I'm gonna press charges!!!
Posted April 2 by Nao
(By the way... April's fool!)
8167
Features / Re: These two bytes may not matter to you...
« on August 11th, 2011, 05:15 PM »Yes, I think so, since separate subdomain etc is still supportable through that.
Simpler ;)Quote More simply... Simplier?
8168
Features / Re: New revs
« on August 11th, 2011, 05:14 PM »
rev 923
(5 files, 7kb)
+ Added ability to load a CSS file in the header even after that header has been filled, e.g. from within parse_bbc(). (Subs-Cache.php, Subs.php, index.template.php)
* Minor tweaks to the post button bar. (sections.css)
* Harmonized text color on button strips. (sections.css)
! Mismatched curly brace. (GenericList.template.php)
(5 files, 7kb)
+ Added ability to load a CSS file in the header even after that header has been filled, e.g. from within parse_bbc(). (Subs-Cache.php, Subs.php, index.template.php)
* Minor tweaks to the post button bar. (sections.css)
* Harmonized text color on button strips. (sections.css)
! Mismatched curly brace. (GenericList.template.php)
8169
Features / Re: These two bytes may not matter to you...
« on August 11th, 2011, 04:49 PM »
So... Is that a yes as to whether I can use theme_url + /images/? :P
We may want to document that... And maybe simplify the code later on, to ensure we don't go through extra lines of code when we could do things simpler. (More simply... Simplier? Why does my spellchecker underline that word? Heck, why does it underline spellchecker, too? :P)
As for topics and posts, no doubt this should be enough, but I was thinking more about the 'smaller' IDs, like tinyints and smallints, really... Even mediumints are not that worthy of attention.
We may want to document that... And maybe simplify the code later on, to ensure we don't go through extra lines of code when we could do things simpler. (More simply... Simplier? Why does my spellchecker underline that word? Heck, why does it underline spellchecker, too? :P)
As for topics and posts, no doubt this should be enough, but I was thinking more about the 'smaller' IDs, like tinyints and smallints, really... Even mediumints are not that worthy of attention.
8170
Features: Posts & Topics / Re: Merge Double Posts
« on August 11th, 2011, 04:46 PM »
Because it's another 'thread' in the list...?
Well, of course if you simply added more details to Post 1 by sending Post 2, you can then physically merge them (manually though)...
I agree it would possibly be a bit confusing to newcomers, having manual & automatic merging done this way, but if we're gonna have threads in the future, might as well think about these details ;)
Well, of course if you simply added more details to Post 1 by sending Post 2, you can then physically merge them (manually though)...
I agree it would possibly be a bit confusing to newcomers, having manual & automatic merging done this way, but if we're gonna have threads in the future, might as well think about these details ;)
8171
Features: Posts & Topics / Re: Merge Double Posts
« on August 11th, 2011, 04:32 PM »Yes you can, it works as you'd expect: supply an id and it'll use it, don't supply it and you get the benefit of auto-increment.
If you merge posts 1 & 2, surely you'd end up with:
Post 1 & 2 by Arantor
Post 3 by Nao
Post 4 by Nao
Sure thing :) That's part of the reason I'm not entirely against the idea.
Works for me :)
8172
Features / Re: These two bytes may not matter to you...
« on August 11th, 2011, 04:28 PM »The idea is that you could have a theme whose image folder is something else but the reality is that theme never specifies an actual folder AFAIK (at least not in its own theme-info.xml), but there is a setting actually stored for it.
I'm okay with themers and modders being given abilities to do plenty of things that aren't by default in SMF/Wedge.
It's another thing when you start offering features that they have absolutely no reason to use.
For instance -- if they want to put their image folder into a separate (cookieless) subdomain, it's something that can be done without any changes. You just point the subdomain to that folder... It's what I used to do for Noisen (until I decided I was bored of paying $10/y for a domain name I only used to redirect to static content :P)
I don't recall there being any performance issues with it, so I'm not that bothered with fixing it right now, but at some point if we get bored...
If we're not providing patches, there isn't really a great deal of good reason to leave the version number in the files, per se - but there may be a reason that hasn't occurred to us yet to leave them in.
Even if we provide automatic updates through the website, I don't see anything that would require having a version number.
8173
Features: Posts & Topics / Re: Merge Double Posts
« on August 11th, 2011, 04:16 PM »Store the original id; when it's reinserted it will take its original place.
And even then, it can be a problem if someone starts playing with the tag to use an existing message ID in it, things like that... Things could go wrong. That's not something I'd see myself do, really -- the potential mess is horrible.
Heck, I don't even think we can insert a message ID and set the id_msg manually. It'll always rely on autoincrement. And I don't see myself modifying the table on the fly to remove the autoincrement flag and reset it later... :P
With a single post being formed, any threaded replies would also be merged into that branch.
If you retain the two posts, you have to figure out how the final thread would be shown.
Post 1 by Nao
Post 2 by Arantor
Post 3 by Nao
Post 4 by Nao
Becomes, to the user:
Post 1 by Nao
Post 2 by Arantor
Post 3 by Nao
Post 4
Post 4 has its own quote, edit buttons etc. Now, let's say I (not Nao) want to answer the part that is in post 3... I click the quote button there. I submit. I'll thus create a Post 5 with a parent ID that is post 3, not post 4 (it would be post 4 if posts 3 & 4 were actually merged like they are now.)
That is -- if I want to show a threaded view, I'll get this:
Post 1 by Nao
Post 2 by Arantor
Post 3 by Nao
Post 5 by Someone
Post 4 by Nao
(Whether or not we should show "by Nao" on Post 4 in threaded view is something we'd decide later on, depending on the layout and design.)
To me I think of posts as atomic items and merging double posts does seem logical to make the result atomic.
The whole double post thing isn't just about dealing with the signature and avatar and so on... it's also about keeping it a single post, in terms of management, in terms of replying to it, splitting and so on. I can see the wisdom of being able to split two merged posts, but at the same time I'm not keen on it looking like two posts; if I merge two posts I want one physical post.
Let's just say for now that I'm not against the idea but I'm not entirely sold on it yet.
8174
Features / Re: These two bytes may not matter to you...
« on August 11th, 2011, 04:08 PM »
Working on a lot of JavaScript optimizations right now...
I think that the editor code (in the HTML) should be tighter. Not that it's going to change anything on compressed files, but if for any reason your server is not sending gzipped data, I've found that my optimizations, while not changing anything to the feature set, actually saves over 3KB... That's not a bandwidth saving I'm going to laugh at, really.
I'm having a couple of issues with one thing though... SMF/Wedge always define images_url in the HTML JS. In Wedge, it is we_images_url. It is only used 3 or 4 times in the entire code, and never for interesting things.
I've been looking at the code for $settings['images_url'], and I can't find any place where it is set to anything else than $settings['theme_url'] . '/images'.
So, my question would be... Can't we just print the we_theme_url variable, and add /images/ to it when needed?
I'm just worried it could be set at some point to $settings['default_theme_url'] . '/images', but I couldn't find it. (I have to say, I'm drowing in micro-optimizations right now... Big commit coming up, eh.)Quote from Arantor on August 10th, 2011, 10:28 PM Never heard about that... But yeah, I figured the signed stuff must be an oversight on the SMF devs' part.
However, I don't feel like checking all INT entries and adding unsigned to them, so if you're not interested with the idea, I guess we can simply forget about it, at least for now...Quote Alrighty.Quote Not worth adding @version to all files, or not worth removing it...?
I don't think the actual @version string is of any interest, whether in the program or legally.
I think that the editor code (in the HTML) should be tighter. Not that it's going to change anything on compressed files, but if for any reason your server is not sending gzipped data, I've found that my optimizations, while not changing anything to the feature set, actually saves over 3KB... That's not a bandwidth saving I'm going to laugh at, really.
I'm having a couple of issues with one thing though... SMF/Wedge always define images_url in the HTML JS. In Wedge, it is we_images_url. It is only used 3 or 4 times in the entire code, and never for interesting things.
I've been looking at the code for $settings['images_url'], and I can't find any place where it is set to anything else than $settings['theme_url'] . '/images'.
So, my question would be... Can't we just print the we_theme_url variable, and add /images/ to it when needed?
I'm just worried it could be set at some point to $settings['default_theme_url'] . '/images', but I couldn't find it. (I have to say, I'm drowing in micro-optimizations right now... Big commit coming up, eh.)
If we can guarantee we never need an unsigned value, we can use that. However int is problematic because unsigned int is an unsigned 32 bit value which runs over the limit of PHP at times (and can be silently switched for a float)
However, I don't feel like checking all INT entries and adding unsigned to them, so if you're not interested with the idea, I guess we can simply forget about it, at least for now...
Tinyint, smallint and mediumint can all be safely made unsigned if the values never go negative.
It can be useful but if you're not offering patches it's almost not worth the effort. More thought needed.Quote OTOH, maybe files shouldn't get a @version at all, in these conditions
I don't think the actual @version string is of any interest, whether in the program or legally.
8175
Off-topic / Re: To fork or not to fork - in other words: Hi :)
« on August 11th, 2011, 02:26 PM »
CSS encoding is just as good anyway. Because it does The equivalent of a solid archive, you can keep your palette optimizations unlike in spriting. And it's easier to deal with. And can be regenerated on the fly. Win win situation. :)