emilk / emilk/egui

Window implementation outside of egui

Open
#4,240 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Rust
Stars
30.6k
Forks
2.1k
Avg merge
1d 9h
Merged PRs (30d)
72

Description

Is your feature request related to a problem? Please describe.

I am currently writing an App which requires window management. The default egui::Window gets me to like 70% of where i want to be, but i need more features (buttons, different title bar etc.)

I thought yanking the current implementation would be a viable approach but that doesn't really work well. It seems to me that in cases like this i either need to write some mini framework on top of egui which is kind of inflexible and inefficient or fork the project.

Describe the solution you'd like

Moving the window to egui_extras or making required methods/fields public. The fields seem useful on their own. Would it be doable to implement, for instance, getters for most internal variables of say Area, WidgetText etc.?

Describe alternatives you've considered

Writing my completely own window implementation using egui and occasionally dropping down to epaint or forking egui.

Additional context

Egui is extremely powerful, but at some points there are certain barriers which make it hard to get additional functionality into existing widgets.
I love working with egui and would love to make these "low level" needs more accessible

Have a nice day ::)

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reviewing the existing egui::Window implementation and the public APIs of Area and WidgetText, then compare what can move to egui_extras without relying on internals. The issue needs a defined scope for extraction or public getters; done means that scope is agreed and the resulting API supports custom window functionality without a fork.

Written by the indexing model from the issue text.

Assessment

Tech stack
rust
Domain
frontend
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.