gtk-rs / gtk3-rs

Rust bindings for GTK 3

gtk3-rs

This project is UNMAINTAINED. Please take a look at gtk4-rs instead!

The gtk-rs organization aims to provide safe Rust binding over GObject-based libraries. You can find more about it on https://gtk-rs.org.

This repository contains all the "core" crates of the gtk-rs organization. For more information about each crate, please refer to their README.md file in their directory.

Minimum supported Rust version

Currently, the minimum supported Rust version is 1.70.0.

Documentation

• Examples
• The Rust API Stable / Development

Ecosystem

The gtk3-rs repository contains Rust crates for GTK 3. However there is a large ecosystem of GObject libraries and many of these libraries have Rust bindings based on the tooling included in gtk-rs. Of particular note:

• gtk-rs-core - bindings for some of the core libraries such as glib, gio, pango, graphene
• gstreamer-rs - bindings for the GStreamer media framework

Additionally, Rust bindings for various libraries are hosted on GNOME's GitLab instance and can be found at https://gitlab.gnome.org/World/Rust.

When using crates that are not part of the gtk-rs repository, you will need to be careful and ensure that they do not pull in incompatible versions of core crates like glib-rs.

Regenerating

To regenerate crates using gir, please use the generator.py file as follows:

$ python3 generator.py

If you didn't do so yet, please check out all the submodules before via

$ git submodule update --checkout

Development

This repository is mostly split into two branches: master and crate. master contains the not yet released code and is where new developments are happening. crate contains the last release source code and isn't supposed to be updated.

This repository is structured as follows:

- crate/
   |
   |-- README.md
   |-- Gir.toml
   |-- Cargo.toml
   |-- src/
   |-- sys/

The crate is a "top" directory (so "atk" or "gdk" in here for example). Each crate contains:

• README.md: explanations about the crate itself and eventually some details.
• Cargo.toml: descriptor of the crate, used by cargo and Rust.
• Gir.toml: configuration used by gir to generate most of the crates' code.
• src: the source code of the crate.
• sys: the 1:1 bindings of the C API.

The gir and gir-files top folders are not crates, but are git submodules which respectively contain the gir tool and the gir files used by the generator.

When running generator.py the tool will automatically update these git submodules and run the gir tool on the gir files to regenerate the code.

During development, it is useful to execute the generator with a different version of the gir tool or of the gir files, for instance to test if the code generation is successful before submitting a pull request to update one of the submodules. This can be done by specifying arguments to the generator script, for instance, to run the generator on a local copy of the gir files:

$ python3 generator.py --gir-files-directory ../gir-files/

See python3 generator.py --help for more details.

gtk3-rs's Issues

Atk usage examples

Hi,
I'm new to gtk-rs, I have installed everything necessary and made an test window with a button following the example on project's website.
It seems to work as expected when controlled by mouse, however the window is completely inaccessible for screenreaders.
I'm blind myself, so this is very important library's aspect to me.
I have found atk, made sure that it's installed by explicitly specifying it as a dependency, but I'm not sure, what to do next.

Are there any usage examples?

I'm using Windows 10 pro 1809 64-bit, Rust 1.39, tested with Jaws and Nvda screenreaders.

Thanks!

Feature embed-lgpl-docs don't add docs for auto/radio_menu_item.rs

cargo test --features embed-lgpl-docs don't change auto/radio_menu_item.rs IMHO because no entries in
lgpl-docs. Than strange as this file was added 5 month ago.

Other affected (but this is normal as it newly added): i_m_context.rs, i_m_multicontext.rs, icon_factory.rs, icon_info.rs, icon_set.rs, icon_source.rs, icon_theme.rs, model_button.rs, print_context.rs, selection_data.rs, shortcuts_window.rs, style_properties.rs, symbolic_color.rs, target_list.rs, text_attributes.rs.

Clarify bug reporting process

I've been a little confused about where to file bugs, sometimes which gtk-rs repo to use and also when to file bugs upstream instead of in this repo. I want to make sure I'm being a good citizen and filing bugs ina helpful matter and not just causing triage noise for this project. Therefore I think it'd be helpful if there was an official comment addressing these two things in the README for gtk. Something akin to:

Filing Bugs

Filing bugs upstream if possible (GNOME Bugzilla) is ideal if you believe the bug is specifically within the C libraries of GTK.

