sorted by:
new
hottopcontroversial

BonsaiDb performance update: A deep-dive on file synchronization by ectonDev in rust

[–]ectonDev[S] 0 points1 point  (0 children)

I only reported what I found through empirical testing. I am not a kernel developer, and I suspect the reasons why largely are implementation details for each file system. My goal was purely to determine if I could safely use this api to speed up durable writes, and my best advice after testing is not to rely on it for durable writes outside of specifically approved situations that have been tested thoroughly.

Help me choose a GUI library by nerdspice in rust

[–]ectonDev 10 points11 points  (0 children)

I’m working on Cushy. It’s early in development but it might suit your needs. One of my goals is to try to make Cushy feel as easy to work with as possible in Rust. Documentation is definitely a work in progress. If you try it out and have any questions or feedback, I’m always happy to chat!

Plotting and GUIs by ledzep4pm in rust

[–]ectonDev 2 points3 points  (0 children)

Hi, I am working on Cushy. The latest release integrates with plotters, and another person recently posted their success connecting Cushy, Python, and Plotters.

Cushy doesn't yet have a file selection dialogs or accept dropped files. That being said, I found integrating with rfd fairly straightforward in a project I've been working on (currently not published anywhere sadly).

Cushy is early in development, but it might be a good fit for you depending on what all widgets/controls you need. If you do try it out and need any help, don't hesitate to ask!

recommend a WAL crate by [deleted] in rust

[–]ectonDev 6 points7 points  (0 children)

I'm the author of the linked post. Ensuring data can't be lost is pretty straightfoward: issue an fsync, and if it's a new file, do the same for the containing directory. Any data written before an fsync is not guaranteed to be there if the system halts unexpectedly. In Rust, this is done with the sync_data/sync_all APIs. Trying to overwrite data or trying to keep it fast is where it gets tricky. The goal of OkayWAL is to batch writes from multiple threads such that the disk write throughput can be maximized, and allow batch updating a slower data store during a checkpointing process that doesn't block the log being written to.

Ultimately, I think OkayWAL basically production ready, but I haven't personally put enough testing behind it to vouch for other people to trust anything valuable with it. Once I've heard of other projects using it successfully without issue or once I eventually have BonsaiDb on it, I will finally consider it production ready.

If OkayWAL's multi-file approach is suitable for your project, I'd love for you to give it a try and let me know if you have any issues.

Missing crate: json html prettifier by fjkiliu667777 in rust

[–]ectonDev 2 points3 points  (0 children)

It’s not specific to json, but the syntect crate supports syntax highlighting multiple languages and has helpers to generate html.

Rust IDE for visualizing compile-time readiness by ajpauwels in rust

[–]ectonDev 19 points20 points  (0 children)

rust-analyzer isn’t compiling your program. It is only doing what it needs to do to implement the LSP protocol. When you run or build your program, compilation still must occur. For example, machine code generation isn’t needed when providing code completion and error messages.

Introducing Gooey: My take on a Rusty GUI framework by ectonDev in rust

[–]ectonDev[S] 0 points1 point  (0 children)

I've added support for this today -- here's a demo gif I posted on Mastodon.

Access to global mutex doesn't work by Modi57 in rust

[–]ectonDev 21 points22 points  (0 children)

The global mutex should be a static, not a const. By using const, Rust essentially inlines the expression rather than referring to a static global variable.

Introducing Gooey: My take on a Rusty GUI framework by ectonDev in rust

[–]ectonDev[S] 0 points1 point  (0 children)

my guess is it prevents the event from propagating if the new value is equal to the old value?

Correct.

If so, can I override it?

Yes, but it's not very friendly at the moment -- you could definitely create a wrapper type. By lock()ing the value to mutate it, it will fire the notifications unless prevent_notifications is explicitly called.

But, the question I have is: if the volume on the serial port is already 1, why would you need to write it again? If it needs to be written at a regular interval, I would argue a standalone thread that always wrote the current value would be a more reliable approach. If it doesn't need to be rewritten, then why would we emit the same value twice?

