Comments (1)
Hi! Thanks for reporting.
I have tried multiple workarounds to get this fixed, but I haven't been able to find a way to fix this without changing egui
. The two issues you're reporting come from the same place. Egui doesn't give us enough options to control the rendering order of things. Right now, the order in which things are drawn is controlled by their LayerId
:
- First, layer ids are sorted by the very coarse-grained
Order
field which is user-editable, but not useful, since it's an enum with 5 hard-coded values. - Then, some
LayerId
s are sorted by their relative positions inside the thectx.memory().areas.order
list. This list is only used forArea
s and is inaccessible to end users behind several private orpub(crate)
fields. Even if it were, the list is only meant to be used forArea
s and would cause trouble if used for other purposes (such as making sure nodes are drawn in the right way).
Due to this limitation (layer ordering being inaccessible), when I wrote this library I wrote a parallel mechanism in node_order
to make sure nodes always get processed in the same order. The problem there is that egui
is immediate mode, so if make the calls to draw nodes bottom-to-top, things will get rendered in the right order, but mouse interaction will be wrong, because nodes on bottom will steal focus.
In my opinion, the right solution here would be to modify egui so that this layer sorting mechanism is better exposed to end users, and detached from areas when possible. I think I have a clear enough picture of the code that I could make a PR for that, but I'm not sure if it would be welcome upstream. With this, we'd be able to define a draw order that is different of the order in which the calls to draw nodes is made.
Another solution would be to use Area
s for the nodes. The problem with that is that the Area
mechanism (which is the base for egui::Window
) does not allow things like accessing area positions or programatically moving the areas. We also don't want the nodes to actually behave like areas (in the sense that a node should never be on top of a floating window, or be able to escape its window, in case you're drawing the node editor inside a window). There's not even support for moving an area to the top. So going that way would require even more changes in egui and I don't think it's a good direction to focus on.
Long story short, solving this issue in the right way needs changes inside egui
, which means it will take a while. I'm going to report this upstream and propose a fix and post here when that happens 🙂.
I would like to suggest a workaround in the meantime, or build some hacky solution on my end that I could ship right now on my end, but I can't find any way to do this that doesn't require messing with egui internals.
PS: By the way, @edeetee this application looks really cool! Is this some sort of shader graph editor? I'd love to see more about it 😄
from egui_node_graph.
Related Issues (20)
- Add topological iterator to Graph class HOT 1
- Easy way to create pre-existing graph state? HOT 1
- Performance concerns HOT 1
- give example the ability to zoom in/out and scroll side to side HOT 1
- missing input on Connection Only and then Connection/Constant node
- Handling disconnection events on node deletion is a bit cumbersome
- Persistence HOT 1
- Suggestion: Read-only mode
- Please add minimalistic example using bevy_egui HOT 11
- Buttons drawn on (after) the graph doesn't working. HOT 4
- The example doesn't work with version 0.3.0 HOT 3
- Would be nice with an example using Bevy and bevy-egui together with this project HOT 1
- Right click output - create node and connect HOT 1
- Hide close button of node widget HOT 3
- New crates.io release HOT 1
- Cant Compile to web HOT 1
- Remove Widget on input connection HOT 1
- Cannot use because Color32 is not in epaint::color::Color32 HOT 4
- Feature request - allow labeling of edges HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from egui_node_graph.