Otherwise if you believe the bug is within the Rust bindings, please file it in the appropriate repo within the gtk-rs family (glib, gio, gtk, etc.). If you are uncertain which repository to file the bug under, please file it under gtk.

Support builder context reuse

It would be useful if a builder context could be reused for creating multiple instances of a widget with similar properties, either by cloning a context, or allowing it to be reused.

let mut label_ctx = gtk::LabelBuilder::new()
    .use_markup(true)
    .xalign(0.0)
    .parent(layout.upcast_ref::<gtk::Container>());

let listbox_ctx = gtk::ListBoxBuilder::new()
    .parent(layout.upcast_ref::<gtk::Container>());

label_ctx.label("<b>System Firmware</b>").build();

let system_firmware = listbox_ctx.clone()
    .margin_bottom(12)
    .build()
    .upcast::<gtk::Container>();

label_ctx.label("<b>Device Firmware</b>").build();

let device_firmware = listbox_content.build().upcast::<gtk::Container>();

This is what the above looks like today:

gtk::LabelBuilder::new()
    .use_markup(true)
    .xalign(0.0)
    .label("<b>System Firmware</b>")
    .parent(layout.upcast_ref::<gtk::Container>())
    .build();

let system_firmware = gtk::ListBoxBuilder::new()
    .margin_bottom(12)
    .parent(layout.upcast_ref::<gtk::Container>())
    .build()
    .upcast::<gtk::Container>();

gtk::LabelBuilder::new()
    .label("<b>Device Firmware</b>")
    .use_markup(true)
    .xalign(0.0)
    .parent(layout.upcast_ref::<gtk::Container>())
    .build();

let device_firmware = gtk::ListBoxBuilder::new()
    .parent(layout.upcast_ref::<gtk::Container>())
    .build()
    .upcast::<gtk::Container>();

Building with `embed-lgpl-docs` deletes all generated docs

Repro

1. Make a new crate with cargo new foo
2. Add dependency on gtk with the embed-lgpl-docs feature enabled:

[dependencies.gtk]
version = "0.7.0"
features = ["embed-lgpl-docs"]

3. Generate rustdoc by running cargo doc
4. Open target/doc/foo/index.html in your browser

Expected outcome

All dependencies are listed in the sidebar and search, including dependencies of gtk.

Actual outcome

Crates built before gtk are omitted from the sidebar and search results, but still exist if you navigate to them manually. The exact set of missing crates varies since Cargo doesn't use a deterministic build order, but dependencies of gtk (such as atk) will always be missing, while dependees (such as our foo) will always be listed.

Workaround

Run cargo doc with embed-lgpl-docs enabled once, then disable it, and cargo clean && cargo doc. The enriched docs will stay since embed-lgpl-docs rewrites the source code cache in-place.

Document how to do an image that is redrawn/updated

Hi,
I've just managed to get something to work, but something that telling me how to do it properly would have been better!
I've got a fractal renderer that renders into a buffer (with OpenCL), and I want to be able to do a callback that causes it to be re-rendered. I'm using a Gtk::Image to display the image. In the end I ended up using a Cairo ImageSurface and using get_data() to get the buffer to pass into the ocl buffer read() method; What took me longer to figure out was that since get_data() fails with non-exclusive as soon as the ImageSurface is associated with the Image, my redraw code has to do set_from_surface(None) before the get_data() and then set_from_surface again with the real value.
That's something that coming from C is non-obvious and I don't think there's any current doc explaining how to do it.

GtkWindowExt::set_default_geometry documentation incorrect

"This function does nothing." Wrong. I used this function to set the sizes for the main window of my application. When I upgraded to the latest version of the gtk crate and was informed by the compiler that this function was deprecated, I checked the documentation and saw the quoted sentence. So I removed the call, recompiled and re-ran my application. The main window was now the size of a postage stamp. I did follow your suggestion to use set_default_size instead, which restored the proper dimensions of the window in question, but assertion that set_default_geometry does nothing is simply false and should be removed from the documentation.

GridExt::attach / ContainerExt::add should return &Self

This would enable builder API capabilities in these commonly-used methods, such that the following incantations would be valid:

