Additions to the Smilies thread

[Aggie]

I humbly ask that the e.raser smiley be added:





Also, how tough is it to re-sort the list?  I'd be willing to take on the task, if the powers that be allow me access.  I'd love to do a bit of a conceptual sort.

[Griffin NoName]

Ok it's added.

Ordering the smilies doesn't work. I spent ages getting the bouncy girls and the fireworks in nice rows but it didn't last. There isn't a "method" that maintains any order. Frustrating.

[Aggie]

Thank you. 

And blerg.

[Griffin NoName]

Added

[Swatopluk]

Thank you!
Now we need an artist to squidfy it too

[Bob in a quantum-state-of-faith]

Also, how tough is it to re-sort the list?  I'd be willing to take on the task, if the powers that be allow me access.  I'd love to do a bit of a conceptual sort.

Ordering the smilies doesn't work. I spent ages getting the bouncy girls and the fireworks in nice rows but it didn't last. There isn't a "method" that maintains any order. Frustrating.

And blerg.

Double-blerg.... I wondered about that, myself.   I had just assumed it was sorted by the arbitrary name/word each symbol is tagged with, with the arbitrary puncuation-marks being included, such as 'rolls-eyes' which is colon-colon-parenthesis (before iconization):

: : ) ==>  

Since all characters also have an underlying numerical value, this is how all computer-driven sort engines operate on text.  Sure, there are exceptions written in to most, to allow the engine to "ignore" capitalization and such-- I've written them myself (the easiest fix for that, is to force-convert a temp copy into all the same case, then sort the temp-copy, then apply the sorted rules to the original).  

But I suspect, if there is no way to sort the icons, that it's based on physical placement within the table itself, and that is likely re-ordered for pixel-space via the web page engine what generates the final images.

But that's just a guess...  one based on experience, but still a guess.

It's a damn shame these smilies cannot be put into some sort of hierarchy, or tree structure... id'd make finding'em easier..  say, with tags?  Such as:  a group of beer-related ones, a group of hugs, a group of ... well you get the idea.

:sigh:

[Sibling Zono (anon1mat0)]

Chances are that the sorting goes by the ID of the object, everytime you enter a row in a table with an identity/autonumber field, it is referenced by that number from then on. If the sorting is based on that all the smilies would have to be deleted and entered again in the desired order.

[Bob in a quantum-state-of-faith]

Chances are that the sorting goes by the ID of the object, everytime you enter a row in a table with an identity/autonumber field, it is referenced by that number from then on. If the sorting is based on that all the smilies would have to be deleted and entered again in the desired order.

That actually makes perfect sense-- the index to the table is auto-generated, and no doubt is not subject to manual manipulation.

[Aggie]

Now that you mention it, most do seem to present in order-added.  I seem to remember thinking that this was not the case, but for the most recent ones it apparently is.

So, if we had a static list, it might be possible to re-sort manually once, but new stuff would always show up at the bottom from there.

[Griffin NoName]

Chances are that the sorting goes by the ID of the object, everytime you enter a row in a table with an identity/autonumber field, it is referenced by that number from then on. If the sorting is based on that all the smilies would have to be deleted and entered again in the desired order.

Now that you mention it, most do seem to present in order-added.  

No it's not as simple as that. They get shunted about willy nilly.

example: (actually not an example, it happened) ----  I add bouncygirl1 bouncgirl2 bouncygirl3 bouncygirl4 which get ID  41, 42, 43 and 44. When added they appear in a row at the bottom of the display window, ie. last and in order. Then, at a later date, I add another smiley. NOTE smileys unchanged except for this new "add". Bouncygirl1 (41) gets moved to middle of row 9 in the smiley window, Bouncygirl2 gets moved to middle of row 2 in the window, bouncygirl3 gets moved near the end of row 11, etc. And it won't just be the previous four added. Others wll move as well. The only thing we can deduce from this is that it is the action of adding alters the sequence of (potentially) all smileys added before but leaves the newest (current add) as the last in the sequence.

(I'm almost always the one adding, and have been monitoring carefully).

If, instead of talking about rows in the window, we talk about rows in the "table" - never assume they are the same thing !!!!! - and therefore a "rowID" (knowledge of sequel maybe needed to understand this point) AND we imagine that a table row holds several smileys then we still have the same issue, random re-assigning, juggling, madness. OK, storing several per table row would be nuts (given we don't have any type of grouping at all), but has to be considered for thoroughness.

Some clue might be accrued from the way the smileys are listed in the "Add/Edit"" Smileys window - they are ordered by the filename the actual image is stored in. (I think this is reasonably mad but there we are). Hence the need to rename files before uploading - smiley file originals are often called eg umz1 - often obscure - so I rename them to what one might actually look for, meaningful filenames like "sportsgirl". Took me ages to delete/rename/re-upload files with meaningful names (delete and overwrite doesn't work) so that I could actually find smileys in the add/edit smiley list more easily and GET THEM INTO ORDER so, for example all fireworks smiley image filenames start with the letters FIRE "fire....." so they appear in order together in the list. But I did that a couple of years back, and now have the system working fine whenever I add a new one (or linked series) I know I have to first choose a filename.

As I said, there could be a clue there, BUT NOTE the order listed in the "add/edit" bears absolutely no relationship to the order you see in the smiley display window OR the filenames, OR the hidden "codes" or the "alt-name" of the smiley. So, there isn't a clue.

I have a feeling, without looking at the program code, which I am being too lazy to do, even though intrigued, that Bob is nearer the mark.

But I suspect, if there is no way to sort the icons, that it's based on physical placement within the table itself, and that is likely re-ordered for pixel-space via the web page engine what generates the final images.

But that's just a guess...  one based on experience, but still a guess.

Unsure about physical placement per se, (but may well be), but pixel-space seems very likely. The window always appears (initially in open) at a set size for me (is this true for everyone). See what happens when resizing the window.................. wider ......... smileys move up staying in order to fill the window nicely........ so more smileys per row,...... there is never a half a smiley displayed at the end of a row...........

NB I have experienced at least one system where smileys get half displayed due to sizing issues.

I may look at the program code, but Bob gets my money for now.  

They've gone for visuals over order. Spacing smileys pre-ordered to varying window sizing is more difficult and slower.

,...... there is never a half a smiley displayed at the end of a row...........

NB I have experienced at least one system where smileys get half displayed due to sizing issues.

Why did I not think of this two years ago and saved myself some headaches?

And a prize to the one who spots the interesting fact about this post.

[Bob in a quantum-state-of-faith]

Oooooh!  A recursive post... I love it!

[Griffin NoName]

Here be a dancing cow.

[pieces o nine]

How now, black & white cow!     

[Bob in a quantum-state-of-faith]

.... wow.

[Opsa]

Swato recently posted this dancing ape:

http://freesmileyface.net/smiley/animals/ape-1301.gif

Actually, I suppose he's a monkey, since he has a tail!)