the end which triggers .gallery_show_loading(). Not a complete fix
for #817 but it's a start and it takes care of one place where we have
a long running process.
I think this was broken in a recent jQuery update. It used to allow matching the HTML "name" attribute with #name_value, now you need to match by elementName[name=name_value].
the "context" menu.
This new context menu is generated using the typical event processing
system, like our other menus. The specialized quick CSS and JS is now
gone, replaced by our generic menu handling code. It's all rolled
together currently using the thumb_menu UI for easy packaging. All
the CSS and JS is updated.
NOTE: the non-dialog links (rotate, album_cover) have a broken UI
because they return JSON which the quick.js code handled specially,
but we don't handle properly now. I need to fix this.
from using a single gQuickPane <div> that we move around. A race
condition happens when you mouse over two thumbnails quickly.
Whichever server response loses the race gets displayed, and sometimes
it's the one that you're no longer hovering over.
Fix it by changing gQuickPane to be a class and creating a <div> per
thumbnail.
Fixes ticket #290.
action. The expectation is that we're going to reload the page (or
redirect to a new url). If we close the dialog, then we can trigger
the onhover for items we've just deleted causing errors.
Simplify the API while we're at it by getting rid of the no-longer-used
on_success argument to openDialog()
This fixes#528.
Kohana makes this type of transition fairly straightforward in that
all controllers/helpers/etc are still located in the cascading
filesystem without any extra effort, except that I've temporarily
added a hack to force modules/gallery into the module path.
Rename what's left of "core" to be "application" so that it conforms
more closely to the Kohana standard (basically, just
application/config/config.php which is the minimal thing that you need
in the application directory)
There's still considerable work left to be done here.