let layout = gtk::ScrolledWindowBuilder::new().build();
layout.add(
        // Expression returns a &gtk::Box
        gtk::BoxBuilder::new()
            .orientation(gtk::Orientation::Vertical)
            .border_width(12)
            .build()
            .add(&widget1)
            .add(&widget2)
            .add(
                // Expression returns a &gtk::Grid
                gtk::GridBuilder::new()
                    .border_width(12)
                    .column_spacing(12)
                    .build()
                    .attach(&widget1, 0, 0, 1, 1)
                    .attach(&widget2, 0, 1, 1, 1)
                    .attach(&widget3, 1, 0, 1, 2)
            )
    );

In fact, all methods could return &self if they currently do not return any value. Enabling an already-constructed widget to change its values using a builder pattern.

gtk_style_context_get_property not generated

This might not be generated because it's similar to g_object_get_property? Despite the naming it does not have the same functionality. Rather, it gets the style property of the Widget. Without it widgets like Granite's avatar widget can't be implemented in Rust.

Replace `TimeVal` with a Rust-y equivalent once more of std::time is stable

Support GtkBindings

I tried adding these to Gir.toml, but I get a panic with "Missing memory management functions for {}" with {} being BindingArg, BindingEntry, BindingSet, and BindingSignal. Is resolving that memory management stuff under active development or what is the current state of it?

Export macros in a Rust 2018 friendly way

Before macros were imported with the [macro_use] attribute above the extern crate declaration. With rust 2018 though, this is no longer needed and macros can be imported with just use. Currently you would need to import weird paths to do so, and the codebase is not does not handle the new module system well.

Not sure how other crates handle this, or if exporting them in the prelude it will be enough, but ideally it would be something simple to do so.

ex. use glib::prelude::glib_object_subclass

implement IO Channels

https://developer.gnome.org/glib/stable/glib-IO-Channels.html

currently only available via manually utilizing glib_sys

Widget Documentation

Two parts here, in order of perceived importance

