…FC3986 encode call to convert 'plain vanilla' path to something that's W3C/browser compliant.
…) but Request.Queue seems to have an issue with not really cleaning up the .requests object in there... :-S
…fic SUBSET of queued requests: you do NOT want to abort/cancel populate requests (gallery loading!) while you DO want to kill thumbnail fetches for a directory list ('fill') as soon as you click on a subdirectory to go there. Also, 'detail' requests are not canceled as those may be for purposes where a thumbnail MUST be obtained.
…lla JSON object (JS object, really); they are not extracted from some piece of HTML, so we DO NOT want to URLdecode these paths!
…those items which don't come with a thumbnail (this can happen for quite a few filetypes, also for overlarge images and files which otherwise failed to have the server produce a thumbnail for them)
…ized; this is particularly important for smaller (less wide) viewports!
…for the renamed entity would be shown but the thumbnail collective would be displayed for the current dir; that is very counter-intuitive, so now thumbnail collective is only shown when the detail of the CURRENT directory is displayed.
…S entities specified before)
…'PSDs' branch but not get in here! (Merge thus includes several nasty demo image files for testing anything you do to / with the MTFM. :-) )
…an merge and aftermath); Demos/gallery-demo.php has been extended to showcase the metadata and serialized output as it is now; it shows the gallery you contructed using MTFM as a series of thumbnails, on which you can click to see the gallery as a milkbox gallery. :-) (Plus showcasing the metadata by providing a slider which can change the size of the thumbnails shown in the HTML page itself. Try it with a series of images!)
…ing home the point these buggers make, I don't know what will... :-))
…ed file.path or .dir + .name: new regime does NOT URLencode file.path any more; the only things URLencoded by the server are the icon and thumb URLs (file.thumb48 / .thumb250 / .icon / .icon48 ); that means any path fed to a FM caller or places in HTML code must be URLencoded by FM frontend (see 'complete' fireEvent call in FileManager.js. Commit is clunky: known issues: + upload kinda works, but the current directory path is b0rked so you 'jump back' to root after upload + gallery is still a problem child: as before, selected file paths are returned unencoded and in 'legal URL space' instead of as absolute URLs + rename, delete & drag&drop move/copy are untested and probably with a path bug or two of their own
…at create and rename dialogs now indeed get focus on their input fields, even in Safari / Chrome.
…at least failures when used with the caption editor there have been fixed re event bubbling. I'm sure MTFM has more keyboard event issues lurking in the dark.
Also tweaked a few calls so diag.log()s show less 'undefined' fields: those trigger me to go investigating as I've had lots of trouble with MSIE b0rking on things like that, while FF et al were fine.
… this one when you're using a framework which needs its URLs tweaked (e.g. frameworks which want their request _not_ encoded in the query section of the URL)
… to turn the special filtering example code on/off simply by changing the define at the top of the file.
…ent!) requirement not listed in header + fix for the [ESC] key: when hit in milkbox, it would close both milkbox AND MTFM. (Though the second issue seems a little more complex; it only went away when I cleared my browser cache in Safari)