Screenshots on prodlist?
category: general [glöplog]
Could it be possible for someone to add screenshots on the prodlist? Sometimes i'll spend ages trawling through prods, especially if I can't remember a lot about the prod.
A fair warning. ps will probably say no to this. I could give you reasons why, but I since it probably won't happen anyway I won't bother.
would overload things
Thanks for the answer anyways guys. :)
This would be dead simple to cook a user script to do that if there was content negociation in http://www.pouet.net/screenshots/ ( hence avoiding to blindly request the screenshot in jpg, jpeg, png, gif )
whats does your definition of content negotiation imply? give me the code to fix it and i'll fix it. actually you even have access to fix it yourself p01 O_O
Maybe worth to look as it's already done on Intro Inferno.
HTTP Content negociation allows to map various representations of a resource to a user agent requesting a URI. Of course Apache supports Content negociation.
Unless I misunderstood something, it could also return an image regardless of its format/extension, and wouldn't require a database lookup of worse to request and scrap the prod.php page of each prod. I'll have to read the docs again. :p
An real life example of content negociation is http://www.w3.org/Icons/w3c_home which returns either a GIF or a PNG based on the accept header sent by the user agent.
Oh yeah I still have the "power". Well, it could be interesting but might hammer the server with all the extra requests.
Unless I misunderstood something, it could also return an image regardless of its format/extension, and wouldn't require a database lookup of worse to request and scrap the prod.php page of each prod. I'll have to read the docs again. :p
An real life example of content negociation is http://www.w3.org/Icons/w3c_home which returns either a GIF or a PNG based on the accept header sent by the user agent.
Oh yeah I still have the "power". Well, it could be interesting but might hammer the server with all the extra requests.
Oh fuck that, the variants must be explicitly declared ... not possible for a large collection of files.
OTOH if we remove the extension of the screenshot's file, the browsers will figure the mime type themselves. Problem solved.
OTOH if we remove the extension of the screenshot's file, the browsers will figure the mime type themselves. Problem solved.
The problem here as I see it is that you have to choose between resizing all the screenshots or overloading the server with traffic for images that will be downsized by the browser.
It's not that you can't use gdlib or other methods to resize the screenshots, it's just that even today there's no resizing at all, and the server relies on what the users are submitting, so you'd need some additional code. (+ a onetime resize for the current stock of screenshots)
It's not that you can't use gdlib or other methods to resize the screenshots, it's just that even today there's no resizing at all, and the server relies on what the users are submitting, so you'd need some additional code. (+ a onetime resize for the current stock of screenshots)
p01: Content negotiation is irrelevant in this case. (Unless you want to compensate for browser bugs)
All you really need to do is to send the correct MIME type for the image you're sending. Basically this is what you need:
All you really need to do is to send the correct MIME type for the image you're sending. Basically this is what you need:
Code:
The last line isn't necessary, but looks nicer if you choose to save the image. <?PHP
header("content-type: $mimetype");
readfile($filename);
header('Content-Disposition: inline; filename='.$filename_wothout_path);Yeah yeah sorry for the content negociation thing. I should have had a second look at the docs before mentionning it. :p
Resizing is tricky when you have static and animated images.
Beside chances are rather big that the clients will cache the images anyway so the having 2 versions of the screenshots might be counter productive.
Resizing is tricky when you have static and animated images.
Beside chances are rather big that the clients will cache the images anyway so the having 2 versions of the screenshots might be counter productive.
maybe i didnt understand exactly what we're talking about but you do know that we dont have the screenshot filetype name stored in the sql database right?.. to show it on prod.php we simple try all possibilies based on the prodid number with the possible filetypes attached (.gif, .jpg, .png) and whatever acuses existance is used..
uh ... didn't know that.
Well, that's one more reason to remove the files' extension altogether. It'll simplify prod.php and make it easier to show the screenshots anywhere else.
Well, that's one more reason to remove the files' extension altogether. It'll simplify prod.php and make it easier to show the screenshots anywhere else.
hmm.. im starting to get what you mean.
hmm.. hope gargaj reads this and implements it directly into pouet v2
hmm.. hope gargaj reads this and implements it directly into pouet v2
well take that piece of code, put it into a showimg.php?id=12345 like nitro said, and presto, userscripts are cooked up with no effort.
FWIW, I just removed the extension of a .jpg, a .gif and a .png and IE7, OP9.5b and FF3b2 opened them correctly.
Yes, that's a thing I forgot to mention in my last post. I've tested that too and all browsers I've tried have been clever and showed the image corectly with no/incorrect file extension and even with the wrong MIME type. (which is what browsers care about anyway)
Because, I hope the images in the search list will be thumbnails, not big ones???
Quote:
It's just a thumbnail in a result list. It's relatively rare for screenshots to contain a GIF animation. Just resize the first frame. Nobody will die.Resizing is tricky when you have static and animated images.
Quote:
How do you mean? I don't we should aim for having the same path to both the thumbnails and big image. Use showimg.php?id=12345 and showthumb.php?id=12345 or whatever is appropriate. Beside chances are rather big that the clients will cache the images anyway so the having 2 versions of the screenshots might be counter productive.
Because, I hope the images in the search list will be thumbnails, not big ones???
As for resizing screenshots to thumbnails, you could of course only resize them on demand in showthumb.php.
I mean to fetch the exact same file and have the browsers resize the screenshots in the search list.
Less effort and the screenshots will then be in cache when the user goes to a prod.php
Less effort and the screenshots will then be in cache when the user goes to a prod.php
It could be an interesting feature if you manage to make it without overloading the server and with small enough screenshots that leave the page readable without having to scroll 50 times to see the whole page :)
a lazy approach would be to let the browsers resize the default pouet screenshots by themselves.
That will make it painful to surf pouet on anything slow. Yes, slow internet connections do exist nowadays.
Preacher : it might also render prodlist.php much less readable.
You can currently see a lot of prods at once. That won't be the case anymore with screenshots.
You can currently see a lot of prods at once. That won't be the case anymore with screenshots.
ppl with slow internet connections should emigrate to kenya!