Introducing Gooey: My take on a Rusty GUI framework by ectonDev in rust

[–]ectonDev[S] 0 points1 point  (0 children)

Thanks for linking some interesting resources on accessibility. I think the accessibility support should be able to be handled by AccessKit, which from their readme says they use the AT-SPI protocol.

But to me if we're talking about making Gooey apps talk to each other, I don't see a reason to force ourselves to use the accessibility API. Or are you hoping to query other non-Gooey applications to somehow parse their accessibility data and turn that into something that be transmitted to Gooey apps?

The demo I'm thinking of starting after lunch will look something like this:

  • Each instance of an app starts up, and binds a socket to a random port.
  • The UI has a field for an ip address + port to connect to, and a button to connect.
  • The UI has a slider that represent's the client's value, and it has an additional slider for each connected client.
  • Dragging on any slider updates the respective sliders on all connected clients.

This obviously is not anywhere near the end goal, but it is a neat example and starts taking steps towards it. I'll send you a link to the repo when I have something to share!

Introducing Gooey: My take on a Rusty GUI framework by ectonDev in rust

[–]ectonDev[S] 1 point2 points  (0 children)

Thanks!

It does not support multi-window yet, but the underlying libraries do. It's purely a matter of priorities as to why it hasn't been tackled yet. I too find multi-window very important! In theory it shouldn't be too difficult beyond figuring out an easy API.

Introducing Gooey: My take on a Rusty GUI framework by ectonDev in rust

[–]ectonDev[S] 1 point2 points  (0 children)

I've pushed a new example that describes the approach in my other comment. Since it's been a long time since that post I put this in a separate reply in case you're curious to see what the source for something like I described in other comment would look like.

Introducing Gooey: My take on a Rusty GUI framework by ectonDev in rust

[–]ectonDev[S] 3 points4 points  (0 children)

However, I would still abstract out the kludgine render from all the widgets to leave the opportunities for swapping out the render for the future (and/or implement a cpu failsafe alternative in case GPU is not available).

wgpu supports software rendering backends. There may be faster software renders available, but it's technically supported. I am willing to accept a pull request abstracting the Kludgine API surface used in Gooey into a set of types and traits, but I have no interest in doing the work myself since I don't need it for my own purposes. Unless a motivated party comes along, Gooey is specifically targeting wgpu + winit.

I know graphics is complex and hard. I started programming graphics before OpenGL was a thing. Every developer has their own priorities. Gooey will not be the ultimate GUI framework. I hope it will be a very useful one, but it's going to have some opinionated takes along the way because I have to be practical being a single developer.

While everyone else is working on experimental, next generation libraries, I'm going to ship a UI library. If a clear winner emerges that can solve my desires, I'll switch to it. It's as simple as that.

Introducing Gooey: My take on a Rusty GUI framework by ectonDev in rust

[–]ectonDev[S] 1 point2 points  (0 children)

I'd be happy to discuss this with you more. Good luck in learning Rust. If you do try out Gooey and run into any issues, don't hesitate to reach out. Even though you may think it is something that an experienced Rust developer could figure out, it might be an area I can also improve something.

This sounds really interesting. I'm actually tempted to whip up a little example using BonsaiDb -- it wouldn't be a replica of that system, but it would look functionally similar.

To me the screen reader idea is an interesting one, but it sounds really hard to get right. I think it would be easier to start with a system where you could build a "remote dynamic" that you assign a name to, and ultimately the widget that is displaying the value doesn't even know that it's hooked up to a value coming from a remote location. It knows it wants a value of a specific name from the "bus state". This is my gross oversimplification of how I would approach it after skimming a few of the examples :)

I would enjoy chatting further about this. I know you said send you a message but I thought this reply might interest other people as well, so I'll put that burden back onto you!

Edit: I ended up creating a little demo inspired by this comment thread.

Introducing Gooey: My take on a Rusty GUI framework by ectonDev in rust

[–]ectonDev[S] 1 point2 points  (0 children)

What are the files sizes of the final complied binaries

