Last modified: 2014-09-24 01:22:00 UTC
The gallery syntax is highly useful, but it assumes one monitor size and resolution for everyone. First, the generated HTML gallery-block should not have a fixed width, but rather expand to fill the width of the browser. This would prevent the images from squishing up against the left side of the window on high-resolution displays. (Or, for that matter, displaying as a long, narrow strip down the middle if the gallery itself is centered.) Second, the thumbnail size used in the gallery should be configurable, preferably through a user setting. (Allowing constructs like [gallery thumbsize=200px] is asking for trouble.) Thus, a user on a 640x480 display could use 100x100px thumbnails, while a user on a 1280x960 display (or someone who just likes their thumbnails big) could use 200x200px. To prevent an overload of thumbnails, the server could provide a few standard resolutions for the user to pick from, say 50, 100, 150, 200, 300 and 400 pixels square.
Created attachment 572 [details] Allow to configure the size of the thumb, the number of columns, and the layout Proposed patch : Each user can select its option in Special:Preferences, anonymous use default settings. * Allow to choose the gallery thumbnail image size (default 120x120) * Allow to choose a gallery layout with or without the table tag (default table layout) * Allow to choose the number of columns (between 1 and 20 columns) per line (default 4)
The changes you made will taint the parsercache which means you have to include change the page rendering hash in your patch, see User::getPageRenderingHash()
Created attachment 573 [details] small patch proposed for this bug Same patch as before with some corrections (one warning corrected, better tab indenting, and rendering hash updated)
Wontfix it as it would decrease the caches efficiency.
Hmm, I probably acted too quickly because of a bad mood (and I apologize for that). I will let a developper juge about that feature request.
In general I'm against multiple thumb sizes as it reduces parser cache reusage and wastes disk space and CPU time unnecessarily. There's invalid XHTML in the preferences. The prefs value validation seems to be going on in the wrong places. There doesn't seem to be protection against invalid size selection values being input or stored. Changing the size set later could change the stored prefs in odd ways, since an index is stored and this may change or become invalid. Check boxes are being treated as ints? It's unclear to me why some of these preferences are added; why a column width *and* a table-less layout? If the table-less layout actually works correctly (eg, wrapping to any window size) that should be the only layout used, and there would be no column width option.
I strongly support Brions opinion about removing the column width. There should only be the gallery layout without tables, which would automatically adopt to the browser width. If you want to make some advanced layout (probably in seldom cases), just don't use a gallery, but put a table construction or other HTML/CSS based thing around it. There is absolutely no need to have multiple different implementations of the same solution (gallery, tables, CSS) for the same problem. On a second note I would suggest to split this enhancement request into 2 separate requests. The user selectable thumbnail size should be handled independent of the table-less layout. Mixing multiple features into a single patch always makes it harder to accept and further develop the code.
Multiple thumb sizes have now been implemented in 1.5, but they don't affect the gallery tags. I think what would be most useful is the option to configure the number of columns in the gallery, keeping the default image width as it is now.
I really think you should allow the user to specify how many images in a gallery are displayed in one row. Right now, I'm using a 1280×960 display, which would allow me to display six images in one row of a gallery, but right now, that value is hard-coded at four.
(In reply to comment #9) > I really think you should allow the user to specify how many images in a gallery > are displayed in one row. Right now, I'm using a 1280×960 display, which would > allow me to display six images in one row of a gallery Yes, but consider that the rendering is cached for more than one user, not all of whom would have that resolution...
The size issue is covered in bug 3276, so I'm refocusing this bug.
brMW0sqgRr
Oops... ;-) copy and pasted the wrong thing! It would be enough to stick to inline images or the use of <div float="left">-related stuff... the same content will then display differently on each browser. If we put the whole thing into a variable-size table, we can even make the heading centered to the actual width of the gallery! Also, as long as there are no triangle-shaped screens, the gallery will have its consistent width.
That's bug 3276, which is distinct from this bug. This bug pertains to using user preferences to set default sizes for galleries, which may be desired for reasons of detail or display size distinct from those solved by fluid gallery width.
Strongly support adding this as a user preferences option; it looks like a design fault to me that a user can change the standard size for thumbs from default (180px?) to something else but cannot change the standard size for gallery images (120px?).
*** Bug 18843 has been marked as a duplicate of this bug. ***
Will this request be approved? Can someone give us an answer?
*** Bug 20782 has been marked as a duplicate of this bug. ***
I don't think, there has to be an distinct option for the thumbnail size in galleries. Only two lines in ImageGallery::__construct need to be added to do the trick: > global $wgUser, $wgThumbUpright; > $mWidths = $mHeights = 2 / 3 * $wgThumbLimits[$wgUser->getOption('thumbsize')]; ((Sorry for Bug 20782, grep'd for "gallery", forgetting "galleries"))
*Bulk BZ Change: +Patch to open bugs with patches attached that are missing the keyword*
Adding the "reviewed" keyword since it looks like Brion reviewed the patch in comment 6. And adding "design" keyword since adding user preference options is also a visual design/UI decision.
This is an old bug. > The gallery syntax is highly useful, but it assumes one monitor size and > resolution for everyone. > > First, the generated HTML gallery-block should not have a fixed width, but > rather expand to fill the width of the browser. This would prevent the images > from squishing up against the left side of the window on high-resolution > displays. (Or, for that matter, displaying as a long, narrow strip down the > middle if the gallery itself is centered.) This has been fixed. See bug 3276 and r77411 > Second, the thumbnail size used in the gallery should be configurable, > preferably through a user setting. (Allowing constructs like [gallery > thumbsize=200px] is asking for trouble.) Thus, a user on a 640x480 display could > use 100x100px thumbnails, while a user on a 1280x960 display (or someone who > just likes their thumbnails big) could use 200x200px. To prevent an overload of > thumbnails, the server could provide a few standard resolutions for the user to > pick from, say 50, 100, 150, 200, 300 and 400 pixels square. We already have a thumbnail size preference (see comment 8). I'm not fan of it, but given it has duplicates bug 20782 and bug 20782, should probably be implemented.
The usre pref "thumbnail size" shoudl affect galleries with no given sizes. 6 years old bug and no fix yet :/
Ideally thumbnail size would be controlled by the skin, not individual users. This is because skins already optimizing for a variety of screen sizes, and the size of the thumbnail image should work together with those optimizations.
