Stop tyranny of private visibility

[enomado]

This is a petition to make more egui internals public.

My product depends on egui and I'm kind of poweruser with special needs in context menues(#4162), layouts, table features (#3089)

I need some way to fork egui components like context menu or table to bikesred features I want. With current visibility levels I cant do it, instead I must fork the whole egui and its super inconvenient.

My questions and pull requests to make situation better are ignored for years.

Historically, there is a lot of private-public PRs

[MeGaGiGaGon]

As someone who is fairly new to Rust, and has helped on one PR for egui, here's my two cents:

For in favor of making more things public, I ran into an annoying private thing while helping on #3906. It would be possible to do arbitrary orderings of Areas, but Areas.order is private, and the corresponding methods for anything except move to top don't exist.

On the other hand, as I understand it making changes to private internals is a non-breaking change. The more of egui internals are public, the more breaking changes will happen.

This makes the main debate, as I understand it, is between making internals public for more user freedom, or keeping internals private for speed of development. I don't know which is more valuable to egui currently, though I would expect that the more stable egui gets, the more internals can be made public.

There is also an additional course of action to consider, which is adding more implementations to interface to that public api and do what you want. While I could write some bodge to order my Areas correctly if Areas.order was public, I'd much prefer having a proper api.

Full disclaimer, I am not emilk, so I don't know exactly what they want to see in a PR like the two you linked. However, I personally would like to see at least some analysis of the downsides of making certain things public. For example, how would making the things in your two PRs public limit the development of menu? To me it looks like menu is still very much in development, so making things public too early would hurt future improvements. I would also want to consider if there are workarounds, which for both of your PRs there seem to be. Are they pretty? No. But is it possible? Yes. Do the ergonomics gained by making these things public outweigh the development costs? I don't know. I would be interested to hear what your take is.

[enomado]

@MeGaGiGaGon first of all

On the other hand, as I understand it making changes to private internals is a non-breaking change. The more of egui internals are public, the more breaking changes will happen.

I absolutely disagree with that. There will always be public breaking changes. Its not project that garantee some sort of stable API.

You can try to build recent egui_dock with recent egui, and you will notice that many of functions are renamed, there is new DnD api, and nothing bad happen. 2 minutes to rename, 10 minutes to start using new api.

I mean, maybe, in 90s with legacy code, in scripting languages, in closed code systems when we rely on memory offset, this could be valid, yes.

The feature of immediate gui is high involvement in rendering process. I've always clicking on Component's render function to see the internals, to see what to tune. as I said - sometimes I just want to fork component and specify behavior, but I cant.

keeping internals private for speed of development

Same here. How keeping internals private affect speed of development? I mean do exists some burden of reliability? Its programming. There will be always changes, updates. for example half of ecosystem was just ruined last few weeks rust-lang/packed_simd#359 rust-lang/rust#122508 and nothing happen. You can always say - this api is subject to change, this is an internal api.

For example, how would making the things in your two PRs

Wait. As for me - I would prioritize public MenuBar, Strip, Table, so when I click "inline frunction" on Response::context_menu it would just work.

so making things public too early would hurt future improvements.

Same question - how? You still have high-level api with Response::context_menu, and in addition you have super-duper low-lever API for hackers with that cool MenuState::load() internals WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND

I would also want to consider if there are workarounds, which for both of your PRs there seem to be.

If you are talking about context_menu - please elaborate. Because my only workarong was in forking a context_menu function which is 20 cloc, and change visibility in my egui fork. There actually 5 possible APIs I see, but as we can see in last sentence of that issue - problem is gone if API was public.

So, after all, my take is: for all who want to use and contribute to egui - there is better to fork code by components, instead of whole repo. furthermore - contributing dont work sometimes. Because merging PR takes months, while it stays totally outdated.

I didn see/understand an arguments for private. You can assume, and I can say I disagree, lol, but you are not @emilk. May be its just a habit from years of industrial development, where everything do this because of some kind of status quo.

[enomado]

Well, #4193 #4200
Okay, should I do another PR, or fork, or what?

Actually I'm so tired of this situation so i'm considering to make self-upgradable repo-fork with auto code rewritting, but there are too many questions about rust-parsing-rewritting tooling, maintaining history, versions...

[emilk]

My questions and pull requests to make situation better are ignored for years.

I'm sorry about that - I just have very little time every week to work on egui, and most of that time goes towards reviewing PRs, and still I don't have enough time to review all of them. If you want PRs merged faster there are a few things you can do to help:

