menu.html.php. This serves two purposes:
1) It's more efficient since we're doing less passes over the Menu tree
2) We're allowing themers to decide whether or not to show empty menus
can override them and define their own menu formats. I worry a little
bit that this approach may be too heavy since we're now doing a lot
more template includes than we were before. Also, I had to change the
Menu API to stop using __toString() because you can't throw exceptions
from __toString() which would make it an unhappy experience for
developers.
and album covers in the context menu.
Notes:
- This requires context_menu() to have a CSS selector that refers to the
<img> that we're operating on, otherwise we don't know how to find the
thumbnail, etc.
- Create Menu_Element_Ajax_Link which has an ajax_handler attribute
that contains a snippet of JS that we're going to run when the ajax
call returns.
- Add $.gallery_replace_image in gallery.common.js
- Add lib/gallery.ajax.js which can be used to ajaxify any link, and have
ui.init.js in the themes call that on all .gAjaxLink elements.
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.
1) Stop changing the menu classes in JS, instead allow us to specify
it in the Menu class itself and then set it to be gThumbMenu in Theme_View
2) Move the gThumbMenu init code to the bottom of the $(document).ready() block;
something in there was interfering with it.
1) Stored the menu element type in the menu element
2) Scanned the menu before display removing any empty sub menus.
Went with the removal approach because there will more users than developers
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.
Bharat Mediratta
Andy StaudacherandTim Almdal
Chad Kieffer