Wedge

I did bump it multiple times and I did PM you about this one, haha. ;)This is why I've held off on committing them, much as it's been a bit awkward ;) I've been living with it since I wrote it and I'm not entirely satisfied with it but I can't tell you why. Incidentally, it isn't the go up/go down part that bothers me, it is actually the (1) itself for some reason >_< The orange does look out of place and catches me every time I see it.

Sure, just be careful about how you style it. There are places where this is used that aren't inside the <nav> tag, which do need different styling (e.g. multipage topics get a small page index next to the topic title which isn't restyled this way.Hmmm. Not sure what to make of that. It is an interesting idea, I'm just not sure how well it work work 'in real use'. Certainly the style works nicely enough, it's just the specific use of it.

Numbers don't need escaping. Some of the places it is used as such I would personally rather not do it since fairly often it does have a habit of expressing the meaning behind that number.

The great thing is that it doesn't have to be used but changed gradually since it's just a shortcut to something we already had longer.

(12 files, 1 deleted, 2KB)

Revision: 1949
Author: arantor
Date: 24 February 2013 04:13:43
Message:
- House cleaning. Nothing seems to be broken, and anything that is, is both non critical and inherently temporary and possibly even pending a commit in its own right on unrelated matters. (Admin.php, PackageGet.php, Packages.php, Subs-Package.php, Packages.template.php, language files: Admin, Errors, ManageSettings, Packages)
----
Modified : /trunk/Sources/Admin.php
Modified : /trunk/Sources/PackageGet.php
Deleted : /trunk/Sources/Packages.php
Modified : /trunk/Sources/Subs-Package.php
Modified : /trunk/Themes/default/Packages.template.php
Modified : /trunk/Themes/default/languages/Admin.english.php
Modified : /trunk/Themes/default/languages/Admin.french.php
Modified : /trunk/Themes/default/languages/Errors.english.php
Modified : /trunk/Themes/default/languages/Errors.french.php
Modified : /trunk/Themes/default/languages/ManageSettings.english.php
Modified : /trunk/Themes/default/languages/ManageSettings.french.php
Modified : /trunk/Themes/default/languages/Packages.english.php
Modified : /trunk/Themes/default/languages/Packages.french.php

I thought Ema was asking about Yoshi's avatar. Mine is the album cover of one of the, IMO, best metal albums ever written - Powerslave by Iron Maiden.

Well, right now I'm 'in between' features. I'm still trying to figure out how I want things to look and function with the language editor ;)

And it's not like I know what to work on otherwise, my list is way too huge to pick something easily. I mean, my last topic just came out randomly clicking things in the admin panel and thinking, crap I hate that page, how can I fix it?

There are a goodly number of things wrong with message icons and I want to get some feedback on them and what to do with them.

1. Single set of icons, not multiple sets
They're actually changeable per physical theme at this point in time. I don't know any theme that ever actually shipped *its own* as such; all the ones I ever saw just shipped whatever the default icons were in SMF at the time.[1] I'd like to propose we make it a single set of icons.

2. Get rid of this 'enable customised icons' nonsense.
There is really no need for this nonsense. There is, yes, the argument to be made about performance, but caching would fix that anyway. We'd get a simpler and better to use UI out of it.

3. Drop the enforcement of it being .gif
There's really no reason why it must be .gif, other than having a standard format to work with. But that's solvable through another thing.


Then we can get a bit more exotic if we wanted.

4. Stop storing it as a textual item.
If we're already storing them in the database anyway, we will already have numeric ids for them. I see no reason why we can't make proper use of them and just store a numeric id in the messages table and be done with it (yes that would SAVE space!)

This isn't without its issues, because it would mean that all the silent-forced changes that occur (for iPod/iPhone/tablets/Android etc. not to mention moved notices, deleted posts at present and posts with attachments) would also have to be in that table. This raises other issues (what happens if the user deletes them? what happens with migrating existing SMF stuff including this site?)

I'm not exactly dead set on this one, but it is certainly an option to explore and not without its caveats. Though it could also mean the user doesn't want those things set, e.g. if they delete the tablet one, don't use that replacement later.

5. Topic filtering
Assuming we make it a numeric id, we could store that numeric id in the topics table (first post's)... it would allow us to stick an index on it and then filter topics on it. Of course, any plugin that adds its own would be rather awkward but it's not insurmountable.


/discuss

1.	This is most notable in the Bloc themes where they were upgraded from 1.1.x to 2.0 themes but kept the 1.1.x message icons.

So I had some long-running batch processes to keep an eye on and while I did that, I quickly knocked this together. It's using the LED Icon Set because I already had icons handy for them (as I used much the same icons for SimpleDesk announcements and thus could easily grab them)

So yeah, 20 minutes or so later (and batch process still running), and I have this. The idea is that you feed it a topic or topics that are SVN changelogs and it'll pretty them up a little, just changing the first character into an image. It's dull, but it amused me for 20 minutes while otherwise bored but not really able to do *that* much.

Not the usual admin refinements, sorry :P Couldn't even be arsed uploading it to the SVN repo or to the plugins folder, it's really tiny and not like I couldn't just quickly make it again in future.

I've implemented this locally, using the name literal. Seems straightforward enough. I've also modified the example query given (which is a real query) to reflect the new code so I know it works.