Wedge

That doesn't say what 'un' is for ;)

Anyway... Is it enough to justify not using -2? I mean, it's apparently only used in the id_parent owner of membergroups.

I'll stick with -3 for now.

Oh, bummer... I just thought about the extra possibility I forgot -- private thoughts that should only be between the user and the person they replied to. I suspect that just filling in a blank value would be okay, though... (The default for the privacy field is -3.)

Hmm, it's getting interesting...
If I implement 'me and recipient', this means I have to add a test for the parent's member ID before showing the thought. Which is okay. But what if you don't want said person to read your post...? Well, will I have to test for the parent only if the field is empty...? And what if you just want the thought to be read by you, the recipient and your friends (a custom ID), *but* the recipient isn't your friend...?! Then I suspect I'll have to add another virtual membergroup, e.g. '-5' would mean 'me and said member...'

Heck, thinking about it, it'd even be simpler to have something like: 'mem-1, mem-5, 12', meaning 'only member 1, member 5 and group 12'... Since we only have to search for mem- + my own user ID for the privacy test, that'd be doable... Meh ;)

Well... I suppose it's not something we'll have to deal with for now.

I tried to find any references to -2 as a membergroup and failed... Is there any reason for its non-use, then...?

I thought about it again, and it just struck me that in AeMe, I did it very simply: I took all groups that were being used as a primary group, and added them to my '-1,0' string... It requires an extra query, though. Or storing that list in a setting, maybe.
Hmm...
This is bordering into hack-land, right? ;)

You mean, adding a per-skin option like <disable> and <hide>, right...? (disable = not selectable, not usable, only used for inheritance. hide = not selectable, but usable through e.g. default skin selection.)
The main reason I never worked on these, is that it's pretty much impossible to put these variables into skin.xml because it means admins have to edit them manually, which is precisely what I want to avoid (so that they can easily upgrade their site later...)
So it has to be done in the admin area, something like having a variable that specifies skin paths to ignore... But I'm not big fan of that either ;) If only because I like the idea of skins being so flexible that, like plugins, you can immediately add or remove them through FTP and they'll be usable or deleted immediately. (Hmm, actually I never tried deleting a skin while it was being used... should try that.)Except it's very unlikely you'd do that. (There's only the Asus Eeepad Transformer/Transformer Prime that does that on a wider scale, AFAIK. These definitely qualify for full desktop experience to me.)Well, mobile support is included in our default theme... Considering that it's less than 30 lines of code or so, I don't think it's that big a deal. Do you?

And an annoying French AAA movie :P
(Was in Marseille when they shot the first one over there. Only time I ever saw a movie (action) scene being shot AND saw it on TV later, lol.)

Hmm yeah that's the thing -- philosophy differences. A mobile device can either be seen as a "device without a mouse or keyboard" (i.e. you need to redo the UI), or a "device with a low resolution". I chose to treat them as low-res devices first. The UI rewrite will come later. To me, what matters in priority is to ensure the text is readable without having to double-tap the screen. This can be done through a media query indeed, and much of it is actually done by default in Wedge (even in Weaving), but as Pete requested that a mobile theme removes elements it's going to hide anyway (because mobile devices are often limited when it comes to bandwidth), I decided to add an extra stylesheet for custom stuff, and deal with userboxes in the template... I don't know if it's for the *best*, but it's certainly looking better than a stock SMF install on my iPod ;)

BTW, PocketIE is a PocketPC program and as such, very old stuff. I think using 'IEMobile' would be smarter, as it accounts for Windows Mobile browsers.

Another minor feature that I've been thinking of for a few days, is the ability to allow for multiple default skins.
It's easy really.

- Default skin for guests
- Default skin for new members

Until now, easy to grasp... But even easier:

- Default skin for mobile devices

This would allow for Wedge to use the 'Wireless' skin by default on iPhones and company, and admins would be able to install Dragooon's Wedge4Mobile theme, and then choose his theme as the default mobile skin as a replacement for Wireless, if they think it's too limited in terms of usability.

I'm sure we could also think of other opportunities to set a different default skin, but for now let's focus on mobile.
Yesterday I went to sm.org, wondering if someone had already thought of it, and indeed emanuele posted a similar mod last month, so I thought it was worth mentioning, just in case I get accused of stealing an idea -- I did think of it by myself, but I also acknowledge that I'm now aware there's a working implementation at SMF :P
I was curious and looked at the detection code (wanted to see if it differentiated between iOS devices and used any tricks to retrieve resolution, such as Ajax polling or a small redirection via JavaScript -- not so much), it's an open-source external script that's being used, I'm just surprised that it can take 32 kilobytes just to detect a mobile device... Oh my :lol:
Wedge does it in a single line, but obviously it's certainly not as extensive!