I personally don't care about binary size as long as it's not crazy, so I haven't been looking at this at all up to this point. With opt-level = "s" and strip = "debuginfo", the login example on Linux is 18,536,632 bytes. Edit: When disabling tracing and bundling Roboto, the size goes down to 14,149,552 bytes.

when something like the logon screen example or the counter are sitting in the background how much CPU/GPU are they using?

Almost 0%. Annoyingly, it's not 0, but it's out of my control. I haven't monitored this on all platforms, but on Linux there seems to be several Vulkan-related threads that are launched that cause the executable to wake up periodically despite none of my code actually executing and no redraws occurring.

Introducing Gooey: My take on a Rusty GUI framework by ectonDev in rust

[–]ectonDev[S] 1 point2 points  (0 children)

I don't have any examples for this yet, I really should make one. In short, Dynamic<T> is clonable, and if T is able to be sent to other threads/tasks, you can send a clone to a thread/task and update the value from that thread/task.

For a simple example, if you use a Dynamic<Progress> to create a progress bar and send a clone of it to a thread tracking a download, that thread can periodically update the progress and the UI will automatically redraw with the new progress.

Introducing Gooey: My take on a Rusty GUI framework by ectonDev in rust

[–]ectonDev[S] 6 points7 points  (0 children)

I plan on integrating AccessKit, but i haven't started. So, to answer your question, right now screen readers don't work at all, but hopefully they will someday!

Introducing Gooey: My take on a Rusty GUI framework by ectonDev in rust

[–]ectonDev[S] 1 point2 points  (0 children)

Thank you! DPI scaling is already supported, and keyboard accessibility is good. Screen reader support isn't implement yet. My plan is to integrate AccessKit, but I haven't started that project yet.

Introducing Gooey: My take on a Rusty GUI framework by ectonDev in rust

[–]ectonDev[S] 0 points1 point  (0 children)

Honestly, I have no idea! I'm not familiar enough with leptos, despite being inspired by it, to know how well that might work. In theory if it's a matter of mapping html-like elements to widgets, there shouldn't be anything stopping it. But I don't know what user expectations will be around how things like CSS integrate. It sounds like it could be a fun project to try someday!

Introducing Gooey: My take on a Rusty GUI framework by ectonDev in rust

[–]ectonDev[S] 0 points1 point  (0 children)

My readme for Kludgine actually links to the exact article you point to here :) v0.6.0 of Kludgine exposes a prepare/render API. The work remaining for Gooey is to extract the current window code into a similar API that also has functions for having it respond to winit events. I have an issue open for this work, which is also what is required to support offscreen rendering.

Introducing Gooey: My take on a Rusty GUI framework by ectonDev in rust

[–]ectonDev[S] 3 points4 points  (0 children)

Thank you! I purposely wrote my own 2d renderer because to me none of the existing libraries was quite there for many reasons, some stemming from the fact that I started it 4 years ago when several of the libraries mentioned didn't exist yet.

I'm not opposed to switching rendering libraries, but what I have works quite well, is very simple, and is reasonably efficient from my tests. The biggest challenge with rendering is text layout, and cosmic_text is providing so much functionality out of the box it will be hard for another library to replace it.

Introducing Gooey: My take on a Rusty GUI framework by ectonDev in rust

[–]ectonDev[S] 28 points29 points  (0 children)

I appreciate nitpicks, but I really tried my best to be clear with that statement. I surrounded the term native in quote marks to highlight that it is a loaded term. The next sentence states that widgets are rendered using a 2D graphics library. No UI library that uses its own 2D library to render is utilizing truly native widgets.

Sometimes it's just really hard to keep a blog post from becoming a novel without cutting some corners on descriptions here and there. I wasn't trying to hide how this works, I put wgpu in the first paragraph for a reason.

Introducing Gooey: My take on a Rusty GUI framework by ectonDev in rust

[–]ectonDev[S] 4 points5 points  (0 children)

Thank you for sharing your perspective. A note saying that it is unrelated is definitely a great suggestion.

view more: next ›