This PR closes #7

A note about the changes. As you noted in #7 the correct place to put the input is _gui_input as that respects the input propagation and resolves the issue when multiple elements are overlapping with one another.

The one use-case this may break is anyone that expects two overlapping EGUI controls to both accept input will end up with broken behaviors between these UIs. This may break some expectations.

In addition, it appears that _gui_input() doesn't require matching the mouse position offset from the screen, it seems to get the correct coordinates, so I removed that code. (it still needs to be mapped to egui::Vec2 though.

Please let me know if you have any questions.

This contains a large number of changes to help integrate themes into Egui as per #5 . Currently it appears to be working but is definitely not ready to be merged.

I wanted to submit this for feedback so that I can clean it up a bit more. Also, I think I still need to figure out how to switch which font is being used. That isn't in yet, oops.

Jumped forward to gdnative 0.10.0 thanks to @bromeon 's changes in #32 I also incorporated the necessary changes to work with egui-themes.

Probably still some more minor things to wrap up before we can do a 0.2.0 release, but any additional testing that folks can do would be greatly appreciated.

Note: At the time of opening this PR, the egui-theme and egui-stylist crates have not yet been published. I'm going to do that shortly.

@setzer22 I am creating an issue that we can use to track the idea of adding some theme support to GodotEgui as well as capture our dicussion from Discord in a more formalized way.

based on capability of using EGUI directly as a tool script, PR #4 I was thinking about how we should proceed to get some kind of unified theming support.

After spending some more time reviewing the egui styles module, I'm in agreement that it's probably best to not bother with Godot Theme support. It's probably far too much work to work on an abstraction layer.

As PR #4 indicates that we have the capability to run EGUI directly in the Godot Editor, I think there's very little reason we shouldn't just work on a theme editor using EGUI. In addition to the benefits of not having to do any theme translation between Godot types and egui types, we can also get an active preview of the theme.

From here, I think it would be useful to just determine some kind of serializable type that can be used to store the theme information such as json, ron, or a .tres (possibly supporting multiple) that contains the relevant EGUI Theme information. Being able to run this inside the editor would be a nice plus for the IDE experience :)

Based on the above There are a couple of points that I'd like to consider as well.

I have a few points I'd like to work on settling below.