A) make fewer smaller PRs
B) remind me with a "bump" if I forgotten a PR for too long
C) help review all the open PRs so I can get through them faster

---

As for "make everything public" - that adds a burden on documentation and maintenance. The rule of thumb should be: a struct field should only be public if mutating it doesn't break any invariance.

I agree there are many parts of egui that should be made more public, and many "make this public please" PRs have been merged.

But I'm also in a situation right now where I made the mistake of making everything in Response public, and now I'm changing the internals of it, but retaining the public functions. Users that were using the public functions will be fine, but anyone using the naked field (e.g. response.hovered instead of response.hovered()) will have tons of breaking changes. This is another problem of public internals.

[felipetesc]

Egui is amazing. We are the ones who should thank you for all the time you spent developing this library and sharing it freely with us. You have already given a lot of your time. And it is important that we do not fail to recognize your effort.

[enomado]

@emilk for me, you are the person who made available writting gui apps in rust. https://github.com/rerun-io/opensource?tab=readme-ov-file I understand you impact to rust ecosystem. and I realized my PRs was not that good. Anyway.

I'm looking the way to live with vanilla egui without PRs, forking, disturbing you, waiting months for the major release, rebasing, discussions etc, etc. Lets say - "less opinionated egui".

Quick example I have: #4162

1. I can do what I want just in few lines of code if internals(MenuState, BarState) were public,
2. "the right way" to solve it - involve you to discussions of new API, which will break things anyway.

And also I was disappointed with this. I wanted hovering, but not selection. If we have selection, we cant click inside column. In my fork, I just rewrite col to make it do what I want.

My point is that I need that feature ASAP, and this feature is too minor to involve any devs to make decisions.

As for "make everything public" - that adds a burden on documentation and maintenance.

Well. What about - "If its not documented - use it on your own risk?" ?

will have tons of breaking changes

Cant say for all community, but for me its not the problem. I can assume that there are some examples in the internet which wouldnt compile and this could scare novice programmers. But I really appreciate that Response was plain clonable and destructurable object. IMO there always be breaking changes.

[emilk]

Well. What about - "If its not documented - use it on your own risk?" ?

I think a more idiomatic approach would be to use #[doc(hidden)] on these public fields. This means they won't show up at all on docs, but you can still access them if you are a power-user who feels comfortable juggling chainsaws. We can still add a /// Docstring to them for the benefit of users reading the code. How does that sound? I'd be on board of making more things public with a #[doc(hidden)] attribute. We should also add a section to the main crate-level docs explaining this policy.

And also I was #3347 (comment). I wanted hovering, but not selection. If we have selection, we cant click inside column. In my fork, I just rewrite col to make it do what I want.

Sounds like a nice feature to upstream (the ability to have a hover highlight without selectability).

[YgorSouza]

That is the standard practice, even in really big crates like proc-macro2:

https://github.com/dtolnay/proc-macro2/blob/48ae5806cfb51175952200138182488356ffe027/src/lib.rs#L1265-L1272

Note that this also hides the API from the rust-analyzer autocomplete, but I guess that's the point anyway. It's just kind of annoying when you actually want to use it.

[Mingun]

I think, that #[doc(hidden)] is a bad practice. If you have API for advanced users / unstable API, you should mark that in the documentation to that API instead of hiding it. #[doc(hidden)] is intended for the cases when you techically should have pub items that is not API (or internal API for your derive macros).

[dimvoly]

I'm running into similar issues to @enomado where I'll make some custom version of e.g. ui.vertical() but some of the internal calls are overly private. Then I'm stuck either forking the whole crate, or trying to re-create the privatized parts just to avoid forking.

Would another solution involve some visibility decorator macro based on crate attributes? Then when you import egui you could say for example:

egui = { version = "0.21.0", features = ["public_internals"] }

Then power users can just turn that flag on. Easier said than done of course.

[voidburn]

This has been a pain point for me as well. I can't debate the finer points of which parts of the APIs should be public, but as a rule of thumb, everything currently implemented in the containers and widgets paths within the Egui crate itself should be able to compile as externally implemented code, with Egui as dependency.

If anything, that would organically inform which of the lower level APIs are involved in making the existing set of components and containers possible, and open up the possibility for increasingly, and equally powerful, component libraries to be made without having to burden the Egui core development team with every little change via PR.

egui
|__src
   |__ containers
   |__ widgets

[felipetesc]

I don't know if everything should be public, but I loved the title ! (Sometime ago #799)