| Top |
| GtkCellEditable * | edit-widget | Read |
| GtkCellRenderer * | edited-cell | Read |
| GtkCellRenderer * | focus-cell | Read / Write |
| void | add-editable | Run First |
| void | apply-attributes | Run First |
| void | focus-changed | Run First |
| void | remove-editable | Run First |
The GtkCellArea is an abstract class for GtkCellLayout widgets (also referred to as "layouting widgets") to interface with an arbitrary number of GtkCellRenderers and interact with the user for a given GtkTreeModel row.
The cell area handles events, focus navigation, drawing and size requests and allocations for a given row of data.
Usually users dont have to interact with the GtkCellArea directly unless they are implementing a cell-layouting widget themselves.
As outlined in GtkWidget’s geometry management section, GTK+ uses a height-for-width geometry management system to compute the sizes of widgets and user interfaces. GtkCellArea uses the same semantics to calculate the size of an area for an arbitrary number of GtkTreeModel rows.
When requesting the size of a cell area one needs to calculate the size for a handful of rows, and this will be done differently by different layouting widgets. For instance a GtkTreeViewColumn always lines up the areas from top to bottom while a GtkIconView on the other hand might enforce that all areas received the same width and wrap the areas around, requesting height for more cell areas when allocated less width.
It’s also important for areas to maintain some cell alignments with areas rendered for adjacent rows (cells can appear “columnized” inside an area even when the size of cells are different in each row). For this reason the GtkCellArea uses a GtkCellAreaContext object to store the alignments and sizes along the way (as well as the overall largest minimum and natural size for all the rows which have been calculated with the said context).
The GtkCellAreaContext is an opaque object specific to the
GtkCellArea which created it (see gtk_cell_area_create_context()
).
The owning cell-layouting widget can create as many contexts as
it wishes to calculate sizes of rows which should receive the
same size in at least one orientation (horizontally or vertically),
However, it’s important that the same GtkCellAreaContext which
was used to request the sizes for a given GtkTreeModel row be
used when rendering or processing events for that row.
In order to request the width of all the rows at the root level of a GtkTreeModel one would do the following:
1 2 3 4 5 6 7 8 9 10 11 12 13 |
GtkTreeIter iter; gint minimum_width; gint natural_width; valid = gtk_tree_model_get_iter_first (model, &iter); while (valid) { gtk_cell_area_apply_attributes (area, model, &iter, FALSE, FALSE); gtk_cell_area_get_preferred_width (area, context, widget, NULL, NULL); valid = gtk_tree_model_iter_next (model, &iter); } gtk_cell_area_context_get_preferred_width (context, &minimum_width, &natural_width); |
Note that in this example it’s not important to observe the returned minimum and natural width of the area for each row unless the cell-layouting object is actually interested in the widths of individual rows. The overall width is however stored in the accompanying GtkCellAreaContext object and can be consulted at any time.
This can be useful since GtkCellLayout widgets usually have to
support requesting and rendering rows in treemodels with an
exceedingly large amount of rows. The GtkCellLayout widget in
that case would calculate the required width of the rows in an
idle or timeout source (see g_timeout_add()
) and when the widget
is requested its actual width in GtkWidgetClass.get_preferred_width()
it can simply consult the width accumulated so far in the
GtkCellAreaContext object.
A simple example where rows are rendered from top to bottom and take up the full width of the layouting widget would look like:
1 2 3 4 5 6 7 8 9 10 11 12 |
static void foo_get_preferred_width (GtkWidget *widget, gint *minimum_size, gint *natural_size) { Foo *foo = FOO (widget); FooPrivate *priv = foo->priv; foo_ensure_at_least_one_handfull_of_rows_have_been_requested (foo); gtk_cell_area_context_get_preferred_width (priv->context, minimum_size, natural_size); } |
In the above example the Foo widget has to make sure that some row sizes have been calculated (the amount of rows that Foo judged was appropriate to request space for in a single timeout iteration) before simply returning the amount of space required by the area via the GtkCellAreaContext.
Requesting the height for width (or width for height) of an area is a similar task except in this case the GtkCellAreaContext does not store the data (actually, it does not know how much space the layouting widget plans to allocate it for every row. It’s up to the layouting widget to render each row of data with the appropriate height and width which was requested by the GtkCellArea).
In order to request the height for width of all the rows at the root level of a GtkTreeModel one would do the following:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 |
GtkTreeIter iter; gint minimum_height; gint natural_height; gint full_minimum_height = 0; gint full_natural_height = 0; valid = gtk_tree_model_get_iter_first (model, &iter); while (valid) { gtk_cell_area_apply_attributes (area, model, &iter, FALSE, FALSE); gtk_cell_area_get_preferred_height_for_width (area, context, widget, width, &minimum_height, &natural_height); if (width_is_for_allocation) cache_row_height (&iter, minimum_height, natural_height); full_minimum_height += minimum_height; full_natural_height += natural_height; valid = gtk_tree_model_iter_next (model, &iter); } |
Note that in the above example we would need to cache the heights returned for each row so that we would know what sizes to render the areas for each row. However we would only want to really cache the heights if the request is intended for the layouting widgets real allocation.
In some cases the layouting widget is requested the height for an
arbitrary for_width, this is a special case for layouting widgets
who need to request size for tens of thousands of rows. For this
case it’s only important that the layouting widget calculate
one reasonably sized chunk of rows and return that height
synchronously. The reasoning here is that any layouting widget is
at least capable of synchronously calculating enough height to fill
the screen height (or scrolled window height) in response to a single
call to GtkWidgetClass.get_preferred_height_for_width()
. Returning
a perfect height for width that is larger than the screen area is
inconsequential since after the layouting receives an allocation
from a scrolled window it simply continues to drive the scrollbar
values while more and more height is required for the row heights
that are calculated in the background.
Once area sizes have been aquired at least for the rows in the
visible area of the layouting widget they can be rendered at
GtkWidgetClass.draw()
time.
A crude example of how to render all the rows at the root level runs as follows:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 |
GtkAllocation allocation; GdkRectangle cell_area = { 0, }; GtkTreeIter iter; gint minimum_width; gint natural_width; gtk_widget_get_allocation (widget, &allocation); cell_area.width = allocation.width; valid = gtk_tree_model_get_iter_first (model, &iter); while (valid) { cell_area.height = get_cached_height_for_row (&iter); gtk_cell_area_apply_attributes (area, model, &iter, FALSE, FALSE); gtk_cell_area_render (area, context, widget, cr, &cell_area, &cell_area, state_flags, FALSE); cell_area.y += cell_area.height; valid = gtk_tree_model_iter_next (model, &iter); } |
Note that the cached height in this example really depends on how
the layouting widget works. The layouting widget might decide to
give every row its minimum or natural height or, if the model content
is expected to fit inside the layouting widget without scrolling, it
would make sense to calculate the allocation for each row at
“size-allocate” time using gtk_distribute_natural_allocation()
.
Passing events to the area is as simple as handling events on any
normal widget and then passing them to the gtk_cell_area_event()
API as they come in. Usually GtkCellArea is only interested in
button events, however some customized derived areas can be implemented
who are interested in handling other events. Handling an event can
trigger the “focus-changed” signal to fire; as well as
“add-editable” in the case that an editable cell was
clicked and needs to start editing. You can call
gtk_cell_area_stop_editing()
at any time to cancel any cell editing
that is currently in progress.
The GtkCellArea drives keyboard focus from cell to cell in a way
similar to GtkWidget. For layouting widgets that support giving
focus to cells it’s important to remember to pass GTK_CELL_RENDERER_FOCUSED
to the area functions for the row that has focus and to tell the
area to paint the focus at render time.
Layouting widgets that accept focus on cells should implement the
GtkWidgetClass.focus()
virtual method. The layouting widget is always
responsible for knowing where GtkTreeModel rows are rendered inside
the widget, so at GtkWidgetClass.focus()
time the layouting widget
should use the GtkCellArea methods to navigate focus inside the area
and then observe the GtkDirectionType to pass the focus to adjacent
rows and areas.
A basic example of how the GtkWidgetClass.focus()
virtual method
should be implemented:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 |
static gboolean foo_focus (GtkWidget *widget, GtkDirectionType direction) { Foo *foo = FOO (widget); FooPrivate *priv = foo->priv; gint focus_row; gboolean have_focus = FALSE; focus_row = priv->focus_row; if (!gtk_widget_has_focus (widget)) gtk_widget_grab_focus (widget); valid = gtk_tree_model_iter_nth_child (priv->model, &iter, NULL, priv->focus_row); while (valid) { gtk_cell_area_apply_attributes (priv->area, priv->model, &iter, FALSE, FALSE); if (gtk_cell_area_focus (priv->area, direction)) { priv->focus_row = focus_row; have_focus = TRUE; break; } else { if (direction == GTK_DIR_RIGHT || direction == GTK_DIR_LEFT) break; else if (direction == GTK_DIR_UP || direction == GTK_DIR_TAB_BACKWARD) { if (focus_row == 0) break; else { focus_row--; valid = gtk_tree_model_iter_nth_child (priv->model, &iter, NULL, focus_row); } } else { if (focus_row == last_row) break; else { focus_row++; valid = gtk_tree_model_iter_next (priv->model, &iter); } } } } return have_focus; } |
Note that the layouting widget is responsible for matching the GtkDirectionType values to the way it lays out its cells.
The GtkCellArea introduces cell properties for GtkCellRenderers in very much the same way that GtkContainer introduces child properties for GtkWidgets. This provides some general interfaces for defining the relationship cell areas have with their cells. For instance in a GtkCellAreaBox a cell might “expand” and receive extra space when the area is allocated more than its full natural request, or a cell might be configured to “align” with adjacent rows which were requested and rendered with the same GtkCellAreaContext.
Use gtk_cell_area_class_install_cell_property()
to install cell
properties for a cell area class and gtk_cell_area_class_find_cell_property()
or gtk_cell_area_class_list_cell_properties()
to get information about
existing cell properties.
To set the value of a cell property, use gtk_cell_area_cell_set_property()
,
gtk_cell_area_cell_set()
or gtk_cell_area_cell_set_valist()
. To obtain
the value of a cell property, use gtk_cell_area_cell_get_property()
,
gtk_cell_area_cell_get()
or gtk_cell_area_cell_get_valist()
.
gboolean (*GtkCellCallback) (GtkCellRenderer *renderer
,gpointer data
);
The type of the callback functions used for iterating over
the cell renderers of a GtkCellArea, see gtk_cell_area_foreach()
.
gboolean (*GtkCellAllocCallback) (GtkCellRenderer *renderer
,const GdkRectangle *cell_area
,const GdkRectangle *cell_background
,gpointer data
);
The type of the callback functions used for iterating over the
cell renderers and their allocated areas inside a GtkCellArea,
see gtk_cell_area_foreach_alloc()
.
renderer |
the cell renderer to operate on |
|
cell_area |
the area allocated to |
|
cell_background |
the background area for |
|
data |
user-supplied data. |
[closure] |
#define GTK_CELL_AREA_WARN_INVALID_CELL_PROPERTY_ID(object, property_id, pspec)
This macro should be used to emit a standard warning about unexpected
properties in set_cell_property()
and get_cell_property()
implementations.
object |
the GObject on which |
|
property_id |
the numeric id of the property |
|
pspec |
the GParamSpec of the property |
void gtk_cell_area_add (GtkCellArea *area
,GtkCellRenderer *renderer
);
Adds renderer
to area
with the default child cell properties.
Since: 3.0
void gtk_cell_area_remove (GtkCellArea *area
,GtkCellRenderer *renderer
);
Removes renderer
from area
.
Since: 3.0
gboolean gtk_cell_area_has_renderer (GtkCellArea *area
,GtkCellRenderer *renderer
);
Checks if area
contains renderer
.
Since: 3.0
void gtk_cell_area_foreach (GtkCellArea *area
,GtkCellCallback callback
,gpointer callback_data
);
Calls callback
for every GtkCellRenderer in area
.
area |
||
callback |
the GtkCellCallback to call. |
[scope call] |
callback_data |
user provided data pointer |
Since: 3.0
void gtk_cell_area_foreach_alloc (GtkCellArea *area
,GtkCellAreaContext *context
,GtkWidget *widget
,const GdkRectangle *cell_area
,const GdkRectangle *background_area
,GtkCellAllocCallback callback
,gpointer callback_data
);
Calls callback
for every GtkCellRenderer in area
with the
allocated rectangle inside cell_area
.
area |
||
context |
the GtkCellAreaContext for this row of data. |
|
widget |
the GtkWidget that |
|
cell_area |
the |
|
background_area |
the |
|
callback |
the GtkCellAllocCallback to call. |
[scope call] |
callback_data |
user provided data pointer |
Since: 3.0
gint gtk_cell_area_event (GtkCellArea *area
,GtkCellAreaContext *context
,GtkWidget *widget
,GdkEvent *event
,const GdkRectangle *cell_area
,GtkCellRendererState flags
);
Delegates event handling to a GtkCellArea.
area |
||
context |
the GtkCellAreaContext for this row of data. |
|
widget |
the GtkWidget that |
|
event |
the GdkEvent to handle |
|
cell_area |
the |
|
flags |
the GtkCellRendererState for |
Since: 3.0
void gtk_cell_area_render (GtkCellArea *area
,GtkCellAreaContext *context
,GtkWidget *widget
,cairo_t *cr
,const GdkRectangle *background_area
,const GdkRectangle *cell_area
,GtkCellRendererState flags
,gboolean paint_focus
);
Renders area
’s cells according to area
’s layout onto widget
at
the given coordinates.
area |
||
context |
the GtkCellAreaContext for this row of data. |
|
widget |
the GtkWidget that |
|
cr |
the cairo_t to render with |
|
background_area |
the |
|
cell_area |
the |
|
flags |
the GtkCellRendererState for |
|
paint_focus |
whether |
Since: 3.0
void gtk_cell_area_get_cell_allocation (GtkCellArea *area
,GtkCellAreaContext *context
,GtkWidget *widget
,GtkCellRenderer *renderer
,const GdkRectangle *cell_area
,GdkRectangle *allocation
);
Derives the allocation of renderer
inside area
if area
were to be renderered in cell_area
.
area |
||
context |
the GtkCellAreaContext used to hold sizes for |
|
widget |
the GtkWidget that |
|
renderer |
the GtkCellRenderer to get the allocation for |
|
cell_area |
the whole allocated area for |
|
allocation |
where to store the allocation for |
[out] |
Since: 3.0
GtkCellRenderer * gtk_cell_area_get_cell_at_position (GtkCellArea *area
,GtkCellAreaContext *context
,GtkWidget *widget
,const GdkRectangle *cell_area
,gint x
,gint y
,GdkRectangle *alloc_area
);
Gets the GtkCellRenderer at x
and y
coordinates inside area
and optionally
returns the full cell allocation for it inside cell_area
.
area |
||
context |
the GtkCellAreaContext used to hold sizes for |
|
widget |
the GtkWidget that |
|
cell_area |
the whole allocated area for |
|
x |
the x position |
|
y |
the y position |
|
alloc_area |
where to store the inner allocated area of the
returned cell renderer, or |
[out][allow-none] |
Since: 3.0
GtkCellAreaContext *
gtk_cell_area_create_context (GtkCellArea *area
);
Creates a GtkCellAreaContext to be used with area
for
all purposes. GtkCellAreaContext stores geometry information
for rows for which it was operated on, it is important to use
the same context for the same row of data at all times (i.e.
one should render and handle events with the same GtkCellAreaContext
which was used to request the size of those rows of data).
Since: 3.0
GtkCellAreaContext * gtk_cell_area_copy_context (GtkCellArea *area
,GtkCellAreaContext *context
);
This is sometimes needed for cases where rows need to share alignments in one orientation but may be separately grouped in the opposing orientation.
For instance, GtkIconView creates all icons (rows) to have the same width and the cells theirin to have the same horizontal alignments. However each row of icons may have a separate collective height. GtkIconView uses this to request the heights of each row based on a context which was already used to request all the row widths that are to be displayed.
Since: 3.0
GtkSizeRequestMode
gtk_cell_area_get_request_mode (GtkCellArea *area
);
Gets whether the area prefers a height-for-width layout or a width-for-height layout.
Since: 3.0
void gtk_cell_area_get_preferred_width (GtkCellArea *area
,GtkCellAreaContext *context
,GtkWidget *widget
,gint *minimum_width
,gint *natural_width
);
Retrieves a cell area’s initial minimum and natural width.
area
will store some geometrical information in context
along the way;
when requesting sizes over an arbitrary number of rows, it’s not important
to check the minimum_width
and natural_width
of this call but rather to
consult gtk_cell_area_context_get_preferred_width()
after a series of
requests.
area |
||
context |
the GtkCellAreaContext to perform this request with |
|
widget |
the GtkWidget where |
|
minimum_width |
location to store the minimum width, or |
[out][allow-none] |
natural_width |
location to store the natural width, or |
[out][allow-none] |
Since: 3.0
void gtk_cell_area_get_preferred_height_for_width (GtkCellArea *area
,GtkCellAreaContext *context
,GtkWidget *widget
,gint width
,gint *minimum_height
,gint *natural_height
);
Retrieves a cell area’s minimum and natural height if it would be given
the specified width
.
area
stores some geometrical information in context
along the way
while calling gtk_cell_area_get_preferred_width()
. It’s important to
perform a series of gtk_cell_area_get_preferred_width()
requests with
context
first and then call gtk_cell_area_get_preferred_height_for_width()
on each cell area individually to get the height for width of each
fully requested row.
If at some point, the width of a single row changes, it should be
requested with gtk_cell_area_get_preferred_width()
again and then
the full width of the requested rows checked again with
gtk_cell_area_context_get_preferred_width()
.
area |
||
context |
the GtkCellAreaContext which has already been requested for widths. |
|
widget |
the GtkWidget where |
|
width |
the width for which to check the height of this area |
|
minimum_height |
location to store the minimum height, or |
[out][allow-none] |
natural_height |
location to store the natural height, or |
[out][allow-none] |
Since: 3.0
void gtk_cell_area_get_preferred_height (GtkCellArea *area
,GtkCellAreaContext *context
,GtkWidget *widget
,gint *minimum_height
,gint *natural_height
);
Retrieves a cell area’s initial minimum and natural height.
area
will store some geometrical information in context
along the way;
when requesting sizes over an arbitrary number of rows, it’s not important
to check the minimum_height
and natural_height
of this call but rather to
consult gtk_cell_area_context_get_preferred_height()
after a series of
requests.
area |
||
context |
the GtkCellAreaContext to perform this request with |
|
widget |
the GtkWidget where |
|
minimum_height |
location to store the minimum height, or |
[out][allow-none] |
natural_height |
location to store the natural height, or |
[out][allow-none] |
Since: 3.0
void gtk_cell_area_get_preferred_width_for_height (GtkCellArea *area
,GtkCellAreaContext *context
,GtkWidget *widget
,gint height
,gint *minimum_width
,gint *natural_width
);
Retrieves a cell area’s minimum and natural width if it would be given
the specified height
.
area
stores some geometrical information in context
along the way
while calling gtk_cell_area_get_preferred_height()
. It’s important to
perform a series of gtk_cell_area_get_preferred_height()
requests with
context
first and then call gtk_cell_area_get_preferred_width_for_height()
on each cell area individually to get the height for width of each
fully requested row.
If at some point, the height of a single row changes, it should be
requested with gtk_cell_area_get_preferred_height()
again and then
the full height of the requested rows checked again with
gtk_cell_area_context_get_preferred_height()
.
area |
||
context |
the GtkCellAreaContext which has already been requested for widths. |
|
widget |
the GtkWidget where |
|
height |
the height for which to check the width of this area |
|
minimum_width |
location to store the minimum width, or |
[out][allow-none] |
natural_width |
location to store the natural width, or |
[out][allow-none] |
Since: 3.0
const gchar *
gtk_cell_area_get_current_path_string (GtkCellArea *area
);
Gets the current GtkTreePath string for the currently
applied GtkTreeIter, this is implicitly updated when
gtk_cell_area_apply_attributes()
is called and can be
used to interact with renderers from GtkCellArea
subclasses.
The current GtkTreePath string for the current
attributes applied to area
. This string belongs to the area and
should not be freed.
Since: 3.0
void gtk_cell_area_apply_attributes (GtkCellArea *area
,GtkTreeModel *tree_model
,GtkTreeIter *iter
,gboolean is_expander
,gboolean is_expanded
);
Applies any connected attributes to the renderers in
area
by pulling the values from tree_model
.
area |
||
tree_model |
the GtkTreeModel to pull values from |
|
iter |
the GtkTreeIter in |
|
is_expander |
whether |
|
is_expanded |
whether |
Since: 3.0
void gtk_cell_area_attribute_connect (GtkCellArea *area
,GtkCellRenderer *renderer
,const gchar *attribute
,gint column
);
Connects an attribute
to apply values from column
for the
GtkTreeModel in use.
area |
||
renderer |
the GtkCellRenderer to connect an attribute for |
|
attribute |
the attribute name |
|
column |
the GtkTreeModel column to fetch attribute values from |
Since: 3.0
void gtk_cell_area_attribute_disconnect (GtkCellArea *area
,GtkCellRenderer *renderer
,const gchar *attribute
);
Disconnects attribute
for the renderer
in area
so that
attribute will no longer be updated with values from the
model.
area |
||
renderer |
the GtkCellRenderer to disconnect an attribute for |
|
attribute |
the attribute name |
Since: 3.0
gint gtk_cell_area_attribute_get_column (GtkCellArea *area
,GtkCellRenderer *renderer
,const gchar *attribute
);
Returns the model column that an attribute has been mapped to, or -1 if the attribute is not mapped.
Since: 3.14
void gtk_cell_area_class_install_cell_property (GtkCellAreaClass *aclass
,guint property_id
,GParamSpec *pspec
);
Installs a cell property on a cell area class.
Since: 3.0
GParamSpec * gtk_cell_area_class_find_cell_property (GtkCellAreaClass *aclass
,const gchar *property_name
);
Finds a cell property of a cell area class by name.
the GParamSpec of the child property
or NULL
if aclass
has no child property with that name.
[transfer none]
Since: 3.0
GParamSpec ** gtk_cell_area_class_list_cell_properties (GtkCellAreaClass *aclass
,guint *n_properties
);
Returns all cell properties of a cell area class.
a newly
allocated NULL
-terminated array of GParamSpec*. The array
must be freed with g_free()
.
[array length=n_properties][transfer container]
Since: 3.0
void gtk_cell_area_add_with_properties (GtkCellArea *area
,GtkCellRenderer *renderer
,const gchar *first_prop_name
,...
);
Adds renderer
to area
, setting cell properties at the same time.
See gtk_cell_area_add()
and gtk_cell_area_cell_set()
for more details.
area |
||
renderer |
a GtkCellRenderer to be placed inside |
|
first_prop_name |
the name of the first cell property to set |
|
... |
a |
Since: 3.0
void gtk_cell_area_cell_set (GtkCellArea *area
,GtkCellRenderer *renderer
,const gchar *first_prop_name
,...
);
Sets one or more cell properties for cell
in area
.
area |
||
renderer |
a GtkCellRenderer which is a cell inside |
|
first_prop_name |
the name of the first cell property to set |
|
... |
a |
Since: 3.0
void gtk_cell_area_cell_get (GtkCellArea *area
,GtkCellRenderer *renderer
,const gchar *first_prop_name
,...
);
Gets the values of one or more cell properties for renderer
in area
.
area |
||
renderer |
a GtkCellRenderer which is inside |
|
first_prop_name |
the name of the first cell property to get |
|
... |
return location for the first cell property, followed
optionally by more name/return location pairs, followed by |
Since: 3.0
void gtk_cell_area_cell_set_valist (GtkCellArea *area
,GtkCellRenderer *renderer
,const gchar *first_property_name
,va_list var_args
);
Sets one or more cell properties for renderer
in area
.
area |
||
renderer |
a GtkCellRenderer which inside |
|
first_property_name |
the name of the first cell property to set |
|
var_args |
a |
Since: 3.0
void gtk_cell_area_cell_get_valist (GtkCellArea *area
,GtkCellRenderer *renderer
,const gchar *first_property_name
,va_list var_args
);
Gets the values of one or more cell properties for renderer
in area
.
area |
||
renderer |
a GtkCellRenderer inside |
|
first_property_name |
the name of the first property to get |
|
var_args |
return location for the first property, followed
optionally by more name/return location pairs, followed by |
Since: 3.0
void gtk_cell_area_cell_set_property (GtkCellArea *area
,GtkCellRenderer *renderer
,const gchar *property_name
,const GValue *value
);
Sets a cell property for renderer
in area
.
area |
||
renderer |
a GtkCellRenderer inside |
|
property_name |
the name of the cell property to set |
|
value |
the value to set the cell property to |
Since: 3.0
void gtk_cell_area_cell_get_property (GtkCellArea *area
,GtkCellRenderer *renderer
,const gchar *property_name
,GValue *value
);
Gets the value of a cell property for renderer
in area
.
area |
||
renderer |
a GtkCellRenderer inside |
|
property_name |
the name of the property to get |
|
value |
a location to return the value |
Since: 3.0
gboolean
gtk_cell_area_is_activatable (GtkCellArea *area
);
Returns whether the area can do anything when activated,
after applying new attributes to area
.
Since: 3.0
gboolean gtk_cell_area_activate (GtkCellArea *area
,GtkCellAreaContext *context
,GtkWidget *widget
,const GdkRectangle *cell_area
,GtkCellRendererState flags
,gboolean edit_only
);
Activates area
, usually by activating the currently focused
cell, however some subclasses which embed widgets in the area
can also activate a widget if it currently has the focus.
area |
||
context |
the GtkCellAreaContext in context with the current row data |
|
widget |
the GtkWidget that |
|
cell_area |
the size and location of |
|
flags |
the GtkCellRendererState flags for |
|
edit_only |
if |
Since: 3.0
gboolean gtk_cell_area_focus (GtkCellArea *area
,GtkDirectionType direction
);
This should be called by the area
’s owning layout widget
when focus is to be passed to area
, or moved within area
for a given direction
and row data.
Implementing GtkCellArea classes should implement this method to receive and navigate focus in its own way particular to how it lays out cells.
Since: 3.0
void gtk_cell_area_set_focus_cell (GtkCellArea *area
,GtkCellRenderer *renderer
);
Explicitly sets the currently focused cell to renderer
.
This is generally called by implementations of
GtkCellAreaClass.focus()
or GtkCellAreaClass.event()
,
however it can also be used to implement functions such
as gtk_tree_view_set_cursor_on_cell()
.
Since: 3.0
GtkCellRenderer *
gtk_cell_area_get_focus_cell (GtkCellArea *area
);
Retrieves the currently focused cell for area
Since: 3.0
void gtk_cell_area_add_focus_sibling (GtkCellArea *area
,GtkCellRenderer *renderer
,GtkCellRenderer *sibling
);
Adds sibling
to renderer
’s focusable area, focus will be drawn
around renderer
and all of its siblings if renderer
can
focus for a given row.
Events handled by focus siblings can also activate the given
focusable renderer
.
area |
||
renderer |
the GtkCellRenderer expected to have focus |
|
sibling |
the GtkCellRenderer to add to |
Since: 3.0
void gtk_cell_area_remove_focus_sibling (GtkCellArea *area
,GtkCellRenderer *renderer
,GtkCellRenderer *sibling
);
Removes sibling
from renderer
’s focus sibling list
(see gtk_cell_area_add_focus_sibling()
).
area |
||
renderer |
the GtkCellRenderer expected to have focus |
|
sibling |
the GtkCellRenderer to remove from |
Since: 3.0
gboolean gtk_cell_area_is_focus_sibling (GtkCellArea *area
,GtkCellRenderer *renderer
,GtkCellRenderer *sibling
);
Returns whether sibling
is one of renderer
’s focus siblings
(see gtk_cell_area_add_focus_sibling()
).
area |
||
renderer |
the GtkCellRenderer expected to have focus |
|
sibling |
the GtkCellRenderer to check against |
Since: 3.0
const GList * gtk_cell_area_get_focus_siblings (GtkCellArea *area
,GtkCellRenderer *renderer
);
Gets the focus sibling cell renderers for renderer
.
A GList of GtkCellRenderers. The returned list is internal and should not be freed.
[element-type GtkCellRenderer][transfer none]
Since: 3.0
GtkCellRenderer * gtk_cell_area_get_focus_from_sibling (GtkCellArea *area
,GtkCellRenderer *renderer
);
Gets the GtkCellRenderer which is expected to be focusable
for which renderer
is, or may be a sibling.
This is handy for GtkCellArea subclasses when handling events, after determining the renderer at the event location it can then chose to activate the focus cell for which the event cell may have been a sibling.
Since: 3.0
GtkCellRenderer *
gtk_cell_area_get_edited_cell (GtkCellArea *area
);
Gets the GtkCellRenderer in area
that is currently
being edited.
Since: 3.0
GtkCellEditable *
gtk_cell_area_get_edit_widget (GtkCellArea *area
);
Gets the GtkCellEditable widget currently used to edit the currently edited cell.
Since: 3.0
gboolean gtk_cell_area_activate_cell (GtkCellArea *area
,GtkWidget *widget
,GtkCellRenderer *renderer
,GdkEvent *event
,const GdkRectangle *cell_area
,GtkCellRendererState flags
);
This is used by GtkCellArea subclasses when handling events
to activate cells, the base GtkCellArea class activates cells
for keyboard events for free in its own GtkCellArea->activate()
implementation.
area |
||
widget |
the GtkWidget that |
|
renderer |
the GtkCellRenderer in |
|
event |
the GdkEvent for which cell activation should occur |
|
cell_area |
the GdkRectangle in |
|
flags |
the GtkCellRendererState for |
Since: 3.0
void gtk_cell_area_stop_editing (GtkCellArea *area
,gboolean canceled
);
Explicitly stops the editing of the currently edited cell.
If canceled
is TRUE
, the currently edited cell renderer
will emit the ::editing-canceled signal, otherwise the
the ::editing-done signal will be emitted on the current
edit widget.
See gtk_cell_area_get_edited_cell()
and gtk_cell_area_get_edit_widget()
.
Since: 3.0
void gtk_cell_area_inner_cell_area (GtkCellArea *area
,GtkWidget *widget
,const GdkRectangle *cell_area
,GdkRectangle *inner_area
);
This is a convenience function for GtkCellArea implementations
to get the inner area where a given GtkCellRenderer will be
rendered. It removes any padding previously added by gtk_cell_area_request_renderer()
.
area |
||
widget |
the GtkWidget that |
|
cell_area |
the |
|
inner_area |
the return location for the inner cell area. |
[out] |
Since: 3.0
void gtk_cell_area_request_renderer (GtkCellArea *area
,GtkCellRenderer *renderer
,GtkOrientation orientation
,GtkWidget *widget
,gint for_size
,gint *minimum_size
,gint *natural_size
);
This is a convenience function for GtkCellArea implementations
to request size for cell renderers. It’s important to use this
function to request size and then use gtk_cell_area_inner_cell_area()
at render and event time since this function will add padding
around the cell for focus painting.
area |
||
renderer |
the GtkCellRenderer to request size for |
|
orientation |
the GtkOrientation in which to request size |
|
widget |
the GtkWidget that |
|
for_size |
the allocation contextual size to request for, or -1 if the base request for the orientation is to be returned. |
|
minimum_size |
location to store the minimum size, or |
[out][allow-none] |
natural_size |
location to store the natural size, or |
[out][allow-none] |
Since: 3.0
struct GtkCellAreaClass { /* Basic methods */ void (* add) (GtkCellArea *area, GtkCellRenderer *renderer); void (* remove) (GtkCellArea *area, GtkCellRenderer *renderer); void (* foreach) (GtkCellArea *area, GtkCellCallback callback, gpointer callback_data); void (* foreach_alloc) (GtkCellArea *area, GtkCellAreaContext *context, GtkWidget *widget, const GdkRectangle *cell_area, const GdkRectangle *background_area, GtkCellAllocCallback callback, gpointer callback_data); gint (* event) (GtkCellArea *area, GtkCellAreaContext *context, GtkWidget *widget, GdkEvent *event, const GdkRectangle *cell_area, GtkCellRendererState flags); void (* render) (GtkCellArea *area, GtkCellAreaContext *context, GtkWidget *widget, cairo_t *cr, const GdkRectangle *background_area, const GdkRectangle *cell_area, GtkCellRendererState flags, gboolean paint_focus); void (* apply_attributes) (GtkCellArea *area, GtkTreeModel *tree_model, GtkTreeIter *iter, gboolean is_expander, gboolean is_expanded); /* Geometry */ GtkCellAreaContext *(* create_context) (GtkCellArea *area); GtkCellAreaContext *(* copy_context) (GtkCellArea *area, GtkCellAreaContext *context); GtkSizeRequestMode (* get_request_mode) (GtkCellArea *area); void (* get_preferred_width) (GtkCellArea *area, GtkCellAreaContext *context, GtkWidget *widget, gint *minimum_width, gint *natural_width); void (* get_preferred_height_for_width) (GtkCellArea *area, GtkCellAreaContext *context, GtkWidget *widget, gint width, gint *minimum_height, gint *natural_height); void (* get_preferred_height) (GtkCellArea *area, GtkCellAreaContext *context, GtkWidget *widget, gint *minimum_height, gint *natural_height); void (* get_preferred_width_for_height) (GtkCellArea *area, GtkCellAreaContext *context, GtkWidget *widget, gint height, gint *minimum_width, gint *natural_width); /* Cell Properties */ void (* set_cell_property) (GtkCellArea *area, GtkCellRenderer *renderer, guint property_id, const GValue *value, GParamSpec *pspec); void (* get_cell_property) (GtkCellArea *area, GtkCellRenderer *renderer, guint property_id, GValue *value, GParamSpec *pspec); /* Focus */ gboolean (* focus) (GtkCellArea *area, GtkDirectionType direction); gboolean (* is_activatable) (GtkCellArea *area); gboolean (* activate) (GtkCellArea *area, GtkCellAreaContext *context, GtkWidget *widget, const GdkRectangle *cell_area, GtkCellRendererState flags, gboolean edit_only); };
adds a GtkCellRenderer to the area. |
||
removes a GtkCellRenderer from the area. |
||
calls the GtkCellCallback function on every GtkCellRenderer in
the area with the provided user data until the callback returns |
||
Calls the GtkCellAllocCallback function on every
GtkCellRenderer in the area with the allocated area for the cell
and the provided user data until the callback returns |
||
Handle an event in the area, this is generally used to activate a cell at the event location for button events but can also be used to generically pass events to GtkWidgets drawn onto the area. |
||
Actually render the area’s cells to the specified rectangle,
|
||
Apply the cell attributes to the cells. This is implemented as a signal and generally GtkCellArea subclasses don't need to implement it since it is handled by the base class. |
||
Creates and returns a class specific GtkCellAreaContext to store cell alignment and allocation details for a said GtkCellArea class. |
||
Creates a new GtkCellAreaContext in the same state as
the passed |
||
This allows an area to tell its layouting widget whether
it prefers to be allocated in |
||
Calculates the minimum and natural width of the areas cells with the current attributes applied while considering the particular layouting details of the said GtkCellArea. While requests are performed over a series of rows, alignments and overall minimum and natural sizes should be stored in the corresponding GtkCellAreaContext. |
||
Calculates the minimum and natural height
for the area if the passed |
||
Calculates the minimum and natural height of the
areas cells with the current attributes applied. Essentially this is
the same as |
||
Calculates the minimum and natural width
for the area if the passed |
||
This should be implemented to handle changes in child
cell properties for a given GtkCellRenderer that were previously
installed on the GtkCellAreaClass with |
||
This should be implemented to report the values of child cell properties for a given child GtkCellRenderer. |
||
This virtual method should be implemented to navigate focus from
cell to cell inside the GtkCellArea. The GtkCellArea should move
focus from cell to cell inside the area and return |
||
Returns whether the GtkCellArea can respond to
|
||
This is called when the layouting widget rendering the
GtkCellArea activates the focus cell (see |
“edit-widget”
property“edit-widget” GtkCellEditable *
The widget currently editing the edited cell
This property is read-only and only changes as
a result of a call gtk_cell_area_activate_cell()
.
Flags: Read
Since: 3.0
“edited-cell”
property“edited-cell” GtkCellRenderer *
The cell in the area that is currently edited
This property is read-only and only changes as
a result of a call gtk_cell_area_activate_cell()
.
Flags: Read
Since: 3.0
“focus-cell”
property“focus-cell” GtkCellRenderer *
The cell in the area that currently has focus
Flags: Read / Write
Since: 3.0
“add-editable”
signalvoid user_function (GtkCellArea *area, GtkCellRenderer *renderer, GtkCellEditable *editable, GdkRectangle *cell_area, gchar *path, gpointer user_data)
Indicates that editing has started on renderer
and that editable
should be added to the owning cell-layouting widget at cell_area
.
area |
the GtkCellArea where editing started |
|
renderer |
the GtkCellRenderer that started the edited |
|
editable |
the GtkCellEditable widget to add |
|
cell_area |
the GtkWidget relative GdkRectangle coordinates
where |
|
path |
the GtkTreePath string this edit was initiated for |
|
user_data |
user data set when the signal handler was connected. |
Flags: Run First
Since: 3.0
“apply-attributes”
signalvoid user_function (GtkCellArea *area, GtkTreeModel *model, GtkTreeIter *iter, gboolean is_expander, gboolean is_expanded, gpointer user_data)
This signal is emitted whenever applying attributes to area
from model
area |
the GtkCellArea to apply the attributes to |
|
model |
the GtkTreeModel to apply the attributes from |
|
iter |
the GtkTreeIter indicating which row to apply the attributes of |
|
is_expander |
whether the view shows children for this row |
|
is_expanded |
whether the view is currently showing the children of this row |
|
user_data |
user data set when the signal handler was connected. |
Flags: Run First
Since: 3.0
“focus-changed”
signalvoid user_function (GtkCellArea *area, GtkCellRenderer *renderer, gchar *path, gpointer user_data)
Indicates that focus changed on this area
. This signal
is emitted either as a result of focus handling or event
handling.
It's possible that the signal is emitted even if the currently focused renderer did not change, this is because focus may change to the same renderer in the same cell area for a different row of data.
area |
the GtkCellArea where focus changed |
|
renderer |
the GtkCellRenderer that has focus |
|
path |
the current GtkTreePath string set for |
|
user_data |
user data set when the signal handler was connected. |
Flags: Run First
Since: 3.0
“remove-editable”
signalvoid user_function (GtkCellArea *area, GtkCellRenderer *renderer, GtkCellEditable *editable, gpointer user_data)
Indicates that editing finished on renderer
and that editable
should be removed from the owning cell-layouting widget.
area |
the GtkCellArea where editing finished |
|
renderer |
the GtkCellRenderer that finished editeding |
|
editable |
the GtkCellEditable widget to remove |
|
user_data |
user data set when the signal handler was connected. |
Flags: Run First
Since: 3.0


Turner lifts Bowling Green over DII Fairmont State 88-66
BOWLING GREEN, Ohio (AP) - Justin Turner registered 16 points as Bowling Green easily beat Division II opponent Fairmont State 88-66 on Friday.
BGSU opened the game on a 12-2 run and it was 24-8 after eight minutes. The Falcons led by 15 points at the break and by 30 with 2:45 remaining.
Trey Diggs had 11 points for Bowling Green (3-1). Caleb Fields and Dylan Frye each added 10 points.
TOP STORIES
Company co-founded by Nancy Pelosi's son charged with securities fraud
Skeptics chuckle as climate activist Greta Thunberg sets sail for Europe on 'plastic yacht'
Trump accused of witness intimidation after criticizing Marie Yovanovitch as she testified
On Monday, Turner was two assists shy of the program’s first triple-double since 2007. He entered averaging 23 points per game.
Przemyslaw Golek had 12 points for the Fighting Falcons. Cole VonHandorf added 12 points and Dale Bonner had 10 points and six rebounds.
Bowling Green takes on Western Kentucky next Friday in the Paradise Jam, and will play either Cincinnati or Illinois State in the following game.
For more AP college basketball coverage: https://apnews.com/Collegebasketball and http://twitter.com/AP_Top25
Elements of this story were generated by Automated Insights, http://www.automatedinsights.com/ap, using data from STATS LLC, https://www.stats.com
Sign up for Daily Newsletters
Copyright © 2019 The Washington Times, LLC.
Please read our comment policy before commenting.


The default implementation of the PermissionProvider interface evaluates permissions based on the information stored in a dedicated part of the repository content call the permission store.
See section Permission Evaluation in Detail.
Oak 1.0 comes with a configurable set of subtrees that are read-accessible to all subjects irrespective of other access control content taking effect. The original aim of these readable trees is to assert full acccess to namespace, nodetype and privilege information and the corresponding configuration therefore lists the following paths:
This default set can be changed or extended by setting the corresponding configuration option. However, it is important to note that many JCR API calls rely on the accessibility of the namespace, nodetype and privilege information. Removing the corresponding paths from the configuration will most probably have undesired effects.
In the default implementation following principals always have full access to the whole content repository (except for hidden items that are not exposed on the Oak API) irrespective of the access control content:
See section Multiplexing support in the PermissionStore.
The permission evaluation present with Oak 1.0 keeps a dedicated location where permissions are being stored for later evaluation. The store is kept in sync with the access control content by a separated PostValidationHook implementation ([PermissionHook]).
The location of the permission store is /jcr:system/rep:permissionStore; in accordance with other stores underneath jcr:system it is global to the whole repository keeping a separate entry for each workspace present with the repository.
The permission entries are grouped by principal and stored below the store root based on the hash value of the path of the access controlled node; hash collisions are handled by adding subnodes accordingly.
/jcr:system/rep:permissionStore/workspace-name [rep:PermissionStore] /principal-name [rep:PermissionStore] /1259237738 [rep:PermissionStore] /0 [rep:Permissions] /1 [rep:Permissions] /c0 [rep:PermissionStore] # hash collision /0 [rep:Permissions] /1 [rep:Permissions] /2 [rep:Permissions] /c1 [rep:PermissionStore] # hash collision /0 [rep:Permissions] /1 [rep:Permissions] /2 [rep:Permissions] /47 [rep:PermissionStore] /0 [rep:Permissions] /1 [rep:Permissions]
Each per path store looks as follows
"1259237738" { "jcr:primaryType": "rep:PermissionStore", "rep:accessControlledPath": "/content", "0": { "jcr:primaryType": "rep:Permissions", "rep:isAllow": false, "rep:privileges": [32], "rep:ntNames": ["nt:unstructured", "oak:Unstructured"] ... /* additional restrictions as present in the entry */ } }
It is important to understand that the permission store is a implementation specific structure that is maintained by the system itself. For this reason access to the permission store is additionally restricted superimposing the regular permissions being enforced for regular repository items.
In detail this means that the permission store cannot be written by JCR nor Oak API method calls. It’s immutability is enforced by a dedicated FailingValidator that prevents any modifications underneath /jcr:system/rep:permissionStore. Similarly read access is not allowed except for system principals. In order to discover and display access control related information API consumers should use the regular JCR and Jackrabbit permission and access control management API as listed in the introduction and in section Using the Access Control Management API.
For the permission store the following built-in node types have been defined:
[rep:PermissionStore] - rep:accessControlledPath (STRING) protected IGNORE - rep:numPermissions (LONG) protected IGNORE - rep:modCount (LONG) protected IGNORE + * (rep:PermissionStore) = rep:PermissionStore protected IGNORE + * (rep:Permissions) = rep:Permissions protected IGNORE [rep:Permissions] - * (UNDEFINED) protected IGNORE - * (UNDEFINED) protected multiple IGNORE + * (rep:Permissions) = rep:Permissions protected IGNORE
In addition Oak 1.0 defines a specific mixin type that allows to store the path(s) of the versionable node with each version history. Adding this mixing and updating the versionable path information is taken care of by a dedicated commit hook implementation (VersionablePathHook).
[rep:VersionablePaths] mixin - * (PATH) protected ABORT
The consistency of this content structure is asserted by a dedicated PermissionValidator. The corresponding errors are all of type Access with the following codes:
| Code | Message |
|---|---|
| 0000 | Generic access violation |
| 0021 | Version storage: Node creation without version history |
| 0022 | Version storage: Removal of intermediate node |
The default implementation supports the following configuration parameters:
| Parameter | Type | Default | Description |
|---|---|---|---|
| PARAM_PERMISSIONS_JR2 | String | - | Enables backwards compatible behavior for the permissions listed in the parameter value containing the permission names separated by ‘,’. Supported values are: USER_MANAGEMENT,REMOVE_NODE |
| PARAM_READ_PATHS | Set<String> | paths to namespace, nodetype and privilege root nodes | Set of paths that are always readable to all principals irrespective of other permissions defined at that path or inherited from other nodes. |
| PARAM_ADMINISTRATIVE_PRINCIPALS | String[] | - | The names of the additional principals that have full permission and for which the permission evaluation can be skipped altogether. |


While you enjoy with MyOrdbok, please feel free to subscribe how you feel about Functions and interface etc.... We gonna love your feedback...


by Dave Mason, with edits by various editors
The goal of this mechanism is to provide a permanent registry for Scheme Requests For Implementation (SRFIs — pronounced "surfie").  Rather, it is a formal way to manage the production of proposals for Scheme.
There are many other things that this process is not. Discussion of those, rationales for some of the implementation details, and answers to related questions are to be found in the SRFI FAQ page.
Related to this process is a Scheme special form, documented in SRFI 7, that a Scheme program can use to ascertain whether an implementation supports a particular standard or feature.
The site https://srfi.schemers.org/
will provide an archive of draft, final and withdrawn
SRFIs and a submission process to submit SRFIs for consideration.
The editors of the SRFIs will be experienced members of the Scheme community independent of the major implementors. They will attempt to keep the quality of SRFIs high, but will ultimately accept any SRFI which conforms to the structure requirements below.
A moderated mailing list, srfi-announce at srfi dot schemers dot
org
, will be used to announce when new SRFI proposals become
drafts. It will carry a final notification when the SRFI has been
either final or withdrawn. Anyone can subscribe to the list,
and implementors are especially encouraged to subscribe.
There will be a mailing list created for the evaluation period of each SRFI where all discussion of the proposal will take place. Anyone may join these lists. The discussion will be archived and the archived discussion will remain part of the permanent record of the SRFI.
All proposals must follow the following steps:
srfi minus editors at srfi dot schemers dot org
.
srfi minus announce at
srfi dot schemers dot org
. As part of the initial editing process, the
editors will ensure that related standards (RnRS, SRFIs, RFCs and
others) are appropriately identified and that the proposal meets the
structural requirements described below. If other related standards are
identified during the comment process or after acceptance, the editors will
keep the references up-to-date. A proposal cannot normally be finalized until
60 days have passed since its initial submission.
If the authors choose, they may submit revised versions of the proposal at any point during the comment period. Every such revision shall be announced to the SRFI's mailing list, and all revisions will be retained in the permanent record of the SRFI.
The SRFI process used to set a hard limit of ninety days on the discussion period. This was done because "Active discussion or revision after 90 days normally suggests that a proposal has been revised at least three times and is not yet mature enough for standardization." The current editor has removed this limit, but strongly encourages authors to submit SRFIs that they believe will only take ninety days, and reserves the right to withdraw SRFIs if authors become unresponsive.
srfi minus
announce at srfi dot schemers dot org
.
Once the SRFI number has been assigned, the proposal will be in one of three states: draft, final, or withdrawn. Lists of proposals in all three states will be available and archived indefinitely, and SRFI numbers will not be reused. The only changes that may be made to a final SRFI are:
Every Scheme implementation is encouraged to provide implementations of final SRFIs where possible, and to retain existing implementations of deprecated SRFIs for a reasonable time period.
New standards, such as RnRS, may supersede or conflict with existing SRFIs. The editors and authors will work to update the relationship of active SRFIs to such standards.
Anyone who finds an error should report it to the SRFI's discussion mailing list. That way, it will be recorded publicly.
We always attempt to reach the author for guidance.
If the corrections are only to the implementation, not the document, we just make the change.
If the author agrees to proposed corrections to the document, or if
the author never expresses an opinion but there is consensus about
corrections on the mailing list, we'll revise the document. See the
example of
SRFI
158. In this case, a tag like errata-1
is added in
the Git repository.
Every SRFI must meet the following requirements:
The sample implementation should normally conform to the specification in point 6 above. If there is any variance (such as the implementation being overly restrictive), the specification will be considered correct, the variance should be explained, and a timetable provided for the sample implementation to meet the specification.
The sample implementation should include automated tests. Tests make porting to new Scheme implementations easier. They also help users understand how your SRFI is to be used. However, if the sample implementation is trivial or not really meant to be used, i.e. it is just a proof of concept, it's okay to omit tests. That should be a rare case. No specific test framework is required, but both SRFI 64 and SRFI 78 are available.
A SRFI may be submitted without an implementation so that the specification may be refined before effort is invested in implementing it. However, an implementation should be provided as soon as possible.
Copyright (C) AUTHOR (YEAR).Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice (including the next paragraph) shall be included in all copies or substantial portions of the Software.
 IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
In addition to the SRFI document, any software written specifically for the SRFI should be published under the above license. However, at the editors' discretion, the SRFI may reference software that was already written and published under another license, citing that software as its sample implementation. The BSD 2- and 3-clause licenses are specifically allowed for this purpose.
The editors may not reject a proposal because they disagree with the importance of the proposal, or because they think it is a wrong-headed approach to the problem. The editors may, however, reject a proposal because it does not meet the requirements listed here.
In particular, lack of a sample implementation (as defined above) is grounds for rejection. This can only occur if the "sample implementation" requirement is being met by an outlined implementation (type 5), and there is consensus that the implementation outline is not adequate. Note that this is never a permanent rejection, because creation of an implementation of one of the other types is a complete refutation of this basis for rejection.
The other likely basis for rejection is an inadequate design specification. In this case, the editors will attempt to help the author(s) conform to the requirements.
Remember, even if a proposal becomes a final SRFI, the need for it must be compelling enough for implementors to decide to incorporate it into their systems, or it will have been a waste of time and effort for everyone involved. If the quality of any SRFI is not high, the likelihood of implementors adding this feature to their implementation is extremely low.
The following terms may be used in SRFIs with the corresponding definitions: The term "a SRFI <n>-conformant implementation" means an implementation of Scheme which conforms to the specification described in SRFI <n>.
The history of this document is here.


Issue: MACRO-SUBFORMS-TOP-LEVEL-PReferences: EVAL-WHEN, COMPILE-FILE,
all macros defined in the standard
Related issues: EVAL-WHEN-NON-TOP-LEVEL
Category: CLARIFICATION
Edit history: v1, 13 Feb 1991, Sandra Loosemore
v2, 11 Mar 1991, Sandra Loosemore
Problem description:
The compilation model defined by issue EVAL-WHEN-NON-TOP-LEVEL specifies
that expansions of macros inherit "top-level-ness" from the macro call.
This makes sense for user-defined macros, but users have no control
over what the expansions of macros defined in the standard are, since
they're provided by the Lisp implementation. The semantics of a macro
call form can depend on whether or not its subforms appear at top-level
in the expansion, so the standard ought to place some constraints
on what the standard macros can expand into.
Proposal (MACRO-SUBFORMS-TOP-LEVEL-P:ADD-CONSTRAINTS):
Clarify that no subforms of calls to macros defined in the standard
inherit "top-level-ness" from the macro call unless explicitly stated
otherwise.
Clarify that no macros now in the standard pass on "top-level-ness"
to their subforms.
Clarify that even if a macro is normally treated as a special form by
the file compiler, both its handling as a special form and its normal
macro expansion must still satisfy these constraints.
Clarify that compiler-macro functions must ensure that expansions
have the same semantics regarding inheritance of top-level-ness
as the normal function or macro definition of the form.
Rationale:
It fixes the problem.
Current Practice:
Probably many implementations currently return macro expansions that
violate these rules.
Cost to Implementors:
Implementors will have to examine the definitions of all macros they
provide to make sure that they conform to these rules. Some
"optimizations" currently performed may turn out to be invalid;
for example, (and <form>)
could expand into (let () <form>)
but not (locally <form>)
or (progn <form>)
or <form>
Cost to Users:
Probably none.
Cost of non-adoption:
User programs will behave differently in different implementations.
Performance impact:
Probably small.
Benefits:
The cost of non-adoption is avoided.
Esthetics:
The whole business of "top-level-ness" is kind of ugly.
Discussion:
It doesn't appear that any of the ~90 macros defined in the standard
require special exceptions from the rule. Certainly none of the
binding, conditional, or iteration macros ought to pass "top-level-ness"
through.


HSP : Hot Soup Processor ver3.6 / onion software 1997-2021(c)
"Peas Editor" visually arranges the elements (parts) that are the basis of the program, It is a tool for automatically generating HSP scripts.
Start it from the shortcut icon of "Peas", or select "ahtman.exe" in the folder where HSP3 is installed. You can use the Peas editor by starting it.
The "Peas Editor" makes the basic script flow visually understandable, as well as You can modify only certain elements without using a script editor, It's a new option for those who haven't touched programming before or for beginners.
In the Peas editor, the program is created according to the parts placed on the screen. Press the "Add" button to place the part on the screen. The parts list screen that can be placed is displayed. If you right-click and select a part from this, it will be placed on the main screen.
Placed parts can be moved by dragging while holding down the left mouse button. It doesn't matter where the parts are placed.
There are several types of parts. The uneven jigsaw puzzle-like parts are used for the flow of the program. You can connect the parts with a line. The contents of the parts connected by the line are executed in order. For details, refer to "Program flow".
Clean parts with no irregularities are called resource parts and cannot be connected by lines. Instead, resource parts are always available from other parts. For example, by arranging music resource parts, you can specify it from the program at any time. You will be able to play music. It ’s like reserving the materials used in the program. It's a good idea to think about it.
Let's actually create a simple program and run it. First, use the "Add" button to place the "Home" parts. The "home" part is the starting point for starting the program. Must be placed first. When you open the "Home" part, you will see a "property edit window" that looks like a screen. This is a screen for editing the contents related to the "Home" part. You can change it to suit what you want to make. For example, changing the "Title Name" changes the title displayed in the title bar on the window. When you have finished editing the content, press "OK" to confirm the edited content. Please note that other operations cannot be performed on the main screen while the "property edit window" is displayed.
Then press the "Save As" button to save the project. If you want the program to work, you need to name and save the project. The Peas editor uses the "My Documents" folder by default. Here, save the project with a name such as "Test" on "My Documents" for easy understanding.
Next, let's put a picture on the screen. Place the image file in bmp or jpeg format in the "My Documents" folder where you saved the project in advance. Please make a copy of one. Here, as an example, "back.jpg" in the peas sample folder of HSP3.1 is used.
Select the "Image display" part with the main "Add" button. The "Image Display" part is placed so that it is connected to the "Home" that has already been placed. The "Properties Edit Window" will appear, and you should see an item for entering an image to display. Here, specify the image file prepared earlier. You can specify the file in the file selection dialog by pressing the "Select" button. Once you have made your selection, press "OK" to confirm.
This completes the flow of the program that displays the image. Make sure that the placed "Home" and "Image display" are connected by a line. This indicates that the "image display" will be executed after the home, which is the starting point of the program. You can move the parts placed on the screen to any position you like. You can freely move it to a shape that is easy for you to see. However, the connecting line will come out of the protrusion on the right side of the part and connect to the left side of the next part. In other words, please note that it is basic to arrange the parts so that they flow from left to right.
At this point, you can actually run the program with the main "Run" button. If the window with the title you specified is displayed and the image file you specified appears in it, it is successful.
If you want to change or check the contents, click the part to select it and then press the "Edit" button. At any time, the "Property Edit Window" will appear and you can modify the contents.
The style of "Peas Editor" is to complete your program by repeating this process. You can save all the positions and contents of the parts you placed in the project file and recall them at any time. I can do it. Also, if you press the "Run" button, it will be in the same folder as the project file. A script file with the same name as the project file and the extension ".hsp" will be generated. This file is an HSP script converted from the content edited with "Peas Editor". You can run it directly from the HSP script editor or create an executable file.
There are also some project files in the HSP3.1 peas sample folder (sample / peas) It is prepared as a sample, so please refer to it.
You can freely change the state of the parts placed on the screen. Any number of parts can be placed on the screen with the "Add" button, You can delete the selected part with the "Delete" button.
The screen to be placed is page-managed. "Page 1/3" displayed in the upper right Shows page information. For page information, "current page number / maximum page number" It is displayed in the form of. The content and execution of the part has nothing to do with the page. It just changes where the parts are placed.
Pages can be moved with the main "<-" and "->" buttons, and the number of pages can be specified. You can also jump directly by pressing the "Page" button. (The maximum number of pages can be increased by directly specifying the number of pages.) You can also return to page 0 at any time with the "Home" button.
You can connect and disconnect parts at any time. Basically, the parts connected by a line are executed in order and stop at the place where the line breaks. If you press the "Disconnect" button with a part selected, the connection with the next part will be disconnected. Also, with the unconnected parts selected, press the "Connect" button to When the dialog "Connect the selected parts. Are you sure?" Is displayed. Select the part you want to connect again and press "OK" to connect the two parts.
The "label" part is like a marker used to indicate the location of a program. By placing the "Label" part from the "Add" button, You can make a mark when jumping from another place.
"Label" parts include "jump" parts and parts such as "conditional branch" or "button". Can be specified. If a jump is made at run time, execution will continue from the specified label.
The "subroutine" part has a function similar to the label part. This part can be named and marked like a "label", As a subroutine to return to the caller after finishing the execution of the part connected to this part You can make it work. (When branching or jumping, by setting the type to "Subroutine call", the "Subroutine" part can be changed. You can call it. )
The "variable" part is a "container" whose contents can be changed in the program. By selecting the "Resources" category from Add Parts and selecting "Variables", You can place "variable" parts on the screen.
Variable parts hold numbers, strings, etc. during program execution The contents can be changed by parts such as "variable assignment". In addition, "conditional branching" and "variable display" that perform processing based on the contents held by the variable are provided.
The Peas editor allows you to visually place parts and generate scripts, while For those who enter scripts directly with HSP script editor etc., there may be some parts that may be troublesome.
The Peas editor is intended to assist the HSP scripting environment. We do not expect to do all the work in the Peas editor. However, routine work, creating very simple scripts, learning programs, etc. I think that there are many situations where the Peas editor is used effectively.
Changing the source of an HSP script that is already running to an AHT file that supports the Peas editor is not possible. It's not that difficult. For example, an adventure game script that allows you to edit user-modifiable parts Publish as an AHT file and create a mechanism for the general public to create a game using only the Peas editor It is also possible to provide.
Those who can build HSP scripts will provide it in the form of AHT, which makes it easier to modify the content. If you can't write an HSP script, you can start from this editor and level up. Building such an environment is the goal of the Peas editor, and we will continue to update for it. It's a schedule.
Parts that can be added with the Peas editor can be freely created by the user according to the specifications of the AHT file. Parts are searched under the "AHT" folder in the same location as ahtman.exe. By adding the aht file to this folder, it will be recognized as an additional part.
AHT files are basically in the same format as HSP source script files. By matching the comment description to the aht specifications, it is possible to set parameter editing items. For more information on AHT files, see AHT Manual (aht.txt) .
The Peas editor is copyrighted by onion software.
"Peas Editor" is distributed in the form of being bundled with "HSP3". The rules for redistribution are the same as for "HSP3". As long as it is done free of charge, you are free to do it.
The source script for the "Peas Editor" is included in the HSPSDK Anyone can freely modify, reorganize, and redistribute it. Redistribution can be in the form of a source script or an executable file.


Container Elements
Default behaviour
Specific widths
[flex="33"]
[flex="55"]
[flex]
[flex="66"]
[flex="33"]
Change Order
[flex-order="3"]
[flex-order="2"]
[flex-order="1"]
Child layouts
Responsive layout
I'm above on mobile, and to the left on larger devices.
I'm below on mobile, and to the right on larger devices.
I flex to one-third of the space on mobile, and two-thirds on other devices.
I flex to two-thirds of the space on mobile, and one-third on other devices.
Padding and margin
I'm on the left, and there's an empty area around me.
I'm on the right, and there's an empty area around me.
Show/Hide
I'm hidden on mobile and shown on larger devices.
I'm shown on mobile and hidden on larger devices.


Original generates the origin URL for a given URL or URL object. In addition to
that it also comes with a simple same
function to check if two URL’s have the
same origin.
This module is browserify and node compatible and is therefor release in the npm registry and can be installed using:
npm install --save original
In all the examples we assume that the module is loaded using:
```js ‘use strict’;
var origin = require(‘original’); ```
To get the origin of a given URL simply call origin
function with any given
URL to get origin.
```js var o = origin(‘https://google.com/foo/bar?path’);
// o = https://google.com ```
To compare if two URL’s share the same origin you can call the same
method.
js
if (origin.same('https://google.com/foo', 'https://primus.io')) {
console.log('same');
} else {
console.log('guess what, google.com and primus.io are not the same origin');
}
And that’s it.
MIT


Rewired State
← Back to rewiredstate.org
Page not found
The page you were looking for could not be found! Please go back and try again.


catch
blocks that immediately rethrow
the caught exception without performing any action on it.
Such catch
blocks are unnecessary and have no error
handling.
Example:
try {
new FileInputStream("");
} catch (FileNotFoundException e) {
throw e;
}


Functions for finding our information about the environment.
More...
Functions for finding our information about the environment.
◆ jmonitor_getdisplayrect()
| void jmonitor_getdisplayrect |
( |
long |
workarea, |
|
|
long |
displayindex, |
|
|
t_rect * |
rect |
|
) |
| |
Return the t_rect for a given display.
- Parameters
-
| workarea | Set workarea non-zero to clip out things like dock / task bar. |
| displayindex | The index number for a monitor. The primary monitor has an index of 0. |
| rect | The address of a valid t_rect whose values will be filled-in upon return. |
◆ jmonitor_getdisplayrect_foralldisplays()
| void jmonitor_getdisplayrect_foralldisplays |
( |
long |
workarea, |
|
|
t_rect * |
rect |
|
) |
| |
Return a union of all display rects.
- Parameters
-
| workarea | Set workarea non-zero to clip out things like dock / task bar. |
| rect | The address of a valid t_rect whose values will be filled-in upon return. |
◆ jmonitor_getdisplayrect_forpoint()
| void jmonitor_getdisplayrect_forpoint |
( |
long |
workarea, |
|
|
t_pt |
pt, |
|
|
t_rect * |
rect |
|
) |
| |
Return the t_rect for the display on which a point exists.
- Parameters
-
| workarea | Set workarea non-zero to clip out things like dock / task bar. |
| pt | A point, for which the monitor will be determined and the rect recturned. |
| rect | The address of a valid t_rect whose values will be filled-in upon return. |
◆ jmonitor_getdisplayscalefactor()
| double jmonitor_getdisplayscalefactor |
( |
long |
displayindex | ) |
|
Return the scale factor for the display on which a point exists.
- Parameters
-
| displayindex | Index of the monitor whose scale factor will be returned. |
◆ jmonitor_getdisplayscalefactor_forpoint()
| double jmonitor_getdisplayscalefactor_forpoint |
( |
t_pt |
pt | ) |
|
Return the scale factor for the display on which a point exists.
- Parameters
-
| pt | A point, for which the monitor will be determined and the scale factor recturned. |
◆ jmonitor_getnumdisplays()
| long jmonitor_getnumdisplays |
( |
void |
| ) |
|
Return the number of monitors on which can be displayed.
- Returns
- The number of monitors.
◆ jmonitor_scale_pt()
| t_pt jmonitor_scale_pt |
( |
t_pt |
unscaled_pt | ) |
|
take an unscaled point and convert it to a scaled point note – most APIs take scaled coordinates so drawing doesn't need to consider scale factor for each monitor
- Parameters
-
| unscaled_pt | the point to be scaled, should be in pixels on the global "virtual" screen consisting of all monitors |
- Returns
- pointer to receive the scaled point, scaled to normalize based on various scale factors and monitor arrangement
◆ jmonitor_unscale_pt()
| t_pt jmonitor_unscale_pt |
( |
t_pt |
scaled_pt | ) |
|
take an unscaled point and convert it to a scaled point note – most APIs take scaled coordinates so drawing doesn't need to consider scale factor for each monitor
- Parameters
-
| scaled_pt | the point to be unscaled, should be in normalized coordinates, scaled based on scale factors and monitor arrangement |
- Returns
- pointer to receive the unscaled point, which will be pixel-based coordinates relative to the main monitor origin


|
|||||||||
| PREV CLASS NEXT CLASS | FRAMES NO FRAMES | ||||||||
| SUMMARY: NESTED | FIELD | CONSTR | METHOD | DETAIL: FIELD | CONSTR | METHOD |
java.lang.Object com.swarmconnect.SwarmMessageThread
public class SwarmMessageThread
| Nested Class Summary | |
|---|---|
static class |
SwarmMessageThread.GotMessagesCB
|
static class |
SwarmMessageThread.GotNumMessages
|
static class |
SwarmMessageThread.GotThreadsCB
|
static class |
SwarmMessageThread.SentMessageCB
|
| Field Summary | |
|---|---|
int |
id
The unique identification number. |
java.lang.String |
lastMessage
The text of the most recent message in the thread. |
SwarmUser |
otherUser
The other user that is participating in the message thread. |
boolean |
viewed
True if the most recent message in the thread has been viewed, false otherwise. |
| Constructor Summary | |
|---|---|
SwarmMessageThread()
|
| Method Summary | |
|---|---|
static void |
getAllThreads(SwarmMessageThread.GotThreadsCB cb)
Gets all threads for the user (regardless of whether or not they have been viewed by the user). |
static void |
getMessages(int threadId,
int otherUserId,
SwarmMessageThread.GotMessagesCB cb)
Gets all messages that were sent by a user (specified by the otherUserId) contained within a SwarmMessageThread (specified by the threadId). |
static void |
getMessages(int threadId,
SwarmMessageThread.GotMessagesCB cb)
Gets all messages contained within a SwarmMessageThread (specified by the threadId). |
void |
getMessages(SwarmMessageThread.GotMessagesCB cb)
Gets the messages contained in this SwarmMessageThread. |
static void |
getNumNewMessages(SwarmMessageThread.GotNumMessages cb)
Gets the number of threads that have not yet been viewed by the user. |
void |
markRead()
Marks the message thread as read (similar to marking an email in your inbox as read). |
void |
reply(java.lang.String message,
SwarmMessageThread.SentMessageCB cb)
Send a reply to a message thread. |
| Methods inherited from class java.lang.Object |
|---|
equals, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait |
| Field Detail |
|---|
public int id
public boolean viewed
public SwarmUser otherUser
public java.lang.String lastMessage
| Constructor Detail |
|---|
public SwarmMessageThread()
| Method Detail |
|---|
public void markRead()
public void reply(java.lang.String message, SwarmMessageThread.SentMessageCB cb)
message
- The string contents of the reply.cb
- The SentMessageCallback returns a SendMessageAPI result if the reply was successfully sent, returns in the sendFailed method.
The result contains a result.newThread boolean that is true if a new thread was created due to the reply, false otherwise.
The result contains a result.threadId identification number for the thread that the reply was sent to.public static void getNumNewMessages(SwarmMessageThread.GotNumMessages cb)
cb
- On success, the GotNumMessages callback returns the integer number of
threads that have not been viewed by the user, returns -1 on failure.public static void getAllThreads(SwarmMessageThread.GotThreadsCB cb)
cb
- On success, the GotThreadsCB returns a List of SwarmMessageThreads, returns null on failure.public void getMessages(SwarmMessageThread.GotMessagesCB cb)
cb
- The GotMessagesCB callback for this request.public static void getMessages(int threadId, SwarmMessageThread.GotMessagesCB cb)
threadId
- The threadId of the SwarmMessageThread for this request.cb
- The GotMessagesCB callback for this request.public static void getMessages(int threadId, int otherUserId, SwarmMessageThread.GotMessagesCB cb)
threadId
- The threadId of the SwarmMessageThread for this request.otherUserId
- The otherUserId of the user for this request.cb
- The GotMessagesCB callback for this request.
|
|||||||||
| PREV CLASS NEXT CLASS | FRAMES NO FRAMES | ||||||||
| SUMMARY: NESTED | FIELD | CONSTR | METHOD | DETAIL: FIELD | CONSTR | METHOD |


RT @kittylyst: Want to work with me? We're hiring a couple of DBAs (Postgres, MySQL, Redis) in our lovely Barcelona office. Hit me up if yo…
9/14/2019, 8:09:49 AM
Favs: 0
Retweets: 0
link--- layout: tweet ---
RT @kittylyst: Want to work with me? We're hiring a couple of DBAs (Postgres, MySQL, Redis) in our lovely Barcelona office. Hit me up if yo…
9/14/2019, 8:09:49 AM
Favs: 0
Retweets: 0
link