| Age | Commit message (Collapse) | Author | Files | Lines |
|
Also adds IS_PROTECTED define in local item scope.
|
|
This change allows using local defines related to each item in the album
or index page.
|
|
This allows us to retrieve unmodified block data that could be used
for conditional processing later.
|
|
|
|
Errors may very well appear on file closing.
TODO: Go through all other file writes and add more checks.
|
|
This adds support for simple password protected areas (albums and
all subalbums) through webserver HTTP authentication. CGG simply
generates .htaccess and password files and it's up to the user to
set up the rest on server side.
No UI changes at this point. Limited to one user per album for
the moment.
|
|
More and more we need to know local and public locations for various
features. Let's introduce general keys once and for all.
|
|
And change g_str_has_prefix() for key name comparison to g_str_equal()
to prevent potential prefix clashes.
|
|
|
|
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 an ability to specify external file to read EXIF/IPTC
data from. The motivation was to work around RAW editors randomly
stripping some EXIF blocks.
|
|
|
|
Simple check whether the EXIF/IPTC key is available for the current
image. Precisely one argument is required, similar to the get_exif_value()
custom function, an Exiv2 metadata attribute string is expected.
This allows templates to change behaviour when certain metadata key
is not present (e.g. don't print the particular table line at all).
|
|
Specifying all arguments in endif() or else() for custom block
functions reduces code readability and debugging comfort.
Let's be less strict and don't require them.
A simple test for function name should be enough, moreover nesting
is not limited by this change at all.
|
|
Similar to replace-table custom functions, this brings an ability
to register custom block functions that can be called from templates
with variable arguments.
The syntax is as follows:
<!-- $(if (function_name(arg1, "arg2", 'arg3'))) -->
...
<!-- $(endif (function_name(arg1, "arg2", 'arg3'))) -->
An optional exclamation mark before the function name reverts the result
(negates) the predicate.
This allows template flexibility with respect to the currently processed image.
|
|
Please shout if it breaks compilation against older glib versions
|
|
Some of us like to have indented arguments from a function name.
|
|
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 adds a support for custom (registered) functions that can be called
from templates with specified arguments.
The syntax is as follows:
<!-- $(function_name(arg1, "arg2", 'arg3')) -->
Arguments are separated by a comma and can be quoted (recommended).
Quoted arguments are allowed to contain a comma as well as another
quote when escaped with a backslash.
To call a function with no arguments just do "function_name()".
Functions are supposed to be registered before actual data are parsed
and are called back from within the parser cycle.
|
|
|
|
|
|
This comes with a cost of decoding full image when only getting image size.
|
|
|
|
|
|
|
|
This change allows greater flexibility for separate themes.
|
|
And also bring back glib/gprintf.h include for g_vasprintf().
|
|
This allows actual defines to be used without explicit update.
Also brings the benefit of placing empty string when define is not defined.
|
|
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)
|
|
Some blocks such as "IMG_LIST" are containers themselves and no data
are retrieved from them. That way they don't ever get marked as used,
resulting in constant hit in the generator loop.
|
|
|
|
And convert it to use global path info.
|
|
No need to store generated data during thread work anymore.
|
|
|
|
This has a nice side effect of not having double slashes in paths anymore.
|
|
This will allow us to pass detailed path info to worker methods.
Each path info instance is bound to a currently processed album
and directory.
Possibly move to struct TItems in the future.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|