Last modified: 2014-09-24 01:22:00 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T3340, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 1340 - Size thumbnails in galleries according to user preferences
Size thumbnails in galleries according to user preferences
Status: REOPENED
Product: MediaWiki
Classification: Unclassified
Parser (Other open bugs)
unspecified
All All
: Low minor with 9 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
: design, patch, patch-reviewed
: 18843 20782 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2005-01-16 01:31 UTC by grendelkhan
Modified: 2014-09-24 01:22 UTC (History)
8 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments
Allow to configure the size of the thumb, the number of columns, and the layout (10.68 KB, patch)
2005-05-24 13:06 UTC, FoeNyx
Details
small patch proposed for this bug (11.41 KB, patch)
2005-05-24 15:10 UTC, FoeNyx
Details

Description grendelkhan 2005-01-16 01:31:27 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.
Comment 1 FoeNyx 2005-05-24 13:06:18 UTC
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)
Comment 2 Ævar Arnfjörð Bjarmason 2005-05-24 13:26:44 UTC
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()
Comment 3 FoeNyx 2005-05-24 15:10:15 UTC
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)
Comment 4 FoeNyx 2005-05-24 15:28:16 UTC
Wontfix it as it would decrease the caches efficiency.
Comment 5 FoeNyx 2005-05-24 17:29:01 UTC
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.
Comment 6 Brion Vibber 2005-05-31 09:54:24 UTC
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.
Comment 7 Michael Keppler 2005-06-02 17:54:58 UTC
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.
Comment 8 Duncan Harris 2005-09-20 14:45:23 UTC
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.
Comment 9 denelson83 2006-05-16 04:23:41 UTC
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.
Comment 10 Rob Church 2006-05-16 11:03:25 UTC
(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...
Comment 11 Rob Church 2006-12-26 05:33:51 UTC
The size issue is covered in bug 3276, so I'm refocusing this bug.
Comment 12 Lazer erazer 2007-03-05 19:07:35 UTC
brMW0sqgRr
Comment 13 Lazer erazer 2007-03-05 19:09:45 UTC
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.
Comment 14 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-03-06 01:50:21 UTC
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.
Comment 15 PDD 2007-04-17 00:54:41 UTC
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?).
Comment 16 Chad H. 2009-05-19 15:13:02 UTC
*** Bug 18843 has been marked as a duplicate of this bug. ***
Comment 17 百楽兎 2009-05-20 11:27:32 UTC
Will this request be approved?
Can someone give us an answer?
Comment 18 Malkovic 2009-09-23 13:09:11 UTC
*** Bug 20782 has been marked as a duplicate of this bug. ***
Comment 19 René Kijewski 2009-09-23 13:24:36 UTC
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"))
Comment 20 p858snake 2011-04-30 00:09:05 UTC
*Bulk BZ Change: +Patch to open bugs with patches attached that are missing the keyword*
Comment 21 Sumana Harihareswara 2011-11-09 16:39:06 UTC
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.
Comment 22 Platonides 2011-11-09 16:55:14 UTC
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.
Comment 23 Subfader 2012-02-22 14:37:11 UTC
The usre pref "thumbnail size" shoudl affect galleries with no given sizes.

6 years old bug and no fix yet :/
Comment 24 Trevor Parscal 2013-02-27 20:13:02 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links