1. In the documentation for each widget, an example picture would do wonders (particularly for GTK novice's like myself). I am not 100% sure what the best strategy for storing all of these pictures would be, but I'd be happy to follow up on this one and add a bunch of example pictures once the storage location was decided.

2. Restructuring the widgets to be reexported from a widgets module might be useful to separate all the widgets from weird structs like LEVEL_BAR_OFFSET_HIGH, PRINT_SETTINGS_*, etc.

gtk-rs on Windows with MSVC should be possible with zero attrition

note: I'm not sure if the best place is here or at sys repository, but as any user looking for gtk-rs on windows will tend to land here, I'm opening this issue here.

This is more of a distribution problem, but may be extremely beneficial for Rust GUI situation.

As it stands, gtk-rs is buildable on Windows using MSVC toolchain, but this does not mean it is usable without additional steps, as an application trying to link with GTK will still need all the GTK libraries previously downloaded (or worse, separately built) and well configured.

The ideal would have to be any application using gtk-rs and being compiled on windows using the MSVC toolchain, to have these libraries (downloaded or compiled) and configuration done by cargo itself (via plugin or build.rs in *-sys crates).

One way to achieve this, would be by abusing or mimicking the "cc" and "cmake" crates. This could be best achieved by using vcpkg-rs. Although vcpkg itself has some issues[1] with GTK port, it builds flawlessly and this can be used as a mean of distribution for dependencies when using MSVC toolchain.

Further improvement can be collaborated with vcpkg-rs

[1] The first issue is that vcpkg GTK port outputs "gtk-3.0.lib" and "gdk-3.0.lib" while gtk-rs expects "gtk-3.lib" and "gtk-3.lib". The second issue is that gtk-rs expects some debug features to be enabled on the libraries, for this I've opened this issue/PR there.

GtkContainer Subclassing: Figure Out Bindings For Virtual Methods

The methods we need to figure out how to bind:

• set_child_property
• get_child_property

Add bindings to save* functions

Currently this crate doesn't cover the various gdk_pixbuf_save* functions. It would be nice if it did.

The function Pixbuf::new_from_vec

Trying to use that function, I had a really hard time using and understanding it. What are the meaning of the arguments ? There is no documentation.

colorspace

What is it ? For new it is Color space for image. I interpreted it as being the number of colour (red, green, blue) but this is supposed to be n_channels. So I don't have a clue what it truly is.

I found this on the gdk documentation website :

The colorspace in which the samples are interpreted.
Flags: Read / Write / Construct Only
Default value: GDK_COLORSPACE_RGB

If I understand its value have to be GDK_COLORSPACE_RGB, is it useful to have this as argument ? If it is useful, why not create a Colorspace enum ?

bits_per_sample

Since there is this line in the code :

assert!(bits_per_sample == 8);

There is only one correct value for bits_per_sample. Why not remove it from the argument of the list ?

row_stride

I had to go on the gdk documentation to understand what this argument is :

Distance in bytes between row starts

Should be in the doc !

Conclusion

I'd agree to contribute but I don't know how the documentation of this crate is generated. Does regular doc comments works ?

Add LabelExt trait implementation information for Label

The LabelExt trait is currently missing from the list of implementated traits for Label in the generated documentation at http://gtk-rs.org/docs/gtk/struct.Label.html#implements

Gir submodules alternative

There is a significant drawback to having 'gir' and 'gir-files' submodules in each repo: wasted space and build time when working with several repos at once. It is desirable to find another solution which would retain ease of use (edit Gir.toml, make gir) and similar control over 'gir' and 'gir-files' revisions used to regenerate code.

Documentation: links are broken for implementors of traits in gtk::prelude

When you go to any trait in gtk::prelude (e.g. ButtonExt) and then click on one of the implementors (e.g. Button) you get a 404 error.

Can't find libpng .lib with vcpkg install of libpng

vcpkg creates a package with the file "libpng16.lib", this crate (or a dependency) searches for "png.lib" instead.

Add Selections constants

Pertains to GDK_SELECTION_*, GDK_TARGET_*, and GDK_SELECTION_TYPE_* reference.

I think these should go in src/selections.rs, and I'd implement them manually, but unlike other constants already exposed by gdk, these do not already exist in gdk_ffi. What's the proper procedure here then? Should these somehow be exposed in gdk_sys first and then re-exported with better names here?

This was broken out of gtk-rs/gdk#148.

Improve null pointer handling

Many parts of this crate's API as well as some of the related ones return Option to handle when a pointer returned from an FFI call is null. Unless the C API documentation says why a returned pointer might be null, it is probably safe to assume that a null pointer means something bad happened and the program shouldn't continue (e.g. allocation failure/OOM). Overuse of Option for little good reason when they would usually prefer to unwrap it anyways pollutes client code and reduces ergonomics.

Want Error::steal() -> *mut GError, or a general way to steal() boxed types

The specific situation is this: I have a glib::Error, and I want to transfer-full it up to C code as a *mut glib_sys::GError. There is no easy way to do it.

@sdroege's way is this:

#[no_mangle]
pub fn something_called_from_c(error: *mut *mut GError) -> gboolean {
    match something_that_returns_glib_error() {
        Ok(()) => true.to_glib(),

        Err(e) => {
            if !error.is_null() {
                *error = e.to_glib_none_mut().0;
                mem::forget(e);
            }

            false.to_glib()
        }
}

I had a hackier way of doing it, with a cast, but this involves a g_error_copy() internally:

if !error.is_null() {
    *error = e.to_glib_full() as *mut _; // cast the *const GError to *mut GError

So, in general: a way to take a Boxed<T> and have a fn steal(self) -> *mut T. This would be really useful for returning GError up to C, and probably useful for boxed types in general. Should this be called steal_ptr or steal_glib_ptr instead?

threads_add_idle asserts it is running on the main thread

I assume it is like this because the auto-generating of the bindings. But I think this function is safe to call when not on the main thread.

Documentation for ScrolledWindow::new misleading

"Usually you want to pass None for the adjustments, which will cause the scrolled window to create them for you."

Pass 'None' for the adjustments leads to

error[E0283]: type annotations required: cannot resolve _: gtk::IsA<gtk::Adjustment>
--> src/main.rs:159:42
|
159 | let scrolled_window:ScrolledWindow = ScrolledWindow::new(None, None);
| ^^^^^^^^^^^^^^^^^^^
|
= note: required by gtk::ScrolledWindow::new

You have gtk::NONE_ADJUSTMENT defined. Why not mention that in the documentation instead of 'None' and avoid leading users down this incorrect path?

Manual implementation of enumerate_*

Gio::File lacks enumerate_* that needs some manual bindings I guess. It would be nice to have them back

• enumerate_children (attributes, flags, cancellable)
• enumerate_children_async (attributes, flags, io_priority, cancellable, callback, *user_data)
• enumerate_children_finish (res)

Calling class functions not supported

It seems it's impossible to call class functions like gtk_widget_class_set_name() or gtk_container_class_install_child_properties() in gtk-rs currently.

CI Inverse diff problem

Currently we use git diff -R --exit-code to check that crate don't contains LGPL docs and that regeneration done right way.
It often cause misunderstanding. Ex. in https://travis-ci.org/gtk-rs/gtk/jobs/478784167#L751-L773 it shows that LGPL docs was accidentally added to code,
but even my first reaction was that docs purge not works :(
There was same misunderstanding for regen check in past.

Maybe we need remove -R options?

Inconsistent column number types

The type of the column indices for some procedures, such as gtk::prelude::TreeStoreExtManual::set, are u32, whereas in other case, such as gtk::TreeModelExt::get_value, the column index type is i32. This is inconsistent and results in unnecessary casting when the column indices for stores/models are defined as consts.

add event_handler_set wrapper

it's not obvious to me how to use the gdk_sys version, so i'd like a higher level wrapper.

Generate pango::Analysis as well

Support defining style class(es) in builder constructors

The versions listed in the docs are out of date

On this page http://gtk-rs.org/docs/ some feature versions are listed but most of them are invalid now.
Would also be nice to change version = "0.1.0" to the latest version.

Cursor manipulations don't seem to be possible

Two issues, but they seem to be related. Let me know if you want them split.

First, Cursor::Type doesn't seem to be properly exposed. If I try t compile this:

extern crate gdk;
use gdk::prelude::*;
use gdk;

fn main () {
    println!("{:?}", gdk::Cursor::Type::Watch);
}

I get this error:

Compiling order_chaos v0.1.0 (file:///export/mwm/src/chiselapp/order_chaos)
gtk.rs:212:59: 212:83 error: no associated item named Watch found for type gdk_sys::GdkCursorType in the current scope
gtk.rs:212 gdk::cursor::Type::Watch)));

It works if I use the gdk-sys crate and gdk_sys::GdkCursorType::Watch, which I believe should be the same thing.

Second, the type for the various gdk set_cursor routines seems to b e wrong. Quoting the docs:

fn set_cursor(&self, cursor: &Cursor)[−]

Sets the default mouse pointer for a Window.

Note that cursor must be for the same display as self.

Use Cursor::new_for_display or Cursor::new_from_pixbuf to create the cursor. To make the cursor invisible, use CursorType::BlankCursor. Passing None for the cursor argument to Window::set_cursor means that self will use the cursor of its parent window. Most windows should use this default.

Ok, how exactly am I supposed to pass None for the cursor argument to put things back, as that isn't an Option argument. Or is there some other None I should be using?

This is my first program using either Rust or gdk, so apologies in the likely event that I've overlooked something obvious.

Supported Rust version?

The documentation doesn't seem to reflect the minimum Rust version requirements. Or am I missing something?

Support for non-owned backend buffers

For a wayland use-case, a classic way to draw a window without using OpenGL/Vulkan is to do software rendering using Cairo.

To do so, the process is:

• create a shared memory pool with the compositor
• allocate a buffer in this memory pool
• create a cairo surface using this buffer
• draw

Translated to Rust, it means creating an ImageSurface from a &mut [u8], which does not look to be possible at the moment, while being a common pattern in C programs.

thread 'main' panicked at 'assertion failed: ::glib::types::instance_of::<Widget>(stash.0 as *const _)'

Hello,

I needed global key bindings, so I used the C keybinder lib: https://github.com/engla/keybinder
The binding seems to be working fine, but when I try to call is_visible on a window for example, I get an assertion failed for the glib type

    keybinder::bind("<Ctrl>A", move || {
        println!("Works!");
        println!("Visible = {}", window.is_visible());
    });

output:

Works!
thread 'main' panicked at 'assertion failed: ::glib::types::instance_of::<Widget>(stash.0 as *const _)', /home/bram/.cargo/registry/src/github.com-1ecc6299db9ec823/gtk-0.1.0/src/auto/window.rs:28

To be honest, I have no idea what could be causing this.
Does anyone have an idea?

Sorry for my ignorance

Missing functions

• Save to file
  • For the start, just having gdk_pixbuf_save() without save parameters would be nice, and probably sufficient for many applications.
  • Unassigned
• Pixbuf::fill()
  • one i32 or u32 parameter, or four rgba parameters?
  • Unassigned

Cannot modify gdk::EventKey or gdk_sys::GdkEventKey fields

Trying to synthesize Events, generating with gdk::Event::new(gdk::EventType::KeyPress) and downcasting to gdk::EventKey. There are few setter functions, so it is not easy to modify any of the fields. gdk::EventKey::as_ref() returns an immutable reference (to gdk_sys::GdkEventKey), and again there are no setter functions for most of the struct members. In particular, for: window, send_event, time, state, keyval. There should be set_window(), etc., for gdk::EventKey, and/or for gdk_sys::GdkEventKey, and/or a gdk::EventKey::as_mut_ref().

Related to the above: the underlying G-object object of the value passed to set_window() needs to have its reference count incremented. I'm assuming this should/would happen as part of the set_window() functionality, unless there is already a separate library call for this.

gdk wayland interaction

Is it possible to use the functions from gdkwayland.h?
Specifically i would like to use gdk_wayland_window_get_wl_surface() and gdk_wayland_window_set_use_custom_surface().

Display::get_event() commented in the code

The get_event, peek_event and put_event are commented in the source code of display.rs, I need it for an application is posible to uncomment this code? works correctly?

Add methods to read out axis values on device

There is currently no way to read out the axis values on a device.
auto/device.rs has a method stub for fn get_axis(&self, axes: &[f64], use_: AxisUse) -> Option<f64>, which it is commented out and the field GdkDevice.axes is not accessible.

gtk::ImageBuilder::icon_size() should take a gtk::IconSize instead of i32

GLContext integration

There currently is no reliable way to use the glium/gl crates together with GLContext (and gtk::GLArea), which a very limited API. Previous discussion is at gtk-rs/examples#44, let's continue it here.

Pass features to `docs.rs` doc generation

It's apparently possible to pass features when docs.rs is building crates:

[package.metadata.docs.rs]
features = ["serde-1", "quickcheck"]

Talk about a hidden feature...

IMContextSimple::add_table

For now, we have some issues understanding how the function is working.

How to access the Pixbuf data without unsafe?

The Pixbuf::get_pixels method is marked as unsafe and PixbufExt::read_pixel_bytes is >=2.32 (and I have 2.30).

How can I access the Pixbuf data in read-only mode?

GtkWidget Subclassing: virtual methods

This issue is to provide a list of vfuncs of GtkWidget, to be crossed of as they are implemented.
The first batch is covered in gtk-rs/gtk#861.

• adjust_baseline_allocation
• adjust_baseline_request
• adjust_size_allocation
• adjust_size_request
• button_press_event
• button_release_event
• can_activate_accel (Needs work on signals API)
• child_notify
• composited_changed
• compute_expand
• configure_event
• damage_event
• delete_event (Needs bindings for GdkEventAny)
• destroy
• destroy_event
• direction_changed
• dispatch_child_properties_changed
• drag_begin
• drag_data_delete
• drag_data_get
• drag_data_received
• drag_drop
• drag_end
• drag_failed
• drag_leave
• drag_motion
• draw
• enter_notify_event
• event
• focus
• focus_in_event
• focus_out_event
• get_accessible
• get_preferred_height
• get_preferred_height_and_baseline_for_width
• get_preferred_height_for_width
• get_preferred_width
• get_preferred_width_for_height
• get_request_mode
• grab_broken_event
• grab_focus
• grab_notify
• hide
• hierarchy_changed
• key_press_event
• key_release_event
• keynav_failed
• leave_notify_event
• map
• map_event
• mnemonic_activate
• motion_notify_event
• move_focus
• parent_set
• popup_menu
• property_notify_event
• proximity_in_event
• proximity_out_event
• query_tooltip
• queue_draw_region
• realize
• screen_changed
• scroll_event
• selection_clear_event
• selection_get
• selection_notify_event
• selection_received
• selection_request_event
• show
• show_all
• show_help
• size_allocate
• state_changed
• state_flags_changed
• style_set
• style_updated
• touch_event
• unmap
• unmap_event
• unrealize
• visibility_notify_event
• window_state_event