Wedge

I haven't formed an opinion on what's best yet, haven't had my morning caffeine dose. :/

If it's semantically better in the sources, do it. It's not like it is now limiting what theme authors can do with it...

Message template in a new file is fine, though be careful: PM is slightly different. The buttons are different (there's no quick edit, no mini menu and if there were, the options would be different),

PMs do not have an icon, they do have a 'sent to:' bar.

So, you're back to your days under the moon eh..? Preference or just plain chance?
Back in the early 00's, I usually went to bed at 5am and woke up at 11, it wasn't really good for me. True, I work better at night, but come to think of it, I simply work better when I'm off from bed or bed time is closing in. It's not really a matter of being a night owl... To me at least.

If I allow for temp disables for instance, I'm sure themers would be glad to have the ability to do it on their side, regardless of the source file's decision. (Of course, they can also remove the skeleton bit they want out, but temp disabling is precisely about letting go of one item in one particular occurrence, e.g. a first post in the page, or whatever.)

Well, why no quick edit..? I certainly can't think of any reason why there shouldn't be. Email notifications, maybe? The problem is a bit of the same with normal posts...

No, it would make more sense to do it all by code... In the PM template, run $skeleton = new weSkeleton($message_skeleton) then manually do a $skeleton->replace('body', 'pm_body'), for instance... You'd just need to have a function template_msg_pm_body() in your PM template to accomodate for this.

Also, the prefix thing...

I've had sleep, I'm back to bed at 5am, up at just past lunchtime. This is my normal routine, really.

Actually, I came across a theory about why we work better at night - http://swizec.com/blog/why-programmers-work-at-night/swizec/3198

I'm trying to conceptualise where a temp disable would actually be used. I think the idea's great but I don't yet see an actual 'example case' for it.

There's absolutely no way to edit a PM once it is sent. I have never once questioned this logic, perhaps I should.

OK... what benefit would it serve to be able to edit a PM? Would it serve a benefit? It's not like it's mass-audience[1] and if there's any ambiguity or confusion, it can be followed up with private messages.

1.	In most cases, anyway.

This seems to make sense but I think it's the sort of thing that will only truly make sense when it is done and can be poked and prodded.

This affects both types of message, incidentally. I'd put it as part of however the subject is set up.

I don't really remember you doing that other than for the last few weeks, except occasionally...

Started reading... Will have to forward to Milady, maybe it'll help her understand why I'm always systematically pulling a Cinderella... :P

Well, this came up when I wrote the mini-skeleton for Msg, really.
For instance, in the template, you get <footer> tags around the footer area if $context['ignoring'] is set. Instead of adding two tests in _before and _after, I figured I could simply disable these functions earlier in the code flow. Then it struck me that I couldn't disable _before and _after function calls, only the entirety of the block (_before, _after and the actual block itself), and adding a setting to disable only the _before and _after would make it look fucked up.
But just after that, I had to create a $context['show_action_bar'] variable to determine whether the action bar should be shown... And it's tested in all three places: before, during and after. In that particular case, having a temp disable could help me disabling the action bar very quickly.

I agree, though, that there's nothing that couldn't be addressed by what I'm doing right now -- $context variable tests in the individual functions.
But it's also an easy addition, I think... (?)
Just set $context['temp_disables'] or something (do you have a better name to suggest...?), and in the render_recursive function, if isset($context['temp_disables'][$id]) then return directly, do not pass Go. Then at the end of the render process, just unset the context var.

Quote

There's absolutely no way to edit a PM once it is sent. I have never once questioned this logic, perhaps I should.

Here's a suggestion... Why don't you post a poll or at least create a new topic to discuss this? I'm sure it's a feature that many people would want -- and also, possibly, would dislike. I personally would rather have it.
Heck, we could even have a feature to delay sending of PM notifications by a minute or so, just like Gmail does to give you time to cancel a sent message ("You're fired!" -- Oops, wrong To: field... Where's that Cancel button?!)
If it detects you're editing the message when it's supposed to send it, it can delay it by an additional minute, etc...
Okay, it's probably a BIT much for not much in return...! But sometimes, it could be helpful. I think.

Quote

OK... what benefit would it serve to be able to edit a PM? Would it serve a benefit? It's not like it's mass-audience[1] and if there's any ambiguity or confusion, it can be followed up with private messages.

1.	In most cases, anyway.

Which is why it may be a 'bit much'.
Alright, we could also simply disable the Quick Edit button in the msg skeleton... :lol:

Quote

This seems to make sense but I think it's the sort of thing that will only truly make sense when it is done and can be poked and prodded.

Plus, I've resumed work on it... Did a few (lot of?) changes in the code path followed to create the main skeleton. For instance, wetem::hide() is called automatically by Wedge if the main skeleton can't be found -- which is either intentional (Ajax data), or accidental (not uploading skeleton.xml to the skins folder). At the very least, you'll be getting the default layer, instead of the "corrupted skin" fatal error. One could argue that the corrupted error is better for debugging, but I'm just not sure about it. For instance, if someone reloads your page WHILE you're upload a new copy of skeleton.xml, they might end up with that error, instead of at the very least getting the content they wanted.

Anyway, all of this can be reverted later...

I've also gotten rid of the prefix.
Will commit my WIP soon. At least, it's working... ;)

Quote

This affects both types of message, incidentally. I'd put it as part of however the subject is set up.

Whadayamean..?

(I've implemented 'temp disables' and renamed it to just... 'skip', which makes more sense. The function is accompanied with a description that explains it's just for the next pass.)

I've been doing it for months. Look at the time stamps of commits. Even as far back as last May, commits from me for 3am or later were becoming increasingly common. If you look at my stats, there is no hour of the day that doesn't have at least 17 posts attached, and 5am ish has quite a few...

That makes sense.

I'd sort of prefer something not in $context but that sounds like where it should be.

OK, I'll kick off a discussion on it. There are a lot of other things to consider about the aspects attached, and I'll bring them all up.

That makes sense to me :)

Have whatever that indicates the prefix as part of the subject template bone[1] and that way it can be sorted out by the template.

1.	If it's a skeleton, part of it is a bone.

Let the source indicate it is a reply through whatever means it has to but then the template can display it, whether it wants to use an icon or anything else.

Makes sense.

All right Sherlock :P
I guess it just didn't jump to me that it was that regular.
Heck I didn't realize I myself posted a few messages at ALL hours of the day! But apparently, except for 3 posts, 4am is the hour where I'm sure to be asleep!
(Feature suggestion™: make these links clickable to actually see the posts I made at 4am... Wondering if they're intelligible at all :lol:)

Don't worry, as soon as I implemented it, I renamed it to an internal array... It made way more sense as it was a per-skeleton thing anyway.

Oh, can you believe that for the first time in my nearly 38 years of existence, I actually built an OBJECT from the ground up, that is not a SINGLETON, and that is actually more USEFUL than any equivalent procedural/functional code, and easier to read?
I'm astonished. I've always been anti-objects, but weSkeleton at least proved that large, complex code can benefit from being objectified... Well, not the case for Wess though, but I did my best too ;)

Quote

That makes sense to me :)