1. Theme Serialization/Deserialization (go for a more Rusty or more Godoty method?
2. How do we want to proceed with creating the theme resource files?
3. How should this be integrated with the GodotEgui class?
4. Where should we develop the addon?
   1. Should the addon be included in this repository?
   2. Would it be worth splitting the theme editor off into it's own repository so that we can potentially support more targets than just Godot?
   3. If hosted in this repository should it be included in the main crate or a separate crate?

Thanks again for getting the EGUI ball rolling!

This should fix the issue with pixels per point not properly being set by the UI. This allows the individual control nodes to properly scale egui as needed.

Also made some minor changes to the function call of paint_shapes, since it is already using &mut self, rather than passing the texture into the method, the method queries for it directly.

Also added some additional widgets to the example to test the mouse position is correct regardless of the pixels_per_point setting.

Let me know if you have any questions about the changes.

This is the first steps towards resolving #14 I would like to give a chance for folks to give this a test for feedback before I finalize the PR. Any observations based on the color would be greatly appreciated. Also if there's a solution for the current blending issue, any advice would be welcome.

Doing

Self {
    egui_test: egui_demo_lib::ColorTest::default()
}

//...

Window::new("Color Test").scroll(true).show(ctx, |ui| {
    self.egui_test.ui(ui, &mut None);
});

Window::new("Settings").scroll(true).show(ctx, |ui| {
   ctx.settings_ui(ui);
});

shows a blank window. Clicking the (invisible) checkbox to turn off vertex gradients makes the content visible.

Possibly a related issue: settings menu turns blank if the following settings are selected: Painting > debug > Coarse culling off, Paint text bounds on, then expand multiple menus.

Hadn't seen that you had already done most of this work here when I started this... Not sending this PR to step on your toes, but since that branch is kinda old and has merge conflicts maybe this can help someone...

Description

I've just run rustup update and tried to build the example_project but receive an error on build.

Error

godot-egui/example_project on  main [!?] is 📦 v0.1.0 via 🦀 v1.56.1 on ☁️  (ap-southeast-2) 
❯ cargo build
   Compiling egui_demo_lib v0.15.0
   Compiling godot_egui v0.1.8 (/Users/rossmurray/dev/egui_test/godot-egui/godot_egui)
error[E0277]: the trait bound `Arc<Style>: From<egui::style::Style>` is not satisfied
   --> godot_egui/src/lib.rs:230:47
    |
230 | ...                   self.egui_ctx.set_style(style);
    |                                     ^^^^^^^^^ the trait `From<egui::style::Style>` is not implemented for `Arc<Style>`
    |
    = help: the following implementations were found:
              <Arc<B> as From<Cow<'a, B>>>
              <Arc<CStr> as From<&CStr>>
              <Arc<CStr> as From<CString>>
              <Arc<OsStr> as From<&OsStr>>
            and 9 others
    = note: required because of the requirements on the impl of `Into<Arc<Style>>` for `egui::style::Style`

error[E0308]: mismatched types
   --> godot_egui/src/lib.rs:231:57
    |
231 | ...                   self.egui_ctx.set_fonts(font_definitions);
    |                                               ^^^^^^^^^^^^^^^^ expected struct `FontDefinitions`, found struct `epaint::text::fonts::FontDefinitions`
    |
    = note: perhaps two different versions of crate `epaint` are being used?

Some errors have detailed explanations: E0277, E0308.
For more information about an error, try `rustc --explain E0277`.
error: could not compile `godot_egui` due to 2 previous errors
warning: build failed, waiting for other jobs to finish...
error: build failed

Context

godot-egui/example_project on  main [!?] is 📦 v0.1.0 via 🦀 v1.56.1 on ☁️  (ap-southeast-2) 
❯ rustup show
Default host: x86_64-apple-darwin
rustup home:  /Users/rossmurray/.rustup

installed toolchains
--------------------

stable-x86_64-apple-darwin (default)
nightly-x86_64-apple-darwin
1.54.0-x86_64-apple-darwin

installed targets for active toolchain
--------------------------------------

thumbv7em-none-eabihf
x86_64-apple-darwin

active toolchain
----------------

stable-x86_64-apple-darwin (default)
rustc 1.56.1 (59eed8a2a 2021-11-01)

godot-egui/example_project on  main [!?] is 📦 v0.1.0 via 🦀 v1.56.1 on ☁️  (ap-southeast-2) took 45s 
❯ rustc --version
rustc 1.56.1 (59eed8a2a 2021-11-01)

godot-egui/example_project on  main [!?] is 📦 v0.1.0 via 🦀 v1.56.1 on ☁️  (ap-southeast-2) 
❯ cargo --version
cargo 1.56.0 (4ed5d137b 2021-10-04)

Fix

I was able to get it built by bumping the versions of egui and egui_demo_lib in the Cargo.toml:

[dependencies]
gdnative = "0.9.3"
egui = "0.15.0"
egui_demo_lib = "0.15.0"
godot_egui = { path = "../godot_egui" }

I was then able to cargo build with only a few deprecation messages received, and the project loaded and ran fine within Godot from that point.

Added extension traits for Ui to allow for simpler integration with Godot Input/InputMap. The individual extension traits are split up into several extensions so that we don't clutter up the functionality and users can use only the portion of the extensions that they need.

This closes #23

After discussion, ensuring that continuous update is the default is more intuitive for getting started.

This only changes the default behavior and the general semantics. Continuous is now the default with Reactive mode being opt in.

The semantics makes it obvious that under normal circumstances godot-egui will update every frame like an immediate mode gui would be expected.

Egui only builds fonts at the start of the next frame, so if the theme is loaded on _ready, the font texture won't be updated until the first GodotEgui::update, which means that a GUI that draws their first frame after some time (e.g. when a menu is first shown) will cause a noticeable hiccup.

This would also cause issues if you want to add some extra fonts after loading a theme. After calling _ready on a GodotEgui object, trying to access egui.fonts().definitions() would return the old value, not the one set by the theme.

Triggering an empty update takes care of the problem with no noticeable side effects.

Currently there are no CI or Publishing actions. While this is tentatively "fixed", I think it would be worthwhile to investigate and work in a more full featured CI so that we can make sure we understand the health of the project.

I'm also less likely to miss something silly when merging PRs.