Skip to main content
Topic: Smileys are still gif. Why? (Read 11609 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Re: Smileys are still gif. Why?

Reply #15

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?
Bugs creator.
Features destroyer.
Template killer.

Re: Smileys are still gif. Why?

Reply #16

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).
Master of Expletives: Now with improved family f@&king friendliness! :D

Sources code: making easy front end changes difficult since 1873. :P

Re: Smileys are still gif. Why?

Reply #17

I was more thinking about removing completely the multiple sets option as a feature.
But yes, 1 default set would be enough. :P
Bugs creator.
Features destroyer.
Template killer.

Re: Smileys are still gif. Why?

Reply #18

Quote from: emanuele – I was more thinking about removing completely the multiple sets option as a feature.
+1
Thorsten "TE" Eurich
------------------------

Re: Smileys are still gif. Why?

Reply #19

Aha. Sounds fine to me.
Master of Expletives: Now with improved family f@&king friendliness! :D

Sources code: making easy front end changes difficult since 1873. :P

Re: Smileys are still gif. Why?

Reply #20

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?

Re: Smileys are still gif. Why?

Reply #21

mhh, to be honest: I'd go with c) until APNG is widely supported by all major browsers..
Thorsten "TE" Eurich
------------------------

Re: Smileys are still gif. Why?

Reply #22

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

Re: Smileys are still gif. Why?

Reply #23

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
Bugs creator.
Features destroyer.
Template killer.

Re: Smileys are still gif. Why?

Reply #24

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.
Thorsten "TE" Eurich
------------------------

Re: Smileys are still gif. Why?

Reply #25

Pfew ..

 Spuds 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?

Re: Smileys are still gif. Why?

Reply #26

Quote from: Spuds – Now should we just leave the fugue set and remove the old ones from ElkArte?
yep, +1.
Thorsten "TE" Eurich
------------------------

Re: Smileys are still gif. Why?

Reply #27

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.
Master of Expletives: Now with improved family f@&king friendliness! :D

Sources code: making easy front end changes difficult since 1873. :P

Re: Smileys are still gif. Why?

Reply #28

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!)

Re: Smileys are still gif. Why?

Reply #29

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.
Master of Expletives: Now with improved family f@&king friendliness! :D

Sources code: making easy front end changes difficult since 1873. :P