We'll just need to split the existing skeleton into more functions, to make it possible to do these.
I really did a basic one, as you'll see. <msg_author> is just a single block of code, I just didn't feel like splitting it into as many functions as needed. Feel free to do it by yourself, otherwise I'll just do it later on.

Quote

Have whatever that indicates the prefix as part of the subject template bone[1] and that way it can be sorted out by the template.

1.	If it's a skeleton, part of it is a bone.

You mean "new weSkeleton('msg')"? Have a look at the source, that's what I did eventually ;)
Originally I used 'msg' as a prefix, but I figured it was best used as a proper ID, for rendering quirks, i.e. main skeleton vs mini-skeletons. There were at least two places that needed to test against the main skeleton.

Quote

Let the source indicate it is a reply through whatever means it has to but then the template can display it, whether it wants to use an icon or anything else.

My code uses the <skeleton id>, so it wouldn't be able to see the context unless we use a modified skeleton with a different ID.
Hmm, maybe we could do something like... (prototype ahead!)

<copy-skeleton from="msg" to="pm">
  <rename from="msg_author" to="pm_author">
</copy-skeleton>

Or something like that... Thus, no need to copy the actual skeleton, meaning that inherited skins can simply modify the parent skeleton and the rest will follow.

Quote

Makes sense.

Most used word of the day. :angel:

Tempting, very tempting.

I'm still wrangling with design work for the new warning system right now.

Sounds great to me.

Not even close. The f-bomb has been dropped many more times today. Lots of stupidity out here in real life.