Last night, I put a new widget into a new class in dojox. dojox.image class will be the home of widgets and utilities that use a common API to do image-manipulation, or grouping. So far, the idea consists of: dojox.image: SlideShow, LightBox, Gallery, Picker, carousel (sp), and Pane (the last being the basic, maybe even private img holder widget powering the various parts).. for some reason I cannot press enter right now? Anyhow, the LightBox is the first to land, and almost has working dojox.data.FlickrStore support, individual images work, and groups when no FlickrStore query is present work. you can see it here for now: http://archive.dojotoolkit.org/nightly/checkout/dojox/image/tests/test_L... ... This forum is here to discuss API suggestions, or to track bad behavior found in the widget. I need to fill in the README, and LightBox admittedly needs a cleanup, as I believe it could run just a little more smoothly.
For starters...
...it should probably be one word, not two camel-cased (i.e. "Lightbox")...otherwise this is great, great stuff.
One suggestion would be to have thumbnails of a group of images on the bottom of the lightbox as an alternate method of navigation...oh, and play/pause.
Lightbox would break the
Lightbox would break the convention that dijit has established of Box, like ComboBox and DateTimeBox and whatnot. Would it not make more sense to match all that, to ease confusion?
I was thinking a dojox.image.ThumbnailList or something would be useful. If LightBox got the common API where you could set 'galleries' and easily update the image node, a ThumbnailList from the images in said gallery would be easy to do, and be easily included in an alternate LightBox.html template (with widgetsInTemplate) ...
as far as play/pause goes, i'd rather wait to see how SlideShow makes use of the (theorietical) ImagePane, and how that can be incorporated back into LightBox, though I think the animation between images would not be as fun when transitioning is automated. seems like maintaining a fixed-sized dialog (or embedded in a page like normal, eg: non-modal) and making the image's max w or h value match the box (scale to fit) would be better for SlideShow?
the API idea is something like (and this is a first draft of tought):
* dojox.image.Pane provides:
setImage() resizeTo() and some other basic image-normalizing things (like an onLoad hook,
or a way to otherwise preLoad images.
* dojox.image.PaneGroup (?) { stack controller? }
an extension on image.Pane (or mixin?) that adds the 'slideshow/gallery' like features:
provides addGroup, addGroupImage, shuffleGroup, removeGroupImage, etc.
so LightBox is a Dialog/Pane (single image) or a Dialog/PaneGroup (from JSON data [ItemFileReadStore, FlickrStore] or a generic list of dojox.image.Panes from markup), all reusing one modal Dialog, and tracking it's own groups (slideshows).
and a SlideShow would be a PaneGroup + _Templated to add in it's own navigation and whatnot via the same API.
is this sound? or am i getting carried away?
should each proposed widget at least TRY to match the common API? Seems like a lot of redundancy could be eliminated by incorporating all the ideas around a solid API.
Normally I'd agree...but...
Normally I'd agree with you but for two reasons:
WRT to the other ideas, I think they are all fine but I think it's really easy to get carried away, and you might be doing that here. Remember the mantra: SIMPLE SIMPLE SIMPLE :)
Large image support
Lightbox works quite well as long as the image is smaller than the browser window size. If it's larger, using the scrollbars repeatedly fires the window.onresize event and besides getting a crazy jitter effect, you can't scroll down to the close button because the dialog keeps repositioning itself.
For my purposes, the ideal solution for images larger than the window would be for the dialog to take up the whole window and put scrollbars on the image itself, with the caption and controls at the bottom always staying visible. That may be more trouble than it's worth and may not even be possible, but it would be nice.
sounds reasonable
sounds reasonable.
especially in cases where even a seemingly "small" image is bigger in one dimension than the browser (eg: wow i have firebug open and viewed the lightbox and now these events are going nuts) ...
or the images from the Flickr datastore happen to be bigger ...
would you mind to file a ticket against my name at trac.dojotoolkit.org (l/p: guest/guest) as an enhancement request stating that same thing (or even just linking to this forum topic)?
not so sure about making the internal pane have scrollbars, but it's feasible to scale an image to a size that will always fit the viewport. i think it could be done without any real performance hit.
just stumbled on this problem myself
I'm sure the fix you gave works (haven't had a chance to try it yet) but isn't there also an accompanying issue with dijit.Dialog? The same issue happens with Dialog boxes. If the box is bigger than the viewport or if the browser window is resized so that the viewport is smaller than the dialog box the same issues arise. I was having the same trouble with Lightbox but noticed the resize wasn't in its code. So I checked out dijit.Dialog and found where it was happening:
// summary: position modal dialog in center of screen
if(dojo.hasClass(dojo.body(),"dojoMove")){ return; }
var viewport = dijit.getViewport();
var mb = dojo.marginBox(this.domNode);
var style = this.domNode.style;
style.left = Math.floor((viewport.l + (viewport.w - mb.w)/2)) + "px";
style.top = Math.floor((viewport.t + (viewport.h - mb.h)/2)) + "px";
}
Specifically, here:
style.left = Math.floor((viewport.l + (viewport.w - mb.w)/2)) + "px";
style.top = Math.floor((viewport.t + (viewport.h - mb.h)/2)) + "px";
The issue is the same as lightbox (which makes sense it inherits from Dialog :D). It constantly repositions so that when you scroll down to get to the bottom of the Dialog box, it lets you scroll down infinitely.
I didn't see a ticket associated with this issue, and it seems to me that it should be addressed as well.
I made a very, very simple fix for myself that just checked if the mb.w,mb.h were greater than the viewport.w, viewport.h then don't change the style (which pretty much does the trick, but has obvious drawbacks). I'm new to the dojo world, should I post the existence of this issue elsewhere? Also, if there is a ticket for this issue already and I missed it then I apologize :D