Graphite VS egui

A tool which looks at this sort of thing which was mentioned here recently:

https://news.ycombinator.com/item?id=44118159

but which didn't seem to get much traction is:

https://pontus.granstrom.me/scrappy/

but it pretty much only works for JavaScript programmers and their friends (or folks interested in learning JavaScript).

Other tools which I'd like to put forward as meriting discussion in this context include:

- LyX --- making new layout files allows a user to create a customized tool for pretty much any sort of document they might wish to work on --- a front-end for LaTeX

- pyspread --- every cell being either a Python program or the output of a program, and the possibility of cells being an image allows one to do pretty much anything without the overhead of making or reading a file

- Ipe https://ipe.otfried.org/ --- an extensible drawing program, this really needs a simpler mechanism for that and I'd love to see a tool in the vector drawing space which addressed that --- perhaps the nascent https://graphite.rs/ ?

https://graphite.rs/ (still early in development) offers node-based editing.

2D Content Creation Tool (Open Source Photoshop?)

I was referring to the link posted to HN: https://graphite.rs/

I love Inkscape so much. I use it every other week to make presentations, slides or just simple graphics when I need it. I illustrated my thesis with it.

Another piece of 2D vector software that I use and recommend is Graphite [1]. It too is open source. Graphite has nodes and can be procedural in nature. Have them both in your graphics toolbox.

[1] https://github.com/GraphiteEditor/Graphite

There is also Graphite (https://graphite.rs/) which, unlike Gimp, has a modern architecture and very ambitious goals (Blender for 2D basically).

If you're interested in either computational geometry, layout/packing/constraints, or functional programming language concepts, those are all the math-related concepts that we're currently interacting with for Graphite, a 2D vector graphics editor that's aiming to become the next Blender (but for 2D instead of 3D). If that sounds interesting, I'd love to help get you started if you want to join our Discord and I can explain the math-related work that we need to get done. Cheers!

I use Egui, in a game-type application.

I'm a bit concerned with Egui gaining in popularity for general purpose GUI applications. It's leading to feature bloat, and probably more overhead. The stated goal originally was that Egui should use less than 1% of main thread frame time.

Originally, Egui was completely one pass. The API looks more general than that; you can align things against the bottom or right, and get things above or to the left to adjust. But originally, that didn't work. You pretty much had to lay out widgets down and to the right. This is fast and simple. Lots of stuff didn't work, such as scrolling text boxes with line wrap.

But users doing ordinary GUI work are demanding more and more layout features, and won't stop until they get browser level layout. Overhead is increasing.[1] This is a problem in Rust game land, which is tiny. At some point, someone may need to fork Egui and create Egui-lite.

[1] https://github.com/emilk/egui/issues/7059

That's very kind -- let's hope the legal profession feels the same way. It's certainly inspired by VS code. It's using egui (https://github.com/emilk/egui) under the hood. Big hats off to Emil Ernerfeldt and the team at rerun (https://app.rerun.io/) for the incredible work on a great immediate mode GUI library.

Thank you for linking your project—that looks really cool! I saw you also implemented a pan-and-zoom area. We are currently working on moving Rerun's implementation to egui [0], so maybe keep an eye on that.

It would be super cool to have layered graph drawing in (Sugiyama-style) in Rerun too. The tricky–but super interesting–challenge that we face is that our layout implementations need to be consistent across timestamps if the underlying structure of the graph changes, which is why we initially chose a force-based layout approach. There, the time-varying aspect is handled naturally by the simulation.

The very interactive nature of Rerun also poses more restrictions on the implementation of our algorithms: re-layouts ideally need to be fast, to produce visualizations quickly, especially when scrubbing the timeline.

I still hope we can rid you of some of the todos ;).

[0](https://github.com/emilk/egui/pull/5505)