Result:
found more than 662 distributions - search limited to the first 2001 files matching your query
( run in 1.468 )
Template-Declare
view release on metacpan or search on metacpan
lib/Template/Declare/TagSet/XUL.pm view on Meta::CPAN
iframe image implementation key
keyset label listbox listcell
listcol listcols listhead listheader
listitem member menu menubar
menuitem menulist menupopup menuseparator
method observes overlay page
parameter popup popupset progressmeter
property radio radiogroup rdf
resizer resources richlistbox row rows
rule script scrollbar scrollbox
separator setter spacer splitter
lib/Template/Declare/TagSet/XUL.pm view on Meta::CPAN
=item C<method>
=item C<observes>
=item C<overlay>
=item C<page>
=item C<parameter>
Template-Lace
view release on metacpan or search on metacpan
lib/Template/Lace.pm view on Meta::CPAN
specification, you would prepend a '@' to the front of it (think in Perl @variable means an
array variable). In the given example "css=\'@link'" we want the attribute 'css' to be a
collection of all the linked stylesheets in the current DOM.
You will use this type of value when you are making components that do complex layout
and overlays of the current DOM (such as when you are creating a master layout page for
your website).
=back
In addition to any attributes you pass to a component via a declaration as described above
lib/Template/Lace.pm view on Meta::CPAN
So four attributes, all coming from the DOM associated with the 'content' area of this component. We
grab the content of the title tag and the content of the HTML body tag, as well as the collection (if
any) of the link takes (for css style sheets) and any template specific meta tags.
If you are looking carefully you have noticed instead of a 'process_dom' method we have a 'on_component_add' method. We could do this with 'process_dom' but that method runs for every request and since this overlay contains no dynamic request bound ...
Here's a sample of the actual result, rendering all the components (you can peek at the repository which has all the code for these examples to see how it all works)
<html>
<head>
Template-Multipass
view release on metacpan or search on metacpan
lib/Template/Multipass.pm view on Meta::CPAN
my $opts = $config->{MULTIPASS};
$self->{_multipass}{config} = $opts;
$self->{_multipass}{vars} = $opts->{VARS} || {};
my $overlay = {
$self->default_meta_options,
%$opts,
};
delete $overlay->{VARS};
$self->{_multipass}{config_overlay} = $overlay;
$self->SUPER::_init( $config, @args );
Data::Visitor::Callback->new(
ignore_return_values => 1,
lib/Template/Multipass.pm view on Meta::CPAN
# process( ...., { meta_opts => { blah } } ) causes { blah } to be given to the inner process used on the meta template
my $opts = $self->{_multipass}{captured_process_opts}{meta_opts} || {};
# calculate the configuration and variables for the meta pass
my $overlay = $self->{_multipass}{config_overlay}; # constructed at _init
local @{ $self->{_multipass}{captured_config} }{ keys %$overlay } = values %$overlay; # START_TAG, END_TAG etc
my $vars = $self->{_multipass}{merged_meta_vars}; # merged by process at the top of the call chain
local $@;
# dispatch the original method on the provider, getting the original result
lib/Template/Multipass.pm view on Meta::CPAN
unless the variables have been changed.
=head1 CONFIGURATION
The configuration values inside C<MULTIPASS> in the top level config will be
overlayed on top of the normal config during meta template processing. This
works for values such as C<START_TAG> and C<END_TAG> (which default to C<{%>
and C<%}>), and may work for other values.
Additionallly the C<MULTIPASS> hash can take a C<VARS> hash to be used as the
meta vars in all runs.
Template-Plugin-ForumCode
view release on metacpan or search on metacpan
examples/MessagePreview.js view on Meta::CPAN
var pWidth = obj.user_input.clientWidth,
pHeight = obj.user_input.clientHeight,
pLeft = obj.user_input.offsetLeft,
pTop = obj.user_input.offsetTop;
obj.preview_overlay = new YAHOO.widget.Overlay(
obj.previewElId,
{
context: [obj.config.user_input, 'tl', 'tl'],
visible: true,
width: obj.user_input.clientWidth + 'px',
height: obj.user_input.clientHeight + 'px',
class: 'message-preview-overlay'
}
);
obj.preview_overlay.setBody(data.formatted);
obj.preview_overlay.render(document.body);
//Dom.get('preview_overlay').style.overflow = 'auto';
Dom.get(obj.previewElId).style.overflow = 'auto';
// I'm sure there's a better way to do this!
Dom.get(obj.previewElId).className = Dom.get(obj.previewElId).className + ' message-preview-overlay';
// update the button
obj.setClicker(
{
icon: obj.config.icon_edit,
examples/MessagePreview.js view on Meta::CPAN
label: this.config.label_preview
}
);
this.user_input.style.visibility = 'visible';
this.preview_overlay.destroy();
YU.Event.removeListener( this.trigger, 'click' );
YU.Event.addListener(
this.trigger,
this.config.trigger_evt,
Template-Pure
view release on metacpan or search on metacpan
lib/Template/Pure.pm view on Meta::CPAN
$t->data_at_path($data, $src)->($dom);
},
"*[data-pure-filter-id=filter-$params{cnt}]\@data-pure-filter-id", sub { undef },
);
}
} elsif($target eq 'pure-overlay') {
$params{node}->following('*')->first->attr('data-pure-overlay-id'=>"overlay-$params{cnt}");
$params{node}->remove;
push @{$params{directives}}, (
"^*[data-pure-overlay-id=overlay-$params{cnt}]", [ +{%attrs, src=>$src }, '^.' => 'src'],
# "*[data-pure-overlay-id=overlay-$params{cnt}]\@data-pure-overlay-id", sub { undef },
);
} else {
warn "Encountering processing instruction $target that I can't process";
}
$params{cnt}++;
lib/Template/Pure.pm view on Meta::CPAN
effort to learn off the top compared to more simple systems like Mustache or even L<Template::Toolkit>.
Although inspired by pure.js L<http://beebole.com/pure/> this module attempts to help mitigate some
of the listed possible downsides with additional features that are a superset of the original
pure.js specification. For example you may include templates inside of templates as includes or even
overlays that provide much of the same benefit that template inheritance offers in many other
popular template frameworks. These additional features are intended to make it more suitable as a general
purpose server side templating system.
=head1 CREATING TEMPLATE OBJECTS
lib/Template/Pure.pm view on Meta::CPAN
</div>
Lastly you can mimic a type of inheritance using data mapping and
node aliasing:
my $overlay_html = q[
<html>
<head>
<title>Example Title</title>
<link rel="stylesheet" href="/css/pure-min.css"/>
<link rel="stylesheet" href="/css/grids-responsive-min.css"/>
lib/Template/Pure.pm view on Meta::CPAN
<p id="foot">Here's the footer</p>
</body>
</html>
];
my $overlay = Template::Pure->new(
template=>$overlay_html,
directives=> [
'title' => 'title',
'^title+' => 'scripts',
'body section#content' => 'content',
]);
lib/Template/Pure.pm view on Meta::CPAN
{
title => \'title',
scripts => \'^head script',
content => \'body',
},
'^.' => $overlay,
]
]);
my $data = +{
meta => {
lib/Template/Pure.pm view on Meta::CPAN
]
);
=head2 Overlay
An overlay replaces the selected node with the results on another template. Typically
you will pass selected nodes of the original template as directives to the new template.
This can be used to minic features like template inheritance, that exist in other templating
systems. One example:
my $overlay_html = q[
<html>
<head>
<title>Example Title</title>
<link rel="stylesheet" href="/css/pure-min.css"/>
<link rel="stylesheet" href="/css/grids-responsive-min.css"/>
lib/Template/Pure.pm view on Meta::CPAN
<body>
</body>
</html>
];
my $overlay = Template::Pure->new(
template=>$overlay_html,
directives=> [
'title' => 'title',
'head+' => 'scripts',
'body' => 'content',
]);
my $base_html = q[
<?pure-overlay src='layout'
title=\'title'
scripts=\'^head script'
content=\'body'?>
<html>
<head>
lib/Template/Pure.pm view on Meta::CPAN
'#story' => 'story,
]
);
print $base->render({
layout => $overlay,
story => 'Once Upon a Time...',
meta => {
title=>'Once',
author=>'jnap',
},
lib/Template/Pure.pm view on Meta::CPAN
</body>
</html>
The syntax of the processing instruction is:
<?pure-overlay src='' @args ?>
Where 'src' is a data path to the template you want to use as the overlay, and @args is
a list of key values which populate the data context of the overlay when you process it.
Often these values will be references to existing nodes in the base template (as in the
examples \'title' and \'body' above) but they can also be used to map values from your
data context in the same way we do so for L</Include> and L</Wrapper>.
If you were to write this as 'directives only' it would look like:
lib/Template/Pure.pm view on Meta::CPAN
'^.' => 'layout',
],
]
);
Please note that although in this example the overlay wrapped over the entire template, it is
not limited to that, rather like the L</Wrapper> processing instruction it just takes the next
tag node following as its overlay target. So you could have more than one overlap in a document
and can overlay sections for those cases where a L</Wrapper> is not sufficently complex.
=head2 Filter
A Filter will process the following node on a L<Template::Pure> instance as if that node was the
source for its template. This means that the target source template must be a coderef that builds
Template-Resolver
view release on metacpan or search on metacpan
lib/Template/Overlay.pm view on Meta::CPAN
$self->{base} = File::Spec->rel2abs($base);
$self->{resolver} = $resolver;
$self->{key} = $options{key};
$logger->debug( 'new overlay [', $self->{base}, ']' );
return $self;
}
sub _overlay_files {
my ( $self, $overlays ) = @_;
my %overlay_files = ();
foreach my $overlay ( ref($overlays) eq 'ARRAY' ? @$overlays : ($overlays) ) {
$overlay = File::Spec->rel2abs($overlay);
my $base_path_length = length($overlay);
find(
sub {
if ( -f $File::Find::name && $_ !~ /~$/ && $_ !~ /^\..+\.swp$/ ) {
my $relative = _relative_path( $File::Find::name, $base_path_length );
$overlay_files{$relative} = $File::Find::name;
}
},
$overlay
);
}
return %overlay_files;
}
sub overlay {
my ( $self, $overlays, %options ) = @_;
my %overlay_files = $self->_overlay_files($overlays);
my $destination = $self->{base};
if ( $options{to} && $options{to} ne $self->{base} ) {
$destination = File::Spec->rel2abs( $options{to} );
my $base_path_length = length( File::Spec->rel2abs( $self->{base} ) );
find(
lib/Template/Overlay.pm view on Meta::CPAN
my $relative = _relative_path( $File::Find::name, $base_path_length );
if ( -d $File::Find::name ) {
make_path( File::Spec->catdir( $destination, $relative ) );
}
if ( -f $File::Find::name ) {
my $template = delete( $overlay_files{$relative} );
my $file = File::Spec->catfile( $destination, $relative );
if ($template) {
$self->_resolve( $template, $file, $options{resolver} );
}
else {
lib/Template/Overlay.pm view on Meta::CPAN
}
},
$self->{base}
);
}
foreach my $relative ( keys(%overlay_files) ) {
my $file = File::Spec->catfile( $destination, $relative );
make_path( ( File::Spec->splitpath($file) )[1] );
$self->_resolve( $overlay_files{$relative}, $file, $options{resolver} );
}
}
sub _relative_path {
my ( $path, $base_path_length ) = @_;
lib/Template/Overlay.pm view on Meta::CPAN
=head1 SYNOPSIS
use Template::Overlay;
use Template::Resolver;
my $overlay_me = Template::Overlay->new(
'/path/to/base/folder',
Template->Resolver->new($entity),
key => 'REPLACEME');
$overlay_me->overlay(
['/path/to/template/base','/path/to/another/template/base'],
to => '/path/to/processed');
=head1 DESCRIPTION
This provides the ability ot overlay a set of files with a set of resolved templates.
It uses L<Template::Resolver> to resolve each file.
=head1 CONSTRUCTORS
=head2 new($base, $resolver, [%options])
Creates a new overlay processor for the files in C<$base> using C<$resolver> to process
the template files. The available options are:
=over 4
=item key
lib/Template/Overlay.pm view on Meta::CPAN
=back
=head1 METHODS
=head2 overlay($overlays, [%options])
Overlays the C<$base> directory (specified in the constructor) with the resolved
templates from the directories in C<$overlays>. C<$overlays> can be either a path,
or an array reference containing paths. If multiple C<$overlays> contain the same
template, the last one in the array will take precedence. The available options are:
=over 4
=item resolver
lib/Template/Overlay.pm view on Meta::CPAN
handled processing of the file, so the default processing will be skipped.
=item to
If specified, the files in C<$base> will not be not be modified. Rather, they will
be copied to the path specified by C<$to> and the overlays will be processed on top
of that directory.
=back
=head1 AUTHOR
Term-CLI
view release on metacpan or search on metacpan
benchmarks/wordlist-en.txt view on Meta::CPAN
overlaunched
overlaunches
overlaunching
overlavish
overlax
overlay
overlaying
overlayings
overlays
overleaf
overleap
overleaped
overleaping
overleaps
Term-Gnuplot
view release on metacpan or search on metacpan
1) in order move the support for the terminal drivers outside of the
support for the main program, thereby encouraging a library of
contributed drivers
2) To make it easy for users to add contributed drivers, by adding
a single #include line to term.h
3) To allow individual compilation on DOS, to save the overlay
manager from having to load _all_ drivers together.
CORRECTION - scale() interface is no longer supported, since it
is incompatible with multiplot.
Test-DBIx-Class
view release on metacpan or search on metacpan
outside ../perl/lib/B/Deparse.pm /^ my $outside = !$lexical && $cv && $cv->OUTSIDE;$/;" v file: class:Deparse
outstanding ../Object-Remote/lib/Object/Remote/Connection.pm /^ my $outstanding = $self->outstanding_futures;$/;" v file: class:Connection
outstanding ../Object-Remote/lib/Object/Remote/Connection.pm /^ my $outstanding = $self->outstanding_futures;$/;" v file: class:Connection
ov_method ../perl/lib/overload.pm /^sub ov_method {$/;" s class:overload
over_level ../perl/lib/diagnostics.pm /^my $over_level = 0; # We look only at =item lines at the first =over level$/;" v file: class:diagnostics
overlay ../perl/lib/B/Deparse.pm /^ local $B::overlay = {};$/;" v file: class:Deparse
overlay ../perl/lib/B/Deparse.pm /^ local $B::overlay = {};$/;" v file: class:Deparse
overlay ../perl/lib/B/Deparse.pm /^ local $B::overlay = {};$/;" v file: class:Deparse
overlay ../perl/lib/B/Deparse.pm /^ local $B::overlay = {};$/;" v file: class:Deparse
overload ../perl/lib/overload.pm /^package overload;$/;" p class:overload
overloading ../perl/lib/overloading.pm /^package overloading;$/;" p class:overloading
overrides ../perl/lib/Unicode/UCD.pm /^ my $overrides;$/;" v file: class:UCD
p ../Catalyst-Controller-HTML-FormFu/lib/HTML/FormFu/Element/RequestToken.pm /^ my $p = $form->element( { plugin => 'Token' } );$/;" v file: class:RequestToken
p ../Catalyst-Runtime/lib/Catalyst.pm /^ my %p = ( _log => $self->log );$/;" v file: class:Catalyst
Test-Harness-Straps
view release on metacpan or search on metacpan
0.30 Tue Jan 8 14:33:02 PST 2008
Forgot to make it install into the core directory and overlay the
existing module [spotted by imcat]
0.29 Wed Oct 17 18:42:23 EDT 2007
Forgot to update the MANIFEST to contain the testing copy of if.pm
Test-OpenLDAP
view release on metacpan or search on metacpan
lib/Test/OpenLDAP.pm view on Meta::CPAN
olcAttributeTypes: ( 1.3.6.1.4.1.4203.666.1.55.10 NAME 'monitorTimestamp' DESC
'monitor timestamp' EQUALITY generalizedTimeMatch ORDERING generalizedTimeOr
deringMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE NO-USER-MODIFIC
ATION USAGE dSAOperation )
olcAttributeTypes: ( 1.3.6.1.4.1.4203.666.1.55.11 NAME 'monitorOverlay' DESC '
name of overlays defined for a given database' SUP monitoredInfo NO-USER-MODI
FICATION USAGE dSAOperation )
olcAttributeTypes: ( 1.3.6.1.4.1.4203.666.1.55.12 NAME 'readOnly' DESC 'read/w
rite status of a given database' EQUALITY booleanMatch SYNTAX 1.3.6.1.4.1.146
6.115.121.1.7 SINGLE-VALUE USAGE dSAOperation )
olcAttributeTypes: ( 1.3.6.1.4.1.4203.666.1.55.13 NAME 'restrictedOperation' D
Test-Perl-Dist
view release on metacpan or search on metacpan
inc/inc_Module-Build/Module/Build/Base.pm view on Meta::CPAN
}
return $ph->{features}->access($key, @_);
}
# No args - get the auto_features & overlay the regular features
my %features;
my %auto_features = $ph->{auto_features}->access();
while (my ($name, $info) = each %auto_features) {
my $failures = $self->prereq_failures($info);
my $disabled = grep( /^(?:\w+_)?(?:requires|conflicts)$/,
Test-SpellCheck-Plugin-Lang-EN-US
view release on metacpan or search on metacpan
share/en/us/en_US.dic view on Meta::CPAN
overland
overlap/SM
overlapped
overlapping
overlarge
overlay/GSM
overleaf
overlie
overload/GMDS
overlong
overlook/GMDS
Test-Text
view release on metacpan or search on metacpan
data/en_US.dic view on Meta::CPAN
overland/S
overlap/MS
overlapped
overlapping
overlarge
overlay/GS
overleaf
overlie
overload/SDG
overlong
overlook/DSG
Test2-Harness-UI
view release on metacpan or search on metacpan
share/css/jquery-ui.css view on Meta::CPAN
/* Misc visuals
----------------------------------*/
/* Overlays */
.ui-widget-overlay {
position: fixed;
top: 0;
left: 0;
width: 100%;
height: 100%;
share/css/jquery-ui.css view on Meta::CPAN
}
.ui-progressbar .ui-progressbar-value {
margin: -1px;
height: 100%;
}
.ui-progressbar .ui-progressbar-overlay {
background: url("data:image/gif;base64,R0lGODlhKAAoAIABAAAAAP///yH/C05FVFNDQVBFMi4wAwEAAAAh+QQJAQABACwAAAAAKAAoAAACkYwNqXrdC52DS06a7MFZI+4FHBCKoDeWKXqymPqGqxvJrXZbMx7Ttc+w9XgU2FB3lOyQRWET2IFGiU9m1frDVpxZZc6bfHwv4c1YXP6k1Vdy292Fb6UkuvFtXpvWSzA+HycXJH...
height: 100%;
-ms-filter: "alpha(opacity=25)"; /* support: IE8 */
opacity: 0.25;
}
share/css/jquery-ui.css view on Meta::CPAN
.ui-corner-br {
border-bottom-right-radius: 3px;
}
/* Overlays */
.ui-widget-overlay {
background: #aaaaaa;
opacity: .3;
-ms-filter: Alpha(Opacity=30); /* support: IE8 */
}
.ui-widget-shadow {
Text-CPP
view release on metacpan or search on metacpan
/* The directory of the this buffer's file. Its NAME member is not
allocated, so we don't need to worry about freeing it. */
struct search_path dir;
/* Used for buffer overlays by cpptrad.c. */
const uchar *saved_cur, *saved_rlimit;
};
/* A cpp_reader encapsulates the "state" of a pre-processor run.
Applying cpp_get_token repeatedly yields a stream of pre-processor
unsigned int, unsigned int));
extern void _cpp_pop_buffer PARAMS ((cpp_reader *));
/* In cpptrad.c. */
extern bool _cpp_read_logical_line_trad PARAMS ((cpp_reader *));
extern void _cpp_overlay_buffer PARAMS ((cpp_reader *pfile, const uchar *,
size_t));
extern void _cpp_remove_overlay PARAMS ((cpp_reader *));
extern bool _cpp_create_trad_definition PARAMS ((cpp_reader *, cpp_macro *));
extern bool _cpp_expansions_different_trad PARAMS ((const cpp_macro *,
const cpp_macro *));
extern uchar *_cpp_copy_replacement_text PARAMS ((const cpp_macro *, uchar *));
extern size_t _cpp_replacement_text_len PARAMS ((const cpp_macro *));
Text-EmacsColor
view release on metacpan or search on metacpan
share/lisp/htmlize.el view on Meta::CPAN
(and (buffer-live-p ,temp-buffer)
(kill-buffer ,temp-buffer))))))))
;; We need a function that efficiently finds the next change of a
;; property (usually `face'), preferably regardless of whether the
;; change occurred because of a text property or an extent/overlay.
;; As it turns out, it is not easy to do that compatibly.
;;
;; Under XEmacs, `next-single-property-change' does that. Under GNU
;; Emacs beginning with version 21, `next-single-char-property-change'
;; is available and does the same. GNU Emacs 20 had
;; `next-char-property-change', which we can use. GNU Emacs 19 didn't
;; provide any means for simultaneously examining overlays and text
;; properties, so when using Emacs 19.34, we punt and fall back to
;; `next-single-property-change', thus ignoring overlays altogether.
(cond
(htmlize-running-xemacs
;; XEmacs: good.
(defun htmlize-next-change (pos prop &optional limit)
share/lisp/htmlize.el view on Meta::CPAN
(t
(setq done t)))
(setq pos newpos))
pos)))
(t
;; GNU Emacs 19.34: hopeless, cannot properly support overlays.
(defun htmlize-next-change (pos prop &optional limit)
(unless limit
(setq limit (point-max)))
(let ((res (next-single-property-change pos prop)))
(if (or (null res)
share/lisp/htmlize.el view on Meta::CPAN
(reduce #'htmlize-merge-two-faces
(cons (make-htmlize-fstruct) fstruct-list)))))
;; GNU Emacs 20+ supports attribute lists in `face' properties. For
;; example, you can use `(:foreground "red" :weight bold)' as an
;; overlay's "face", or you can even use a list of such lists, etc.
;; We call those "attrlists".
;;
;; htmlize supports attrlist by converting them to fstructs, the same
;; as with regular faces.
share/lisp/htmlize.el view on Meta::CPAN
(defun htmlize-faces-in-buffer ()
"Return a list of faces used in the current buffer.
Under XEmacs, this returns the set of faces specified by the extents
with the `face' property. (This covers text properties as well.) Under
GNU Emacs, it returns the set of faces specified by the `face' text
property and by buffer overlays that specify `face'."
(let (faces)
;; Testing for (fboundp 'map-extents) doesn't work because W3
;; defines `map-extents' under FSF.
(if htmlize-running-xemacs
(let (face-prop)
share/lisp/htmlize.el view on Meta::CPAN
(nunion (mapcar #'htmlize-unstringify-face face-prop)
faces :test 'equal)
(adjoin (htmlize-unstringify-face face-prop)
faces :test 'equal)))
(setq pos next)))
;; Faces used by overlays.
(dolist (overlay (overlays-in (point-min) (point-max)))
(let ((face-prop (overlay-get overlay 'face)))
;; FACE-PROP can be a face/attrlist or a list thereof.
(setq faces (if (htmlize-face-list-p face-prop)
(nunion (mapcar #'htmlize-unstringify-face face-prop)
faces :test 'equal)
(adjoin (htmlize-unstringify-face face-prop)
share/lisp/htmlize.el view on Meta::CPAN
;; faces are sorted by increasing priority, i.e. the last face takes
;; precedence.
;;
;; Under XEmacs, this returns all the faces in all the extents at
;; point. Under GNU Emacs, this returns all the faces in the `face'
;; property and all the faces in the overlays at point.
(cond (htmlize-running-xemacs
(defun htmlize-faces-at-point ()
(let (extent extent-list face-list face-prop)
(while (setq extent (extent-at (point) nil 'face extent))
share/lisp/htmlize.el view on Meta::CPAN
(let ((face-prop (get-text-property (point) 'face)))
(setq all-faces (if (htmlize-face-list-p face-prop)
(nreverse (mapcar #'htmlize-unstringify-face
face-prop))
(list (htmlize-unstringify-face face-prop)))))
;; Faces from overlays.
(let ((overlays
;; Collect overlays at point that specify `face'.
(delete-if-not (lambda (o)
(overlay-get o 'face))
(overlays-at (point))))
list face-prop)
;; Sort the overlays so the smaller (more specific) ones
;; come later. The number of overlays at each one
;; position should be very small, so the sort shouldn't
;; slow things down.
(setq overlays (sort* overlays
;; Sort by ascending...
#'<
;; ...overlay size.
:key (lambda (o)
(- (overlay-end o)
(overlay-start o)))))
;; Overlay priorities, if present, override the above
;; established order. Larger overlay priority takes
;; precedence and therefore comes later in the list.
(setq overlays (stable-sort
overlays
;; Reorder (stably) by acending...
#'<
;; ...overlay priority.
:key (lambda (o)
(or (overlay-get o 'priority) 0))))
(dolist (overlay overlays)
(setq face-prop (overlay-get overlay 'face))
(setq list (if (htmlize-face-list-p face-prop)
(nconc (nreverse (mapcar
#'htmlize-unstringify-face
face-prop))
list)
(cons (htmlize-unstringify-face face-prop) list))))
;; Under "Merging Faces" the manual explicitly states
;; that faces specified by overlays take precedence over
;; faces specified by text properties.
(setq all-faces (nconc all-faces list)))
all-faces))))
;; htmlize supports generating HTML in two several fundamentally
Text-Hoborg
view release on metacpan or search on metacpan
data/en_US.dic view on Meta::CPAN
overland/S
overlap/MS
overlapped
overlapping
overlarge
overlay/GS
overleaf
overlie
overload/SDG
overlong
overlook/DSG
Text-Scigen
view release on metacpan or search on metacpan
lib/Text/Scigen/scirules.in view on Meta::CPAN
EXP_TYPE_UM deployment
EXP_TYPE_UM prototype
EXP_WHERE_UM cluster
EXP_WHERE_UM testbed
EXP_WHERE_UM overlay network
# common places to run experiments
EXP_WHERE_CMN desktop machines
EXP_WHERE_CMN mobile telephones
EXP_WHERE_CMN system
Text-Xslate
view release on metacpan or search on metacpan
lib/Text/Xslate.pm view on Meta::CPAN
Thanks to gardejo for the proposal to the name B<template cascading>.
Thanks to makamaka for the contribution of Text::Xslate::PP.
Thanks to jjn1056 to the concept of template overlay (now implemented as C<cascade with ...>).
Thanks to typester for the various inspirations.
Thanks to clouder for the patch of adding C<AND> and C<OR> to TTerse.
Thrift-API-HiveClient2
view release on metacpan or search on metacpan
lib/Thrift/API/HiveClient2/cli_service.thrift view on Meta::CPAN
// protocol layer, in which case these fields may be
// left unset.
2: optional string username
3: optional string password
// Configuration overlay which is applied when the session is
// first created.
4: optional map<string, string> configuration
}
struct TOpenSessionResp {
lib/Thrift/API/HiveClient2/cli_service.thrift view on Meta::CPAN
1: required TSessionHandle sessionHandle
// The statement to be executed (DML, DDL, SET, etc)
2: required string statement
// Configuration properties that are overlayed on top of the
// the existing session configuration before this statement
// is executed. These properties apply to this statement
// only and will not affect the subsequent state of the Session.
3: optional map<string, string> confOverlay
}
Tickit-Widget-Layout-Desktop
view release on metacpan or search on metacpan
lib/Tickit/Widget/Layout/Desktop.pm view on Meta::CPAN
$rb->eraserect($rect);
}
method children { @{$self->{widgets}} }
=head2 overlay
Render all window outlines on top of the target widget.
Takes the following parameters:
lib/Tickit/Widget/Layout/Desktop.pm view on Meta::CPAN
=back
=cut
method overlay ($rb, $rect, $exclude) {
my $target = $exclude->window->rect;
# TODO change this when proper accessors are available
my %win_map = map {
refaddr($_->window) => $_
Tickit-Widget-LogAny
view release on metacpan or search on metacpan
lib/Tickit/Widget/LogAny.pm view on Meta::CPAN
}
});
$win->expose;
};
} else {
# We don't have any suitable float holders, so we'll just overlay this
# using our window as a parent. This next set of measurements assumes we
# have a bit of space to play with - if we don't, I'm not sure how best
# to handle this: use the root window instead, or just bail out?
my $float = $win->make_float(
2,
Tie-Cache-LRU
view release on metacpan or search on metacpan
bench/big_test_data view on Meta::CPAN
overland
overlap
overlapped
overlapping
overlaps
overlay
overlaying
overlays
overload
overloaded
overloading
overloads
overlook
Tie-Cache
view release on metacpan or search on metacpan
size of the cache. This can be especially useful if you access
great amounts of data, but only access a minority of the data a
majority of the time.
The implementation is a hash, for quick lookups,
overlaying a doubly linked list for quick insertion and deletion.
On a WinNT PII 300, writes to the hash were done at a rate
3100 per second, and reads from the hash at 6300 per second.
Work has been done to optimize refreshing cache entries that are
frequently read from, code like $cache{entry}, which moves the
entry to the end of the linked list internally.
Tie-Cacher
view release on metacpan or search on metacpan
So, the cache only "remembers" the last written entries, up to the
size of the cache. This can be especially useful if you access
great amounts of data, but only access a minority of the data a
majority of the time.
The implementation is a hash, for quick lookups, overlaying a doubly linked
list for quick insertion and deletion. Notice that the OO interface will
be faster than the tie interface.
=head2 EXPORT
Tie-ShadowHash
view release on metacpan or search on metacpan
lib/Tie/ShadowHash.pm view on Meta::CPAN
and convenient access to a disparate set of data sources.
The shadow hash can be modified, and the modifications override the data
sources, but modifications aren't propagated back to the data sources. In
other words, the shadow hash treats all data sources as read-only and saves
your modifications in an overlay in memory. This lets you make changes to the
shadow hash and have them reflected later in your program without affecting
the underlying data in any way. This behavior is the reason why it is called
a shadow hash.
=head1 Constructing the hash
Tie-TransactHash
view release on metacpan or search on metacpan
lib/Tie/TransactHash.pm view on Meta::CPAN
=head1 OVERVIEW
Editing a hash causes problems because it rearranges the hash. If the
editing is to be done in sequence then this makes life difficult. The
TransactHash class uses a fixed sequence hash class which overlays the
normal hash and allows editing in place. It stores all of the changes
to the original hash in memory until it is told to apply them.
As a side effect of this design, the class also provides a
commit/rollback system. When a commit is called, the order of the
TimeZone-Solar
view release on metacpan or search on metacpan
lib/TimeZone/Solar.pm view on Meta::CPAN
There are normal variations of a matter of minutes between local solar noon and clock noon, depending on
the latitude and time of year. That variation is always the same number of minutes as local solar noon
differs from noon UTC at the same latitude on the Prime Meridian (0° longitude), due to seasonal effects
of the tilt in Earth's axis relative to our orbit around the Sun.
The Solaer time zones also have another set of overlay time zones the width of 1 degree of longitude, which puts
them in 4-minute intervals of time. These are a hyper-local niche for potential use by outdoor events or activities
which must be scheduled around daylight. They can also be used by anyone who wants the middle of the scheduling day
to coincide closely with local solar noon.
=head2 Definition of Solar time zones
Tk
view release on metacpan or search on metacpan
demos/demos/widget_lib/transtile.pl view on Meta::CPAN
# and transparent stuff.
my($demo) = @_;
$TOP = $MW->WidgetDemo(
-name => $demo,
-text => ['This window demonstrates tiles and transparent images. The Canvas has a yellow background, which displays for one second before it\'s overlayed with a tile of tiny camels. On top of the tile layer are three non-transparent imag...
-title => 'Tile and Transparent Demonstration',
-iconname => 'transtile',
);
my $tile = $TOP->Photo(-file =>Tk->findINC('Camel.xpm'));
# A tiled Canvas - the tile overlays the background color.
my $c = $TOP->Canvas(
-background => 'yellow',
-width => 300,
-height => 250,
demos/demos/widget_lib/transtile.pl view on Meta::CPAN
-fill => 'blue',
-stipple => 'transparent',
);
$c->bind($o3, '<Motion>' => $cb);
# A transparent GIF overlaying everything.
$c->createImage(300, 300,
-image => $TOP->Photo(-data => &encoded_gif, -format => 'gif'),
-anchor => 'se',
);
( run in 1.468 second using v1.01-cache-2.11-cpan-49f99fa48dc )