Just wondering. If not using animated smileys by default, it would probably make more sense to make the default sets png. This is better if you want the same smileys to handle both dark and light themes, and it's better for Android (which doesn't really support gif).
Agree, makes sense :)
Tracked, so we don't forget: https://github.com/elkarte/Elkarte/issues/500
Problem with the current sets is that they are gif and we don't have anything else (as far as I know), so convert them to png wouldn't change anything in respect to light and dark themes...
One set was .png that I converted to .gif ... the main reason for gif was for the animated support. ... Could add support for both to the smiley code, but I can't even figure out how to use the smiley admin interface let alone the code :P
...I thought the extension was not "added" by the code, but included in the name...meh...
Your probably right, but I stand by
Thanks
ol' StrawForBrains :D
lol
Rewrite it! :P
I always found the SMF smiley admin stuffz quite easy to use. What have you done to it to make it difficult? :D
Spuds!!
You added drag&drop, you know smiley could benefit a lot from it, right? O:-)
BTW, when I suggested .png for default smileys I was assuming that all common image file formats would be supported, not just .png. Some people will want custom animated smileys, and I have even used .jpg for some static "smileys" which weren't emoticons as such.
My idea was that if we use .png for default smileys that gets rids of the problem of the wrong matte colour on some backgrounds, because they wont need a matte at all. If someone wants a custom gif and it has to have a matte to stop it looking jaggy, that's their lookout. Nothing we can do about that.
Since the standard old SMF smiley stuffz already accepts any image format, we shouldn't need to change anything there. All we need to do is use .png for our default smileys. There ya go. :)
Smiley's should be fonts, not gif's or png's.
Tell that to all the people who want to use existing gif's and/or png's.
I know, I didn't expect anyone to go for it.
Not really. It's not a bad idea for some applications. I don't think it'd be popular for a forum though, since a lot of people will want to customise smiley sets, and that's easier with images. Yes, some things really are easier with images. You get that. :D
While we are talking about smiles and Spuds doesn't like the interface...what do you think about removing the sets? And keep "just" the option to add new/remove/manage smiley?
Well we should have one default set, IMO. I don't see any need to have several though (and TBH some of them aren't that great).
I was more thinking about removing completely the multiple sets option as a feature.
But yes, 1 default set would be enough. :P
Aha. Sounds fine to me.
Back to this for a moment ....
I have the Fugue icons as PNG's (those are the ones we use on this site) and updated my local to PNG's, removed the old sets, updated a couple of areas to default to .png when you don't have smileys enable.
Now the questions of should we do some other things or not.
Smiley codes are tied to a filename and they are unique, such that each code points to a filename across sets, so changing to .png means we can't have another :-) code that is for a smile.gif in one set since our default is smile.png, .... all those :-) need to point to a smile.png in the sets.
So if you load another smiley set and they are all gifs, you will get the old does not exist notice, so if you really want to use that gif set with the :-) you can't until you unset it from smile.png ... I hope I have that right and it makes sense.
So
A) who cares, if they want gif for one of the default codes in our set they need to do some work. Meaning our default codes need to be the same filetype across all sets for the same code. ... Downside, lots of smiley sets will not work as they are gif
B) use the filename w/o extension to see if it exists, and based off the set chosen set a smiley_encode tag of png, gif, bmp, etc (based on the smile icon filename and assume all the defaults are of this type). This allows you to load smile sets of any type against the codes. Downside, you can't mix in a set, they are gif or png or etc
C) Same as b but only for the default codes, then any user defined ones are tied to the filename-type and that must be the same in all sets (assuming you want it to render n all sets). This allows for our default codes to be mixed type across sets and user defined codes be the same across sets.
D) Leave the default set as .gif, if someone wants a dark theme, they get the extra work.
thoughts?
mhh, to be honest: I'd go with c) until APNG is widely supported by all major browsers..
Damn ... why did I make that option 'C' ... we all know that when unsure of an answer in a multiple choice test C is most often the right answer !
Actually C is what I was thinking as well ... I liked A and D due to the sheer laziness aspect, but felt C might be the way to go. Mind you I'm note sure C will work, but it should :P
Considering I never used more than one set of smiley (and suspect outside sm.org is fairly normal to have just one), I can only say: do what you prefer. :P
arg, I'm sorry.. I'd vote for d), not c) .. (need my bed, so tired today :o)..
leave it as gifs until APNG is supported.
d) works fine and we don't need PNG all over the place.. there's still a reason for GIF sometimes.
Pfew ..
/me wipes sweat from brow :P
I took a quick look at option C, and its doable but would need a bit of work with all the places smiles go ... so D it is :D
Now should we just leave the fugue set and remove the old ones from ElkArte?
I'm missing something here. At the moment (SMF smiley stuff) you can set any file type for any smiley, and have different file types in the same set, and share smileys across sets or not, as you like. So, why does any of that need changing just because you want default smileys to be PNG? I don't get it.
Well do note that I'm smiley set inept :D
looking at the code, ... smile codes are tied to a filename, across sets ... so :-) = smile.png .... if you import a new set that has smile.gif you can not assign it to the :-) code since it is taken.
So yes we can make the defaults png and it will be fine, but if you import a new set based on gif (which most are), the default codes will not render since smile.gif is not smile.png, you will need to give it a new code or convert them to png or other (as in I'm completely missing something since I don't do them sets!)
Oh ok, well in that case I wouldn't think it's a problem. They can just use a custom code if they want to. The defaults will only be the basics, and should be non-animated anyway, so I can't see a problem with having default codes stuck to png suffix. Not really. It might mildly annoy a few people but they'll get over it.
Also, there's an old trick themers used to use when they wanted png images in 1.1.x and 2.0.x without hacking all the image calls in the templating. You just make your png and then rename it to a gif suffix. It works.
I haven't tried doing it the other way, but that might work too (IOW, make your animated gif and rename it to png).
ETA: Oh and regarding smiley sets, frankly I've never seen the point of them.