Replies: 2 comments 5 replies
|
Okay, my review so far: First of all, I am impressed. Especially by your windowing. I know I'm nobody special, and my opinion shouldn't matter to you anyways, but, nevertheless, I wanted to say: This is really good. I tend to use as few resources that I didn't make myself as possible, so, the frameworks that I do use I get very well acquainted with. It is not easy to convince a person to start over with all of their experience in one framework for another, potentially better framework, no matter how good it is. But I think what you are working on here is really really important. I've made ICED work for me, but it's without a doubt one of the more difficult frameworks to learn. And it's a hard sell, you have to learn something that's deliberately not meant to be easy. Not that they TRY to make it hard, but they state clearly in their own docs to basically beat it if you're new to Rust: they don't have time for you. Which is fair, to be able to do what ICED does, they lean on all of the most advanced rust capabilities for their framework. Which makes it really strong in ways I have never experienced before, and is what made me fall in love with Rust and ICED all at once. There's beauty in a really complicated thing that resolves to something quite simple, as I feel are what make Rust and ICED special, especially specific parts like the cosmic-text glyph rasterizing buffer - that one blew my mind when I took it apart during the design of a text editor I made (which I actually use every day, it is my primary text editor now). My point being, ICED is a great idea - conceptually, it is beautiful and a wonderful showcase of why to choose Rust if you are really into programming and computer science. But it's not gonna work, it's too hard to learn, and worse - it's not perfect even when you do. Ply reminds me of ICED in spirit - in its elegance and unusually sensibility. When I read about it, I thought, "Oh, of course. That's the way it should be." and it's clear how much time went into considering everything that matters for a GUI framework. The reason I'm interested in Ply is that I feel like it could solve the biggest problem (imo) that Rust has at the moment. I recently met with an old friend of mine, and we caught up, and talked about computer science and programming etc, he just graduated college and got a bachelors, major comp sci and minor in math, so we had some nerdy things to say ;D We were talking about what languages and frameworks we use for various things, and when I mentioned that I used Rust for just about everything these days, his first question was, "Is Rust actually usable for GUIs now?" I think ICED is just fine, and I can work with it easily enough now, but, it's not an unfair question. I'm not sure ICED is ever gonna be a convincing sell to answer it with either. Ply though? Ply really could be. It could be how Rust becomes considered a viable choice for GUIs finally. That's why I've decided to give it my full attention. Because I want more Rust in the world. Which means we need to have a good GUI framework. Good is hard to define, but I feel like Ply speaks for itself. Good is definitely what Ply is. It make sense, it doesn't suck, and its learning curve is reasonable. I don't think you can really ever say a GUI framework is easy to learn - not if it's powerful enough to really do things with. But the balance is well struck with Ply. It's no more difficult or weird than it needs to be. I hope you feel proud of this, you have earned it. I'll do what I can to push Ply forward, I think it's worth my time. Recently, I had an App Store submission get rejected due to a winit bug: I fixed the bug in winit and submitted a PR... So naturally, the first thing I did after building vcode* was go hunting for the same kind of flagged private calls in a Ply build. I diffed the whole symbol table against the public macOS SDK and came up with zero private CGS calls, fantastic. But the reason I am so impressed is because miniquad does its own minimal windowing in AppKit and metal, so it never will call for the CGS window-server APIs that get rejected. Now THAT is how you do it! I used Ply for the GUI of * A 3D printer tool - It is a Here is what vcode looks like: 
Oh, and ignore the preview image, it's not entirely accurate, here is what the resulting gcode actually looks like in bambu studio: 
It may not look like it's anything special. But the thing is, unlike if you try to generate the gcode for a PCB stencil made from an STL in bambu, this one will actually look identical to what you see in bambu because it doesn't make a mess at every pad with a retraction. it makes as few retractions as possible, and never anywhere near the pads. It works great. I'll upload a photo of the actual print too. Here's the scan from my HP Envy printer, which really doesn't do the DFN footprint justice. 
And here it is pressed against the text of this comment so you can see the light through the tiniest pads are really there ;D 
I'm thrilled with how Sorry, I didn't mean to make this post entirely about my project lol. But I reckon there's no better way to showcase a GUI framework than by showcasing a project made with said framework, so ;D Oh, I also took the opportunity to try the wasm - it looks GREAT. So I will also link the wasm version for people to try out which I've hosted on my webserver. Oh, instructions: in KiCad, go to Fabrication Outputs➞Gerbers then change the format to svg. All you need is the paste layer. Drag it onto the page, that's pretty much it!
|
|
@pszsh Sorry for the late reply, I am coming back from my senior trip to Berlin. Ply is being a little neglected recently, I have a nice job and a boyfriend now, so life is quite good but also a little busy with drivers license, the game project, finals, other projects on the side and then uni coming up too. Ply is of course open-source and basically-public-domain and will be as such forever, that is my mission. So there are issues for others to work on and you can contribute too, in fact you already did: Your comment on padding made me realize that a text input with non-floating children makes no sense, and it shouldn't be a regular element but making I have been working on IME #75 for quite a while now that's why Ply is stuck currently basically stuck inbetween a huge under-the-hood change. So that currently has the highest priority to me and I don't even have a Mac to test everything on. But again, things have been busy and I have other urgent deadlines to tend to and things I've been pushing around. I love that someone is motivated to do something with my usable engine, although still in its infancy. And your project seems awesome. By the way, I checked out the repository for vcode and noticed your custom license note. I totally get what you are trying to do with keeping corporations away, but without explicit legal text, even hobbyists and individuals can't legally copy or use your software. Also, because there is no standard disclaimer of liability, you are holding yourself responsible for warranties or damages. If your goal is to let individuals use it freely while keeping corporations out, you might want to consider using something like my Ply Noncommercial License 1 (https://plyx.iz.rs/noncommercial-license/1/). It's still a great app nonetheless. You seem to really be enjoying Ply, would you say you are enjoying it enough for me to set up sponsoring? The problem with me is that with so much going on I'd feel like I'm disappointing any donators. |
|
Hmm. I have no idea. When it comes to marketing and business, I am probably the worst choice of person to ask. As you noted yourself, I don't know how licenses work ;D I didn't even know open source code could get sponsorships. I am not a busy person. I have a bf, but we don't live super close, and I don't drive, and, well, you pretty much covered the general struggles of life well. I don't do as much as you do, life-wise. Well, there are a few things with Ply, I have no idea with the sponsor thing, but, I've been trying to decide whether or not to fix the things with Ply. The issue is, and this issue I am more familiar with, this is deeply yours, you've put a lot of heart into it. That's not a bad thing, but it does mean it might be hard to let others work on it too. Maybe not, this is a very personal sort of thing and I'm no good at guessing. And yeah, I could just make my own fork and work on it myself and it wouldn't matter if you liked it or not. But, I could just make my own GUI engine too, and it's a compelling thought, as I've done a lot of compositor work with my project Acord. But it would be genuinely nice to work on something with somebody else for once. I'm all about doing my own thing, and I'm good at it. But I respect you, you've got ambition and clearly intelligence, and your work is good. So I guess I am asking you, should I work on Ply with you? I just don't wanna do work that doesn't end up getting used, if I'm the only one who's going to use it, I've got a whole gitea filled with work I wrote that nobody cares about already, so, I'll just keep working on that stuff. Sorry, I think I got a bit defensive there. I don't mean to insult you or imply I doubt you're mature enough to handle someone else working on your project. You seem fine; I'm merely self-projecting. But these are my honest fears, regardless of who you are. I just don't have it in me to be any more disappointed in myself. So I have trouble putting myself out there. Regardless, I wish you luck with Uni, and know that I admire the sort of person who goes, "fuck it," "...I'm going to work really hard at something extremely technical and difficult, because I'm annoyed by a problem and nobody else seems to see it. Gonna have to do it myself then." There are worse ways to live life.
|
|
https://else-if.org/entries/shelf-life Well, you inspired me. I have this blog I never post on, but I did today. Thanks. |
|
This is not my personal sort of thing, and it never was made that way. I have no pains in handing it over if a great opportunity arises. You said you wanted to "work together," but open source is usually more of working on a project independently, and less of programming together and more about accepting contributions. That's what makes it work so well. You can make your contributions in the form of PRs and I'll give you feedback on them and then they'll go and resolve issues. You can read about the exact process in CONTRIBUTING.md. So what I'm saying is yes you should work on Ply if you want, probably not a good idea to work "with me" right now based on how much shit I have to do. I don't know what you mean by I would be immature, people often tell me I'm too mature. I can handle other people working on my stuff. I've already accepted PRs by others. Good luck to you too. I read that blog seems kinda.. ambiguous but you do you. |
|
@pszsh Oh forgot to say: You can DM me on discord (also @TheRedDeveloper) by the way, other people from Ply have already done that. |
|
@pszsh Are you good? How's it looking? I have more time now. |
Uh oh!
There was an error while loading. Please reload this page.
I love Rust and ICED. I do complex GUI stuff. I've been working on a 3D Magneto-Statics, Electrical Circuit, and Mechanical Motion Multi-Physics engine called Sitter over the last few months. It's a BEM + FMM-LU fast direct solver under the hood with an emphasis on being able to run very complicated simulations you could not begin to script in other engines.
I'm not gonna be switching GUI backends for that project, but to give you an idea of what kind of work I do.
I hand't been looking for an ICED alternative, I love ICED, I've grown used to its shortcomings. But when I read your blog post, I was moved. Compelled to agree with you.
Over the next few weeks, I'll share the work I do in Ply.
Thanks for making this, I've got high hopes for this being the start of a really good thing.
If you're looking for specific feedback on any one particular area, please let me know and I'll be sure to explore it.
All reactions