| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Although this may look weird on a first sight it does the trick.
Perhaps as a result of another bug in recent Webkit-based browsers,
still good enough for the time being.
|
|
|
|
Fractional HiDPI scaling (1.5x) on newer Webkit-based browsers tend
to cause extra black borders around the index item thumbnails due to
rounding error. Turned out borders created by CSS box-shadow are
rendered differently and less prone to rounding errors. Though this
way of border rendering is slightly different but generally more
acceptable.
|
|
Odd base image sizes are a real problem for fractional scaling (HiDPI 1.5x).
|
|
Recent Webkit-based browsers tend to animate link colour from builtin one
(blue) once the common CSS stylesheet file gets loaded, resulting in
unwanted animation. So set a sane default color within the HTML files
so that the animation goes unnoticed. Still would be great to disable
initial transitions altogether.
|
|
Let the album thumbnails shine, no need to dim them as we really want
to present the albums.
|
|
Useful for 4k size where additional HiDPI sizes (i.e. 6k and 8k) are
overkill to generate and aren't very common on the market yet.
|
|
Suitable for >30" native 4k screens with no scaling.
|
|
Tested on various common resolutions with standard browser and system toolbars.
|
|
This works by creating corresponding hidpi image sizes on startup and
letting the machinery generate high resolution images from the source
images (no way to use supplied images). However since browsers expect
exact image dimension multiples for the particular scale factor,
a reference image size (scale factor 1.0x) must be read first, then
cropped to match reference aspect ratio and resized to exact dimensions.
That way pixel-perfect results can be achieved for the chosen scale
factor.
TODO: the CSS background-image: image-set() tags are not supported
on Firefox.
TODO: try the 1.5x scale factor
|
|
This change brings the possibility to tweak resize options using standard
ImageMagick `convert` command syntax. Separate options are offered for
thumbnails.
|
|
This is a huge step forward in terms of usability and simplicity.
Image sizes are now determined by browser automatically based
on window width.
As a result the image size switch buttons have been removed and only
a single page is generated (index.html).
Note: in order to make image title, description and EXIF table
dynamically aligned to the image width, "display: table" and relatives
were used. This may not be the best webdesigner practice but it's
an effective and sufficient approach for the moment.
|
|
This commit brings deeper changes to the image sizes concept. The goal
was to allow more flexible input in resizing vs. supplied files mixed
mode. Instead of hard <noresize> flags the decision whether to resize
or copy an image is now based on threshold. While not 100% universal,
it brings more control regarding image size bounds. Also brings a level
of tolerance for specific errors (off-by-one exports).
Image sizes' rules are a bit simpler, hopefully easier to understand.
A lot can be achieved by combination of thresholds.
|
|
Introducing a modern looking theme that changes gallery philosophy a bit.
Instead of having thumbnails on an album page and photos on separate pages
this new design brings emphasis on story telling. Viewer is advised to
go through the whole album sequentially, bringing atmosphere to the whole
set.
All photos are loaded within a single page and keyboard navigation via
left/right arrows is supposed to be used to switch the presentation
mode on.
Three photo sizes are supported now with the 'preview' size being the
default. High resolution size has been introduced for 2560x1440 screens
and larger.
Note that this template uses code from 3rd parties, see CREDITS for
details. I haven't been able to contact anyone behind the TheCodePlayer.com
project so licensing of the breadcrumbs might be an issue.
|
|
Let's call this design a "classic" one.
|
|
This changes image size handling a little bit. An optional <fallback size="xxx" />
tag tells the generator to use different image size when an image for the current
image size has not been supplied from the album XML file.
This is effectively used for the legacy <nofullsize> tag fallback. More generally
this is useful for templates showing additional image sizes. Also saves space as
images not having the custom size supplied are not generated from the source image.
|
|
... just a matter of personal taste.
Note: this breaks the template API only in current unreleased versions.
|
|
This commit brings full flexibility of custom image size definition and
usage. When a custom image size is defined, it automatically maps to the
album <item> tag arguments. Alternatively, this automatic name matching
can be overriden by <size tagname="..."> theme setup tags.
This allows us to supply image of different sizes that can be also used
in templates.
Legacy behaviour of "fullsize" and "preview" image size fallback is
retained (though not recommended in new theming setups).
|
|
Turned out there was no need for having most of the picture page
closed in a block.
|
|
This mode retains given aspect ratio and crops the area from inside of the
source image.
|
|
This commit makes use of a common function for all template parsing and page
writing. The behaviour is controlled by the "item" argument passed in. This
allows us to have a single code that generates code for list of items as well
as for a single item. In the future, this can be used for e.g. combining
thumbnails and large images on the same page.
Other than that this commit also brings several other changes:
- further clarification of theming setup XML file
- <protected_thumbnail> tag has been moved out of the <album> structure into
the <index> structure where it functionally belongs. Only whole albums can
be protected and the substitute thumbnail is displayed on index pages.
- position marker format has been broken out to a constant
- added few more FIXMEs to mark places that will change soon
- some template variables have been renamed
|
|
Navigation bar can be complex and comprises of several different elements.
Until now the navigation bar was almost hardcoded. We needed to separate
different types of navigation bar elements:
* NAV_BAR_FIRST
- the first element, usually denoting gallery root. This element takes
priority and is used when there are no other elements in the path.
* NAV_BAR_ELEM
- normal element used in the path between first and last elements.
* NAV_BAR_LAST
- ending element, guaranteed there's at least the NAV_BAR_FIRST element
before.
* NAV_BAR_CURRENT
- non-clickable informational element displaying the current page title.
Optional, in contrast to the former three defines.
* NAV_BAR_CURRENT_ROOT
- a special case of the latter one, displayed at the very root page.
Also optional, in that case the navigation bar would become empty.
|
|
This change makes thumbnail image sizes more flexible by explicitly
stating the particular image size is a thumbnail. And each thumbnail
image size can have different squared settings.
On the theme side it's now mandatory to specify which thumbnail size
to use (if applicable). This allows us to have different thumbnail styles
for index and album pages.
This commit also removes the <squared_thumbnails> tag from setup.xml
file but retains fallback for ver. 1 setup.xml files.
|
|
Although probably not very common scenario, let's be consistent across
all defined image sizes and clearly state that an explicitly supplied
image file for an optional image size should carry the tag in order
not to get resized.
|
|
Adding notes mostly about legacy features.
|
|
This commit makes setup files (setup.xml and referenced design
setup xml file) versioned and adds checks for correct versions.
If a newer versioned file is detected, warning is printed out
in assumption that a stray cgg version is used.
If the version information is missing or is lower than expected
version, files are read in legacy mode. Some values are left
on defaults and missing mandatory values are either read from
renamed keys or made up to suit current requirements.
This essentially brings back compatibility with old setup.xml
files that are usually part of galleries.
However, some values are hardcoded and should be kept in mind
to update and test the legacy mode along with future enhancements.
|
|
Some browsers may understand this tag and use the associated link for
easy transition to the next item.
While in case the link points to the index page the rel="index" value
should be used, we would lose browser capability to determine previous/next
page for transitioning, thus hardcoding for our case.
http://mail.xfce.org/pipermail/xfce/2011-August/028993.html
http://mail.xfce.org/pipermail/xfce4-commits/2011-March/017929.html
http://microformats.org/wiki/existing-rel-values
|
|
Also adds IS_PROTECTED define in local item scope.
|
|
|
|
For the moment we're using Exif.CanonSi.0x000c key from Exiv2 namespace
since it's an unknown tag to it. This may need little tweaking in the
future when proper naming becomes upstream.
|
|
This brings a new HAS_EXIF define which is present when
EXIF information are available. Templates have been modified
to inform user when not available.
The test for EXIF metadata presence is fairly basic, we only look
for aperture, focal length and exposure time attributes. This might
be a subject to change in the future.
|
|
This allows much greater flexibility from templates regarding
EXIF metadata handling, no more hardcoded symbols. It's possible
to display essentially any attribute known to Exiv2. Please see
http://exiv2.org/metadata.html
This brings two new functions that can be called from templates:
* get_exif_value (exiv2_attribute)
* get_exif_value_fixed (exiv2_attribute)
Both functions take a string argument of metadata attribute name
from Exiv2 namespace. The difference is that get_exif_value_fixed()
does some extra formatting for several basic attributes
(e.g. datetime format).
|
|
|
|
|
|
|
|
This change allows greater flexibility for separate themes.
|
|
This is very basic scripting support - simple value retrieval and
block conditionals. Defines could be either static from theme setup
or programatically added during page generation.
|
|
This extends current templating system to another dimension,
bringing the possibility to have multiple themes generated
at once. The purpose is to be able to switch between multiple
designs, from PC to mobile, classic vs. flat view, slideshow, etc.
For the moment, only the classic theme is available.
Rules:
* for switching between themes, place a link inside your template
manually - it's not a cgg concern, only your theming infrastructure
* don't forget to define different file names for index and album
pages across different themes
* it's recommended to keep default theme named as "index.*" to avoid
showing directory listing on webserver
Notes:
* some TODOs will be fixed when we have new theme using these advanced
features (e.g. pictures in album pages)
* TODO: introduce tag/block conditional system, allow custom user
defines for each theme/page
* TODO: deprecate <show_go_up>, <show_exif_table> and <border style>
in favor of conditionals (these tags belong to theming)
|
|
This will hopefully fix all known scrolling issues as we got rid of
the master content scrolling div. Needs to be tested thoroughly on
touchscreen browsers.
Also, paging by the Space key works now once page is rendered.
|
|
|
|
Disabled by default, only very simple center crop implemented.
The SQUARED_SIMPLE_SHAVE_AMOUNT constant may be slightly adjusted
according to future experience. It's a really dumb algorithm which
may not be suitable for every picture.
Looking for a fast and smart algorithm to determine image weight center
and radius, i.e. focus on object of interest. The OpenCV's face recognition
features are worth to test and consider, though I fear the speed issues.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Dist sample source structure
- automake always deference symlinks, we need to find better way to handle the sample structure
|
|
|
|
|
